idnits 2.17.1 draft-bryan-p2psip-dsip-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2031. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2042. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2049. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2055. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 11 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 IETF Trust Copyright Line does not match the current year -- 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 peer has located an initial bootstrap peer, the process of joining the overlay is started by constructing a REGISTER message and sending it to the bootstrap peer. Third party registration MAY NOT be used for registering peers into the overlay, and attempts to do so MUST be rejected by the peer receiving such a request (although third party registrations are used for other purposes, as described below). The peer 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 (February 25, 2007) is 6270 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) == Outdated reference: A later version (-04) exists of draft-willis-p2psip-concepts-03 ** Downref: Normative reference to an Informational draft: draft-willis-p2psip-concepts (ref. '2') == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-05 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-13 ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '10') ** Obsolete normative reference: RFC 4474 (ref. '11') (Obsoleted by RFC 8224) ** Downref: Normative reference to an Informational RFC: RFC 3174 (ref. '12') == Outdated reference: A later version (-15) exists of draft-ietf-sip-certs-02 == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-02 Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 P2PSIP D. Bryan 3 Internet-Draft SIPeerior Technologies, Inc. 4 Intended status: Standards Track B. Lowekamp 5 Expires: August 29, 2007 SIPeerior; William & Mary 6 C. Jennings 7 Cisco Systems 8 February 25, 2007 10 dSIP: A P2P Approach to SIP Registration and Resource Location 11 draft-bryan-p2psip-dsip-00 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 29, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document outlines the motivation, requirements, and 45 architectural design for a distributed Session Initiation Protocol 46 (dSIP). dSIP is a Peer-to-Peer (P2P) based approach for SIP 47 registration and resource discovery using distributed hash tables 48 maintained with SIP messages. This design removes the need for 49 central servers from SIP, while offering full backward compatibility 50 with SIP, allowing reuse of existing clients, and allowing P2P 51 enabled peers to communicate with conventional SIP entities. A basic 52 introduction to the concepts of P2P is presented, backward 53 compatibility issues addressed, and security considerations are 54 discussed. 56 dSIP is one possible implementation of the protocols being discussed 57 for creation in the P2PSIP WG. In the context of the work being 58 proposed, this draft represents a concrete proposal for the P2PSIP 59 Peer Protocol, using SIP with extensions as the underlying protocol. 60 In this architecture, no P2PSIP Client Protocol is needed, rather 61 unmodified SIP is used for access by non-peers. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.1. Peer-to-Peer Fundamentals . . . . . . . . . . . . . . . . 6 70 3.2. DHTs and Overlay Structure . . . . . . . . . . . . . . . . 7 71 3.3. P2PSIP . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 4. The Architecture of dSIP . . . . . . . . . . . . . . . . . . . 8 73 4.1. Peer Functions and Behavior in dSIP . . . . . . . 9 74 4.2. P2P Overlay Structure . . . . . . . . . . . . . . . . . . 10 75 4.3. Use of SIP Messages in dSIP . . . . . . . . . . . . . . . 11 76 4.4. Routing in dSIP . . . . . . . . . . . . . . . . . . . . . 12 77 4.4.1. dSIP Operations . . . . . . . . . . . . . . . . . . . 13 78 4.5. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 15 79 5. Message Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15 80 5.1. Option Tags . . . . . . . . . . . . . . . . . . . . . . . 16 81 5.2. Hash Algorithms and Identifiers . . . . . . . . . . . . . 16 82 5.2.1. Peer-IDs . . . . . . . . . . . . . . . . . . . . . . . 16 83 5.2.2. Resource-IDs and the Replication . . . . . . . . . . . 17 84 5.3. P2PSIP URIs . . . . . . . . . . . . . . . . . . . . . . . 17 85 5.3.1. Peer URIs . . . . . . . . . . . . . . . . . . . . . . 17 86 5.3.2. Resource URIs and the resource-ID URI Parameter . . . 18 87 5.4. The DHT-PeerID Header and Overlay Parameters . . . . . . . 19 88 5.4.1. Hash Algorithms and the algorithm Parameter . . . . . 19 89 5.4.2. Overlay Names and the overlay Parameter . . . . . . . 20 90 5.4.3. DHT Algorithms and the dht Parameter . . . . . . . . . 21 91 5.4.4. PeerID Expires header parameter . . . . . . . . . . . 21 92 5.5. The DHT-Link Header . . . . . . . . . . . . . . . . . . . 21 93 5.5.1. Expires Processing . . . . . . . . . . . . . . . . . . 22 94 6. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 22 95 6.1. Peer Registration . . . . . . . . . . . . . . . . . . . . 23 96 6.2. Resource Registration . . . . . . . . . . . . . . . . . . 23 97 6.3. Session Establishment . . . . . . . . . . . . . . . . . . 24 98 6.4. DHT Maintenance . . . . . . . . . . . . . . . . . . . . . 24 99 7. Peer/DHT Operations . . . . . . . . . . . . . . . . . . . . . 25 100 7.1. Peer Registration . . . . . . . . . . . . . . . . . . . . 25 101 7.1.1. Constructing a Peer Registration . . . . . . . . . . . 25 102 7.1.2. Processing the Peer Registration . . . . . . . . . . . 27 103 7.2. Peer Query . . . . . . . . . . . . . . . . . . . . . . . . 29 104 7.2.1. Constructing a Peer Query Message . . . . . . . . . . 29 105 7.2.2. Processing Peer Query Message . . . . . . . . . . . . 30 106 7.3. Populating the Joining Peer's Routing Table . . . . . . . 31 107 7.4. Transfering User Registrations . . . . . . . . . . . . . . 31 108 7.5. Peers Leaving the Overlay Gracefully . . . . . . . . . . . 31 109 7.6. NAT and Firewall Traversal . . . . . . . . . . . . . . . . 32 110 7.7. Handling Failed Requests . . . . . . . . . . . . . . . . . 32 111 8. Resource Operations . . . . . . . . . . . . . . . . . . . . . 32 112 8.1. Resource Registrations . . . . . . . . . . . . . . . . . . 32 113 8.2. Refreshing Resource Registrations . . . . . . . . . . . . 33 114 8.3. Removing Resource Registrations . . . . . . . . . . . . . 34 115 8.4. Querying Resource Registrations . . . . . . . . . . . . . 34 116 8.5. Session Establishment . . . . . . . . . . . . . . . . . . 34 117 8.6. Presence . . . . . . . . . . . . . . . . . . . . . . . . . 35 118 8.7. Offline Storage . . . . . . . . . . . . . . . . . . . . . 35 119 9. Pluggable DHT Algorithm Requirements . . . . . . . . . 35 120 10. Security Considerations . . . . . . . . . . . . . . . . . . . 36 121 10.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 36 122 10.2. Protecting the ID Namespace . . . . . . . . . . . . . . . 37 123 10.2.1. Protection Using ID Hashing . . . . . . . . . . . . . 37 124 10.2.2. Cryptographic Protection . . . . . . . . . . . . . . . 38 125 10.3. Protecting the resource namespace . . . . . . . . . . . . 38 126 10.4. Protecting the Routing . . . . . . . . . . . . . . . . . . 39 127 10.5. Protecting the Signaling . . . . . . . . . . . . . . . . . 39 128 10.6. Protecting the Media . . . . . . . . . . . . . . . . . . . 39 129 10.7. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 39 130 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 39 131 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39 132 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 133 14. Changes to this Version . . . . . . . . . . . . . . . . . . . 40 134 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 135 15.1. Normative References . . . . . . . . . . . . . . . . . . . 41 136 15.2. Informative References . . . . . . . . . . . . . . . . . . 42 137 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 138 Intellectual Property and Copyright Statements . . . . . . . . . . 44 140 1. Introduction 142 As SIP [1] and SIMPLE based Voice over IP (VoIP) and Instant 143 Messaging (IM) systems have increased in popularity, situations have 144 emerged where centralized servers are either inconvenient or 145 undesirable. For example, a group of users wishing to communicate 146 between each other, but using machines that are not consistently 147 connected to the network, are often forced to use a central server 148 that is outside the control of the group. Similarly, groups wishing 149 to establish ephemeral networks for use in meetings, conferences, or 150 classes often do not wish to configure a centralized server. 151 Organizations may also want to allow their members to communicate 152 with each other without traffic flowing to third parties, but may not 153 have the staff or equipment to maintain a server. 155 Peer-to-Peer (P2P) computing has emerged as a mechanism for 156 completely decentralized, server-free implementations of various 157 applications. In particular, many recent efforts have focused on 158 applying P2P to SIP within the IETF, starting with the forerunners of 159 this document submitted by the authors. Since then a substantial 160 usecases document [15] has emerged and, most recently, a concepts and 161 terminology [2] document has helped define a common set of terms. 162 This iteration of this document incorporates the terminology from 163 that draft. 165 This draft presents dSIP, a SIP based system that uses P2P mechanisms 166 to remove the need for central servers in SIP and SIMPLE based 167 communications systems. While this draft evolved from early work 168 done on the SoSIMPLE [16] P2PSIP project, it has changed extensively. 169 This works reflects experience gained in actually building 170 commercially available P2PSIP products based on this draft, as well 171 as from extensive work/insight gleaned from the P2PSIP mailing list. 173 2. Terminology 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in RFC 2119 [3]. 179 Terminology defined in RFC 3261 [1] is used without definition. 181 We use the terminology and definitions from the Concepts and 182 Terminology for Peer to Peer SIP [2] draft extensively in this 183 document without further definition. Other terms used in this 184 document are defined inline when used and are also defined below for 185 reference. 187 In this illustrative purposes in this document we sometimes use 10 188 hexadecimal digit values for SHA-1 hashes. In reality, SHA-1 189 produces 40 digit values. They are shortened in this document for 190 clarity and typographical considerations only. 192 2.1. Definitions 193 Peer-to-Peer (P2P) Architecture: An architecture in which peer nodes 194 cooperate together to perform tasks. Each peer has essentially 195 equal importance and performs the same tasks within the network. 196 Additionally, peers communicate directly with one another to 197 perform tasks. Contrast this to a Client-Server architecture. 198 Client-Server Architecture: An architecture in which some small 199 number of nodes (servers) provide services to a larger number of 200 nodes (clients). Client nodes initiate connections to servers, 201 but typically do not communicate among themselves. 202 Conventional SIP: The architecture used by SIP as defined by 203 RFC3261, RFC3263, and many others. Conventional SIP centralizes 204 certain roles, such as registrar, but allows for direct end-to-end 205 establishment of dialogs and media connections. 206 Distributed Hash Table (DHT): A mechanism in which resources are 207 given a unique key produced by hashing some attribute of the 208 resource, locating them in a hash space (see below). Peers 209 located in this hash space also have a unique ID within the hash 210 space. Peers store information about resources with keys that are 211 numerically similar to the peer's ID in the hash space. 212 Namespace or hash space: The range of values that valid results from 213 the hash algorithm fall into. For example, using the SHA-1 214 algorithm, the namespace is all 40 digit hexadecimal identifiers. 215 This namespace forms the set of valid values for Peer-IDs and 216 Resource-IDs (see below). 217 Routing Table: The list of peers that a peer uses to send messages 218 to when routing. The structure and makeup of this table varies 219 depending on the particular DHT selected. 220 Connection Table: A list of peers that the peer currently is 221 maintaining open connections to. In general, this is a superset 222 of the Routing Table. The extra entries may be cached entries for 223 efficiency or additional entries needed for NAT traversal 224 purposes. 225 Neighbors: A collection of peers that a particular peer can reach in 226 one hop. In general, note that a peer's set of neighbors is 227 equivalent to the entries in that peer's Routing Table. However, 228 neighbors may include one or more peers that immediately precede 229 the peer (predecessors) and one or more peers that immediately 230 follow the peer in the namespace (successor peers). Note that 231 neighbor relations do NOT have to be symmetric. 233 Adapter Peer: An adapter peer is a peer in the overlay that acts as 234 an adapter for other non-P2P enabled SIP entities, allowing them 235 to access the resources of the overlay. The adapter peer 236 participates actively in the overlay network, while the non-P2P 237 enabled SIP entities it provides service to DO NOT participate 238 directly in the overlay. Compare these to the term "super peer" 239 in the P2P community, although adapter peers may be thin software 240 shims intended for only one client. 241 Peer Admission: The act of a peer joining the overlay. Registration 242 allows a peer to communicate with other peers, and requires 243 (allows?) it to take on some server-like responsibilities such as 244 maintaining resource location information. It DOES NOT register 245 the user so that they can receive phone calls, which is the 246 conventional SIP use of the word registration. We refer to 247 conventional SIP registration as "user registration". 248 User Registration: The act of a user registering themselves with a 249 SIP network. User registration creates a mapping between a SIP 250 URI and a contact for a user. This is the conventional meaning of 251 registration in SIP. For a dSIP peer, this action MUST occur 252 after peer registration. User or resource registration are terms 253 used in this draft to refer to P2PSIP Resource Record Insertion, 254 with the additional requirement that the resource's (user's) peer 255 must first be admitted. 256 Joining Peer: During the peer admission process, this is the peer 257 that is attempting to register -- that is, the peer that is 258 attempting to join the overlay network. 259 Bootstrap Peer: During the process of peer registration, the 260 bootstrap peer is the peer that the joining peer contacts. This 261 peer may be a well-known peer, a peer located using a broadcast 262 method, a peer that the joining peer previously knew about, or a 263 peer that another bootstrap peer referred the joining peer to. 264 The bootstrap peer MAY validate the joining peer's credentials and 265 help the joining peer in opening connections to the admitting 266 peer, but its primary purpose is to direct the joining peer to the 267 admitting peer. 268 Admitting Peer: During the process of peer registration, this is the 269 peer that is currently responsible for the portion of the 270 namespace the new peer will eventually reside in. This peer is 271 responsible for generating many of the messages exchanged during 272 peer registration. 274 3. Background 276 3.1. Peer-to-Peer Fundamentals 278 The fundamental principle behind Peer-to-Peer (P2P) Architectures is 279 that applications are provided by number of entities, called peers or 280 nodes working together with each other to accomplish tasks. Each and 281 every peer is responsible for contributing to serving some of the 282 transactions that take place on the network. Contrast this with the 283 more traditional Client-Server Architecture in which a large number 284 of clients communicate only with a small number of central servers 285 responsible for performing tasks. 287 Each peer provides server-like functionality and services as well as 288 being a client within the system. In this way, the services or 289 resources that would be provided by a centralized entity are instead 290 available in a distributed fashion from the peers of the system. 291 Note that a particular peer may or may not provide a particular 292 service, but some peer does, ensuring that collectively the peers can 293 provide that particular service. The peers form a logical cluster of 294 peers called an overlay or overlay network. The services provided 295 are often said to be provided by the overlay, since collectively the 296 members provide the services. The overlay is so named because they 297 form a new, small sub-network at a higher logical level than lower 298 level network connections. 300 In many P2P systems peers are assumed to be ephemeral in nature. A 301 peer may join or leave the overlay at any time. The design of 302 algorithms for P2P architectures take this into account. Information 303 is replicated, and the topology of the overlay can be quickly adapted 304 as peers enter and leave. 306 3.2. DHTs and Overlay Structure 308 While very early P2P systems used flood based techniques, most newer 309 P2P systems locate resources using a Distributed Hash Table, or DHT 310 to improve efficiency. Peers are organized using a Distributed Hash 311 Table (DHT) structure. In such a system, every resource has a 312 Resource-ID, which is obtained by hashing some keyword or value that 313 uniquely identifies the resource. Resources can be thought of as 314 being stored in a hash table at the entry corresponding to their 315 Resource-ID. The peers that make up the overlay network are also 316 assigned an ID, called a Peer-ID, in the same hash space as the 317 Resource-IDs. A peer is responsible for storing all resources that 318 have Resource-IDs near the peer's Peer-ID. The hash space is divided 319 up so that all of the hash space is always the responsibility of some 320 particular peer, although as peers enter and leave the system a 321 particular peer's area may change. Messages are exchanged between 322 the peers in the DHT as the peers enter and leave to preserve the 323 structure of the DHT and exchange stored entries. Various DHT 324 implementations may visualize the hash space as a grid, circle, or 325 line. 327 Peers keep information about the location of other peers in the hash 328 space and typically know about many peers nearby in the hash space, 329 and progressively fewer more distant peers. We refer to this table 330 of other peers as a Routing Table. When a user wishes to search, 331 they consult the list of peers they are aware of and contact the peer 332 with the Peer-ID nearest the desired Resource-ID. If that peer does 333 not know how to find the resource, it either returns information 334 about a closer peer it knows about, or forwards the request to a 335 closer peer. In this fashion, the request eventually reaches the 336 peer responsible for the resource, which then replies to the 337 requester. 339 3.3. P2PSIP 341 Unlike a conventional SIP architecture, P2PSIP systems require no 342 central servers. In a conventional SIP architecture many UAs connect 343 to one or more central servers which play a number of roles, 344 including proxy server, registrar, presence server, and redirect 345 server. In a P2PSIP architecture, the peers participating in the 346 overlay not only act as conventional SIP UAs, allowing their users to 347 place and receive calls, but, when viewed collectively with the other 348 peers, perform the roles normally provided by a central server. Each 349 participating peer will maintain some fraction of the information 350 that would normally be maintained by the central servers in a 351 conventional SIP network. 353 P2PSIP peers provide many functions, more than any single entity in a 354 conventional SIP architecture. Minimally, a participating peer must 355 be an active member of the overlay, participating in storage of 356 resources, routing and providing some SIP "server-like" behaviors as 357 well. In the terminology used in the concepts draft, these peers 358 speak the P2PSIP Peer Protocol to organize among themselves. 360 The general concepts are more fully explained in the Concepts and 361 Terminology for Peer to Peer SIP [2] draft. 363 4. The Architecture of dSIP 365 In this section we provide an overview of the architecture of dSIP 366 and explain how it works in an informative way. Protocol details and 367 syntax are provided in a normative form in the remainder of the 368 document. 370 dSIP is a specific proposal for the P2PSIP Peer Protocol proposed in 371 the Concepts and Terminology for Peer to Peer SIP [2] draft, using 372 SIP messages as the syntax for encoding the protocol. The function 373 of the P2PSIP Peer Protocol is to provide for mechanisms to maintain 374 the overlay, as well as to store and retrieve information, and to 375 route messages when needed. dSIP's syntax is SIP with a number of 376 newly defined headers, however no new methods are added to SIP in 377 dSIP. 379 Because dSIP uses conventional SIP messages, the mechanisms used for 380 NAT traversal in SIP, including STUN [4], TURN [17], and ICE [5] are 381 reused, as explained in NAT Traversal for dSIP [6]. As a 382 consequence, many peers are able to participate in the overlay even 383 when behind NATs. For those that cannot for some reason, 384 conventional SIP can be used, and these peers can connect using 385 adapter peers, as described below. Since conventional SIP is used 386 for this, there is no need for a P2PSIP Client Protocol, and 387 therefore dSIP defines no such protocol. 389 dSIP is modular, allowing for the use of multiple DHTs, including 390 those defined later. DHTs can be negotiated among the peers in much 391 the same way as codecs or features are negotiated in conventional 392 SIP. For compatibility, support for one basic DHT algorithm, Chord, 393 is required. Additional DHTs can be added and supported. We detail 394 the Chord algorithm for dSIP [7] and provide an alternate DHT 395 algorithm for dSIP, based on Bamboo [8]. Note that this document 396 does not specify the details of the DHTs, including Chord. These are 397 defined in their own documents, which describe how the basic dSIP 398 operations and syntax are used to implement that specific DHT 399 algorithms. Our intention and hope is that others will design other 400 overlay algorithms that rely on the same basic operations so that 401 compatibility can be maintained. 403 4.1. Peer Functions and Behavior in dSIP 405 dSIP peers provide many functions, more than any single entity in a 406 conventional SIP architecture. Minimally, a participating peer must 407 be an active member of the overlay and must provide some SIP "server- 408 like" behaviors as well. The code that implements the additional 409 server-like and DHT behavior can be located in several places in the 410 network. The simplest is to have peers that are endpoints directly 411 joining the overlay as peers. In this case, these peers provide the 412 basic functionality of any SIP endpoint, but additionally implement 413 the operations described in this document to enable self-organization 414 and provide SIP server-like functionality. 416 The behavior can also be located in an adapter peer, which allows one 417 or more non-P2P aware SIP UAs (UAs that do not speak dSIP) to 418 interact with the P2P overlay network. These adapters perform the 419 additional self-organizing and SIP server-like behavior on behalf of 420 the UA or UAs they support. In this case, only the adapter peer is a 421 peer in the overlay, the UAs are not peers themselves. In this 422 approach, the adaptors speak the P2PSIP Peer Protocol (dSIP in this 423 case), where the UAs speak conventional SIP. All interaction with 424 the P2P overlay is carried out by the adapter peer. The adapter 425 essentially acts as a proxy server for the unmodified SIP UAs. The 426 adapter can take the form of a small software shim or may be code 427 within a conventional RFC 3261 server. 429 In most places in this document, which type of peer we are discussing 430 won't affect the discussion. In those cases where it will, we have 431 noted the differences. 433 4.2. P2P Overlay Structure 435 The P2P overlay in dSIP consists of peers, which collectively serve 436 as a directory service for locating resources (users, voicemail 437 messages, etc.). Peers are organized using a supported Distributed 438 Hash Table (DHT) P2P structure. dSIP allows for pluggable DHT 439 algorithms the exact form of which is defined in the DHT algorithm 440 definition. 442 Each peer is assigned a Peer-ID, and each resource that is stored in 443 the overlay is assigned a Resource-ID. These values must map to the 444 same name space. dSIP provides for various algorithms to be used to 445 produce these values, although all members of the overlay must use 446 the same algorithm. For example, in the Chord DHT implementation, 447 SHA-1 is used to produce 160 bit values for both the Peer-ID and 448 Resource-ID. 450 The Peer-ID assigned to each peer determines the peer's location in 451 the DHT and the range of Resource-IDs for which it will be 452 responsible. The exact mapping between these is determined by the 453 DHT algorithm used by the overlay. The mechanism for selecting these 454 Peer-IDs depends on the security mechanism being used by the overlay. 455 For example, a simple SHA-1 hash of the IP address and the port of 456 the peer could be used to generate the Peer-IDs or alternatively, a 457 certificate based system in which CAs assign Peer-IDs could be used 458 to obtain the Peer-IDs [9]. 460 Every resource has a Resource-ID, obtained by hashing some keyword 461 that identifies the resource. The Resource-IDs map to the same space 462 as the Peer-IDs. In the case of users, the unique keyword is the 463 userid and the resource is the registration -- a mapping between the 464 user name and a contact. Resources can be thought of as being stored 465 in the distributed hash table at a location corresponding to their 466 Resource-ID. Because entities searching for resources must be able 467 to locate them given the unique keyword, Resource-IDs are produced by 468 hashing, and are never assigned, regardless of the DHT and security 469 algorithms being used. 471 A resource with Resource-ID k will be stored by the peer with Peer-ID 472 closest to the Resource-ID, as defined by the particular pluggable 473 DHT algorithm being used. As peers enter and leave, resources may be 474 stored on different peers, so the information related to them is 475 exchanged as peers enter and leave. Redundancy is used to protect 476 against loss of information in the event of a peer failure and to 477 protect against compromised or subversive peers. 479 Since each DHT is defined and functions differently, we generically 480 refer to the table of other peers that the DHT maintains and uses to 481 route requests (neighbors) as a Routing Table. dSIP defines the 482 syntax for the headers used to exchange these entries, but leaves the 483 exact form of the data each DHT stores in the table as a decision for 484 the DHT implementation. Peers may additionally maintain a list of 485 peers to which they maintain connections for purposes other than 486 routing, for example NAT traversal or caching. This larger table 487 (usually a superset of the routing table) is referred to as the 488 connection table in dSIP. In this draft, we refer to routing 489 decisions being made from the entries in the routing table, although 490 a peer might choose an entry from the connection table if it is a 491 better match. 493 When locating a resource with a particular Resource-ID, the peer will 494 send the request to the routing table entry with the Peer-ID closest 495 to the desired Resource-ID, as defined by the particular DHT in use. 496 Since DHTs must converge on the resource, the peer receiving the 497 request is assumed to know of a peer with a Peer-ID closer to the 498 Resource-ID, and responds by suggesting or forwarding the message to 499 this peer, depending on the routing mechanism being used. 501 4.3. Use of SIP Messages in dSIP 503 dSIP uses SIP messages to implement the P2PSIP Peer Protocol. This 504 was done for a number of reasons. In order to properly implement a 505 P2PSIP protocol, it is necessary to have mechanisms to store, 506 retrieve and query the locations of resources, as well as to route 507 information. NAT traversal and security considerations require 508 several techniques for routing information, as discussed below. 509 Pluggable hashing techniques and DHT algorithms require capabilities 510 to negotiate the use of these pluggable modules. We have found SIP 511 offers mechanisms that meet all of these requirements today, has well 512 defined security mechanisms, and additionally works well with the 513 IETF suite of NAT traversal techniques: STUN, TURN and ICE. Because 514 all this work would need to be redefined in a new P2PSIP protocol, 515 and because all P2PSIP devices must, by definition, implement SIP 516 anyway, we feel the only reasonable syntax choice for the P2PSIP Peer 517 Protocol is SIP. 519 Our motivation throughout has been to preserve the semantics of 520 conventional SIP messages to the extent possible. All of the 521 messages that are needed to maintain the DHT, as well as those needed 522 to query for information, are implemented using SIP messages. 523 Fundamentally, messages are being exchanged for two purposes. The 524 purpose of the first class of messages is to maintain the DHT, such 525 as the messages needed to join or leave the overlay, and to transfer 526 information between peers. The second type of message is the type 527 most SIP users will be familiar with -- registering users, inviting 528 other users to a session, etc. -- basic session establishment. As 529 the DHT is used as a distributed registrar, the registration and 530 other searches are performed within the DHT. Once the target 531 resource has been located, further communication proceeds directly 532 between the UAs (or designated adapter peers) as with conventional 533 SIP communications. 535 The messages used to manipulate the DHT are SIP REGISTER messages. 536 RFC 3261, Section 10.2, specifies that REGISTER messages are used to 537 "add, remove, and query bindings." Accordingly, we have selected 538 REGISTER methods to use to add, remove, and query bindings. We use 539 REGISTER both for the bindings of hosts as neighbors (entries in the 540 routing table) in DHT maintenance operations as well as the bindings 541 of resource names to locations that are commonly maintained by SIP 542 registrars. The only fundamental difference is that these operations 543 occur within the overlay, rather than on the conventional server. 545 4.4. Routing in dSIP 547 When a peer sends a message within the DHT, it begins by calculating 548 the target ID it is attempting to locate, using the particular 549 algorithm used by the overlay. The target could be another user, a 550 particular resource, or a peer (including itself) for DHT maintenance 551 purposes. It then consults its routing table, and its other neighbor 552 peers, for the closest peer it is aware of to the target ID, as 553 defined by the closeness metric of the DHT in use. 555 In discussions of P2PSIP, several mechanisms have been discussed for 556 routing. In each case, the initial message is sent from the 557 requester to the peer in the routing table most likely to route 558 correctly, as defined by the DHT algorithm in use. Subsequently, 559 that peer may provide further routing using one of three mechanisms. 560 These three types of routing are: 561 o Iterative: If the contacted peer is not responsible for the target 562 ID, then the contacted peer issues a 302 redirect response 563 pointing the search peer toward the best match the contacted peer 564 has for the target ID. The searching peer then contact the peer 565 to which it has been redirected and the process iterates until the 566 responsible peer is located. 568 o Recursive: If the contacted peer is not responsible for the target 569 ID, it will forward the query to the nearest peer to the target 570 that it knows, and the process repeats until the target is 571 reached. The response unwinds and follows the same path on the 572 message return. Because dSIP uses SIP messages for transport, 573 SIP's proxy behavior is used to enable recursive routing. 574 o Semi-Recursive: Semi-Recursive is the same as Recursive routing on 575 the outbound leg, but the reply "shortcuts" and is directly sent 576 back to the requester. When discussing these techniques, we often 577 just refer to Iterative and Recursive, because of the similarity 578 between recursive and semi-recursive routing. 580 Various mechanisms may be used within the same overlay and even 581 within the same search. For example, a search may start as 582 iterative, but if a particular peer receiving the request knows that 583 the requester cannot reach the next hop directly (perhaps due to NAT 584 issues), the search may have recursive and iterative portions. 586 In general, the messages can be routed using any of these mechanisms, 587 and this draft does not specify which mechanism will be used. The 588 decision as to which mechanism is appropriate may be a factor of 589 security, NAT traversal, or even the properties of the particular DHT 590 being used. We generally refer to the message as being routed 591 through the overlay. 593 4.4.1. dSIP Operations 595 dSIP provides mechanisms that are used for a number of operations. 597 4.4.1.1. Peer Registration 599 When a peer (called the joining peer) wishes to join the overlay, it 600 determines its Peer-ID and sends a REGISTER message to a bootstrap 601 peer already in the overlay, requesting to join. Any peer in the DHT 602 may serve as a bootstrap peer. The mechanism for selecting bootstrap 603 peers is application dependent, and discussed in Bootstrapping 604 (Section 4.5). 606 Following the iterative routing scheme, the bootstrap peer looks up 607 the peer it knows nearest to the Peer-ID of the joining peer and 608 responds with 302 redirect to this closer peer. The joining peer 609 will repeat this process until it reaches the peer currently 610 responsible for the space it will occupy. 612 If recursive routing is being used, the bootstrap peer looks up the 613 peer it knows nearest to the Peer-ID of the joining peer and forwards 614 the REGISTER message to that peer. This process of forwarding the 615 message repeats until the peer currently responsible for the space 616 the joining peer will occupy is found. 618 Once the peer responsible for the joining peer's portion of the 619 namespace is located, the joining peer then exchanges DHT state 620 information with this peer, called the admitting peer, to allow the 621 joining peer to learn about other peers in the overlay (neighbors) 622 and to obtain information about resources the joining peer will be 623 responsible for maintaining. Other DHT maintenance messages will be 624 exchanged later to maintain the overlay as other peers enter and 625 leave, as well as to periodically verify the information about the 626 overlay, but once the initial messages are exchanged, a peer has 627 joined the overlay. 629 4.4.1.2. Resource Registration 631 The peer registration does not register the peer's user(s) or other 632 resources with the P2PSIP network -- it has only allowed the peer to 633 join the overlay. Once a peer has joined the overlay, the user that 634 peer hosts must be registered with the system. This process is 635 referred to as resource registration. This registration is analogous 636 to the conventional SIP registration, in which a message is sent to 637 the registrar creating a mapping between a SIP URI and a user's 638 contact. The only difference is that since there is no central 639 registrar, some peer in the overlay will maintain the registration on 640 the users behalf. 642 Resource registrations are routed similarly to peer registrations. 643 The resource's peer calculates the resource-ID and contacts the peer 644 it is aware of nearest to the resource-ID. This search process 645 continues in either an iterative or recursive manner until the 646 responsible peer is located. This peer then stores the registration 647 for that user and returns a 200 response. 649 For redundancy, resources should also be registered at additional 650 peers within the overlay. These replicas are located by adding a 651 replica number to the resource name and hashing to identify a new 652 resource-ID for each replica. In this way, replicas are located at 653 unrelated points around the DHT, minimizing the risk of an attacker 654 compromising more than one registration for a single resource. 656 4.4.1.3. Session Establishment 658 Sessions are established by contacting the UA identified by the 659 registration in the DHT. The first step in establishing a session is 660 locating this peer, which is done by searching for a resource in the 661 DHT. The name of the target resource is used to calculate a 662 resource-ID and a REGISTER message with no Contact information (a 663 conventional SIP search) is sent to the closest known peer to that 664 resource-ID. The search iterates until the responsible peer is 665 located. The responsible peer then returns either a 200 OK with the 666 Contact information for the resource or a 404 Not Found. The session 667 is then initiated directly with the resource's UA. 669 4.4.1.4. DHT Maintenance 671 In order to keep the overlay stable, peers must periodically perform 672 book keeping operation to take into account peer failures. These DHT 673 maintenance messages are sent using REGISTER messages and the overlay 674 algorithm being used will dictate how often and where these messages 675 are sent. 677 DHT maintenance messages are routed similarly to peer registrations 678 and resource registrations. The peer calculates the Peer-ID of the 679 peer it wants to exchange DHT information with and contacts the peer 680 it is aware of closest to that Peer-ID. This search process 681 continues in either an iterative or recursive manner until the peer 682 is located at which point the peers exchange DHT maintenance 683 information. 685 4.5. Bootstrapping 687 When a peer wishes to join an existing overlay, it must first locate 688 some peer that is already participating in the overlay, referred to 689 as the bootstrap peer. Peers may use any method they choose to 690 locate the initial bootstrap peer --- the decision is outside the 691 scope of this specification. The following are a few of the many 692 methods that may be used: 693 Static Locations: Some number of peers in the overlay may be 694 persistent and have well know addresses. These addresses could be 695 configured into the peer application or obtained using an out-of- 696 band mechanism such as a web page. 697 Cached Peers: While this mechanism cannot be used the first time 698 that a peer runs, on subsequent attempts to join the overlay a 699 peer might attempt to use a previously contacted peer as a 700 bootstrap peer. 701 Broadcast mechanisms: Peers can use a broadcast mechanism to locate 702 the initial peer, for example by sending the first REGISTER 703 message to the SIP multicast address. 705 5. Message Syntax 707 This section provides normative text explaining the syntax of the 708 extensions we use for SIP messages. 710 5.1. Option Tags 712 We create a new option tag "dht" as described in RFC 3261. This 713 option tag indicates support for DHT based P2PSIP. Peers MUST 714 include a Require and Supported header with the option tag dht for 715 all messages that are intended to be processed using dSIP or include 716 P2P extensions. Clients supporting P2P and contacting another SIP 717 entity using a non-P2P mechanism for a transaction that may or may 718 later be P2P SHOULD include a Supported header with dht. For a 719 typical session establishment the search within the DHT MUST specify 720 Require dht, whereas the actual contact with the resource's UA SHOULD 721 include a Supported header with dht but SHOULD NOT include a Require 722 header with dht. 724 5.2. Hash Algorithms and Identifiers 726 All IDs used for an overlay must be calculated using the same 727 algorithm. Implementations MUST support the SHA-1 algorithm, which 728 produces a 160 bit hash value. The hash algorithm used is specified 729 in the DHT-PeerID header, described below. An implementation MAY 730 rely on a secret initialization vector, key, or other shared secret 731 to use the identifier as an HMAC, from RFC 2104 [10] such that no 732 peer may join the overlay without knowledge of the shared secret, 733 however this technique by itself does not protect the overlay against 734 replay attacks. See Security Extensions to the Distributed Session 735 Initiation Protocol (dSIP) [9]for information on how to protect 736 against replay attacks. 738 Both Peer-IDs and Resource-IDs MUST have the same range of values 739 (map to the same space). Formally: 741 P2PID = token 743 When using SHA-1: 745 P2PID = 40LHEX 747 5.2.1. Peer-IDs 749 The particular DHT algorithm being used MAY specify an alternate 750 mechanism for determining Peer-ID. Similarly, some security models 751 may assign Peer-IDs from a central authority. In the event that 752 neither of these mechanisms are being used, the Peer-ID MUST be 753 formed by taking the IP address of the peer, without the colon or 754 port, and with no leading zeros, and hashing this string with the 755 hash algorithm. Then the least significant sixteen bits of the hash 756 are replaced by the port used by the peer. For peers behind a NAT 757 participating in an overlay on the public Internet, they must 758 identify their address on the public Internet through a protocol such 759 as STUN [4] and use this address for their Peer-ID. 761 The string hashed to obtain the PeerID is formally defined below as 762 ipaddress. 764 ipaddress = IPV4address / IPv6reference 766 PeerID is formally defined as: 768 PeerID = P2PID 770 5.2.2. Resource-IDs and the Replication 772 Resource-IDs MUST be formed by hashing the resource URI after 773 converting it to canonical form. To do that, all URI parameters MUST 774 be removed (including the user-param) except for the replica URI 775 parameter, Any escaped characters MUST be converted to their 776 unescaped form. Formally: 778 ResourceID = P2PID 780 5.3. P2PSIP URIs 782 Because hashing URIs to produce identifiers is a non-trivial cost, 783 dSIP messages are constructed including these values already 784 calculated. This is strictly as a courtesy to peers processing 785 messages for this peer, as it prevents them from having to hash the 786 URI again before routing. Identifiers provided in a message are a 787 courtesy only and MUST NOT be used when making any changes to the 788 data stored in an overlay, as they may be spoofed or incorrect. If 789 the hash parameter is used incorrectly for routing, this only affects 790 the transmitting peer's user. If it is used to insert or modify 791 stored information, it can affect the system's integrity. Peers MUST 792 verify the hash of all URIs before making changes that affect the 793 overlay. 795 5.3.1. Peer URIs 797 A P2PSIP peer is represented by constructing a SIP-URI (or SIPS-URI) 798 with the keyword "peer" or a short form of "P" for the userinfo 799 portion. The URI parameter "peer-ID", or the short form "pID" MUST 800 be used. 802 PeerURI = ("peer@" / "P@") hostport ";" PeerID-Param ";" 803 uri-parameters 805 Formally, the peerID uri-parameter is defined as type other-param 806 from RFC 3261 with a pname of "peerID" or "pID" for short form, and a 807 pvalue which is of type PeerID. A peer receiving a PeerURI MUST 808 verify the hash value of the PeerID-Param before using it to update 809 its routing table. 811 PeerID-Param = ("peer-ID" / "pID") EQUAL PeerID 813 For search operations, where an identifier is being searched for, but 814 the host responsible for that identifier is unknown, hostport MUST be 815 set to "0.0.0.0". All non-search operations MUST specify a valid 816 hostport. 818 P2P Peer URIs MUST NOT include the resource-ID URI parameter (below), 819 as it is intended to define information about resources that are 820 stored in the overlay, not information about the peers making up the 821 overlay. P2P Peer URIs used in name-addr SHOULD NOT include any 822 display-name information, and peers receiving name-addrs for peers 823 with display-name information MUST ignore the information. 825 Examples, using a shortened hash for clarity: 826 The URI for a peer using the SHA-1 hash algorithm, with 827 hashed ID ed57487add matching an IP address 10.6.5.5 used 828 in a To header. Uses the short forms: 830 To: 832 The URI for a peer using the SHA-1 hash algorithm, with 833 hashed ID ed57487add matching an IP address 10.6.5.5 used 834 in a To header. Uses the long forms: 836 To: 838 5.3.2. Resource URIs and the resource-ID URI Parameter 840 Resource URIs are no different for P2PSIP resources than for non-P2P 841 SIP applications. However, because calculating the ResourceID is a 842 significant expense, the optional URI parameter resource- 843 ID= or the short form rID= SHOULD be 844 provided. This parameter is a courtesy only and MUST NOT be used 845 when making any changes to the data stored in an overlay without 846 being recalculated, as it may be spoofed or incorrect. The 847 resource-ID URI parameter is of type other-param as defined in RFC 848 3261. 850 resourceID-param = ("resource-ID" \ "rID") EQUAL ResourceID 852 P2P Resource URIs MUST NOT include the PeerID-Param URI parameter, 853 because this indicates that the target of the URI is a peer. P2P 854 Resource URIs MAY include other user-parameters such as user=phone. 856 Examples (again using shortened hashes for clarity): 857 The URI for a user resource with username bob@p2psip.org using 858 the SHA-1 hash algorithm, with hashed Resource-ID 723fedaab1. 859 The optional resource-ID URI parameter is included, using the 860 long form: 862 sip:bob@p2psip.org;resource-ID=723fedaab1 864 The URI for a user resource with username bob@p2psip.org using 865 the SHA-1 hash algorithm, with hashed Resource-ID 723fedaab1. 866 The optional resource-ID URI parameter is included, using the 867 short form: 869 sip:bob@p2psip.org;rID=723fedaab1 871 The URI, used in a To header for user Alice White, with username 872 alice@p2psip.org. This example omits the optional resource-ID URI 873 parameter: 875 To: "Alice White" 877 5.4. The DHT-PeerID Header and Overlay Parameters 879 We introduce a new SIP header called the DHT-PeerID header. This 880 header is used to express the Peer-ID of the sending peer as well as 881 to identify the name and parameters of the overlay. The format of 882 the DHT-PeerID header is as follows: 884 DHT-PeerID = "DHT-PeerID" HCOLON PeerURI SEMI algorithm SEMI 885 dht-param SEMI overlay-param *(SEMI generic-param) 887 Examples: 888 A peer with an SHA-1 hashed Peer-ID of a04d371e on IP 192.168.1.1. 889 We include the PeerURI, algorithm, dht-param, and overlay as well as 890 the optional expires header parameter. In this example, the overlay 891 name is chat and the DHT algorithm being used is dhtalg1.0 893 DHT-PeerID: ;algorithm=sha1; 894 dht=dhtalg1.0;overlay=chat;expires=600 896 5.4.1. Hash Algorithms and the algorithm Parameter 898 The hash algorithm used for the overlay is specified as a parameter 899 of the DHT-PeerID header. This parameter MUST appear in the DHT- 900 PeerID header. It MUST be the algorithm used to calculate all PeerID 901 and ResourceID values used in the message. It SHOULD NOT appear in 902 other headers in the message, but if it does it MUST match the value 903 in the DHT-PeerID header. 905 The hash algorithm is specified using the algorithm parameter from 906 RFC3261. The tokens used to identify the algorithm MUST be the same 907 as those used in other SIP documents such as RFC4474. [11] Currently, 908 those consist of 'sha1', indicating SHA-1 as defined in RFC 3174 [12] 909 and 'hmac-sha1', indicating HMAC-SHA1 as defined in RFC2104 [10]. 910 Implementations MUST support the SHA-1 algorithm. 912 A peer MUST reject a message with 488 Not Acceptable here if it 913 specifies a different hash algorithm than that used by the peer's 914 overlay. An initial contact to a bootstrap peer may specify the hash 915 algorithm as the wildcard "*", in which case the joining peer 916 indicates its willingness to use whatever hash algorithm the 917 bootstrap peer identifies in its response. A peer responding to such 918 a request MUST route the message according to the rules described in 919 the Message Routing Section (Section 6) if all other elements of the 920 message are correct and the routing algorithm indicates such a 921 response is appropriate. If the normal response would be to allow 922 the join with a 200 OK, the receiving peer MAY respond with a 302 923 redirect to itself and specifying the algorithm used in this overlay, 924 in which case the joining peer should reissue the message with the 925 proper hash algorithm specification. 927 5.4.2. Overlay Names and the overlay Parameter 929 Each overlay is named using a string, which SHOULD be unique to a 930 particular deployment environment. Peers will use this value to 931 identify messages in cases where they may belong to multiple overlays 932 simultaneously. These are defined formally simply as a token: 934 overlay-name = "*" / token 936 The overlay-param parameter MUST appear in the DHT-PeerID header. It 937 SHOULD NOT appear in other headers in the message, but if it does it 938 MUST match the value in the DHT-PeerID header. This parameter is 939 defined formally as: 941 overlay-param = "overlay" EQUAL overlay-name 943 A peer MUST reject a message with 488 Not Acceptable here if it 944 specifies an overlay in which the peer is not participating. An 945 initial contact to a bootstrap peer MAY specify overlay-name as the 946 wildcard "*", in which case the joining peer indicates its 947 willingness to join whatever overlay the bootstrap peer identifies in 948 its response. A peer responding to such a request MUST route the 949 message according to the rules described in the Message Routing 950 Section (Section 6) if all other elements of the message are correct 951 and the routing algorithm indicates such a response is appropriate. 952 If the normal response would be to allow the join with a 200 OK, the 953 receiving peer MAY respond with a 302 redirect to itself, in which 954 case the joining peer should reissue the message with the proper 955 overlay specification. 957 5.4.3. DHT Algorithms and the dht Parameter 959 The routing algorithm used to implement the overlay is specified 960 using a dht-param in the DHT-PeerID header. It SHOULD NOT appear in 961 other headers in the message, but if it does it MUST match the value 962 in the DHT-PeerID header. This parameter is defined formally as: 964 dht-name = token 965 dht-param = "dht" EQUAL dht-name 967 The behavior of a peer receiving a message with a dht-param 968 specifying a routing algorithm other than that which it is following 969 is dependent on the routing algorithm. An initial contact of a 970 bootstrap peer MAY specify dht-param as the wildcard "*", in which 971 case the joining peer indicates its willingness to use whatever DHT 972 algorithm the bootstrap peer identifies in its response. A peer 973 responding to such a request MUST route the message according to the 974 rules described in the Message Routing Section (Section 6) if all 975 other elements of the message are correct and the routing algorithm 976 indicates such a response is appropriate. New routing algorithms 977 SHOULD be designed to maintain backward compatibility with previous 978 algorithms where possible. If the routing algorithm specified is 979 incompatible, a 488 Not Acceptable Here response MUST be returned. 981 5.4.4. PeerID Expires header parameter 983 The DHT-PeerID header MAY include an Expires parameter indicating how 984 long a recipient may keep knowledge of this peer. If not present, a 985 default of 3600 is assumed. Mobile peers may wish to specify a 986 shorter interval. 988 5.5. The DHT-Link Header 990 We introduce a new SIP header called the DHT-Link header. The DHT- 991 Link header is used to transfer information about where in the DHT 992 other peers are located. In particular, it is used by peers to pass 993 information about its neighbor peers and routing table information 994 stored by a peer. 996 DHT-Link = "DHT-Link" HCOLON PeerURI SEMI link-param SEMI 997 expires-param *(SEMI generic-param) 998 link-param = "link" EQUAL link-value 999 expires-param = "expires" EQUAL delta-seconds 1001 The value of linkvalue -- that is, how you represent what type of 1002 link this is, is defined by the DHT algorithm specification. The 1003 generic-param leaves flexibility for an algorithm to add additional 1004 parameters if needed. 1006 As an example, the header might look like (using a shortened 10 digit 1007 Peer-ID for clarity). The value *** here is intended to represent a 1008 value determined by the particular DHT: 1010 DHT-Link: ;link=***;expires=600 1012 5.5.1. Expires Processing 1014 Each DHT-Link header MUST contain an expires parameter. Each peer 1015 maintains an expiration time for each of its neighbor and routing 1016 table entries. These expiration times are updated whenever the peer 1017 receives a response with a longer expiration time than it currently 1018 maintains, most commonly in the PeerID header of a response to a join 1019 or search. A peer MUST NOT report an expired entry in a DHT-Link 1020 header. A peer MUST update the expires parameter with the current 1021 value, adjusted for passed time, each time it generates a DHT-Link 1022 header. 1024 6. Message Routing 1026 When a peer sends a message within the DHT, it begins by calculating 1027 the target ID it is attempting to locate, which might be its own 1028 location in the DHT, or a user's registration, for which it hashes 1029 the user's URI to obtain the appropriate Resource-ID. It then 1030 consults its routing table, and its other neighbor peers, for the 1031 closest peer it is aware of to the target ID. 1033 The messages in the overlay MAY be routed either iteratively or 1034 recursively. The Request-Disposition header as described in [13] 1035 SHOULD be used to indicate if the next node should process the 1036 message using a recursive or iterative mechanism. If the header is 1037 omitted, the receiving node may process the message either 1038 recursively or iteratively. 1040 If the Request-Disposition header is iterative, the contacted peer 1041 MUST determine if it is responsible for that target ID. If it is 1042 not, then the contacted peer MUST issue a 302 redirect pointing the 1043 search peer toward the best match the contacted peer has for the 1044 target ID. The searching peer then contact the peer to which it has 1045 been redirected and the process iterates until the responsible peer 1046 is located. 1048 In recursive routing, the peer sends a message to the peer it knows 1049 that is nearest to the target. If the contacted peer is not 1050 responsible for the target ID, it MUST forward the query to the 1051 nearest peer to the target that it knows, and the process repeats 1052 until the target is reached. This process follows standard proxy 1053 behavior in RFC 3261. 1055 6.1. Peer Registration 1057 When a peer (the joining peer) wishes to join the overlay, it creates 1058 its Peer-ID and sends a REGISTER message to a bootstrap peer already 1059 in the overlay, requesting to join. Any peer in the DHT may serve as 1060 a bootstrap peer, although we expect that most UAs will be configured 1061 with a small number of well-known peers. 1063 Following the iterative routing scheme, the bootstrap peer looks up 1064 the peer it knows nearest to the Peer-ID of the joining peer and 1065 responds with 302 redirect to this nearer peer. The joining peer 1066 will repeat this process until it reaches the peer currently 1067 responsible for the space it will occupy. 1069 If recursive routing is being used, the bootstrap peer looks up the 1070 peer it knows nearest to the Peer-ID of the joining peer and forwards 1071 the REGISTER message to that peer. This process of forwarding the 1072 message repeats until the peer currently responsible for the space 1073 the joining peer will occupy is found. 1075 Once the peer responsible for the joining peer's portion of the 1076 namespace is located, the joining peer then exchanges DHT state 1077 information with this peer, called the admitting peer, to allow the 1078 joining peer to learn about other peers in the overlay (neighbors) 1079 and to obtain information about resources the joining peer will be 1080 responsible for maintaining. Other DHT maintenance messages will be 1081 exchanged later to maintain the overlay as other peers enter and 1082 leave, as well as to periodically verify the information about the 1083 overlay, but once the initial messages are exchanged, a peer has 1084 joined the overlay. 1086 6.2. Resource Registration 1088 The peer registration does not register the peer's user(s) or other 1089 resources with the P2PSIP network -- it has only allowed the peer to 1090 join the overlay. Once a peer has joined the overlay, the user that 1091 peer hosts must be registered with the system. This process is 1092 referred to as resource registration. This registration is analogous 1093 to the conventional SIP registration, in which a message is sent to 1094 the registrar creating a mapping between a SIP URI and a user's 1095 contact. The only difference is that since there is no central 1096 registrar, some peer in the overlay will maintain the registration on 1097 the users behalf. 1099 Resource registrations are routed similarly to peer registrations. 1100 The resource's peer calculates the resource-ID and contacts the peer 1101 it is aware of closest to the resource-ID. This search process 1102 continues in either an iterative or recursive manner until the 1103 responsible peer is located. This peer then stores the registration 1104 for that user and returns a 200 response. 1106 For redundancy, resources should also be registered at additional 1107 peers within the overlay. These replicas are located by adding a 1108 replica number to the resource name and hashing to identify a new 1109 resource-ID for each replica. In this way, replicas are located at 1110 unrelated points around the DHT, minimizing the risk of an attacker 1111 compromising more than one registration for a single resource. 1113 6.3. Session Establishment 1115 Sessions are established by contacting the UA identified by the 1116 registration in the DHT. The first step in establishing a session is 1117 locating this peer, which is done by searching for a resource in the 1118 DHT. The name of the target resource is used to calculate a 1119 resource-ID and a REGISTER message with no Contact information (a 1120 conventional SIP search) is sent to the closest known peer to that 1121 resource-ID. The search iterates until the responsible peer is 1122 located. The responsible peer then returns either a 200 OK with the 1123 Contact information for the resource or a 404 Not Found. The session 1124 is then initiated directly with the resource's UA. 1126 If the peer needs to have the session establishment routed through 1127 the overlay, it MAY use the Request-Disposition header with a value 1128 of proxy to request that intermediate nodes proxy the invite over the 1129 overlay on their behalf. This is particular critical for NAT 1130 traversal [6]. 1132 6.4. DHT Maintenance 1134 In order to keep the overlay stable, peers must periodically perform 1135 book keeping operations to take into account peer failures. These 1136 DHT maintenance messages are sent using REGISTER messages and the 1137 overlay algorithm being used will dictate how often and where these 1138 messages are sent. 1140 DHT maintenance messages are routed similarly to peer registrations 1141 and resource registrations. The peer calculates the Peer-ID of the 1142 peer it wants to exchange DHT information with and contacts the peer 1143 it is aware of closest to that Peer-ID. This search process 1144 continues until the current closest peer to the target Peer-ID is 1145 located at which point the peers exchange DHT maintenance 1146 information. 1148 7. Peer/DHT Operations 1150 The SIP REGISTER message is used extensively in this system. 1151 REGISTER is used to register users, as in conventional SIP systems, 1152 and we discuss this further in the Resource Registration 1153 (Section 8.1) section of this document. Additionally, SIP REGISTER 1154 messages are used to register a new peer with the DHT and to transmit 1155 the information needed to maintain the DHT. 1157 7.1. Peer Registration 1159 After a peer has located an initial bootstrap peer, the process of 1160 joining the overlay is started by constructing a REGISTER message and 1161 sending it to the bootstrap peer. Third party registration MAY NOT 1162 be used for registering peers into the overlay, and attempts to do so 1163 MUST be rejected by the peer receiving such a request (although third 1164 party registrations are used for other purposes, as described below). 1165 The peer MUST construct a SIP REGISTER message following the 1166 instructions in RFC3261, Section 10, with the exceptions/rules 1167 outlined below. 1169 7.1.1. Constructing a Peer Registration 1171 The Request-URI MUST include only the IP address of the peer that is 1172 being contacted (initially the bootstrap peer). This URI MUST NOT 1173 include any of the P2P defined parameters. For example, a request 1174 intended for peer 10.3.44.2 should look like: "REGISTER sip:10.3.44.2 1175 SIP/2.0". 1177 The To and From fields of the REGISTER message MUST contain the URI 1178 of the registering peer constructed according to the rules in the 1179 subsection Peer URIs (Section 5.3.1) in the Message Syntax section. 1181 While allowing the IP address of the sender for To and From is 1182 different than conventional SIP registers, there are two reasons for 1183 this. First, in a P2P network, which peer the request is sent to, 1184 and thus the domain for which the registration is intended, is not 1185 important. Any peer can process the information, and the user name 1186 is not associated with a particular IP address or DNS domain, but 1187 rather with the overlay name, which is encoded elsewhere. In that 1188 sense, the IP address used is irrelevant. Choosing the domain of the 1189 sender ensures that if a request is sent to a non-P2P aware RFC 3261 1190 compliant registrar, it will be rejected. RFC 3261 (section 10.3) 1191 states that a registrar should examine the To header to determine if 1192 it presents a valid address-of-record for the domain it serves. 1193 Since the IP address of the sending peer is unlikely to be a valid 1194 address for a non-P2P aware registrar, the message will be rejected, 1195 eliminating possibly erroneous handling by the registrar. 1197 The registering peer MUST also list its PeerURI in the contact field 1198 when registering so that this may be identified as a registration/ 1199 update, rather than a query. The peer MUST provide an expires 1200 parameter or expires header with a non-zero value. As in standard 1201 SIP registrations, Expire headers with a value of zero will be used 1202 to remove registrations. 1204 The registering peer MUST provide a DHT-PeerID header field. It MAY 1205 leave the overlay parameter set to "*" for its initial registration 1206 message, but MUST set this parameter to the name of the overlay it is 1207 joining as soon as it receives a response from the bootstrap peer. 1209 The registering peer MUST include Require and Supported headers with 1210 the option tag "dht". 1212 Assume that a peer running on IP address 10.4.1.2 on port 5060 1213 attempts to join the network by contacting a bootstrap peer at 1214 address 10.7.8.129. Further assume that 10.4.1.2 hashes to 1215 463ac4b449 under SHA-1 (using a 10 digit hash for example 1216 simplicity), and the least significant bits are replaced with the 1217 port number, yielding 463ac413c4 and that the overlay name is chat 1218 and the dht-param is dhtalg1.0. An example message would look like 1219 this (neglecting tags): 1221 REGISTER sip:10.7.8.129 SIP/2.0 1222 To: 1223 From: 1224 Contact: 1225 Expires: 600 1226 DHT-PeerID: ;algorithm=sha1; 1227 dht=dhtalg1.0;overlay=chat;expires=600 1228 Require: dht 1229 Supported: dht 1231 7.1.2. Processing the Peer Registration 1233 The receiving peer determines that this is a P2PSIP message based on 1234 the presence of the dht Require and Supported fields. In the event 1235 that the peer does not support P2P extensions, it MUST reply with a 1236 420 Bad Extension response. If the peer examines the overlay 1237 parameters and determines that this is not an overlay the peer 1238 participates in, the peer MUST reject the message with a 488 Not 1239 Acceptable Here response. Likewise if the peer examines the dht- 1240 param and determines that the algorithm specified is not compatible 1241 with its algorithm, the peer MUST reject the message with a 488 Not 1242 Acceptable Here response. If a P2P peer receives a non-P2P request 1243 it MAY reject it with a message such as 421 Extension Required or it 1244 MAY process it as a conventional SIP message. 1246 An implementation may support both P2P and conventional SIP messages. 1247 In that case, it MAY include the dht Supported field with all 1248 messages but MUST NOT include it with messages intended for 1249 conventional nodes. 1251 7.1.2.1. Routing the Peer Registration 1253 The presence of peer-ID URI parameter in the To and Contact headers 1254 and a valid expiration time indicate that this message is a peer 1255 registration and the receiving peer MUST process this as a DHT level 1256 request. The bootstrap peer SHOULD verify that the Peer-ID 1257 corresponds to peer listed in the URI by validating the hash or the 1258 peers credentials. If these do not match, the message SHOULD be 1259 rejected with a response of 493 Undecipherable. The bootstrap peer 1260 examines the Peer-ID to determine if it corresponds to the portion of 1261 the overlay the bootstrap peer is responsible for. If it does, the 1262 peer will handle the REGISTER request itself. If not, the bootstrap 1263 peer will either provide the joining peer with information about a 1264 peer closer to the area of the overlay where the joining peers 1265 Peer-ID is stored (iterative routing) or forward the request along 1266 the closest peer it knows about (recursive routing). If a Request- 1267 Disposition header is present and set to proxy, the peer MUST use a 1268 recursive routing mechanism, and if it is present and set to 1269 redirect, the peer MUST use an iterative routing mechanism. In the 1270 event that the Request-Disposition header is not present, the peer 1271 may choose either mechanism. 1273 In the case of iterative routing, if the receiving peer is not 1274 responsible for the area of the hash table where Peer-ID should be 1275 stored, the peer SHOULD generate a 302 message. The 302 is 1276 constructed according the rules of RFC 3261 with the following rules. 1277 The receiving peer MUST look in its list of neighbors or in the 1278 routing table to find the peer with Peer-ID nearest the to joining 1279 peer's Peer-ID, and use it to create a contact field in the form of a 1280 peer URI, as specified in the P2P Peer URIs (Section 5.3.1) section 1281 of this document, including appropriate URI parameters. The response 1282 MUST contain a valid DHT-PeerID header. This response is sent to the 1283 joining peer. 1285 In the case of recursive routing, if the receiving peer is not 1286 responsible for the area of the hash table where the Peer-ID should 1287 be stored, the receiving peer should forward the request to the peer 1288 it knows about that is closest to the Peer-ID. 1290 A peer MUST NOT add a new peer to its routing table or redirect 1291 requests to that new peer until it has successfully contacted that 1292 peer itself. By redirecting a message to another peer, the contacted 1293 peer indicates that it believes that peer to be alive and that it is 1294 willing to route messages to it for NAT and Firewall traversal 1295 purposes. 1297 Using our example register from the previous section, assume that 1298 iterative routing is being used and that the bootstrap peer 1299 10.7.8.129 receives the message, determines it is not responsible for 1300 that area of the overlay, and redirects the joining peer to a peer 1301 with Peer-ID 47e46fa2cd at IP address 10.3.1.7. The 302 response, 1302 again neglecting tags, is shown below. Note that the peer creating 1303 the response uses its information to construct the DHT-PeerID header. 1305 SIP/2.0 302 Moved Temporarily 1306 To: 1307 From: 1308 Contact: 1309 Expires: 600 1310 DHT-PeerID: ;algorithm=sha1; 1311 dht-param=dhtalg1.0;overlay=chat;expires=600 1312 Require: dht 1313 Supported: dht 1315 Upon receiving the 302, the joining peer uses the contact address as 1316 the new bootstrap peer. The process is repeated until the peer 1317 contacted is currently responsible for the area of the DHT in which 1318 the new peer will reside. The receiving peer that is responsible for 1319 that portion of the overlay is referred to as the admitting peer. 1321 TODO: we should have example of how to forward request in a recursive 1322 routing case 1324 7.1.2.2. Admitting the Joining Peer 1326 The admitting peer MUST verify that the Peer-ID is valid, as 1327 described above. If these do not match, the message MUST be rejected 1328 with a response of 493 Undecipherable. The admitting peer recognizes 1329 that it is presently responsible for this region of the hash space -- 1330 that is, it is currently the peer storing the information that this 1331 Peer-Id will eventually be responsible for. The admitting peer knows 1332 this because the joining peer's Peer-ID is closest to its own 1333 Peer-ID. The admitting peer is responsible for helping the joining 1334 peer become a member of the overlay. In addition to verifying that 1335 the Peer-ID was properly calculated, the admitting peer MAY perform 1336 additional security checks [9]. Once any challenge has been met, the 1337 admitting will reply with a 200 OK message to the joining peer. As 1338 in a conventional registration, the Contact in the 200 OK will be the 1339 same as in the request, and the expiry time MUST be provided. 1341 The admitting peer MUST reply with a 200 response if the admitting 1342 peer's Peer-ID is the closest to the joining peer's Peer-ID. Each 1343 DHT algorithm MAY choose to define closest however they want, but the 1344 DHT algorithm MUST be able to deterministically find the closest 1345 Peer-ID. The admitting peer must populate the DHT-Link headers with 1346 all values required by the DHT routing protocol so that the joining 1347 peer can initialize its neighbors and routing table entries. 1348 Additionally, the admitting peer MUST include its DHT-PeerID header 1349 containing the admitting peer's Peer-ID and IP. 1351 7.2. Peer Query 1353 As with conventional SIP, REGISTER messages that are sent without a 1354 Contact: header are assumed to be queries, as described in Section 10 1355 of RFC3261. 1357 7.2.1. Constructing a Peer Query Message 1359 The peer looks for the routing table entry or neighbor peer that is 1360 closest to the ID they are searching for. If the routing table has 1361 not yet been filled, then the peer may send the request to any peer 1362 it has available, including their other neighbor peers or even some 1363 bootstrap peer. While these initial searches may be less efficient, 1364 they will succeed. The Request-URI MUST include only the IP address 1365 of the peer that the search is intended for. This URI MUST NOT 1366 include any of the P2P defined parameters. For example, a request 1367 intended for peer 10.3.44.2 should look like: "REGISTER sip:10.3.44.2 1368 SIP/2.0". 1370 Because this is a query, the sending peer MUST NOT include a contact 1371 header. The sender MUST NOT include an expires header. 1373 The peer MUST provide a DHT-PeerID header. 1375 The peer MUST include Require and Supported headers with the option 1376 tag "dht". 1378 Assume that a peer running on IP address 10.4.1.2 on port 5060 wants 1379 to determine who is responsible for Peer-ID 4823affe45, and asks the 1380 peer with IP address 10.5.6.211 Further assume that the peer uses 1381 SHA-1 (using a 10 digit hash for example simplicity), and that the 1382 overlay name is chat. An example message would look like this 1383 (neglecting tags): 1385 REGISTER sip:10.5.6.211 SIP/2.0 1386 To: 1387 From: 1388 DHT-PeerID: ;algorithm=sha1; 1389 dht-param=dhtalg1.0;overlay=chat;expires=600 1390 Require: dht 1391 Supported: dht 1393 The To field of the REGISTER message MUST contain the PeerURI of the 1394 identifier being search for, constructed according to the rules in 1395 the subsection P2P peer URIs (Section 5.3.1) in the Message Syntax 1396 section. If a specific peer is being sought, the PeerURI must 1397 specify that hostport. If only the identifier is being searched for, 1398 then hostport MUST be set to "0.0.0.0". The From URI MUST use the 1399 searching peer's PeerURI. 1401 7.2.2. Processing Peer Query Message 1403 The receiving peer determines that this is a P2PSIP message based on 1404 the presence of the dht Require and Supported fields. In the event 1405 that the peer does not support P2P extensions, it MUST reply with a 1406 5xx class response such as 501 Not Implemented. If the peer examines 1407 the overlay parameters and determines that this is not an overlay the 1408 peer participates in, the peer MUST reject the message with a 488 Not 1409 Acceptable Here response. In the event a P2P peer receives a non-P2P 1410 request, it SHOULD reject it with a message such as 421 Extension 1411 Required. 1413 7.2.2.1. Routing the Peer Query Message 1415 The presence of a PeerURI and lack of an expiration time indicate 1416 that this message is a peer query and the receiving peer MUST process 1417 this as a DHT level request. The receiving peer SHOULD NOT alter any 1418 of its internal values such as successor or predecessor in response 1419 to this message, since it is a query. Otherwise, the message is 1420 processed and routed as a peer registration (Section 7.1.2.1) until 1421 the responsible peer is reached. 1423 7.2.2.2. Responding to the Peer Query Message 1425 If the receiving peer is responsible for the region that the search 1426 key lies within, it MUST respond to the query. If the receiving 1427 peer's Peer-ID exactly matches the search key, it MUST respond with a 1428 200 OK message. If it is responsible for that region, but its 1429 Peer-ID is not the search key, it MUST respond with a 404 Not Found 1430 message. The peer MAY verify the Peer-ID and IP address presented by 1431 the querying peer in the message. If these do not match, the message 1432 should be rejected with a response of 493 Undecipherable. 1434 7.3. Populating the Joining Peer's Routing Table 1436 Once admitted, the joining peer SHOULD populate its routing table and 1437 locate neighbors by issuing queries for peers with the appropriate 1438 identifiers. If the admitting peer provided neighbor or routing 1439 table information in its response, the joining peer MAY use this 1440 information to construct a temporary routing table and neighbor 1441 information and use this temporary table in the queries to populate 1442 the table. 1444 7.4. Transfering User Registrations 1446 When a new peer joins, it splits the area in the hash space the 1447 admitting peer is responsible for. Some portion of the user 1448 registrations the admitting peer was responsible for may now be the 1449 responsibility of the joining peer, and these user registrations are 1450 handed to the joining peer by means of third party user 1451 registrations. Third party registrations are allowed for user 1452 registrations and arbitrary searches, but are not allowed for peer 1453 registrations. These registrations are exactly the same as those 1454 discussed in Registering and Removing User Registrations 1455 (Section 8.1), except that as they are third party registration from 1456 a peer, that is, the From header contains the PeerURI of the 1457 admitting peer. 1459 7.5. Peers Leaving the Overlay Gracefully 1461 Peers MUST send their registrations to the closest peer before 1462 leaving the overlay, as described in the section above. 1463 Additionally, peers MUST unregister themselves with their symmetric 1464 neighbors (if the DHT routing algorithm uses symmetric neighbors in 1465 any form). These graceful exit REGISTER messages are constructed 1466 exactly the same as one used to join, with the following exceptions. 1467 The expires parameter or header MUST be provided, and MUST be set to 1468 0. DHT-Link headers must be provided, as specified in DHT routing 1469 algorithm 1471 7.6. NAT and Firewall Traversal 1473 The filtering properties of NATs and firewalls can lead to non- 1474 transitive connectivity. Typically this will manifest itself in a 1475 peer receiving a 302 redirecting it to another peer that it cannot 1476 contact, most likely because address dependent filtering is 1477 occurring. We discuss mechanisms to address these problems in [6]. 1479 7.7. Handling Failed Requests 1481 When a request sent to another peer fails, the peer MUST perform 1482 searches to update its pointers. If the failed request was sent to a 1483 peer in the routing table or a neighbor peer, then the searches 1484 discussed in Populating the Joining Peer's Routing Table 1485 (Section 7.3) should be performed. 1487 8. Resource Operations 1489 The most important element of resource operations within the P2PSIP 1490 DHT is that they are performed exactly as if using a conventional SIP 1491 registrar, except that the registrar responsibilities are distributed 1492 among the DHT members. 1494 8.1. Resource Registrations 1496 When a peer is in the overlay, it must register the contacts for 1497 users and other resources for which it is responsible into the 1498 overlay. This differs from the registrations described above in that 1499 these registrations are responsible for entering a URI name to URI 1500 location mapping into the overlay as data, rather than joining a peer 1501 into the overlay. These registrations are very similar to those 1502 outlined in section 10 of RFC3261. 1504 The Request-URI that is constructed for the REGISTER MUST be 1505 addressed to the peer the request is sent to. The To and From fields 1506 of the REGISTER message MUST contain the Resource URI of the resource 1507 being registered, as described in Resource URIs (Section 5.3.2). The 1508 request MUST include the value dht in Require and Supported headers. 1509 The request MUST include a DHT-PeerID header and MAY include one or 1510 more DHT-Link headers. 1512 The resource registration MUST include at least one Contact header 1513 containing a location of the resource and allowing this to be 1514 identified as a registration/update, rather than a query. The peer 1515 MUST provide an expires parameter or an Expire header with a non-zero 1516 value. As in standard SIP registrations, Expires parameters with a 1517 value of zero will be used to remove registrations. Any valid 1518 Contact for RFC 3261 is valid Contact for P2PSIP. Most users will 1519 register a Contact with the address of the user's UA (which may or 1520 may not be the IP address of the peer, since the peer could be an 1521 adaptor peer). The Contact URI does not need to include the 1522 ResourceID or other P2PSIP parameters as it is stored in the DHT but 1523 not processed or routed by it in any way. 1525 The message is routed in a fashion exactly analogous to that 1526 described in the section on peer registration (Section 7.1). In 1527 iterative routing algorithms, 302 messages are sent to indicate that 1528 the message is to be redirected to another Peer URI. In recursive 1529 routing algorithms, the receiving peer SHOULD forward the request to 1530 the peer in its connection table that is closest to the ResourceID. 1531 Once the message arrives at a destination that is responsible for 1532 that portion of the hash namespace, the peer recognizes it as a 1533 resource registration, rather than a peer wishing to join the system, 1534 based upon the fact that the To and From fields do not contain a Peer 1535 URI. The peer responds with a 200 indicating a successful 1536 registration. The response is constructed as dictated by RFC3261. 1538 The registering peer SHOULD construct and register replica 1539 registrations using the same Contact headers, but with the replica 1540 URI parameter used in the To and From headers. 1542 8.2. Refreshing Resource Registrations 1544 Resource registrations are refreshed exactly as described in RFC 1545 3261, Section 10. Responsible peers should send a new registration 1546 with a valid expiration time prior to the time that the registration 1547 is set to expire. 1549 Agents MAY cache the address where they previously registered and 1550 attempt to send refreshes to this peer, but they are not guaranteed 1551 success, as a new peer may have registered and may now be responsible 1552 for this area of the space. In such a case if iterative routing is 1553 being used, the peer will receive a 302 from the peer with which they 1554 previously registered, and should follow the same procedure for 1555 locating the peer they used in the initial registration. 1557 As with initial registrations, the sending peer should use the 1558 neighbor peer or routing table information provided in the 200 to 1559 send these updates to the redundant peers as well. 1561 8.3. Removing Resource Registrations 1563 Resource registrations are removed exactly as described in RFC 3261, 1564 Section 10. Responsible peers MUST send a registration with 1565 expiration time of zero. 1567 As with initial registrations, the sending peer MUST construct 1568 replica unregister messages and use these to unregister the replicas. 1570 8.4. Querying Resource Registrations 1572 Resource queries are constructed as described in RFC 3261, Section 1573 10. Querying peers should send a REGISTER message with no contact 1574 header. As described in Peer Search (Section 7.2.1), this mechanism 1575 can also be used to locate the peer responsible for a particular 1576 Resource-ID. 1578 A P2P environment can do little to protect against an individual peer 1579 compromising the registrations it is responsible for. Accordingly, a 1580 UA cannot trust a response from a single peer, whether it indicates a 1581 successful search or an error. In the absence of other methods of 1582 verifying the response (such as having a certificate of the user 1583 being searched for and a signed registration that can be verified 1584 with the certificate) a UA should search for the primary registration 1585 and at least one replica. Because the locations the replicas are 1586 stored are unrelated to the location of the primary registration, a 1587 single attacker is unlikely to be able to compromise both entries. 1588 As the overlay gains more peers and more replicas are searched for, 1589 the odds of a compromise are reduced. Better protection for 1590 registrations is discussed in [9]. 1592 8.5. Session Establishment 1594 When a caller wishes to send a SIP message (such as an INVITE, 1595 MESSAGE or SUBSCRIBE), the caller must first locate the peer where 1596 this callee's information resides using the resource search procedure 1597 described in the section titled Resource Location. (Section 8.4) 1599 Establishing a session is done entirely in the normal SIP fashion 1600 after the user is located using the P2P resource query. Once the 1601 peer responsible for the Resource-ID is located, it will provide 1602 either a 200, providing a contact for the users UA, or will provide a 1603 404 if the user is not registered. If a 200 with a valid contact is 1604 received, the call will then be initiated directly with the UAS of 1605 the called using the standard RFC 3261 fashion for methods such as 1606 INVITE or MESSAGE, or the INVITE can be processed by routing it 1607 through the overlay if necessary for NAT traversal [6]. 1609 8.6. Presence 1611 We use SUBSCRIBE/NOTIFY for this. We subscribe to every user on our 1612 friend list when we come online. If the friends are online, that 1613 means that we know exactly where they are. Peers MAY use the PeerIDs 1614 of their friends' peers as additional routing table entries or 1615 neighbor peers (essentially, cached values), consulting these first, 1616 as connections are likely to be made to people on the user's friend 1617 list. These should also be periodically checked, as described in the 1618 DHT Maintenance (Section 6.4). 1620 If friends are offline, one should periodically try to make the 1621 connection. However, if a UA receives a SUBSCRIBE from a friend that 1622 it believes to be offline, it SHOULD attempt to subscribe to that 1623 friend. This will allow people that are reciprocally on each other's 1624 friend lists to rapidly be notified when one or the other comes 1625 online, therefore the retry interval for subscribing to offline 1626 friends can be fairly long because it is only necessary in the case 1627 of race conditions or other temporary failures in resource location. 1629 8.7. Offline Storage 1631 Delivery of messages to offline users, or voicemail for voice 1632 applications, requires storing that information for later retrieval. 1633 Storing user configuration information in a format accessible from 1634 the network also will allow a user to retrieve their profile from any 1635 computer. Cao et al. [18] describe an approach that separates the 1636 storage of resource location information from the actual storage of 1637 the offline research. We believe that this approach is in agreement 1638 with the approach taken by the rest of this document, which relies on 1639 the DHT overlay to store the registrar's location information, but 1640 relies on external, conventional methods for the actual connection. 1641 For offline storage, it also allows the use of other standard 1642 protocols to store and retrieve the offline information, keeping the 1643 P2PSIP scope restricted to storing resource mappings. 1645 9. Pluggable DHT Algorithm Requirements 1647 All dSIP peers MUST support the Chord pluggable DHT algorithm for 1648 compatibility. They MAY support additional pluggable algorithms. 1649 The requirements for new pluggable algorithms are defined in this 1650 section. 1652 Pluggable algorithm MUST use Peer-IDs and Resource-IDs as defined in 1653 Hash Algorithms and Identifiers (Section 5.2) Pluggable algorithms 1654 are free to define what hash algorithms they support, but they MUST 1655 clearly specify what they are. 1657 A resource with Resource-ID k will be stored by the peer with Peer-ID 1658 closest to the Resource-ID. The definition of closeness may vary in 1659 different DHT algorithms, but each DHT algorithm MUST guarantee 1660 Resource-ID searches converge to exactly one peer responsible for 1661 that portion of the namespace. As peers enter and leave, resources 1662 may be stored on different peers, so the information related to them 1663 is exchanged as peers enter and leave. Redundancy is used to protect 1664 against loss of information in the event of a peer failure. 1666 Each new DHT algorithm MUST define a value for the dht-name parameter 1667 to be used in the dht-param parameter of the DHT-PeerID header, as 1668 defined in DHT Algorithms and the dht parameter (Section 5.4.3). 1670 Each new DHT algorithm MUST define the valid BNF for the link-value 1671 used in the DHT-Link header, as defined in The DHT-Link header 1672 (Section 5.5). 1674 10. Security Considerations 1676 The goal of P2PSIP is to scale gracefully from ad hoc groups of a few 1677 people to an overlay of millions of peers across the globe. As such, 1678 there is no one security model that fits the needs of all envisioned 1679 environments; for the small network establishing a certificate chain 1680 is ludicrously difficult, while for a global network the unrestricted 1681 ability to insert resources and devise useful Peer IDs is a clear 1682 invitation to insecurity. Any P2PSIP protocol must offer a range of 1683 security models that can be selected according to the needs of the 1684 overlay. 1686 10.1. Threat Model 1688 Without other security, the attacker is able to generate an ID and 1689 become a valid peer in the system. They can see other peers and 1690 process certain queries. Attackers may wish to receive 1691 communications intended for other participants, prevent other users 1692 from receiving their messages, prevent large portions of the users 1693 from receiving messages, or send messages that appear to be from 1694 others. Users would like to be sure they are communicating with the 1695 same person they have previously talked to, to be able to verify 1696 identity via some out of band mechanism. Attackers may try to squat 1697 on all the good names. Users would like names that are meaningful to 1698 them. Attackers may have computers that are many times faster than 1699 the average user's. Attackers may be able to DOS other particular 1700 peers and make them fail. To make a robust DHT, many peers need to 1701 store information on behalf of the community. Peers may lie about 1702 this and not store the information. Attackers may wish to see who is 1703 communicating with whom and how much data is getting communicated. 1705 Many of the threats to P2P SIP are also threats to conventional SIP. 1706 As such, P2P SIP imports much of its security from conventional SIP. 1707 However, because conventional SIP generally relies on secure servers 1708 to maintain the integrity of the system, modifications to those 1709 techniques are required to maintain the same level of security. 1711 10.2. Protecting the ID Namespace 1713 The fundamental protection that P2PSIP relies on is protecting the ID 1714 namespace. In particular, many of the attacks on P2PSIP require 1715 identifying a particular portion of the ID space and acquiring 1716 control of that space. This is a common vector both for attacks on a 1717 particular user, by obtaining control of the location in the overlay 1718 where the user is registered, and on the overlay itself, by means of 1719 a Sybil [19] attack when one is able to insert multiple identities at 1720 different locations on the ring. 1722 The P2PSIP ID Namespace is considered protected when an attacker is 1723 not able to select an arbitrary Peer-ID and insert a peer at the 1724 location by convincing other peers to route traffic to them. This 1725 protects against hijacking and DoS attacks. The ID Namespace may 1726 also be protected by restricting admission to the overlay to some 1727 authorized (and trusted) set of individuals. 1729 10.2.1. Protection Using ID Hashing 1731 The default base security for P2PSIP determines Peer-IDs by hashing 1732 the peer's IP address and appending the port number. The security of 1733 this scheme depends on the ease with which an attacker can choose 1734 their own Peer-ID. Because the port number is only appended to the 1735 Peer-ID, an attacker gains nothing by selecting different ports on 1736 the same node. Assuming that the SHA1 hash used to calculate the 1737 Peer-ID is reliably random, the attacker's ability to succeed depends 1738 on the number of separate IP addresses that they are able to obtain 1739 from which to launch their attacks. 1741 In the current predominantly IPV4 Internet, few attackers have access 1742 to more than a handful of IP addresses, perhaps a few hundred at 1743 worst. For a large-scale P2P system, this is unlikely to provide the 1744 ability to hijack a particular user ID or control a sufficient 1745 portion of the network to affect other peers, in particular when 1746 registrations are replicated at independent peers. Ultimately, 1747 however, a sufficiently skilled and provisioned attacker can 1748 compromise this scheme. 1750 As the Internet migrates to IPV6, however, it is unclear that the 1751 assumption that few attackers have access to a significant range of 1752 IP addresses will remain true. Therefore, hashing IP addresses to 1753 Peer-IDs is assumed to provide a diminishing amount of security in 1754 the future. 1756 10.2.2. Cryptographic Protection 1758 Stronger protection guarantees are possible by relying on 1759 cryptographic techniques to restrict the generation of peer IDs, 1760 either through requiring knowledge of a shared secret to calculate a 1761 valid hash or by issuing certificates through a central authority. 1762 These techniques are further described in Security for dSIP [9]. 1764 10.3. Protecting the resource namespace 1766 The two primary vectors of attacks on resources in a P2PSIP overlay 1767 are inserting illegitimate resources into the overlay and corrupting 1768 the registrations for which a compromised peer is responsible. 1770 For overlays that do not rely on certificates, once a peer has joined 1771 the overlay there are no restrictions on its ability to register 1772 resources. In an unsecured network, multiple peers can register the 1773 same resource (username) in the overlay. However, self-signed 1774 certificates [14] can be used to authenticate a user as the same user 1775 previously contacted with that certificate. Unless a conventional 1776 SIP authentication server is available, however, establishing 1777 identity upon initial contact is still a problem. One potential 1778 solution is for an overlay that is expected to persist over long 1779 time-frames to store the credentials of previous users for 1780 verification of a new registration. These techniques are beyond the 1781 scope of this document. 1783 The second form of resource attack, which is really an ID attack, 1784 concerns the attacks that are possible when a peer has legitimately 1785 inserted itself into the overlay and is now responsible for storing 1786 resource registrations. Such an attack could occur through a 1787 corrupted peer or by an attacker who convinces the CA to issue them a 1788 certificate for a Peer-ID. In this case, the peer can corrupt any 1789 resource that is assigned to it. In the absence of certificates, the 1790 primary means of defense of such attacks is relying on the 1791 replication described in Section Section 5.2.2. By storing replicas 1792 of each registration on multiple peers and performing parallel 1793 searches for resource lookup, the searching peer protects itself from 1794 a single peer trying to corrupt the namespace. 1796 Further protection from each attack vector is achieved by relying on 1797 certificates for resource authentication [9]. 1799 10.4. Protecting the Routing 1801 The DHT forms a complex routing table. When a peer joins, it may 1802 contact a subversive peer that lies about the finger table 1803 information it provides. The subversive peer could do this to try to 1804 trick the joining peer to route all the traffic to a subversive group 1805 of peers. Prevention of this attack relies on protecting the 1806 namespace and (for hashed namespaces) identifying trusted bootstrap 1807 peers to use when joining. 1809 Resource searches are protected from a single subversive peer through 1810 the use of parallel searches on replicated registrations. Similar 1811 protection could be achieved through performing parallel searches 1812 using multiple bootstrap peers for initial join, but such 1813 specification is beyond the scope of this draft. When possible, 1814 securing the namespace is a better solution. 1816 10.5. Protecting the Signaling 1818 The goal here is to stop an attacker from knowing who is signaling 1819 what to whom. An attacker being able to observe the activities of a 1820 specific individual is unlikely given the randomization of IDs and 1821 routing based on the present peers discussed above. 1823 10.6. Protecting the Media 1825 As with conventional SIP, all the media SHOULD be encrypted. 1826 Negotiating encryption for an end-to-end media session should be 1827 performed in the same manner for P2PSIP communications. 1829 10.7. Replay Attacks 1831 Defense against replay attacks is discussed in [9]. 1833 11. Open Issues 1835 There are certainly many open issues. Here are a few. 1837 Still to be worked out are details of how P2PSIP names are 1838 disambiguated from conventional names that use DNS based routing. 1840 12. Acknowledgments 1842 A team of people have worked on the various drafts related to the 1843 dSIP protocol and extensions thereof. The team consists of: David 1844 Bryan, Eric Cooper, James Deverick, Cullen Jennings, Bruce Lowekamp, 1845 Philip Matthews, and Marcia Zangrilli. 1847 Thanks to all who have been actively participating in the P2PSIP 1848 efforts. Special thanks to Spencer Dawkins, Enrico Marocco, and 1849 Jean-Francois Wauthy for providing editorial feedback, and Henry 1850 Sinnreich, Eric Rescorla, and Alan Johnston for various discussions 1851 related to this work. 1853 13. IANA Considerations 1855 This document would require registering the following: 1856 o Option tag "DHT" 1857 o "DHT-Link" as a Header Field 1858 o "DHT-PeerID" as a Header Field 1859 o "peer" as a valid value for parameter user (?) 1860 o "Resource-ID" as a valid URI parameter (?) 1861 o "hmac-sha1" as an Identity-Info 'alg' parameter 1863 [ToDo: This section needs to be revamped to include all the new BNF 1864 introduced] 1866 14. Changes to this Version 1868 While this is a -00 document, it has grown from the earlier drafts 1869 draft-bryan-sipping-p2p-xx. As such, we discuss the changes from the 1870 most recent version of that draft, -03. 1871 1. The earlier draft has been split into a number of drafts: 1872 1. This draft, providing the background and overall concept, 1873 basic terminology for encoding P2P messages in SIP, 1874 2. We have removed "-" from a number of headers and parameter names 1875 to shorten the overall length of the messages. Additionally, we 1876 have provided short versions for some strings in the syntax to 1877 help reduce message size. 1878 3. We have attempted to use the new terminology defined in [2] 1879 wherever possible, and have attempted not to replicate 1880 definitions here. In particular, we have substituted the use of 1881 the term "peer" for "node" 1882 4. As a consequence of the above, NodeID has been replaced with 1883 PeerID, both in text and in the actual defined messages sent 1884 over the wire. 1885 5. We have made many changes to include details essential to using 1886 this in real deployed systems or clarifying difficult concepts; 1887 lessons learned from building a commercial application based on 1888 this draft. 1890 6. Large parts of the description of how an initial overlay is 1891 formed were quite confusing as our description did not 1892 explicitly embrace the NULL predecessor concept of Chord. We 1893 have corrected this in the sections describing the algorithms. 1894 7. A full and detailed example showing the startup of a 3 node 1895 system has been inserted into the examples section. 1896 8. A new section has been added detailing early work on 1897 incorporating SIP identity into a P2P environment. This work is 1898 then used in the security section. 1899 9. The security section has been thoroughly rewritten to reflect 1900 changes both in our thoughts and the thoughts of the P2PSIP 1901 working group as a whole. 1902 10. We corrected a number of outright errors and typos pointed by a 1903 number of individuals, as mentioned in the acknowledgments. 1905 15. References 1907 15.1. Normative References 1909 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1910 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1911 Session Initiation Protocol", RFC 3261, June 2002. 1913 [2] Willis, D., "Concepts and Terminology for Peer to Peer SIP", 1914 draft-willis-p2psip-concepts-03 (work in progress), 1915 October 2006. 1917 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1918 Levels", BCP 14, RFC 2119, March 1997. 1920 [4] Rosenberg, J., "Simple Traversal Underneath Network Address 1921 Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-05 1922 (work in progress), October 2006. 1924 [5] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 1925 Methodology for Network Address Translator (NAT) Traversal for 1926 Offer/Answer Protocols", draft-ietf-mmusic-ice-13 (work in 1927 progress), January 2007. 1929 [6] Cooper, E., Matthews, P., Bryan, D., and B. Lowekamp, "NAT 1930 Traversal for dSIP", Internet 1931 Draft draft-matthews-p2psip-dsip-nat-traversal-00, 1932 February 2007. 1934 [7] Zangrilli, M. and D. Bryan, "A Chord-based DHT for Resource 1935 Lookup in P2PSIP", Internet 1936 Draft draft-zangrilli-p2psip-dsip-dhtchord-00, February 2007. 1938 [8] Zangrilli, M. and D. Bryan, "A Bamboo-based DHT for Resource 1939 Lookup in P2PSIP", Internet 1940 Draft draft-zangrilli-p2psip-dsip-dhtbamboo-00, February 2007. 1942 [9] Lowekamp, B. and J. Deverick, "Authenticated Identity 1943 Extensions to dSIP", Internet 1944 Draft draft-lowekamp-p2psip-dsip-security-00, February 2007. 1946 [10] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 1947 for Message Authentication", RFC 2104, February 1997. 1949 [11] Peterson, J. and C. Jennings, "Enhancements for Authenticated 1950 Identity Management in the Session Initiation Protocol (SIP)", 1951 RFC 4474, August 2006. 1953 [12] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", 1954 RFC 3174, September 2001. 1956 [13] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 1957 Preferences for the Session Initiation Protocol (SIP)", 1958 RFC 3841, August 2004. 1960 [14] Jennings, C., "Certificate Management Service for The Session 1961 Initiation Protocol (SIP)", draft-ietf-sip-certs-02 (work in 1962 progress), October 2006. 1964 15.2. Informative References 1966 [15] Bryan, D., Shim, E., and B. Lowekamp, "Use Cases for Peer-to- 1967 Peer Session Initiation Protocol (P2PSIP)", Internet 1968 Draft draft-bryan-sipping-p2p-usecases-00, November 2005. 1970 [16] Bryan, D., Jennings, C., and B. Lowekamp, "SOSIMPLE: A 1971 Serverless, Standards-based, P2P SIP Communication System", 1972 Proceedings of the 2005 International Workshop on Advanced 1973 Architectures and Algorithms for Internet Delivery and 1974 Applications (AAA-IDEA) '05, June 2005. 1976 [17] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal 1977 Underneath NAT (STUN)", draft-ietf-behave-turn-02 (work in 1978 progress), October 2006. 1980 [18] Cao, F., Bryan, D., and B. Lowekamp, "Providing Secure Services 1981 in Peer-to-Peer Communications Networks with Central Security 1982 Server", Internation Conference on Internet and Web 1983 Applications and Services (ICIW) '06, February 2006. 1985 [19] Douceur, J., "The Sybil Attack", IPTPS '02, March 2002. 1987 Authors' Addresses 1989 David A. Bryan 1990 SIPeerior Technologies, Inc. 1991 3000 Easter Circle 1992 Williamsburg, VA 23188 1993 USA 1995 Phone: +1 757 565 0101 1996 Email: dbryan@sipeerior.com 1998 Bruce B. Lowekamp 1999 SIPeerior; William & Mary 2000 3000 Easter Circle 2001 Williamsburg, VA 23188 2002 USA 2004 Phone: +1 757 565 0101 2005 Email: lowekamp@sipeerior.com 2007 Cullen Jennings 2008 Cisco Systems 2009 170 West Tasman Drive 2010 MS: SJC-21/3 2011 San Jose, CA 95134 2012 USA 2014 Phone: +1 408 421 9990 2015 Email: fluffy@cisco.com 2017 Full Copyright Statement 2019 Copyright (C) The IETF Trust (2007). 2021 This document is subject to the rights, licenses and restrictions 2022 contained in BCP 78, and except as set forth therein, the authors 2023 retain all their rights. 2025 This document and the information contained herein are provided on an 2026 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2027 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2028 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2029 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2030 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2031 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2033 Intellectual Property 2035 The IETF takes no position regarding the validity or scope of any 2036 Intellectual Property Rights or other rights that might be claimed to 2037 pertain to the implementation or use of the technology described in 2038 this document or the extent to which any license under such rights 2039 might or might not be available; nor does it represent that it has 2040 made any independent effort to identify any such rights. Information 2041 on the procedures with respect to rights in RFC documents can be 2042 found in BCP 78 and BCP 79. 2044 Copies of IPR disclosures made to the IETF Secretariat and any 2045 assurances of licenses to be made available, or the result of an 2046 attempt made to obtain a general license or permission for the use of 2047 such proprietary rights by implementers or users of this 2048 specification can be obtained from the IETF on-line IPR repository at 2049 http://www.ietf.org/ipr. 2051 The IETF invites any interested party to bring to its attention any 2052 copyrights, patents or patent applications, or other proprietary 2053 rights that may cover technology that may be required to implement 2054 this standard. Please address the information to the IETF at 2055 ietf-ipr@ietf.org. 2057 Acknowledgment 2059 Funding for the RFC Editor function is provided by the IETF 2060 Administrative Support Activity (IASA).