idnits 2.17.1 draft-bryan-sipping-p2p-02.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2395. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2372. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2379. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2385. ** 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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 17 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 590 has weird spacing: '...ion tag indic...' == Line 1433 has weird spacing: '...llowing this ...' == Line 1435 has weird spacing: '... header with ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: After a node has located an initial bootstrap node, the process of joining the overlay is started by constructing a REGISTER message and sending it to the bootstrap node. Third party registration MAY NOT be used for registering nodes into the overlay, and attempts to do so MUST be rejected by the node receiving such a request. (although third party registrations are used for other purposes, as described below) The node MUST construct a SIP REGISTER message following the instructions in RFC3261, section 10, with the exceptions/rules outlined below. -- 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 (March 5, 2006) is 6598 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '3') ** Downref: Normative reference to an Informational RFC: RFC 3174 (ref. '4') Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING WG D. Bryan 3 Internet-Draft B. Lowekamp 4 Expires: September 6, 2006 College of William and Mary 5 C. Jennings 6 Cisco Systems 7 March 5, 2006 9 A P2P Approach to SIP Registration and Resource Location 10 draft-bryan-sipping-p2p-02 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on September 6, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This document outlines the motivation and requirements for a Peer-to- 44 Peer (P2P) based approach for SIP registration and resource discovery 45 using distributed hash tables, and presents the architectural design 46 for such a system. This design removes the need for central servers 47 from SIP, while offering full backward compatibility with SIP, 48 allowing reuse of existing clients, and allowing P2P enabled nodes to 49 communicate with conventional SIP entities. A basic introduction to 50 the concepts of P2P is presented, backward compatibility issues 51 addressed, and the security considerations are considered. 53 This is very early work to explore the characteristics that a P2P 54 system might have. It is less secure in many ways than the 55 traditional approach to SIP but has certain other interesting 56 characteristics that may make it desirable in some situations. This 57 work is being discussed on the p2psip@cs.columbia.edu mailing list. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.1 Peer-to-Peer Fundamentals . . . . . . . . . . . . . . . . 5 65 3.2 Distributed Hash Table (DHT) Systems . . . . . . . . . . . 6 66 3.3 Chord . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.4 Issues for P2P Systems . . . . . . . . . . . . . . . . . . 8 68 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 4.1 Node Functions and Behavior . . . . . . . . . . . . . . . 9 70 4.2 P2P Overlay Structure . . . . . . . . . . . . . . . . . . 9 71 5. General Architecture . . . . . . . . . . . . . . . . . . . . 11 72 5.1 Use of SIP Messages . . . . . . . . . . . . . . . . . . . 11 73 5.2 Pluggable Overlay Algorithms . . . . . . . . . . . . . . . 12 74 6. Message Routing . . . . . . . . . . . . . . . . . . . . . . 12 75 6.1 Node Registration . . . . . . . . . . . . . . . . . . . . 12 76 6.2 Resource Registration . . . . . . . . . . . . . . . . . . 13 77 6.3 Session Establishment . . . . . . . . . . . . . . . . . . 13 78 7. Message Syntax . . . . . . . . . . . . . . . . . . . . . . . 14 79 7.1 Option Tags . . . . . . . . . . . . . . . . . . . . . . . 14 80 7.2 Hash Algorithms and Identifiers . . . . . . . . . . . . . 14 81 7.2.1 Node-IDs . . . . . . . . . . . . . . . . . . . . . . . 14 82 7.2.2 Resource-IDs and the replica URI parameter . . . . . . 15 83 7.3 P2P SIP URIs . . . . . . . . . . . . . . . . . . . . . . . 15 84 7.3.1 Node URIs and the user=node URI Parameter . . . . . . 15 85 7.3.2 Resource URIs and the resource-ID URI Parameter . . . 16 86 7.4 The DHT-NodeID Header and Overlay Parameters . . . . . . . 17 87 7.4.1 Hash Algorithms and the algorithm Parameter . . . . . 17 88 7.4.2 Overlay Names and the overlay Parameter . . . . . . . 18 89 7.4.3 DHT Algorithms and the dht Parameter . . . . . . . . . 18 90 7.4.4 NodeID Expires header parameter . . . . . . . . . . . 19 91 7.5 The DHT-Link Header . . . . . . . . . . . . . . . . . . . 19 92 7.5.1 The linktype and depth values . . . . . . . . . . . . 19 93 7.5.2 Expires Processing . . . . . . . . . . . . . . . . . . 20 94 8. Node/DHT Operations . . . . . . . . . . . . . . . . . . . . 20 95 8.1 Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 20 96 8.2 Node Registration . . . . . . . . . . . . . . . . . . . . 21 97 8.2.1 Constructing a Node Registration . . . . . . . . . . . 21 98 8.2.2 Processing the Node Registration . . . . . . . . . . . 22 99 8.3 Node Query . . . . . . . . . . . . . . . . . . . . . . . . 25 100 8.3.1 Constructing a Node Query Message . . . . . . . . . . 25 101 8.3.2 Processing Node Query Message . . . . . . . . . . . . 26 102 8.4 Populating the Joining Node's Finger Table . . . . . . . . 27 103 8.5 Transfering User Registrations . . . . . . . . . . . . . . 27 104 8.6 Nodes Leaving the Overlay Gracefully . . . . . . . . . . . 27 105 8.7 Handling Failed Requests . . . . . . . . . . . . . . . . . 27 106 9. Chord Overlay Algorithm . . . . . . . . . . . . . . . . . . 28 107 9.1 DHT Name Parameter . . . . . . . . . . . . . . . . . . . . 28 108 9.2 Starting a New Overlay . . . . . . . . . . . . . . . . . . 28 109 9.3 Finger Table . . . . . . . . . . . . . . . . . . . . . . . 28 110 9.4 Node Admission . . . . . . . . . . . . . . . . . . . . . . 29 111 9.5 Chord Query Processing . . . . . . . . . . . . . . . . . . 30 112 9.6 Chord Finger Table . . . . . . . . . . . . . . . . . . . . 30 113 9.7 Chord Graceful Leaving . . . . . . . . . . . . . . . . . . 30 114 9.8 Chord Periodic Stabilization . . . . . . . . . . . . . . . 30 115 9.9 Node Failure . . . . . . . . . . . . . . . . . . . . . . . 31 116 9.10 Resource Replicas . . . . . . . . . . . . . . . . . . . 31 117 10. Resource Operations . . . . . . . . . . . . . . . . . . . . 31 118 10.1 Resource Registrations . . . . . . . . . . . . . . . . . 31 119 10.2 Refreshing Resource Registrations . . . . . . . . . . . 32 120 10.3 Removing Resource Registrations . . . . . . . . . . . . 32 121 10.4 Querying Resource Registrations . . . . . . . . . . . . 33 122 10.5 Session Establishment . . . . . . . . . . . . . . . . . 33 123 10.6 Presence . . . . . . . . . . . . . . . . . . . . . . . . 33 124 10.7 Offline Storage . . . . . . . . . . . . . . . . . . . . 34 125 10.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . 34 126 10.8.1 Example of a Node Registration . . . . . . . . . . . 37 127 10.8.2 Example of a User Registration . . . . . . . . . . . 39 128 10.8.3 Example of a Session Establishment . . . . . . . . . 42 129 10.8.4 Example of a Node Leaving the System . . . . . . . . 44 130 10.8.5 Example of a Successful User Search . . . . . . . . 44 131 10.8.6 Example of an Unsucessful User Search . . . . . . . 44 132 10.9 Security Considerations . . . . . . . . . . . . . . . . 44 133 10.9.1 Threat Model . . . . . . . . . . . . . . . . . . . . 44 134 10.9.2 Protecting the Namespace . . . . . . . . . . . . . . 45 135 10.10 Protecting the Routing . . . . . . . . . . . . . . . . . 45 136 10.11 Protecting the Signaling . . . . . . . . . . . . . . . . 46 137 10.12 Protecting the Media . . . . . . . . . . . . . . . . . . 46 138 10.13 Replay Attacks . . . . . . . . . . . . . . . . . . . . . 46 139 10.14 Cut and Paste Attacks . . . . . . . . . . . . . . . . . 46 140 10.15 Identity Theft Attacks . . . . . . . . . . . . . . . . . 47 141 10.16 Limitations of the Security . . . . . . . . . . . . . . 47 142 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 47 143 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 48 144 13. Implementations . . . . . . . . . . . . . . . . . . . . . . 48 145 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 48 146 15. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 48 147 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 148 16.1 Normative References . . . . . . . . . . . . . . . . . . 50 149 16.2 Informative References . . . . . . . . . . . . . . . . . 51 150 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 51 151 Intellectual Property and Copyright Statements . . . . . . . 53 153 1. Introduction 155 As SIP [2] and SIMPLE based Voice over IP (VoIP) Instant Messaging 156 (IM) systems have increased in popularity, situations have emerged 157 where centralized servers are either inconvenient or undesirable. 158 For example, a group of users wishing to communicate between each 159 other, but using machines that are not consistently connected to the 160 network are often forced to use a central server that is outside the 161 control of the group. Similarly, groups wishing to establish 162 ephemeral networks for use in meetings, conferences, or classes often 163 do not wish to configure a centralized server. Organizations may 164 also want to allow their members to communicate with each other 165 without traffic flowing to third parties, but may not have the staff 166 or equipment to maintain a server. 168 Peer-to-Peer (P2P) computing has emerged as a mechanism for 169 completely decentralized, server-free implementations of various 170 applications. This draft presents a SIP based system that uses P2P 171 mechanisms to remove the need for central servers in SIP and SIMPLE 172 based communications systems. This draft derives from work done on 173 the SoSIMPLE [6] P2P SIP project. 175 2. Terminology 177 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 178 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 179 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 180 described in RFC2119 [1]. 182 Terminology defined in RFC 3261 [2] is used without definition. 184 Terms relating to P2P or new to this document are defined when used 185 and are also defined in the Definitions (Section 15) section of this 186 document. 188 In many places in this document, 10 hexadecimal digit values are used 189 in examples as SHA-1 hashes. In reality, these hashes are 40 digit. 190 They are shortened in this document for clarity only. 192 3. Background 194 3.1 Peer-to-Peer Fundamentals 196 The fundamental principle behind Peer-to-Peer (P2P) Architectures is 197 that each and every member of the network has equal importance in the 198 transactions that take place on the network, and that these nodes 199 communicate with each other to accomplish tasks. Contrast this with 200 the more traditional Client-Server Architecture in which a large 201 number of clients communicate only with a small number of central 202 servers responsible for performing tasks. Each entity that 203 participates in a P2P system, usually called a node or peer, provides 204 server-like functionality and services as well as being a client 205 within the system. In this way, the services or resources that would 206 be provided by a centralized entity are instead available from the 207 nodes of the system. Note that a particular node may or may not 208 provide a particular service, but some node does, ensuring that 209 collectively the nodes can provide that particular service. The 210 logical network connecting the peers to one another is referred to as 211 an overlay network or overlay, as it is in some sense a new, small 212 sub-network at a higher logical level than lower level network 213 connections. 215 Some P2P networks have certain nodes that provide a higher level of 216 functionality. Often these nodes form a P2P network and connect to 217 each other, then serve a number of true clients. These more powerful 218 nodes are often referred to as super-nodes. This approach is often 219 used to traverse NATs, with nodes residing outside of the NATs 220 serving as super-nodes, and to allow nodes with more bandwidth to 221 serve as concentrators for information. 223 Many P2P systems further assume that nodes are ephemeral in nature. 224 A node may join or leave the overlay at any time. The design of 225 algorithms for P2P architectures take this into account. Information 226 is often replicated, and the topology of the overlay can be quickly 227 adapted as nodes enter and leave. 229 Likely the best known (or perhaps most infamous) use of P2P 230 technology is file sharing. In these systems, individual users store 231 files, and join the overlay network by connecting to a small number 232 of nodes already in the overlay. When the user wishes to locate a 233 particular file they don't have, they contact these neighbors. 234 Several alternatives exist for this query. In early systems, a node 235 searching for a file would ask their neighbors if they had the file. 236 If one of these nodes had the file, it would respond telling the 237 requester they had the file. If not, they passed the request on to 238 their neighbors. The search was limited to a particular depth using 239 a Time to Live (TTL) mechanism, but since nodes had no idea what 240 other nodes were doing, queries continued until the TTL was reached, 241 even if some node had already replied. This approach, often called 242 the flood search approach, proved inefficient. 244 3.2 Distributed Hash Table (DHT) Systems 246 To improve the efficiency, most newer systems locate resources using 247 a Distributed Hash Table, or DHT. Nodes are organized using a 248 Distributed Hash Table (DHT) structure. In such a system, every 249 resource has a Resource-ID, which is obtained by hashing some keyword 250 or value that uniquely identifies the resource. Resources can be 251 thought of as being stored in a hash table at the entry corresponding 252 to their Resource-ID. The nodes that make up the overlay network are 253 also assigned an ID, called a Node-ID, which maps to the same hash 254 space as the Resource-IDs. A node is responsible for storing all 255 resources that have Resource-IDs near the node's Node-ID. The hash 256 space is divided up so that all of the hash space is always the 257 responsibility of some particular node, although as nodes enter and 258 leave the system a particular node's area may change. Messages are 259 exchanged between the nodes in the DHT as the nodes enter and leave 260 to preserve the structure of the DHT and exchange stored entries. 261 Various DHT implementations may visualize the hash space as a grid, 262 circle, or line. 264 Nodes keep information about the location of other nodes in the hash 265 space and in general know about most nodes nearby in the hash space, 266 and progressively fewer more distant nodes. When a user wishes to 267 search, they consult the list of node they are aware of and contact 268 the node with the Node-ID nearest the desired Resource-ID. If that 269 node does not know how to find the resource, it either suggests the 270 closest node it knows about, or asks that node itself and returns the 271 result. In this fashion, the request eventually reaches the node 272 responsible for the resource, which then replies to the requester. 274 3.3 Chord 276 The Chord [7] system is one particular popular DHT algorithm. Chord 277 uses a ring-type structure for the nodes in the overlay. In this 278 structure, a node with a hash of 0 would be located adjacent to a 279 node that hashes to the highest possible hash value. If the hash has 280 2^n bits in the range, each node will keep a "finger table" of 281 pointers to at most n other nodes. The ith entry in the finger table 282 contains a pointer to a node at least 2^(i) units away in the hash 283 space. These highest finger table entry thus point to a range 1/2 of 284 the way across the hash space, the next highest 1/4, the next 1/8, 285 and the smallest entry points to a range only 1 away in the hash 286 space. The set of nodes pointed to by these finger table entries are 287 referred to as the neighbors of the node, since they can be reached 288 directly. 290 Searching in Chord is accomplished by sending messages to the node in 291 the finger table that is closest to the destination address. That 292 neighbor will have finer resolution detail about the area and can 293 route the message closer to the desired node. This process is 294 repeated until the message reaches the node responsible for the 295 destination, which can determine if the resource searched for is 296 present. 298 This draft uses an algorithm derived from the Chord algorithm to 299 communicate between nodes in the DHT. Specifically, the algorithm 300 detailed in Chord Overlay Algorithm (Section 9) has been adapted to 301 use iterative searches rather than recursive searches in order to 302 minimize the potential for Denial-of-Service (DOS) attacks. Chord is 303 selected because of its simplicity, convergence properties, and 304 general familiarity within the P2P community. We anticipate that 305 other IETF working groups will be standardizing other DHT protocols 306 and expect that the protocol and principles described in this draft 307 will easily transfer to an alternative DHT algorithm. We have 308 included specification of the specific DHT algorithm being used to 309 support such transitions. 311 3.4 Issues for P2P Systems 313 All P2P systems need to solve the problem of locating some initial 314 node in the overlay, often called a bootstrap node, in order to join. 315 Some approaches taken to solving this problem include using some set 316 of fixed nodes, requiring that a node be located using an offline 317 mechanism, or using a broadcast/multicast mechanism. 319 P2P architectures offer several advantages over centralized 320 architectures. P2P systems distribute resources across multiple 321 machines, greatly reducing the potential of failure due to a single 322 node failing. This results in increased robustness, as well as some 323 measure of protection from Denial-of-Service (DOS) attacks. P2P 324 systems also have the advantage of scaling more easily as the number 325 of nodes increases, since each new node offers additional server-like 326 functionality when it joins. P2P systems have their own class of 327 problems, however. In particular, malicious nodes can provide 328 incorrect information, possibly denying access to resource in the 329 system. Additionally, users can sometimes create many nodes in the 330 system, possibly using this as a mechanism for hijacking the system. 331 These type of attack is often referred to as a Sybil [8] attack. 333 When referring to P2P systems in this document, we are referring to 334 what are called true P2P systems in the literature. Some systems, 335 such as the original Napster system, as well as many existing SIP 336 deployments (which are occasionally referred to as P2P), are more 337 properly referred to as hybrid systems. In hybrid systems, nodes 338 communicate with each other to exchange information, but resource 339 location is still handled with a centralized server. Our goal in 340 this document is a system that requires no central server of any 341 type. 343 4. Overview 345 In this section we provide an overview of how P2P SIP works. 347 Protocol details are provided in the remainder of the document. 349 Unlike a conventional SIP architecture, P2P SIP systems require no 350 central servers. In a traditional SIP architecture many UAs connect 351 to a central proxy server. In a P2P SIP network the peers connect 352 directly to a few other peers, forming a virtual overlay network of 353 peers which communicate with each other to provide services in the 354 overlay. The nodes participating in the overlay not only act as 355 traditional SIP UAs, allowing their users to place and receive calls, 356 but, when viewed collectively with the other peers, perform the roles 357 of registrars and proxies in traditional SIP networks. These roles 358 include resource location, maintaining presence information, and call 359 routing. Each participating peer will maintain some fraction of the 360 information that would normally be maintained by the proxy and/or 361 registrar in a conventional SIP network. 363 4.1 Node Functions and Behavior 365 P2P SIP nodes provide many functions, more than any single entity in 366 a traditional SIP architecture. Minimally, a participating peer must 367 be an active member of the overlay and must provide some SIP "server- 368 like" behaviors as well. The code that implements the additional 369 server-like and DHT behavior can be located in several places in the 370 network. The simplest is to have nodes that are endpoints directly 371 joining the overlay as peers. In this case, these nodes provide the 372 basic functionality of any SIP endpoint, but additionally implement 373 the operations described in this document to enable self-organization 374 and provide SIP functionality. 376 The behavior can also be located in an adapter node, which allow one 377 or more non-P2P aware SIP UAs to interact with the P2P overlay 378 network. These adapters perform the additional self-organizing and 379 SIP server-like behavior on behalf of the UA or UAs it supports. In 380 this case, only the adapter node is a peer in the overlay, the UAs 381 are not peers themselves. All interaction with the P2P network is 382 carried out by the adapter node. The adapter essentially acts as a 383 proxy server for the unmodified SIP UAs. The adapter can take the 384 form of a small software shim, or may be code within a traditional 385 RFC 3261 server. 387 In most places in this document, which type of node we are discussing 388 won't affect the discussion. In those cases where it will, we have 389 noted the differences. 391 4.2 P2P Overlay Structure 393 The P2P overlay consists of nodes, which collectively serve as a 394 directory service for locating resources (users, voicemail messages, 395 etc.). Nodes are organized using a Distributed Hash Table (DHT) P2P 396 structure based on Chord. Like Chord, the system uses consistent 397 hashing to a one dimensional namespace, conceptually in the form of a 398 circle. Unlike Chord, all the messages needed to maintain the DHT 399 are implemented as SIP messages. We use many Chord-like terms, which 400 are defined in the section Definitions and Terminology. (Section 15) 402 Each node is assigned a Node-ID that determines the node's location 403 in the DHT ring and the range of resources for which it will store 404 location information. Node-IDs are created by hashing the IP address 405 and port of the node providing service. This creates some security 406 issues. See the Open Issues (Section 11) section of this document 407 for more information. We allow for different algorithms to be used 408 to calculate these hashes, but all members of the overlay MUST use 409 the same algorithm. 411 Every resource has a Resource-ID, obtained by hashing some keyword 412 that identifies the resource. The Resource-IDs map to the same space 413 as the Node-IDs. In the case of users, the unique keyword is the 414 userid and the resource is the registration -- a mapping between the 415 user name and a contact. Resources can be thought of as being stored 416 in the distributed hash table at a location corresponding to their 417 Resource-ID. 419 Like Chord, a resource with Resource-ID k will be stored by the first 420 node with Node-ID equal to or greater (mod the size of the namespace) 421 than k, ensuring that every Resource-ID is associated with some node. 422 As nodes enter and leave, resources may be stored on different nodes, 423 so the information related to them is exchanged as nodes enter and 424 leave. Redundancy is used to protect against loss of information in 425 the event of a node failure. 427 Each node keeps information about how to contact some number of other 428 nodes in the overlay. In terms of the overlay network, these are the 429 neighbors of the node, since they are reachable in one hop. The node 430 keeps track of its immediate predecessor node, as well as one or more 431 successor nodes. The node also keeps a table of information about 432 other neighbors called a finger table, consisting of nodes 433 distributed with exponential spacing around the overlay. 435 Messages are routed by taking advantage of a key property of these 436 finger tables. A node has more detailed, fine grained information 437 about nodes near it than further away, but it knows at least a few 438 more distant nodes. When locating a resource with a particular 439 Resource-ID, the node will send the request to the finger table entry 440 with the Node-ID closest to the desired Resource-ID. Because the 441 node receiving the request has many neighbors with similar Node-IDs, 442 it will presumably know of a node with a Node-ID closer to the 443 Resource-ID, and suggests this node to in response. The request is 444 then resent to this closer node. The process is repeated until the 445 node responsible for the Resource-ID is located, which can then 446 determine if it is storing the information. 448 5. General Architecture 450 5.1 Use of SIP Messages 452 This draft explores one possible protocol that can be used to 453 implement for P2P SIP. Our motivation throughout has been to 454 preserve the semantics of standard SIP messages to the extent 455 possible. All of the messages that are needed to maintain the DHT, 456 as well as those needed to query for information are implemented 457 using SIP messages. Fundamentally, messages are being exchanged for 458 two purposes. The purpose of the first class of messages is to 459 maintain the DHT, such as the messages needed to join or leave the 460 overlay, and to transfer information between nodes. The second type 461 of messages are those used to allow the users of the overlay to 462 communicate. This second type of message is the type most SIP users 463 will be familiar with -- registering users, inviting other users to a 464 session, etc. As the DHT is used as a distributed registrar, the 465 registration and other searches are performed within the DHT. Once 466 the target resource has been located, further communication proceeds 467 directly between the UAs (or designated adapter nodes) as with 468 traditional SIP communications. 470 The messages used to manipulate the DHT are SIP REGISTER messages. 471 RFC 3261, Section 10.2, specifies that REGISTER messages are used to 472 "add, remove, and query bindings." Accordingly, we have selected 473 REGISTER methods to use to add, remove, and query bindings. We use 474 REGISTER both for the bindings of hosts as neighbors in DHT 475 maintanence operations as well as the bindings of resource names to 476 locations that are commonly maintained by SIP registrars. 478 The previous version of this draft utilized INVITE to perform 479 searches within the DHT, with the guiding principle being that the 480 INVITE would be redirected until it reached that actual UA of the 481 desired contact. After further consideration, this use of INVITE 482 raised the problem that it might result in a DHT-based SIP operation 483 being sent to a simpler SIP device unaware of the SIP extensions. By 484 explicitly requiring DHT operations to be performed using REGISTER 485 operations, and the final end-to-end connection made in the 486 traditional SIP manner, we allow P2P-aware agents to deliberately 487 separate their interactions with other P2P-aware nodes from those 488 interactions that require only traditional SIP messages, and can be 489 performed with non-P2P agents. 491 5.2 Pluggable Overlay Algorithms 493 While this draft explores a protocol that was designed with a 494 modification of the Chord algorithm in mind, we have attempted to 495 make the SIP communication general-purpose, such that it can be used 496 to implement a variety of overlay algorithms. Following these 497 intentions, we have separated the overlay-specific algorithms into a 498 Chord Overlay Algorithm (Section 9) section, which describes how the 499 basic P2P SIP operations can be used to implement an iterative Chord 500 algorithm. Our intention and hope is that others will design other 501 overlay algorithms that rely on the same basic operations and are 502 perhaps even optimizations of the basic Chord algorithm so that 503 compatibility can be maintained. Furthermore, as other IETF working 504 groups explore ideas for standardizing P2P algorithms, we hope that 505 the basic SIP messages can remain consistent while only the overlay 506 "module" needs to be redesigned to reflect the new protocols. 508 6. Message Routing 510 When a node sends a message within the DHT, it begins by calculating 511 the target ID it is attempting to locate, which might be its own 512 location in the DHT, obtained by hashing its own IP address, or a 513 user's registration, for which it hashes the user's URI to obtain the 514 appropriate Resource-ID. It then consults its finger table for the 515 closest node it is aware of to the target ID. In the trivial case of 516 initial startup, the application may know only of a single bootstrap 517 node. The message is sent to that node, which performs the requested 518 operation if it is responsible for that ID. If the contacted node is 519 not responsible for the target ID, then the contacted node issues a 520 302 redirect pointing the searching node toward the best match the 521 contacted node has for the target ID. The searching node then 522 contacts the node to which it has been redirected, and the process 523 iterates until the responsible node is located. 525 6.1 Node Registration 527 When a node (the joining node) wishes to join the overlay, it creates 528 its Node-ID and sends a REGISTER message to a bootstrap node already 529 in the overlay, requesting to join. Any node in the DHT may serve as 530 a bootstrap node, although we expect that most UAs will be configured 531 with a small number of well-known nodes. Following the above routing 532 scheme, the bootstrap node looks up the node it knows nearest to the 533 Node-ID of the joining node and responds with 302 redirect to this 534 nearer node. The joining node will repeat this process until it 535 reaches the node currently responsible for the space it will occupy. 536 The joining node then exchanges additional REGISTER messages with 537 this node, called the admitting node, to allow the joining node to 538 learn about other nodes in the overlay (neighbors) and to obtain 539 information about resources the joining node will be responsible for 540 maintaining. Other messages will be exchanged later to maintain the 541 overlay as other nodes enter and leave, as well as to periodically 542 verify the information about the overlay, but once the initial 543 messages are exchanged, a node has joined the overlay. 545 6.2 Resource Registration 547 The node registration does not register the node's user(s) or other 548 resources with the P2P SIP network -- it has only allowed the node to 549 join the overlay. Once a node has joined the overlay, the user that 550 node hosts must be registered with the system. This process is 551 referred to as resource registration. This registration is analogous 552 to the traditional SIP registration, in which a message is sent to 553 the registrar creating a mapping between a SIP URI and a user's 554 contact. The only difference is that since there is no central 555 registrar, some node in the overlay will maintain the registration on 556 the users behalf. 558 Resource registrations are routed similarly to node registrations. 559 The resource's node calculates the resource-ID and contacts the node 560 it is aware of closest to the resource-ID. This search process 561 iterates using 302 redirects until the responsible peer is located. 562 This node then stores the registration for that user and returns a 563 200 response. 565 For redundancy, resources should also be registered at additional 566 nodes within the overlay. These replicas are located by adding a 567 replica number to the resource name and hashing to identify a new 568 resource-ID for each replica. In this way, replicas are located at 569 unrelated points around the DHT, minimizing the risk of an attacker 570 compromising more than one registration for a single resource. 572 6.3 Session Establishment 574 Sessions are established by contacting the UA identified by the 575 registration in the DHT. The first step in establishing a session is 576 locating this node, which is done by searching for a resource in the 577 DHT. The name of the target resource is used to calculate a 578 resource-ID and a REGISTER message with no Contact information (a 579 conventional SIP search) is sent to the closest known node to that 580 resource-ID. The search iterates until the responsible peer is 581 located. The responsible node then returns either a 200 OK with the 582 Contact information for the resource or a 404 Not Found. The session 583 is then initiated directly with the resource's UA. 585 7. Message Syntax 587 7.1 Option Tags 589 We create a new option tag "dht" as described in RFC 3261. This 590 option tag indicates support for DHT based P2P SIP. Nodes MUST 591 include a Require and Supported header with the option tag dht for 592 all messages that are intended to processed in a P2P method or 593 include P2P extensions. Clients supporting P2P and contacting 594 another SIP entity using a non-P2P mechanism for a transaction that 595 may or may later be P2P SHOULD include a Supported header with dht. 596 For a typical session establishment the search within the DHT MUST 597 specify Require dht, whereas the actual contact with the resource's 598 UA SHOULD include a Supported header with dht but SHOULD NOT include 599 a Require header with dht. 601 7.2 Hash Algorithms and Identifiers 603 All IDs used for an overlay must be calculated using the same 604 algorithm. Implementations SHOULD use the SHA-1 algorithm, which 605 produces a 160 bit hash value. The Hash algorithm used is specified 606 in the DHT-NodeID header, described below. An implementation MAY 607 rely on a secret initialization vector, key, or other shared secret 608 to use the identifier as an HMAC, from RFC 2104 [3] such that no node 609 may join the overlay without knowledge of the shared secret. 611 7.2.1 Node-IDs 613 Node-IDs are determined by the algorithm being used. In the case of 614 sha1, <40 hex digit hash>. The Node-ID MUST be formed by taking the 615 IP address of the node, followed by a colon, followed by the port, 616 and hashing this string with the appropriate algorithm. For sha1, 617 the resulting Node-ID looks like 618 a04d371e3f4078a7a8c49bb7a4ea6199fc9d5c77. 620 The string hashed to obtain the NodeID is formally defined below as 621 ipport. 623 ipport = IPV4address ":" port 625 NodeID is formally defined as: 627 NodeID = token 629 When using sha1: 631 NodeID = 40LHEX 633 7.2.2 Resource-IDs and the replica URI parameter 635 No special restrictions, beyond those imposed by RFC 3261, are 636 imposed on the resource URIs in a P2P SIP system. Note that various 637 security schemes, two of which are discussed in Protecting the 638 Namespace (Section 10.9.2) may place restrictions of their own on the 639 user's URIs. 641 For reliability, redundant registrations are made for resources to 642 avoid certain forms of DOS attacks and guard against the loss of 643 information in case of node failure. The primary registration is 644 made using the canonical form of the resource's URI, but all replica 645 registrations are made by attaching a replica URI parameter to the 646 URI, with the value indicating the replica number, counting from 1. 647 The replica parameter MUST NOT be included for the primary 648 registration. The replica URI parameter is of type other-param as 649 defined in RFC 3261. 651 replica-param = "replica=" %x31-39 ; 1-9 653 Resource-IDs MUST be formed by hashing the resource URI after 654 converting it to canonical form. To do that, all URI parameters MUST 655 be removed (including the user-param) except for the replica URI 656 parameter, Any escaped characters MUST be converted to their 657 unescaped form. Formally: 659 ResourceID = token 661 When using sha1: 663 ResourceID = 40LHEX 665 7.3 P2P SIP URIs 667 7.3.1 Node URIs and the user=node URI Parameter 669 A P2P SIP node is represented by constructing a URI with the NodeID 670 as the userinfo portion and the ipport of the node as the hostport 671 portion. Additionally, the URI parameter "user=node" MUST be used. 673 NodeURI = NodeID "@" hostport ";" user-param uri-parameters 675 Formally, the user=node parameter is defined by using the keyword 676 "node" of type token, serving as "other-user" in the definition of 677 user-param from RFC 3261. A node receiving a NodeURI MUST verify the 678 hash before using it to update its neighbors or finger table. 680 For search operations, where an identifier is being searched for, but 681 the host responsible for that identifier is unknown, hostport SHOULD 682 be set to "0.0.0.0". All non-search operations MUST specify a valid 683 hostport. 685 P2P node URIs MUST NOT include the resource-ID URI parameter, as it 686 is intended to define information about resources that are stored in 687 the overlay, not information about the nodes making up the overlay. 688 P2P node URIs used in name-addr SHOULD NOT include any display-name 689 information, and nodes receiving name-addrs for nodes with display- 690 name information MUST ignore the information. 692 Examples (using shortened Node-ID for clarity): 693 The URI for a node using the sha1 hash algorithm, with hashed ID 694 ed57487add matching an IP address 10.6.5.5 used in a To header: 696 To: 698 7.3.2 Resource URIs and the resource-ID URI Parameter 700 Resource URIs are no different for P2P SIP resources than for non-P2P 701 SIP applications. However, because calculating the ResourceID is a 702 significant expense, the optional URI parameter resource- 703 ID= SHOULD be provided. This parameter is a courtesy 704 only and MUST NOT be used when making any changes to the data stored 705 in an overlay without being recalculated, as it may be spoofed or 706 incorrect. The resource-ID URI parameter is of type other-param as 707 defined in RFC 3261. 709 resourceID-param = "resource-ID=" ResourceID 711 P2P user URIs MUST NOT include the user=node URI parameter, because 712 this indicate that the target of the URI is a node. P2P user URIs 713 MAY include other user-parameters such as user=phone. 715 Examples (again using shortened Node-ID for clarity): 716 The URI for a user with username bob@p2psip.org using the sha1 hash 717 algorithm, with hashed Resource-ID 723fedaab1. The optional 718 resource-ID URI parameter is included: 720 sip:bob@p2psip.org;resource-ID=723fedaab1 722 The URI, used in a To header for user Alice White, with username 723 alice@p2psip.org. This example omits the optional resource-ID URI 724 parameter: 726 To: "Alice White" 728 7.4 The DHT-NodeID Header and Overlay Parameters 730 We introduce a new SIP header called the DHT-NodeID header. This 731 header is used to express the Node-ID of the sending node as well as 732 to identify the name and parameters of the overlay. The format of 733 the DHT-NodeID header is as follows: 735 DHT-NodeID = "DHT-NodeID" HCOLON NodeURI SEMI algorithm SEMI 736 dht-param SEMI overlay-param *(SEMI generic-param) 738 Examples: 739 A node with an SHA-1 hashed Node-ID of a04d371e on IP 192.168.1.1. 740 We include the required user=node, algorithm, and overlay as well as 741 the optional expires header parameter. 743 DHT-NodeID: ;algorithm=sha1; 744 overlay=chat;expires=600 746 7.4.1 Hash Algorithms and the algorithm Parameter 748 The hash algorithm used for the overlay is specified as a parameter 749 of the DHT-NodeID header. This parameter MUST appear in the DHT- 750 NodeID header. It MUST be the algorithm used to calculate all NodeID 751 and ResourceID values used in the message. It SHOULD NOT appear in 752 other headers in the message, but if it does it MUST match the value 753 in the DHT-NodeID header. 755 The hash algorithm is specified using the algorithm parameter from 756 RFC3261. The tokens used to identify the algorithm MUST be the same 757 as those used in other SIP documents such as 758 draft-ietf-sip-identity-06. [5] Currently, those consist of 'sha1', 759 indicating SHA-1 as defined in RFC 3174. [4] Implementations SHOULD 760 use the SHA-1 algorithm for all implementations. 762 A node should reject a message with 488 Not Acceptable here if it 763 specifies a different hash algorithm than that used by the overlay in 764 which the node is not participating. An initial contact of a 765 bootstrap node may specify the hash algorithm as the wildcard "*", in 766 which case the joining node indicates its willingness to use whatever 767 hash algorithm the bootstrap node identifies in its response. A node 768 responding to such a request MUST provide a normal 302 forwarding 769 response if all other elements of the message are correct and the 770 routing algorithm indicates such a response is appropriate. If the 771 normal response would be to allow the join with a 200 OK, the 772 receiving node MAY respond with a 302 redirect to itself, in which 773 case the joining node should reissue the message with the proper hash 774 algorithm specification. 776 7.4.2 Overlay Names and the overlay Parameter 778 Each overlay is named using a string, which SHOULD be unique to a 779 particular deployment environment. Nodes will use this value to 780 identify messages in cases where they may belong to multiple overlays 781 simultaneously. These are defined formally simply as a token: 783 overlay-name = "*" / token 785 The overlay-param parameter MUST appear in the DHT-NodeID header. It 786 SHOULD NOT appear in other headers in the message, but if it does it 787 MUST match the value in the DHT-NodeID header. This parameter is 788 defined formally as: 790 overlay-param = "overlay" EQUAL overlay-name 792 A node should reject a message with 488 Not Acceptable here if it 793 specifies an overlay in which the node is not participating. An 794 initial contact of a bootstrap node may specify overlay-name as the 795 wildcard "*", in which case the joining node indicates its 796 willingness to join whatever overlay the bootstrap node identifies in 797 its response. A node responding to such a request MUST provide a 798 normal 302 forwarding response if all other elements of the message 799 are correct and the routing algorithm indicates such a response is 800 appropriate. If the normal response would be to allow the join with 801 a 200 OK, the receiving node MAY respond with a 302 redirect to 802 itself, in which case the joining node should reissue the message 803 with the proper overlay specification. 805 7.4.3 DHT Algorithms and the dht Parameter 807 The routing algorithm used to implement the overlay is specified 808 using a dht-param in the DHT-NodeID header. It SHOULD NOT appear in 809 other headers in the message, but if it does it MUST match the value 810 in the DHT-NodeID header. This parameter is defined formally as: 812 dht-name = token 813 dht-param = "dht" EQUAL dht-name 815 The behavior of a node receiving a message with a dht-param 816 specifying a routing algorithm other than that which it is following 817 is dependent on the routing algorithm. New routing algorithms SHOULD 818 be designed to maintain backward compatibility with previous 819 algorithms where possible. If the routing algorithm specified is 820 incompatible, a 488 Not Acceptable Here response should be returned. 822 7.4.4 NodeID Expires header parameter 824 The DHT-NodeID header MAY include an Expires parameter indicating how 825 long a recipient may keep knowledge of this node in a finger table. 826 If not present, a default of 3600 is assumed. Mobile nodes may wish 827 to specify a shorter interval. 829 7.5 The DHT-Link Header 831 We introduce a new SIP header called the DHT-Link header. The DHT- 832 Link header is used to transfer information about where in the DHT 833 other nodes are located. In particular, it is used by nodes to pass 834 information about the predecessor, successors, and finger table 835 information stored by a node. 837 DHT-Link = "DHT-Link" HCOLON NodeURI SEMI link-param SEMI 838 expires-param *(SEMI generic-param) 839 link-param = "link" EQUAL linktype-token depth-token 840 depth-token = 1*DIGIT 841 linktype-token = "P" / "F" / "S" / other-token 842 expires-param = "expires" EQUAL delta-seconds 844 and an example, the header might look like (using a shortened 10 845 digit Node-ID for clarity): 847 DHT-Link: ;link=S1;expires=600 849 7.5.1 The linktype and depth values 851 The linktype and depth values are dependent on the DHT routing 852 algorithm employed by the node. For the algorithm described in 853 Section Chord Overlay Algorithm (Section 9), the linktype MUST be one 854 of three single characters, P, S, or F. P MUST be used to indicate 855 that the information provided describes a predecessor of the sending 856 node. S MUST indicate that the information describes a successor 857 node, and F MUST indicate that it is a finger table node from the 858 sending node. 860 For the algorithm in Chord Overlay Algorithm (Section 9), the depth 861 MUST be a non-negative integer representing which predecessor, 862 successor, or finger table entry is being described. For 863 predecessors and successors, this MUST indicate numeric depth. In 864 other words, "P1" indicates the nodes immediate predecessor, while 865 "S5" would indicate the fifth successor. "P0" or "S0" would indicate 866 the sending node itself. In the case of finger table entries, the 867 depth MUST indicate the exponent of the offset. Since finger tables 868 point to ranges in the hash table that are offset from the current 869 node in the hash space by a power of two. That is, finger table 870 entry i points to a range that begins with a node 2^i away in the 871 hash space, and there are a maximum of k finger table entries, where 872 k is the size of the hash result in bits. For an finger table entry, 873 the depth corresponds to this exponent i. In other words, "F0" would 874 correspond to a finger table entry pointing to the node for a range 875 starting a distance 2^0 = 1 from the Node-ID in the hash space, while 876 "F6" would point to node used to search for resources in a range 877 starting 2^6 = 64 away from the Node-ID in the hash space. 879 7.5.2 Expires Processing 881 Each DHT-Link header MUST contain an expires parameter. Each node 882 maintains an expiration time for each of its neighbor and finger 883 table entries. These expiration times are updated whenever the node 884 receives a response with a longer expiration time than it currently 885 maintains, most commonly in the NodeID header of a response to a join 886 or search. A node MUST NOT report an expired entry in a DHT-Link 887 header. A node MUST update the expires parameter with the current 888 value, adjusted for passed time, each time it generates a DHT-Link 889 header. 891 8. Node/DHT Operations 893 The SIP REGISTER message is used extensively in this system. 894 REGISTER is used to register users, as in conventional SIP systems, 895 and we discuss this further in the Resource Registration 896 (Section 10.1) section of this document. Additionally, SIP REGISTER 897 messages are used to register a new node with the DHT and to transmit 898 the information needed to maintain the DHT. 900 8.1 Bootstrapping 902 When a node wishes to join an existing overlay, it must first locate 903 some node that is already participating in the overlay. referred to 904 as the bootstrap node. Nodes MAY use any method they choose to 905 locate the initial bootstrap node. The following are a few of many 906 methods that may be used: 907 Static Locations: Some number of nodes in the overlay may be 908 persistent, and have well know addresses. These address could be 909 configured into the node application, or obtained using an out-of- 910 band mechanism such as a web page. 911 Cached Nodes: While this mechanism cannot be used the first time that 912 a node runs, on subsequent attempts to join the overlay, a node 913 might attempt to use a previously contacted peer as a bootstrap 914 node. 916 Broadcast mechanisms: Nodes can use a broadcast mechanism to locate 917 the initial peer, for example by sending the first REGISTER 918 message to the SIP multicast address. 920 In the rest of this section, we assume that the joining node is not 921 the first node, and that a bootstrap node has been located. 923 8.2 Node Registration 925 After a node has located an initial bootstrap node, the process of 926 joining the overlay is started by constructing a REGISTER message and 927 sending it to the bootstrap node. Third party registration MAY NOT 928 be used for registering nodes into the overlay, and attempts to do so 929 MUST be rejected by the node receiving such a request. (although 930 third party registrations are used for other purposes, as described 931 below) The node MUST construct a SIP REGISTER message following the 932 instructions in RFC3261, section 10, with the exceptions/rules 933 outlined below. 935 8.2.1 Constructing a Node Registration 937 The Request-URI SHOULD include only the IP address of the node that 938 is being contacted (initially the bootstrap node). This URI SHOULD 939 NOT include any of the P2P defined parameters. For example, a 940 request intended for node 10.3.44.2 should look like: "REGISTER sip: 941 10.3.44.2 SIP/2.0". 943 The To and From fields of the REGISTER message MUST contain the URI 944 of the registering node constructed according to the rules in the 945 subsection Node URIs (Section 7.3.1) in the Message Syntax section. 947 While using the IP address of the sender for To and From is different 948 than traditional SIP registers, there are two reasons for this. 949 First, in a P2P network, which node the request is sent to, and thus 950 the domain for which the registration is intended, is not important. 951 Any node can process the information, and the user name is not 952 associated with a particular IP address or DNS domain, but rather 953 with the overlay name, which is encoded elsewhere. In that sense, 954 the IP address used is irrelevant. Choosing the domain of the sender 955 ensures that if a request is sent to a non-P2P aware registrar RFC 956 3261 compliant registrar, it will be rejected. RFC 3261 (section 957 10.3) states that a registrar should examine the To header to 958 determine if it presents a valid address-of-record for the domain it 959 serves. Since the IP address of the sending node is unlikely to be a 960 valid address for a non-P2P aware registrar, the message will be 961 rejected, eliminating possibly erroneous handling by the registrar. 963 The registering node MUST also list its NodeURI in the contact field 964 when registering so that this may be identified as a registration/ 965 update, rather than a query. The node MUST provide an expires 966 parameter or expires header with a non-zero value. As in standard 967 SIP registrations, Expire headers with a value of zero will be used 968 to remove registrations. 970 The registering node MUST provide a DHT-NodeID header field. It MAY 971 leave the overlay parameter set to "*" for its initial registration 972 message, but MUST set this parameter to the name of the overlay it is 973 joining as soon as it receives a response from the bootstrap node. 975 The registering node MUST include Require and Supported headers with 976 the option tag "dht". 978 Assume that a node running on IP address 10.4.1.2 on port 5060 979 attempts to join the network by contacting a bootstrap node at 980 address 10.7.8.129. Further assume that 10.4.5.23:5060 hashes to 981 463ac4b449 under sha1 (using a 10 digit hash for example simplicity), 982 and that the overlay name is chat. An example message would look 983 like this (neglecting tags): 985 REGISTER sip:10.7.8.129 SIP/2.0 986 To: 987 From: 988 Contact: 989 Expires: 600 990 DHT-NodeID: ;algorithm=sha1; 991 overlay=chat;expires=600 992 Require: dht 993 Supported: dht 995 8.2.2 Processing the Node Registration 997 The receiving node determines that this is a P2P SIP message based on 998 the presence of the dht Require and Supported fields. In the event 999 that the node does not support P2P extensions, it MUST reply with a 1000 5xx class response such as 501 Not Implemented. If the node examines 1001 the overlay parameters and determines that this is not an overlay the 1002 node participates in, the node MUST reject the message with a 488 Not 1003 Acceptable Here response. In the event a P2P node receives a non-P2P 1004 request, it SHOULD reject it with a message such as 421 Extension 1005 Required. 1007 8.2.2.1 Routing the Node Registration 1009 The presence of user=node URI parameter in the To and Contact headers 1010 and a valid expiration time indicate that this message is a node 1011 registration and the receiving node MUST process this as a DHT level 1012 request. The bootstrap node SHOULD verify that the hashed Node-ID 1013 corresponds to the IP address specified in the URI by hashing the IP 1014 address and port and comparing it to the Node-ID. If these do not 1015 match, the message should be rejected with a response of 493 1016 Undecipherable. The bootstrap node examines the Node-ID to determine 1017 if it corresponds to the portion of the overlay the bootstrap node is 1018 responsible for. If it does, the node will handle the REGISTER 1019 request itself, if not, it will provide the joining node with 1020 information about a node closer to the area of the overlay where the 1021 joining nodes Node-ID is stored. 1023 If the receiving node is not responsible for the area of the hash 1024 table where Node-ID should be stored, the node MUST generate a 302 1025 message. Nodes SHOULD NOT proxy the request, as described in 1026 RFC3261:10.3, item1. (although they could, it would place undue 1027 burden on a peer to ask it to do so, so we advise against it) The 302 1028 is constructed following the rules of RFC 3261 with the following 1029 rules. The receiving node MUST look up the node in its finger table 1030 nearest the joining node's Node-ID, and use it to create a contact 1031 field in the form of a node URI, as specified in the P2P Node URIs 1032 (Section 7.3.1) section of this document, including appropriate URI 1033 parameters. The response MUST contain a valid DHT-NodeID header. 1034 This response is sent to the joining node. 1036 Using our example register from the previous section, assume that 1037 bootstrap node 10.7.8.129 receives the message, determines it is not 1038 responsible for that area of the overlay, and redirects the joining 1039 node to a node with Node-ID 47e46fa2cd at IP address 10.3.1.7. The 1040 302 response, again neglecting tags, is shown below. Note that the 1041 node creating the response uses its information to construct the DHT- 1042 NodeID header. 1044 SIP/2.0 302 Moved Temporarily 1045 To: 1046 From: 1047 Contact: 1048 Expires: 600 1049 DHT-NodeID: ;algorithm=sha1; 1050 overlay=chat;expires=600 1051 Require: dht 1052 Supported: dht 1054 Upon receiving the 302, the joining node uses the contact address as 1055 the new bootstrap node. The process is repeated until the node 1056 contacted is currently responsible for the area of the DHT in which 1057 the new node will reside. The receiving node that is responsible for 1058 that portion of the overlay is referred to as the admitting node. 1060 8.2.2.2 Admitting the Joining Node 1062 The admitting node MUST verify that the Node-ID hash of the IP 1063 address is valid, as described above. If these do not match, the 1064 message should be rejected with a response of 493 Undecipherable. 1065 The admitting node recognizes that it is presently responsible for 1066 this region of the hash space -- that is, it is currently the node 1067 storing the information that this Node-Id will eventually be 1068 responsible for. The admitting node knows this because the joining 1069 node's Node-ID falls between the Node-ID of the admitting node and 1070 its predecessor. The admitting node is responsible for helping the 1071 joining node become a member of the overlay. In addition to 1072 verifying that the Node-ID was properly calculated, the admitting 1073 node MAY require an authentication challenge to the REGISTER message. 1074 Once any challenge has been met, the admitting will reply with a 200 1075 OK message to the joining node. As in a traditional registration, 1076 the Contact in the 200 OK will be the same as in the request, and the 1077 expiry time MUST be provided. 1079 The admitting node MUST reply with a 200 response if the joining node 1080 has a Node-ID between the admitting node's Node-ID and the admitting 1081 node's predecessor's Node-ID. The admitting node must populate the 1082 DHT-Link headers with all values required by the routing protocol so 1083 that the joining node can initialize its neighbors and finger table 1084 entries. Additionally, the admitting node MUST include its DHT- 1085 NodeID header containing the admitting node's Node-ID and IP. 1087 For further details of the contents of the link headers and the 1088 joining node processing, see Chord Admission Processing 1089 (Section 9.4). 1091 Continuing the example register from the previous sections, assume 1092 now that the node with Node-ID 47e46fa2cd and IP address 10.3.1.7 is 1093 currently responsible for 463ac4b449 in the namespace. The admitting 1094 node here does send the fingertable, but we show only the first entry 1095 entry for clarity. We also omit the additional successors used to 1096 support redundancy for clarity. The response would look something 1097 like: 1099 SIP/2.0 200 OK 1100 To: 1101 From: 1102 Contact: 1103 Expires: 600 1104 DHT-NodeID: ;algorithm=sha1; 1105 overlay=chat;expires=600 1106 DHT-Link: ;link=P1;expires=412 1107 DHT-Link: ;link=S1;expires=816 1108 DHT-Link: ;link=F2;expires=121 1109 Require: dht 1110 Supported: dht 1112 Both the admitting node and joining node SHOULD immediately perform 1113 both a stabilize and fix fingers operation (Section 9.8) to stabilize 1114 the overlay. 1116 8.3 Node Query 1118 As with traditional SIP, REGISTER messages that are sent without a 1119 Contact: header are assumed to be queries, as described in Section 10 1120 of RFC3261. This corresponds to the find_successor operation in 1121 Chord. 1123 8.3.1 Constructing a Node Query Message 1125 The node looks for the finger table entry that covers the range they 1126 wish to search. If the finger table entry has not yet been filled 1127 (and the node was not provided another finger table to use to get 1128 started), then the node may send the request to any node it has 1129 available, including their successor, predecessor, or even some 1130 bootstrap node. While these initial searches may be less efficient, 1131 they will succeed. The Request-URI SHOULD include only the IP 1132 address of the node that the search is intended for. This URI SHOULD 1133 NOT include any of the P2P defined parameters. For example, a 1134 request intended for node 10.3.44.2 should look like: "REGISTER sip: 1135 10.3.44.2 SIP/2.0". 1137 Because this is a query, the sending node MUST NOT include a contact 1138 header. The sender MUST NOT include an expires header. 1140 The node MUST provide a DHT-NodeID header. 1142 The node MUST include Require and Supported headers with the option 1143 tag "dht". 1145 Assume that a node running on IP address 10.4.1.2 on port 5060 wants 1146 to determine who is responsible for Node-ID 4823affe45, and asks the 1147 node with IP address 10.5.6.211 Further assume that the node uses 1148 sha1 (using a 10 digit hash for example simplicity), and that the 1149 overlay name is chat. An example message would look like this 1150 (neglecting tags): 1152 REGISTER sip:10.5.6.211 SIP/2.0 1153 To: 1154 From: 1155 DHT-NodeID: ;algorithm=sha1; 1156 overlay=chat;expires=600 1157 Require: dht 1158 Supported: dht 1160 The To field of the REGISTER message MUST contain the NodeURI of the 1161 identifier being search for, constructed according to the rules in 1162 the subsection P2P node URIs (Section 7.3.1) in the Message Syntax 1163 section. If a specific node is being sought, the NodeURI must 1164 specify that IP address. If only the identifier is being searched 1165 for, then hostport MUST be set to "0.0.0.0". The From URI MUST use 1166 the searching node's NodeURI. 1168 8.3.2 Processing Node Query Message 1170 The receiving node determines that this is a P2P SIP message based on 1171 the presence of the dht Require and Supported fields. In the event 1172 that the node does not support P2P extensions, it MUST reply with a 1173 5xx class response such as 501 Not Implemented. If the node examines 1174 the overlay parameters and determines that this is not an overlay the 1175 node participates in, the node MUST reject the message with a 488 Not 1176 Acceptable Here response. In the event a P2P node receives a non-P2P 1177 request, it SHOULD reject it with a message such as 421 Extension 1178 Required. 1180 8.3.2.1 Routing the Node Query Message 1182 The presence of user=node URI parameter and lack of an expiration 1183 time indicate that this message is a node query and the receiving 1184 node MUST process this as a DHT level request. The receiving node 1185 SHOULD NOT alter any of its internal values such as successor or 1186 predecessor in response to this message, since it is a query. 1187 Otherwise, the message is processed and routed as a node registration 1188 (Section 8.2.2.1) until the responsible node is reached. 1190 8.3.2.2 Responding to the Node Query Message 1192 If the receiving node is responsible for the region that the search 1193 key lies within, it MUST respond to the query. If the receiving 1194 node's Node-ID exactly matches the search key, it MUST respond with a 1195 200 OK message. If it is responsible for that region, but its 1196 Node-ID is not the search key, it MUST respond with a 404 Not Found 1197 message. The node MAY verify the Node-ID and IP address presented by 1198 the querying node in the message. If these do not match, the message 1199 should be rejected with a response of 493 Undecipherable. 1201 The reply that is constructed MUST provide information about the 1202 receiving node's neighbors and finger table entries. For further 1203 details of the contents of the link headers and the joining node 1204 processing, see Chord Query Processing (Section 9.5). 1206 8.4 Populating the Joining Node's Finger Table 1208 Once admitted, the joining node MUST populate its finger table by 1209 issuing queries for nodes with the appropriate identifiers. If the 1210 admitting node provided finger table information, the joining node 1211 MAY use this information to construct a temporary finger table, and 1212 use this temporary table in the queries to populate the table. For 1213 more information on populating the table, see Chord Finger Table 1214 (Section 9.6). 1216 8.5 Transfering User Registrations 1218 Because the joining node has split the area in the hash space that 1219 the admitting node was responsible for, some portion of these user 1220 registrations are now the responsibility of the joining node, and 1221 these user registrations are handed to the joining node by means of 1222 these user registrations. These are third party registration. Third 1223 party registrations are allowed for user registrations and arbitrary 1224 searches, but are not allowed for node registrations. These 1225 registrations are exactly the same as those discussed in Registering 1226 and Removing User Registrations (Section 10.1), except that as they 1227 are third party registration from a node, the From header contains 1228 the NodeURI of the admitting node. 1230 8.6 Nodes Leaving the Overlay Gracefully 1232 Nodes MUST send their registrations to their successor before leaving 1233 the overlay, as described in the section above. Additionally, nodes 1234 MUST unregister themselves with both their successor and predecessor. 1235 This REGISTER is constructed exactly the same as one used to join, 1236 with the following exceptions. The expires parameter or header MUST 1237 be provided, and MUST be set to 0. DHT-Link headers must be 1238 provided, as specified in Chord Graceful Leaving (Section 9.7). 1240 8.7 Handling Failed Requests 1242 When a request sent to any node fails, the user MUST perform searches 1243 to update their pointers. If the failed request was sent to a node 1244 in the finger table, than the searches discussed in Populating the 1245 Joining Node's Finger Table (Section 8.4) should be performed for all 1246 intervals that rely on the failed node. If the predecessor or 1247 successor node fails, a search for the predecessor or successor's ID 1248 should be performed, and requests should should be repeated, based on 1249 the predecessors and successors returned by these, until the correct 1250 successor or predecessors are determined. 1252 9. Chord Overlay Algorithm 1254 The DHT routing algorithm used in this protocol is based on Chord, 1255 with adaptations to rely on iterative operations rather than 1256 recursive operations. As this places the burden of an operation on 1257 the searching or joining node, rather than on intermediate nodes, it 1258 is more appropriate for an Internet protocol. 1260 We anticipate other routing algorithms being developed that may 1261 improve the performance, locality, or security of this algorithm. 1262 For this reason, the Chord-specific portions of the protocol are 1263 confined to this Section. The other elements of the protocl should 1264 be equally relevant to any DHT-based P2P routing algorithm. 1266 9.1 DHT Name Parameter 1268 For this protocol, the dht-param token must be set to "ChordIter1.0" 1270 9.2 Starting a New Overlay 1272 A node starting an overlay for the first time need not do anything 1273 special in order to construct the overlay. The node MUST initalize 1274 its finger table such that all entries point to itself. The node 1275 MUST set its successor (which is also the first entry of the finger 1276 table) to itself, and MUST set its predecessor to NULL. 1278 9.3 Finger Table 1280 Chord recommends keeping a number of finger table entries equal to 1281 the size in bits of the hash space, for example 160 for SHA-1. These 1282 entries point to the first node at least 2^i away from the node, for 1283 0 <= i <= 159, mod 2^160. Essentially, the node divides the overlay 1284 hash circle up into segments, the first being the segment from 1285 [0-2^0) away from the node, the second being from [2^0-2^1), the 1286 third being from [2^1-2^2), etc., all the way to the segment from 1287 [2^158-2^159) away from node. It then stores an entry in the finger 1288 table for the first node with a Node-ID greater than or equal to the 1289 start of this interval. In this way, the node has many entries 1290 pointing to nearby nodes, and less and less entries about more remote 1291 nodes. These tables are populated when the node joins the overlay, 1292 and are kept up to date by periodically updating them. 1294 We recommend that, while using the full SHA-1 hash algorithm, nodes 1295 maintain less than the full 160 entries in the finger table, perhaps 1296 16 entries for small networks, 32 for larger networks. As this 1297 effects only the efficiency of the client, it is left to the 1298 implementor to determine a useful value. Note that a client can 1299 easily store enough finger table entries to exceed the maximum MTU 1300 size when transmitting the full finger table. In this case, a client 1301 may need to reduce the number of finger table entries reported in 1302 DHT-Link headers. 1304 9.4 Node Admission 1306 When handling an initial join from a node, the admitting node MUST 1307 reply with a 200 response if the joining node has a Node-ID between 1308 the admitting node's Node-ID and the admitting node's predecessor's 1309 Node-ID. The admitting node MUST provide the joining node with its 1310 current predecessor and successor in the 200. These MUST be placed 1311 placed in DHT-Link headers, as described in The DHT-Link Header 1312 (Section 7.5) section of this document. The predecessor MUST be 1313 transmitted in a DHT-Link header using a type of P and a depth of 1. 1314 The successor MUST be transmitted in a DHT-Link header using a type 1315 of S and a depth of 1. All nodes SHOULD maintain 4 successors at all 1316 times for redundancy. The 200 SHOULD contain the next 4 successor 1317 nodes, for use in redundancy. 1319 The joining node obtains the Node-ID and address of the admitting 1320 node from the DHT-Node header, and the information about the 1321 admitting node's predecessor from the DHT-Link P 1 header. The 1322 joining node MUST set its successor to be the admitting node, and its 1323 predecessor to be the admitting node's predecessor. The admitting 1324 node MUST set its predecessor to be the joining node, and MUST obtain 1325 the information from the DHT-Node header in the register request. 1326 The admitting node's successor is unchanged. 1328 The admitting node SHOULD send a copy of the entries in their finger 1329 table to the joining node, using DHT-Link headers of the F type. As 1330 the joining node will likely be nearby the admitting node in the hash 1331 space (at least for an overlay with a reasonable number of nodes), 1332 this finger table information can likely improve the performance of 1333 the queries required to obtain a correct finger table information. 1334 It is the responsibility of the joining node to calculate and 1335 reconstruct the intervals that the admitting would have based on the 1336 F parameters and the Node-ID supplied in the 200. Note that 1337 providing the first finger is optional, as it is (by definition) 1338 identical to the required successor field. 1340 9.5 Chord Query Processing 1342 A reply that is constructed to a query by the responsible node MUST 1343 provide the current predecessor and successor in the 200 or 404 1344 message. These MUST be placed placed in DHT-Link headers, as 1345 described in The DHT-Link Header (Section 7.5) section of this 1346 document. The predecessor MUST be transmitted in a DHT-Link header 1347 using a type of P and a depth of 1. The successor MUST be 1348 transmitted in a DHT-Link header using a type of S and a depth of 1. 1349 The 200 or 404 SHOULD contain the next 4 successor nodes, for use in 1350 redundancy. Additionally, the replying node MUST include its DHT- 1351 NodeID header. 1353 9.6 Chord Finger Table 1355 To populate the finger table, a node must take its Node-ID and, by 1356 applying the exponential offsets for each finger, calculate the 1357 Resource-IDs corresponding to the start of each finger interval. See 1358 the P2P Overlay Structure (Section 4.2) subsection in the Overview 1359 section of this document. The joining node then performs a search 1360 for each of these start intervals, as described above. The resulting 1361 Node-IDs/IPs are entered into the corresponding finger table entries. 1362 This is analogous to the fix_fingers procedure in Chord. 1364 9.7 Chord Graceful Leaving 1366 When a node sends its unregister message to its successor and 1367 predecessor, it MUST include DHT-Link headers listing its predecessor 1368 and 4 successor nodes. This allows the nodes receiving the requests 1369 to obtain the information needed to correct their predecessor and 1370 successor nodes, as well as keep their successor lists needed for 1371 redundancy current. 1373 9.8 Chord Periodic Stabilization 1375 In order to keep the overlay stable, nodes must periodically perform 1376 book keeping operations to take into account node failures. 1377 Periodically (we suggest 60-360 seconds), nodes MUST perform an 1378 arbitrary query for their current successor's Node-ID. The node 1379 should examine the response from their successor. The predecessor 1380 reported should be the node that made the request. If it is not, the 1381 node MUST update their own successor with the predecessor returned, 1382 and additionally MUST send a REGISTER to this node, structured as if 1383 the stabilizing node had just entered the system. This will serve to 1384 properly update the overlay. This is analogous to the notify 1385 procedure in Chord. 1387 Additionally, when this periodic stabilization takes place, the node 1388 should perform searches as discussed in Populating the Joining Node's 1389 Finger Table (Section 8.4) to ensure that the finger table is up to 1390 date. 1392 9.9 Node Failure 1394 Node failure is handled by the periodic stabilization and responses 1395 to failed requests discussed above. 4-way redundancy registrations 1396 ensures that unless 4 sequential nodes fail, registrations will not 1397 be lost. 1399 9.10 Resource Replicas 1401 When a resource is registered, the registering node SHOULD create at 1402 least 2 redundant replicas to ensure the registry information is 1403 secure in the DHT. The registering node is responsible for 1404 maintaining these replicas along with the primary entry. 1406 10. Resource Operations 1408 The most important element of resource operations within the P2P SIP 1409 DHT is that they are performed exactly as if using a traditional SIP 1410 registrar, except that the registrar responsibilities are distributed 1411 among the DHT members. 1413 10.1 Resource Registrations 1415 When a node is in the overlay, it must register the contacts for 1416 users and other resources for which it is responsible into the 1417 overlay. This differs from the registrations described above in that 1418 these registrations are responsible for entering a URI name to URI 1419 location mapping (with a specific IP address) into the overlay as 1420 data, rather than joining a node into the overlay. These 1421 registrations are very similar to those outlined in section 10 of 1422 RFC3261. 1424 The Request-URI that is constructed for the REGISTER MUST be 1425 addressed to the node the request is sent to. The To and From fields 1426 of the REGISTER message MUST contain the Resource URI of the resource 1427 being registered, as described in Resource URIs (Section 7.3.2). The 1428 request MUST include the value dht in Require and Supported headers. 1429 The request MUST include a DHT-NodeID header and MAY include one or 1430 more DHT-Link headers. 1432 The resource registration must include at least one Contact header 1433 containing a location of the resource and allowing this to be 1434 identified as a registration/update, rather than a query. The node 1435 MUST provide an expires parameter or an Expire header with a non- 1436 zero value. As in standard SIP registrations, Expires parameters 1437 with a value of zero will be used to remove registrations. Any valid 1438 Contact for RFC 3261 is valid Contact for P2P SIP. Most users will 1439 register a Contact with the address of the user's UA (which may or 1440 may not be the IP address of the node, since the node could be an 1441 adaptor node). The Contact URI does not need to include the 1442 ResourceID or other P2P SIP parameters as it is stored in the DHT but 1443 not processed or routed by it in any way. 1445 The message is routed in a fashion exactly analogous to that 1446 described in the section on node registration (Section 8.2). 302 1447 messages are sent to indicate that the message is to be redirected to 1448 another node (this contact should contain the URI parameter 1449 user=node). Once the message arrives at a destination that is 1450 responsible for that portion of the hash namespace, the node 1451 recognizes it as a resource registration, rather than a node wishing 1452 to join the system, based upon the fact that the To and From fields 1453 do not contain user=node parameters. The node responds with a 200 1454 indicating a successful registration. The response is constructed as 1455 dictated by RFC3261. 1457 The registering node SHOULD construct and register replica 1458 registrations using the same Contact headers, but with the replica 1459 URI parameter used in the To and From headers. 1461 10.2 Refreshing Resource Registrations 1463 Resource registrations are refreshed exactly as described in RFC 1464 3261, Section 10. Responsible nodes should send a new registration 1465 with a valid expiration time prior to the time that the registration 1466 is set to expire. 1468 Agents MAY cache the address where they previously registered and 1469 attempt to send refreshes to this node, but they are not guaranteed 1470 success, as a new node may have registered and may now be responsible 1471 for this are of the space. In such a case, the node will receive a 1472 302 from the node with which they previously registered, and should 1473 follow the same procedure for locating the node they used in the 1474 initial registration. 1476 As with initial registrations, the sending node should use the 1477 successors provided in the 200 to send these updates to the redundant 1478 nodes as well. 1480 10.3 Removing Resource Registrations 1482 Resource registrations are removed exactly as described in RFC 3261, 1483 Section 10. Responsible nodes MUST send a registration with 1484 expiration time of zero. 1486 As with initial registrations, the sending node SHOULD construct 1487 replica unregister messages and use these to unregister the replicas. 1489 10.4 Querying Resource Registrations 1491 Resource queries are constructed as described in RFC 3261, Section 1492 10. Querying nodes should send a registration with no contact 1493 header. As described in Node Search (Section 8.3.1), this mechanism 1494 can also be used to locate the node responsible for a particular 1495 Resource-ID. 1497 A P2P environment can do little to protect against an individual node 1498 compromising the registrations it is responsible for. Accordingly, a 1499 UA cannot trust a response from a single node, whether it indicates a 1500 successful search or an error. In the absence of other methods of 1501 verifying the response (such as having a certificate of the user 1502 being searched for and a signed registration that can be verified 1503 with the certificate) a UA should search for the primary registration 1504 and at least one replica. Because the locations the replicas are 1505 stored are unrelated to the location of the primary registration, a 1506 single attacker is unlikely to be able to compromise both entries. 1507 As the overlay gains more nodes and more replicas are searched for, 1508 the odds of a compromise are reduced. 1510 10.5 Session Establishment 1512 When a caller wishes to send a SIP message (such as an INVITE or 1513 MESSAGE message to start a conversation, or a subscribe message to 1514 create a presence relationship with another user), the user must 1515 first locate the node where this called's information resides using 1516 the resource search procedure described in the section titled 1517 Resource Location. (Section 10.4) 1519 Establishing a session is done entirely in the normal SIP fashion 1520 after the user is located using the P2P resource query. Once the 1521 node responsible for the Resource-ID is located, it will provide 1522 either a 200, providing a contact for the users UA, or will provide a 1523 404 if the user is not registered. If a 200 with a valid contact is 1524 received, the call will then be initiated directly with the UAS of 1525 the called using the standard RFC 3261 fashion for methods such as 1526 INVITE or MESSAGE. 1528 10.6 Presence 1530 We use SUBSCRIBE/NOTIFY for this. We subscribe to every node on our 1531 buddy list when we come online. If the user's are online, that means 1532 that we know exactly where they are. Nodes SHOULD use their buddies 1533 as additional "finger table" entries (essentially, cached values), 1534 consulting these first, as connections are likely to be made to 1535 people on the users buddy list. These should also be periodically 1536 checked, as described in the Periodic Stabilization (Section 9.8) 1537 section. 1539 If buddies are offline, one should periodically try to make the 1540 connection. Alternately, we use the same register mechanism that is 1541 used at node-join time to let nodes we are here, rather than forcing 1542 them to do periodic subscribes. If a UA receives a SUBSCRIBE from 1543 some buddy that is currently offline, it SHOULD attempt to subscribe 1544 to that buddy. This will allow people that are reciprocally on each 1545 others buddy lists to rapidly be notified when one or the other comes 1546 online. 1548 10.7 Offline Storage 1550 Delivery of messages to offline users, or voicemail for voice 1551 applications, requires storing that information for later retrieval. 1552 Storing user configuration information in a format accessible from 1553 the network also will allow a user to retrieve their profile from any 1554 computer. Cao et al, [9] describe an approach that separates the 1555 storage of resource location information from the actual storage of 1556 the offline research. We believe that this approach is in agreement 1557 with the approach taken by the rest of this document, which relies on 1558 the DHT overlay to store the registrar's location information, but 1559 relies on external, traditional methods for the actual connection. 1560 For offline storage, it also allows the use of other standard 1561 protocols to store and retrieve the offline information, keeping the 1562 P2P SIP scope restricted to storing resource mappings. 1564 10.8 Examples 1566 For our examples, we use a simplified network. Rather than use a 1567 full SHA-1 hash, and the resulting 2^160 namespace, we instead use a 1568 smaller 4 bit hash, leading to a namespace of size 16. All hash 1569 results in our examples are contrived. We list the Node-ID and 1570 Resource-IDs as xx, where xx is a number between 0 and 15 (2^4 1571 namespace). In a real situation, the full 40 hex chars would be 1572 used. Additionally, because the number of finger table entries is so 1573 small in this case, we use the full 4 entries, where in a real case 1574 we suggest that one uses less than the number of bits in the 1575 namespace. 1577 The empty overlay can be visualized as a circle with 16 possible 1578 vacant points, each corresponding to one possible location in the 1579 hash space. On the left, we have labeled these locations in the hash 1580 space as 0-15, starting in the upper left, and have used 0s to 1581 indicate vacant spaces in the hash space. On the right, we show the 1582 same network with 3 operating nodes, denoted by capital Ns, with 1583 Node-IDs of 3, 5, and 10. We will use this sample network state as 1584 the starting point for all our networks: 1586 0 1 2 0 1 2 1587 0----0----0 0----0----0 1588 / \ / \ 1589 15 0 0 3 15 0 N 3 1590 / \ / \ 1591 14 0 0 4 14 0 0 4 1592 | | | | 1593 13 0 0 5 13 0 N 5 1594 | | | | 1595 12 0 0 6 12 0 0 6 1596 \ / \ / 1597 11 0 0 7 11 0 0 7 1598 \ / \ / 1599 0----0----0 N----0----0 1600 10 9 8 10 9 8 1602 Further, for the sake of example simplicity, assume the node Node-ID 1603 3 has IP address 10.0.0.3, the node node with Node-ID 5 has IP 1604 address 10.0.0.5, etc. 1606 Data that hashes to a Resource-ID is stored by the next node whose 1607 Node-ID is equal to or larger than the Resource-ID, mod the size of 1608 the hash. As such, Node 3 is responsible for any resources hashing 1609 from 11-15, as well as 0-3. Node 5 is responsible for resources with 1610 Resource-IDs from 4-5, and Node 10 is responsible for resources with 1611 Resource-IDs from 6-10. From this illustration, you follow a 1612 location clockwise until you encounter a node, and this is the node 1613 responsible for storing the information. This is illustrated below: 1615 0 1 2 1616 0----0----0 1617 / \ 1618 15 0 N 3 1619 / 1620 14 0 0 4 1621 | | 1622 13 0 N 5 1623 | 1624 12 0 0 6 1625 \ / 1626 11 0 0 7 1627 / 1628 N----0----0 1629 10 9 8 1631 Finger tables give pointers to nearby nodes. For our system, with 4 1632 bit identifiers, we have 4 finger table entries. These finger tables 1633 point to the node nearest to Node-ID + 2^0, Node-ID + 2^1, Node-ID + 1634 2^2 and Node-ID + 2^3. If no node is present at that location, the 1635 next available node will be used. Thus, for our 3 nodes, the finger 1636 tables look like the following, with ranges (indicated in traditional 1637 mathematical form) mapping to the node those requests will be sent 1638 to: 1640 Node 3 Node 5 Node 10 1641 2^0 Entry [4,5) -> 5 [6,7) -> 10 [11,12) -> 3 1642 2^1 Entry [5,7) -> 5 [7,9) -> 10 [12,14) -> 3 1643 2^2 Entry [7,11) -> 10 [9,13) -> 10 [14,2) -> 3 1644 2^3 Entry [11.3) -> 3 [13,5) -> 3 [2,10) -> 3 1646 Assume further our sample network is called sipchat, and that 2 users 1647 are currently registered. User alice has a Resource-ID of 5, so her 1648 registration information is stored at node 5. User bob is also 1649 registered, and has a Resource-ID of 12, so his registration 1650 information is stored by node 3. Assume further that bob's UA is co- 1651 located with Node 10, so his contact is sipchat/bob@10.10.10.10, and 1652 that alice is running a UA on a completely separate IP of 1653 10.99.99.99, but is using an adapter node running on Node 3, 1654 therefore Node 3 will send messages on alice's behalf, but alice's 1655 contact is sipchat/alice@10.99.99.99. 1657 In each of the examples below, we assume we start from the network 1658 described above. Changes to the example network from previous 1659 examples are discarded. 1661 Note that for simplicity we do not show user registration redundancy 1662 in any examples. This includes responses -- we only send predecessor 1663 and successor, as well as finger table -- not redundant successors. 1665 10.8.1 Example of a Node Registration 1667 Assume a new node wishes to join the system. The node has an IP 1668 address of 10.0.0.14, which we shall assume hashes to a Node-ID of 1669 14. From an out of band mechanism, this node discovers node 5. This 1670 node constructs a REGISTER as described in Node Registration 1671 (Section 6.1), and sends it to node 5. Node 5 verifies that 1672 10.0.0.14 hashes to 14, then checks to see if it controls that 1673 portion of the namespace. Since it does not, it looks up in its 1674 finger table where it would route a search for 14, and determines it 1675 would send it to node 3. The node then sends a 302 back to node 14, 1676 with a contact of node 3. 1678 Node 14 the constructs a new REGISTER and sends it to Node 3. Again, 1679 Node 3 verifies the hash, and determines it is currently responsible 1680 for 14 in the hash space. After an optional challenge, it replies 1681 with a 200 OK message to admit the node to the system. Finally, Node 1682 3 sends a third party registration on behalf of bob to Node 14, 1683 transferring bob's registration to the new node. 1685 Node 14 Node 5 Node 3 1686 | | | 1687 |(1) REGISTER | | 1688 |------------------>| | 1689 | | | 1690 |(2) 302 | | 1691 |<------------------| | 1692 | | | 1693 |(3) REGISTER | | 1694 |-------------------------------------->| 1695 | | | 1696 |(4) 200 | | 1697 |<--------------------------------------| 1698 | | | 1699 |(5) REGISTER | | 1700 |<--------------------------------------| 1701 | | | 1702 |(6) 200 | | 1703 |-------------------------------------->| 1704 | | | 1706 Node 14 -> Node 5 1707 REGISTER sip:10.0.0.5 SIP/2.0 1708 To: 1709 From: 1710 Contact: 1711 Expires: 600 1712 DHT-NodeID: ;algorithm=sha1;overlay=chat; 1713 expires=600 1714 Require: dht 1715 Supported: dht 1717 Node 5 -> Node 14 1719 SIP/2.0 302 Moved Temporarily 1720 To: 1721 From: 1722 Contact: 1723 DHT-NodeID: ;algorithm=sha1;overlay=chat; 1724 expires=1200 1725 DHT-Link: ;link=P1;expires=427 1726 DHT-Link: ;link=S1;expires=387 1727 Require: dht 1728 Supported: dht 1730 Node 14 -> Node 3 1732 REGISTER sip:10.0.0.3 SIP/2.0 1733 To: 1734 From: 1735 Contact: 1736 Expires: 600 1737 DHT-NodeID: ;algorithm=sha1;overlay=chat; 1738 expires=600 1739 Require: dht 1740 Supported: dht 1742 Node 3 -> Node 14 1744 SIP/2.0 200 OK 1745 To: 1746 From: 1747 Contact: 1748 Expires: 600 1749 DHT-NodeID: ;algorithm=sha1;overlay=chat; 1750 expires=600 1751 DHT-Link: ;link=P1;expires=125 1752 DHT-Link: ;link=S1;expires=919 1753 DHT-Link: ;link=F0;expires=919 1754 DHT-Link: ;link=F1;expires=919 1755 DHT-Link: ;link=F2;expires=125 1756 DHT-Link: ;link=F3;expires=600 1757 Require: dht 1758 Supported: dht 1760 Node 3 -> Node 14 1762 REGISTER sip:10.0.0.14 SIP/2.0 1763 To: 1764 From: 1765 Contact: 1766 Expires: 201 1767 DHT-NodeID: ;algorithm=sha1;overlay=chat; 1768 expires=600 1769 Require: dht 1770 Supported: dht 1772 Node 14 -> Node 3 1774 SIP/2.0 200 OK 1775 To: 1776 From: 1777 Contact: 1778 Expires: 201 1779 DHT-NodeID: ;algorithm=sha1;overlay=chat; 1780 expires=600 1781 Require: dht 1782 Supported: dht 1784 10.8.2 Example of a User Registration 1786 Assume user Carl starts a UA co-located with node 5. Carl's contact 1787 will be carl@10.0.0.5, and his user name will be carl@p2psip.org. 1788 Carl's Node hashes his user id and determines that the corresponding 1789 Resource-ID will be 11 -- that is, Carl's registration will be stored 1790 by by the node responsible for Resource-ID 11 -- ultimately Node 3 in 1791 our example. 1793 Carl's UA begins by constructing a SIP REGISTER message as described 1794 in Resource Registrations (Section 10.1). Carl's UA consults its 1795 finger table, and determines that it should route requests pertaining 1796 to a Resource-ID of 11 to Node 10. The REGISTER is sent to Node 10, 1797 which observes that it is not responsible for that portion of the 1798 namespace, and consults the finger table, finding Node 3 in the 1799 appropriate entry. Node 10 sends a 302 containing Node 3 as a 1800 contact. 1802 Node 5 constructs a new REGISTER on behalf of carl, and sends it to 1803 Node 3. Node 3 recognizes that it is responsible for storing this 1804 registration, and replies with a 200 OK (although in reality it might 1805 challenge in some way). The 200 contains some number of successor 1806 nodes -- in this case 2 (although in our contrived example, one is 1807 node 5 itself) that Carl's node could send redundant registrations 1808 to. In our example, we do not show these. The 200 also (like 302s) 1809 must contain successors/predecessors in case the request is being 1810 used for stabilization. Again, in the tiny contrived example it 1811 looks odd since the second successor is the same as the predecessor. 1812 In a larger example this would not be the case. 1814 [To Do: Maybe use a bigger example to fix these problems? That might 1815 be to big and ugly. Need a good way to show this] 1817 Node 5 Node 10 Node 3 1818 | | | 1819 |(1) REGISTER | | 1820 |------------------>| | 1821 | | | 1822 |(2) 302 | | 1823 |<------------------| | 1824 | | | 1825 |(3) REGISTER | | 1826 |-------------------------------------->| 1827 | | | 1828 |(4) 200 | | 1829 |<--------------------------------------| 1830 | | | 1832 Node 5 -> Node 10 1834 REGISTER sip:10.0.0.10 SIP/2.0 1835 To: 1836 From: 1837 Contact: 1838 Expires: 600 1839 DHT-NodeID: ;algorithm=sha1;overlay=chat; 1840 expires=1200 1842 Require: dht 1843 Supported: dht 1845 Node 10 -> Node 5 1847 SIP/2.0 302 Moved Temporarily 1848 Contact: 1849 DHT-NodeID: ;algorithm=sha1;overlay=chat; 1850 expires=800 1851 DHT-Link: ;link=P1;expires=1200 1852 DHT-Link: ;link=S1;expires=412 1853 Require: dht 1854 Supported: dht 1856 Node 5 -> Node 3 1858 REGISTER sip:10.0.0.3 SIP/2.0 1859 To: 1860 From: 1861 Contact: 1862 Expires: 600 1863 DHT-NodeID: ;algorithm=sha1;overlay=chat; 1864 expires=1200 1865 Require: dht 1866 Supported: dht 1868 Node 3 -> Node 5 1870 SIP/2.0 200 OK 1871 To: 1872 From: 1873 Contact: 1874 Expires: 600 1875 DHT-NodeID: ;algorithm=sha1;overlay=chat; 1876 expires=600 1877 DHT-Link: ;link=P1;expires=405 1878 DHT-Link: ;link=S1;expires=1200 1879 DHT-Link: ;link=S2;expires=405 1880 Require: dht 1881 Supported: dht 1883 10.8.3 Example of a Session Establishment 1885 Assume user Bob wishes to call user Alice. Bob's node hashes Alice's 1886 user id, resulting in a Resource-ID of 5. Bob's node (recall that 1887 Bob's UA is co-located with node 10) consults it's finger table, and 1888 determines that a request for Resource-ID 5 should be routed to Node 1889 3. A REGISTER query message is constructed and routed to Node 3. 1890 Node 3 determines it is not responsible for a Resource-ID of 5, looks 1891 up the ID in it's finger table and determines it should be routed to 1892 Node 5, so it returns a 302 referring to Node 5. Bob's node resends 1893 the REGISTER to Node 5, which stores Alice's information. It sends a 1894 200 with Alice's contact -- sipchat/alice@10.99.99.99. Bob finally 1895 sends an INVITE to Alice's UA, and session establishment is completed 1896 as normal. 1898 Node 10 Node 3 Node 5 Alice UA 1899 | | | | 1900 |(1) REGISTER | | | 1901 |------------------>| | | 1902 | | | | 1903 |(2) 302 | | | 1904 |<------------------| | | 1905 | | | | 1906 |(3) REGISTER | | | 1907 |----------------------------------->| | 1908 | | | | 1909 |(4) 200 | | | 1910 |<-----------------------------------| | 1911 | | | | 1912 |(5) INVITE | | | 1913 |------------------------------------------------------>| 1914 | | | | 1915 |(6) 180 | | | 1916 |<------------------------------------------------------| 1917 | | | | 1918 |(7) 200 | | | 1919 |<------------------------------------------------------| 1920 | | | | 1921 |(8) ACK | | | 1922 |------------------------------------------------------>| 1923 | | | | 1925 Node 10 -> Node 3 1927 REGISTER sip:10.0.0.3 SIP/2.0 1928 To: 1929 From: 1930 DHT-NodeID: ;algorithm=sha1;overlay=chat; 1931 expires=800 1932 Require: dht 1933 Supported: dht 1935 Node 3 -> Node 10 1937 SIP/2.0 302 Moved Temporarily 1938 To: 1939 From: 1940 Contact: 1941 DHT-NodeID: ;algorithm=sha1;overlay=chat; 1942 expires=600 1943 DHT-Link: ;link=P1;expires=421 1944 DHT-Link: ;link=S1;expires=1004 1945 Require: dht 1946 Supported: dht 1948 Node 10 -> Node 5 1950 REGISTER sip:10.0.0.5 SIP/2.0 1951 To: 1952 From: 1953 DHT-NodeID: ;algorithm=sha1;overlay=chat; 1954 expires=800 1955 Require: dht 1956 Supported: dht 1958 Node 5 -> Node 10 1960 SIP/2.0 200 OK 1961 To: 1962 From: 1963 Contact: 1964 DHT-NodeID: ;algorithm=sha1;overlay=chat; 1965 expires=1200 1966 DHT-Link: ;link=P1;expires=108 1967 DHT-Link: ;link=S1;expires=492 1968 Require: dht 1969 Supported: dht 1971 Node 10 -> Alice UA 1972 INVITE sip:alice@p2psip.org SIP/2.0 1973 To: 1974 From: 1975 Contact: 1976 DHT-NodeID: ;algorithm=sha1;overlay=chat; 1977 expires=800 1978 Supported: dht 1980 The remainder of the call is completed as any other SIP call. Note 1981 that if Alice's UA is DHT-compliant, then it will recognize the 1982 Supported field and DHT-NodeID header, and may respond with similar 1983 fields. However, if it does not support DHT extensions, it will 1984 simply ignore those values and complete the call as any normal non- 1985 P2P SIP UA. 1987 10.8.4 Example of a Node Leaving the System 1989 [To Do: Add an example here] 1991 10.8.5 Example of a Successful User Search 1993 [To Do: Add an example here] 1995 10.8.6 Example of an Unsucessful User Search 1997 [To Do: Add an example here] 1999 10.9 Security Considerations 2001 To Do: Still a lots of work to be done here. 2003 There are many inherent security issues in a system such as this, and 2004 it is clearly not the solution for everyone. It trades off some 2005 security for certain other properties such as functioning without a 2006 centralized server or owner of the namespace. 2008 10.9.1 Threat Model 2010 The attacker is assumed to be able to generate an identity and become 2011 a valid node in the system. They can see other nodes and process 2012 certain queries. Attackers may wish to receive communications 2013 intended for other participants, prevent other users from receiving 2014 their messages, prevent large portions of the users from receiving 2015 messages, or send messages that appear to be from others. Users 2016 would like to be sure they are communicating with the same person 2017 they have previously talked to, to be able to verify identity via 2018 some out of band mechanism. Attackers may try to squat on all the 2019 good names. Users would like names that are meaningful to them. 2020 Attackers may have computers that are many times faster than the 2021 average user's. Attackers may be able to DOS other particular nodes 2022 and make them fail. To make a robust DHT, many nodes need to store 2023 information on behalf of the community. Nodes may lie about this and 2024 not store the information. Attackers may wish to see who is 2025 communicating with whom and how much data is getting communicated. 2027 10.9.2 Protecting the Namespace 2029 Key requirements of the system are that there is no centralized 2030 naming authority and users can pick names. If two users pick the 2031 same name, the system must be able to determine which of them should 2032 be allowed to use the name. At some level this is tricky, because 2033 different clients could pick the same new name at the same time on 2034 opposite sides of the ring. Any local mechanism would let that 2035 happen, whereas a global mechanism is very difficult to implement 2036 efficiently on a P2P network that is dynamically changing. 2038 10.9.2.1 Certificate Based Protection 2040 The goal of this approach is to end up with a security environment 2041 comparable to ssh, which in the opinion of the authors is excellent 2042 even though it is less than perfect. This approach tries to limit 2043 the damage produced by the theft of a person's identity instead of 2044 directly stopping the theft in the first place. The system requires 2045 each user to have a self signed certificate and use S/MIME and AIBs 2046 for signing the messages. When users first contact each other, they 2047 can store the certificates, and each user can warn the other user if 2048 they change on future communications. UAs SHOULD be able to display 2049 the sha1 hash of the certificate to the user for out of band 2050 verification. Address books SHOULD store these certificates, and UAs 2051 should trust the information in users' address books at a higher 2052 level than information contained in messages they receive over the 2053 wire. 2055 As described earlier, if the nodes and users desiring to join an 2056 overlay can establish a shared secret, they can use that secret as a 2057 seed to the Identifier algorithm, thus prohibiting anyone unaware of 2058 that secret from joining the overlay because they will be unable to 2059 construct valid identifiers. 2061 10.10 Protecting the Routing 2063 The DHT forms a complex routing table. When a node joins, it may 2064 accidentally contact a subversive node that lies about the finger 2065 table information it provides. The subversive node could do this to 2066 try to trick the joining node to route all the traffic to a 2067 subversive group of nodes. 2069 10.11 Protecting the Signaling 2071 The goal here is to stop the attacker from knowing who is signaling 2072 what to whom. Ultimately this will be impossible if a large 2073 percentage of the ring is compromised. It it possible to make it 2074 statistically hard for a user to figure out what some specific other 2075 user is doing. This is done by forcing the hash locations to be 2076 bound to the contact information via the crypto hash. In many cases, 2077 the attacker does not have wide control over the range and number of 2078 IPs available to them to attempt these attacks. IPv6 will expand 2079 this and this work will have to look at perhaps hashing the upper 2080 bits separately from the lower bits to again force the attacker into 2081 a position where it is harder to control their IP address and thus 2082 the hash function result that determines where they are inserted into 2083 the DHT. 2085 Interactive systems mean that nodes only see the queries. Clients 2086 can randomly generate these to obfuscate who they are tying to 2087 connect to. Cached results localize the area in the DHT where an 2088 attacker's node would have to be located to see an attempted 2089 connection to a given node. 2091 10.12 Protecting the Media 2093 All the media needs to be S/MIME encrypted. Doing so reduces the 2094 value of intercepting others' communications, because the media 2095 cannot be seen in the message. This is critical. 2097 10.13 Replay Attacks 2099 Very loosely synchronized time is fairly easy to maintain on modern 2100 devices using only the internal clock. This is used in the SIP Date 2101 header field value along with random Call-ID and to and from tags, 2102 resulting in a fair amount of protection against replay attacks. 2104 10.14 Cut and Paste Attacks 2106 Using the AIB to protect the message with S/MIME makes cut and paste 2107 attacks on of fields other than the VIA headers very difficult. 2109 A node can always re-sign the whole thing using a different self 2110 sided certificate but new certificate would likely be caused by the 2111 receiver if a previous communication had been made. 2113 10.15 Identity Theft Attacks 2115 The lack of central authority to resolve name disputes in the 2116 namespace means that at some level this problem is unsolved. The 2117 approach has tended to be to allow everyone to call themselves Wally 2118 then let the certificates sort them out. Users with names that are 2119 often "stolen" by others will learn that theirs is a poor choice of 2120 name because it is too valuable, and they will select a less valuable 2121 name. Equilibrium will prevail, or chaos. 2123 10.16 Limitations of the Security 2125 The limitations of the security revolve around the intrinsic 2126 characteristic that anyone can create a name - names are not unique 2127 and routing to a particular name does not guarantee reaching a unique 2128 user. 2130 11. Open Issues 2132 There are certainly many open issues. Here are a few. 2134 Still to be worked out are details of what names look like, how they 2135 are allocated and protected, and how they are disambiguated from 2136 traditional names that use DNS based routing. 2138 Using routable IP addresses for the Node-ID is problematic. Using 2139 them solves a big problem with preventing the Sybil attack and 2140 preventing people from simply making tons of nodes that join the 2141 network and pollute the space; but on the other hand, this will be a 2142 BIG problem with NATs. If home users' machines are used, some large 2143 fraction probably have IP addresses in the 192.168.0.x and 2144 192.168.1.x families. These addresses will all hash to the same ID. 2145 I used IP addresses for now in the draft, but we need a better way to 2146 generate Node-IDs that works for NATs and preserves all the 2147 protection against P2P attacks that comes from using them. 2149 We have had various thoughts on this issue. One thought is to 2150 require the use of mechanisms such as STUN and require that actual IP 2151 addresses be placed in the messages. This works well but permits 2152 only one node to be behind each NAT. Appending a port does NOT solve 2153 the problem, as users then, by selecting arbitrary port numbers can 2154 create a very large number of Node-IDs, and in a network with a small 2155 number of nodes, could likely find a Node-ID that would place them 2156 between any pair of nodes they desired, causing disruption to the 2157 network. One possibility we have considered is to append the port 2158 number -- unmodified -- to the hash. This would still allow users 2159 behind a NAT to have different Node-IDs, but the range of addresses 2160 within the hash would be very limited -- the user would only be able 2161 to insert themselves between other nodes behind the same NAT they are 2162 behind. There would still be issues with being able to control an 2163 arbitrary number of successors, but they seem less serious than the 2164 other alternative. This issue needs to be explored. 2166 12. Acknowledgments 2168 The following people provided useful feedback, commentary, advice, 2169 design ideas, criticism, or proofreading during the course of writing 2170 this draft: 2172 Adam Roach, Robert Sparks, Kundan Singh, Henning Schulzrinne, Marcia 2173 Zangrilli. 2175 Thank you for your help! 2177 13. Implementations 2179 There are several different implementations of P2P SIP. To date, 2180 they each follow different, mutually incompatible protocols. 2182 14. IANA Considerations 2184 This document would require registering the following: 2185 o Option tag "DHT" 2186 o "DHT-Link" as a Header Field 2187 o "DHT-NodeID" as a Header Field 2188 o "node" as a valid value for parameter user (?) 2189 o "Resource-ID" as a valid URI parameter (?) 2191 [ToDo: This section needs to be revamped to include all the new BNF 2192 introduced] 2194 15. Definitions 2195 Peer-to-Peer (P2P) Architecture: An architecture in which nodes 2196 cooperate together to perform tasks. Each node has essentially 2197 equal importance and performs the same tasks within the network. 2198 Additionally, nodes communicate directly with one another to 2199 perform tasks. Contrast this to a Client-Server architecture. 2200 Client-Server Architecture: An architecture in which some small 2201 number of nodes (servers) provide services to a larger number of 2202 nodes (clients). Client nodes connect to servers, but typically 2203 do not communicate among themselves. 2204 Node or Peer: Any entity that participates in the overlay network, 2205 understanding the p2p extensions described in this in document, is 2206 a "node" or "peer". For P2P SIP, the term "node" usually refers 2207 to P2P-enabled UAs and to adapter nodes that serve to connect non- 2208 P2P SIP devices. 2210 Resource: A resource is an object for which a pointer is stored in 2211 the DHT. Resources include user registrations, voicemail 2212 messages, etc. 2213 Overlay or Overlay Network: This document refers to the virtual 2214 network created by the interconnection between the nodes 2215 participating in the P2P SIP network as the "overlay network", in 2216 keeping with the terminology used in the P2P community. 2217 Distributed Hash Table (DHT): A mechanism in which resources are 2218 given a unique key produced by hashing some attribute of the 2219 resource, locating them in a hash space (see below). Nodes 2220 located in this hash space also have a unique id within the hash 2221 space. Nodes store information about resources with keys that are 2222 numerically similar to the node's ID in the hash space. 2223 Namespace or hash space: The range of values that valid results from 2224 the hash algorithm fall into. For example, using the SHA-1 2225 algorithm, the namespace is all 40 digit hexadecimal identifiers. 2226 This namespace forms the set of valid values for Node-IDs and 2227 Resource-IDs (see below). 2228 Resource-ID: The value resulting from hashing the a resource's unique 2229 name or keyword. Any information about this resource will then be 2230 stored at that location in the namespace, and maintained by a node 2231 with a Node-ID with a value numerically similar to the 2232 Resource-ID. In P2P SIP, User names are hashed to Resource-IDs to 2233 determine where in hash space they should be stored. 2234 Node-ID: The value resulting from hashing the unique ID of a 2235 particular node. A node with particular Node-ID will be 2236 responsible for maintaining information about resources with 2237 Resource-IDs that are nearby in the hash space. 2238 Chord: A particular algorithm/approach to implementing a DHT. Uses a 2239 circular arrangement for the namespace. 2240 Finger Table: The list of nodes that a node uses to send messages to. 2241 The finger table contains many entries about nodes with similar 2242 IDs, and fewer entries about more remote IDs. 2243 Neighbors: A collection of nodes that a particular node can reach in 2244 one hop. In general, note that a node's set of neighbors is 2245 equivalent to the entries in that node's finger table. In our DHT 2246 structure, neighbor relations are NOT symmetric. 2247 Adapter Node: An adapter node is a node in the overlay that acts as 2248 an adapter for other non-P2P enabled SIP entities, allowing them 2249 to access the resources of the overlay. The adapter node 2250 participates actively in the overlay network, while the non-P2P 2251 enabled SIP entities it provides service to DO NOT participate 2252 directly in the overlay. Compare these to the term "super node" 2253 in the P2P community, although adapter nodes may be thin software 2254 shims intended for only one client. 2256 Successor Node and Predecessor Node: A term borrowed from Chord. 2257 These terms refer to the node directly after (before) a particular 2258 node in the address space. This does not mean the successor/ 2259 predecessor node's ID is one greater/less than the node, it simply 2260 means that there are no other nodes in the namespace between the 2261 node and the successor/predecessor. Note that the first node in a 2262 finger table is typically also the first successor node. 2263 Node Registration: The act of a peer joining the overlay. 2264 Registration allows a peer to communicate with other peers, and 2265 requires (allows?) it to take on some server-like responsibilities 2266 such as maintaining resource location information. It DOES NOT 2267 register the user so that they can receive phone calls, which is 2268 the traditional SIP use of the word registration. We refer to 2269 traditional SIP registration as "user registration". 2270 User Registration: The act of a user registering themselves with a 2271 SIP network. User registration creates a mapping between a SIP 2272 URI and a contact for a user to be created. This is the 2273 traditional meaning of registration in SIP. For a P2P SIP node, 2274 this action MUST occur after node registration. 2275 Joining Node: During the node registration process, this is the node 2276 that is attempting to register -- that is, the node that is 2277 attempting to join the overlay network. 2278 Bootstrap Node: During the process of node registration, the 2279 bootstrap node is the node that the joining node contacts. This 2280 node may be a well-known node, a node located using a broadcast 2281 method, a node that the joining node previously knew about, or a 2282 node that another bootstrap node referred the joining node to. 2283 Often, the only role the bootstrap node plays in the node 2284 registration is to direct the joining node to the admitting node. 2285 Admitting Node: During the process of node registration, this is the 2286 node that is currently responsible for the portion of the 2287 namespace the new node will eventually reside in. This node is 2288 responsible for generating many of the messages exchanged during 2289 node registration. 2291 16. References 2293 16.1 Normative References 2295 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2296 Levels", BCP 14, RFC 2119, March 1997. 2298 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2299 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 2300 Session Initiation Protocol", RFC 3261, June 2002. 2302 [3] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 2303 for Message Authentication", RFC 2104, February 1997. 2305 [4] Eastlake, 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 2306 (SHA1)", RFC 3174, September 2001. 2308 [5] Peterson, J. and C. Jennings, "Enhancements for Authenticated 2309 Identity Management in the Session Initiation Protocol (SIP)", 2310 Internet Draft draft-ietf-sip-identity-06, October 2005. 2312 16.2 Informative References 2314 [6] Bryan, D., Jennings, C., and B. Lowekamp, "SOSIMPLE: A 2315 Serverless, Standards-based, P2P SIP Communication System", 2316 Proceedings of the 2005 International Workshop on Advanced 2317 Architectures and Algorithms for Internet Delivery and 2318 Applications (AAA-IDEA) '05, June 2005. 2320 [7] Stoica, I., Morris, R., Liben-Nowell, D., Karger, D., Kaashoek, 2321 M., Dabek, F., and H. Balakrishnan, "Chord: A Scalable Peer-to- 2322 peer Lookup Service for Internet Applications", IEEE/ACM 2323 Transactions on Networking (To appear) . 2325 [8] Douceur, J., "The Sybil Attack", IPTPS '02, March 2002. 2327 [9] Cao, F., Bryan, D., and B. Lowekamp, "Providing Secure Services 2328 in Peer-to-Peer Communications Networks with Central Security 2329 Server", Internation Conference on Internet and Web Applications 2330 and Services (ICIW) '06, February 2006. 2332 Authors' Addresses 2334 David A. Bryan 2335 College of William and Mary 2336 Department of Computer Science 2337 P.O. Box 8795 2338 Williamsburg, VA 23187 2339 USA 2341 Phone: +1 757 784 5601 2342 Email: bryan@ethernot.org 2343 Bruce B. Lowekamp 2344 College of William and Mary 2345 Department of Computer Science 2346 P.O. Box 8795 2347 Williamsburg, VA 23187 2348 USA 2350 Phone: 2351 Email: lowekamp@cs.wm.edu 2353 Cullen Jennings 2354 Cisco Systems 2355 170 West Tasman Drive 2356 MS: SJC-21/3 2357 San Jose, CA 95134 2358 USA 2360 Phone: +1 408 421 9990 2361 Email: fluffy@cisco.com 2363 Intellectual Property Statement 2365 The IETF takes no position regarding the validity or scope of any 2366 Intellectual Property Rights or other rights that might be claimed to 2367 pertain to the implementation or use of the technology described in 2368 this document or the extent to which any license under such rights 2369 might or might not be available; nor does it represent that it has 2370 made any independent effort to identify any such rights. Information 2371 on the procedures with respect to rights in RFC documents can be 2372 found in BCP 78 and BCP 79. 2374 Copies of IPR disclosures made to the IETF Secretariat and any 2375 assurances of licenses to be made available, or the result of an 2376 attempt made to obtain a general license or permission for the use of 2377 such proprietary rights by implementers or users of this 2378 specification can be obtained from the IETF on-line IPR repository at 2379 http://www.ietf.org/ipr. 2381 The IETF invites any interested party to bring to its attention any 2382 copyrights, patents or patent applications, or other proprietary 2383 rights that may cover technology that may be required to implement 2384 this standard. Please address the information to the IETF at 2385 ietf-ipr@ietf.org. 2387 Disclaimer of Validity 2389 This document and the information contained herein are provided on an 2390 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2391 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2392 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2393 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2394 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2395 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2397 Copyright Statement 2399 Copyright (C) The Internet Society (2006). This document is subject 2400 to the rights, licenses and restrictions contained in BCP 78, and 2401 except as set forth therein, the authors retain all their rights. 2403 Acknowledgment 2405 Funding for the RFC Editor function is currently provided by the 2406 Internet Society.