idnits 2.17.1 draft-ietf-p2psip-sip-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 219 has weird spacing: '...ionType type...' == Line 221 has weird spacing: '...ionData data...' -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 07, 2009) is 5528 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3263' is defined on line 423, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-p2psip-base-00 == Outdated reference: A later version (-09) exists of draft-ietf-p2psip-concepts-02 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 P2PSIP C. Jennings 3 Internet-Draft Cisco 4 Intended status: Standards Track B. Lowekamp, Ed. 5 Expires: September 8, 2009 SIPeerior Technologies 6 E. Rescorla 7 Network Resonance 8 S. Baset 9 H. Schulzrinne 10 Columbia University 11 March 07, 2009 13 A SIP Usage for RELOAD 14 draft-ietf-p2psip-sip-01 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. This document may contain material 20 from IETF Documents or IETF Contributions published or made publicly 21 available before November 10, 2008. The person(s) controlling the 22 copyright in some of this material may not have granted the IETF 23 Trust the right to allow modifications of such material outside the 24 IETF Standards Process. Without obtaining an adequate license from 25 the person(s) controlling the copyright in such materials, this 26 document may not be modified outside the IETF Standards Process, and 27 derivative works of it may not be created outside the IETF Standards 28 Process, except to format it for publication as an RFC or to 29 translate it into languages other than English. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on September 8, 2009. 49 Copyright Notice 51 Copyright (c) 2009 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents in effect on the date of 56 publication of this document (http://trustee.ietf.org/license-info). 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. 60 Abstract 62 This document defines a SIP Usage for REsource LOcation And Discovery 63 (RELOAD), The SIP Usage provides the functionality of a SIP proxy or 64 registrar in a fully-distributed system. The SIP Usage provides 65 lookup service for AoRs stored in the overlay. The SIP Usage also 66 defines GRUUs that allow the registrations to map an AoR to a 67 specific node reachable through the overlay. The AppAttach method is 68 used to establish a direct connection between nodes through which SIP 69 messages are exchanged. 71 Table of Contents 73 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 3. Registering AORs . . . . . . . . . . . . . . . . . . . . . . . 6 76 4. Looking up an AOR . . . . . . . . . . . . . . . . . . . . . . 8 77 5. Forming a Direct Connection . . . . . . . . . . . . . . . . . 9 78 6. GRUUs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 7. SIP-REGISTRATION Kind Definition . . . . . . . . . . . . . . . 9 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 81 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 8.2. SIP-Specific Issues . . . . . . . . . . . . . . . . . . . 10 83 8.2.1. Fork Explosion . . . . . . . . . . . . . . . . . . . . 10 84 8.2.2. Malicious Retargeting . . . . . . . . . . . . . . . . 11 85 8.2.3. Privacy Issues . . . . . . . . . . . . . . . . . . . . 11 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 87 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 89 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 90 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 91 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12 92 A.1. Changes since draft-ietf-p2psip-reload-00 . . . . . . . . 12 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 95 1. Overview 97 The SIP Usage of RELOAD allows SIP user agents to provide a peer-to- 98 peer telephony service without the requirement for permanent proxy or 99 registration servers. In such a network, the RELOAD overlay itself 100 performs the registration and rendezvous functions ordinarily 101 associated with such servers. 103 The SIP Usage involves two basic functions: 104 Registration: SIP UAs can use the RELOAD data storage 105 functionality to store a mapping from their AOR to their Node-ID 106 in the overlay, and to retrieve the Node-ID of other UAs. 107 Rendezvous: Once a SIP UA has identified the Node-ID for an AOR it 108 wishes to call, it can use the RELOAD message routing system to 109 set up a direct connection which can be used to exchange SIP 110 messages. 112 For instance, Bob could register his Node-ID, "1234", under his AOR, 113 "sip:bob@dht.example.com". When Alice wants to call Bob, she queries 114 the overlay for "sip:bob@dht.example.com" and gets back Node-ID 1234. 115 She then uses the overlay to establish a direct connection with Bob 116 and can use that direct connection to perform a standard SIP INVITE. 117 The way this works is as follows: 119 1. Bob, operating Node-ID 1234, stores a mapping from his URI to his 120 Node-ID in the overlay. I.e., "sip:bob@dht.example.com -> 1234". 121 2. Alice, operating Node-ID 5678, decides to call Bob. She looks up 122 "sip:bob@dht.example.com" in the overlay and retrieves "1234". 123 3. Alice uses the overlay to route an AppAttach message to Bob's 124 peer. Bob responds with his own AppAttach and they set up a 125 direct connection, as shown below. 127 Alice Peer1 Overlay PeerN Bob 128 (5678) (1234) 129 ------------------------------------------------- 130 AppAttach -> 131 AppAttach -> 132 AppAttach -> 133 AppAttach -> 134 <- AppAttach 135 <- AppAttach 136 <- AppAttach 137 <- AppAttach 139 <------------------ ICE Checks -----------------> 140 INVITE -----------------------------------------> 141 <--------------------------------------------- OK 142 ACK --------------------------------------------> 143 <------------ ICE Checks for media -------------> 144 <-------------------- RTP ----------------------> 146 It is important to note that RELOAD's only role here is to set up the 147 direct SIP connection between Alice and Bob. As soon as the ICE 148 checks complete and the connection is established, then ordinary SIP 149 is used. In particular, the establishment of the media channel for 150 the phone call happens via the usual SIP mechanisms, and RELOAD is 151 not involved. Media never goes over the overlay. After the 152 successful exchange of SIP messages, call peers run ICE connectivity 153 checks for media. 155 As well as allowing mappings from AORs to Node-IDs, the SIP Usage 156 also allows mappings from AORs to other AORs. For instance, if Bob 157 wanted his phone calls temporarily forwarded to Charlie, he could 158 store the mapping "sip:bob@dht.example.com -> 159 sip:charlie@dht.example.com". When Alice wants to call Bob, she 160 retrieves this mapping and can then fetch Charlie's AOR to retrieve 161 his Node-ID. 163 2. Terminology 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in RFC 2119 [RFC2119]. 169 We use the terminology and definitions from Concepts and Terminology 170 for Peer to Peer SIP [I-D.ietf-p2psip-concepts] and the RELOAD Base 171 Protocol [I-D.ietf-p2psip-base] extensively in this document. 173 3. Registering AORs 175 In ordinary SIP, a UA registers its AOR and location with a 176 registrar. In RELOAD, this registrar function is provided by the 177 overlay as a whole. To register its location, a RELOAD peer stores a 178 SipRegistration structure under its own AOR. This uses the SIP- 179 REGISTRATION Kind-ID, which is formally defined in Section 7. 180 Note: GRUUs are handled via a separate mechanism, as described in 181 Section 6. 183 As a simple example, if Alice's AOR were "sip:alice@dht.example.com" 184 and her Node-ID were "1234", she might store the mapping 185 "sip:alice@example.org -> 1234". This would tell anyone who wanted 186 to call Alice to contact node "1234". 188 RELOAD peers MAY store two kinds of SIP mappings: 190 o From AORs to destination lists (a single Node-ID is just a trivial 191 destination list.) 192 o From AORs to other AORs. 194 The meaning of the first kind of mapping is "in order to contact me, 195 form a connection with this peer." The meaning of the second kind of 196 mapping is "in order to contact me, dereference this AOR". This 197 allows for forwarding. For instance, if Alice wants calls to her to 198 be forwarded to her secretary, Sam, she might insert the following 199 mapping "sip:alice@dht.example.org -> sip:sam@dht.example.org". 201 The contents of a SipRegistration structure are as follows: 203 enum {sip_registration_uri (1), sip_registration_route (2), 204 (255)} SipRegistrationType; 206 select (SipRegistration.type) { 207 case sip_registration_uri: 208 opaque uri<0..2^16-1>; 210 case sip_registration_route: 211 opaque contact_prefs<0..2^16-1>; 212 Destination destination_list<0..2^16-1>; 214 /* This type can be extended */ 216 } SipRegistrationData; 218 struct { 219 SipRegistrationType type; 220 uint16 length; 221 SipRegistrationData data; 222 } SipRegistration; 224 The contents of the SipRegistration PDU are: 226 type 227 the type of the registration 229 length 230 the length of the rest of the PDU 232 data 233 the registration data 235 o If the registration is of type "sip_registration_uri", then the 236 contents are an opaque string containing the URI. 237 o If the registration is of type "sip_registration_route", then the 238 contents are an opaque string containing the callee's contact 239 preferences and a destination list for the peer. 241 RELOAD explicitly supports multiple registrations for a single AOR. 242 The registrations are stored in a Dictionary with the dictionary keys 243 being Node-IDs. Consider, for instance, the case where Alice has two 244 peers: 246 o her desk phone (1234) 247 o her cell phone (5678) 249 Alice might store the following in the overlay at resource 250 "sip:alice@dht.example.com". 252 o A SipRegistration of type "sip_registration_route" with dictionary 253 key "1234" and value "1234". 254 o A SipRegistration of type "sip_registration_route" with dictionary 255 key "5678" and value "5678". 257 Note that this structure explicitly allows one Node-ID to forward to 258 another Node-ID. For instance, Alice could set calls to her desk 259 phone to ring at her cell phone. It's not clear that this is useful 260 in this case, but may be useful if Alice has two AORs. 262 In order to prevent hijacking, registrations are subject to access 263 control rules. Before a Store is permitted, the storing peer MUST 264 check that: 266 o The certificate contains a username that is a SIP AOR that hashes 267 to the Resource-ID being stored at. 268 o The certificate contains a Node-ID that is the same as the 269 dictionary key being stored at. 271 Note that these rules permit Alice to forward calls to Bob without 272 his permission. However, they do not permit Alice to forward Bob's 273 calls to her. See Section 8.2.2 for more on this point. 275 4. Looking up an AOR 277 When a RELOAD user wishes to call another user, starting with a non- 278 GRUU AOR, he follows the following procedure. (GRUUs are discussed 279 in Section 6). 281 1. Check to see if the domain part of the AOR matches the domain 282 name of an overlay of which he is a member. If not, then this is 283 an external AOR, and he MUST do one of the following: 284 * Fail the call. 285 * Use ordinary SIP procedures. 286 * Attempt to become a member of the overlay indicated by the 287 domain part, if that overlay is a RELOAD overlay.) 288 2. Perform a Fetch for kind SIP-REGISTRATION at the Resource-ID 289 corresponding to the AOR. This Fetch SHOULD NOT indicate any 290 dictionary keys, which will result in fetching all the stored 291 values. 293 3. If any of the results of the Fetch are non-GRUU AORs, then repeat 294 step 1 for that AOR. 295 4. Once only GRUUs and destination lists remain, the peer removes 296 duplicate destination lists and GRUUs from the list and forms a 297 SIP connection to the appropriate peers as described in the 298 following sections. If there are also external AORs, the peer 299 follows the appropriate procedure for contacting them as well. 301 5. Forming a Direct Connection 303 Once the peer has translated the AOR into a set of destination lists, 304 it then uses the overlay to route AppAttach messages to each of those 305 peers. The "application" field MUST be 5060 to indicate SIP. If 306 certificate-based authentication is in use, the responding peer MUST 307 present a certificate with a Node-ID matching the terminal entry in 308 the route list. Note that it is possible that the peers already have 309 a RELOAD connection between them. This MUST NOT be used for SIP 310 messages. However, if a SIP connection already exists, that MAY be 311 used. Once the AppAttach succeeds, the peer sends SIP messages over 312 the connection as in normal SIP. 314 6. GRUUs 316 GRUUs do not require storing data in the Overlay Instance. Rather, 317 they are constructed by embedding a base64-encoded destination list 318 in the gr URI parameter of the GRUU. The base64 encoding is done 319 with the alphabet specified in table 1 of RFC 4648 with the exception 320 that ~ is used in place of =. An example GRUU is 321 "sip:alice@example.com;gr=MDEyMzQ1Njc4OTAxMjM0NTY3ODk~". When a peer 322 needs to route a message to a GRUU in the same P2P network, it simply 323 uses the destination list and connects to that peer. 325 Because a GRUU contains a destination list, it MAY have the same 326 contents as a destination list stored elsewhere in the resource 327 dictionary. 329 Anonymous GRUUs are done in roughly the same way but require either 330 that the enrollment server issue a different Node-ID for each 331 anonymous GRUU required or that a destination list be used that 332 includes a peer that compresses the destination list to stop the 333 Node-ID from being revealed. 335 7. SIP-REGISTRATION Kind Definition 337 This section defines the SIP-REGISTRATION kind. 339 Name SIP-REGISTRATION 341 Kind IDs The Resource Name for the SIP-REGISTRATION Kind-ID is the 342 AOR of the user. The data stored is a SipRegistrationData, which 343 can contain either another URI or a destination list to the peer 344 which is acting for the user. 346 Data Model The data model for the SIP-REGISTRATION Kind-ID is 347 dictionary. The dictionary key is the Node-ID of the storing 348 peer. This allows each peer (presumably corresponding to a single 349 device) to store a single route mapping. 351 Access Control USER-NODE-MATCH. 353 Data stored under the SIP-REGISTRATION kind is of type 354 SipRegistration. This comes in two varieties: 356 sip_registration_uri 357 a URI which the user can be reached at. 359 sip_registration_route 360 a destination list which can be used to reach the user's peer. 362 8. Security Considerations 364 8.1. Overview 366 RELOAD provides a generic storage service, albeit one designed to be 367 useful for P2PSIP. In this section we discuss security issues that 368 are likely to be relevant to any usage of RELOAD. In Section 8.2 we 369 describe issues that are specific to SIP. 371 8.2. SIP-Specific Issues 373 8.2.1. Fork Explosion 375 Because SIP includes a forking capability (the ability to retarget to 376 multiple recipients), fork bombs are a potential DoS concern. 377 However, in the SIP usage of RELOAD, fork bombs are a much lower 378 concern because the calling party is involved in each retargeting 379 event and can therefore directly measure the number of forks and 380 throttle at some reasonable number. 382 8.2.2. Malicious Retargeting 384 Another potential DoS attack is for the owner of an attractive number 385 to retarget all calls to some victim. This attack is difficult to 386 ameliorate without requiring the target of a SIP registration to 387 authorize all stores. The overhead of that requirement would be 388 excessive and in addition there are good use cases for retargeting to 389 a peer without there explicit cooperation. 391 8.2.3. Privacy Issues 393 All RELOAD SIP registration data is public. Methods of providing 394 location and identity privacy are still being studied. 396 9. IANA Considerations 398 IANA [shall register/has registered] code point TBD to represent the 399 SIP-REGISTRATION kind, as described in Section 7. 401 10. Acknowledgments 403 This draft is a merge of the "REsource LOcation And Discovery 404 (RELOAD)" draft by David A. Bryan, Marcia Zangrilli and Bruce B. 405 Lowekamp, the "Address Settlement by Peer to Peer" draft by Cullen 406 Jennings, Jonathan Rosenberg, and Eric Rescorla, the "Security 407 Extensions for RELOAD" draft by Bruce B. Lowekamp and James Deverick, 408 the "A Chord-based DHT for Resource Lookup in P2PSIP" by Marcia 409 Zangrilli and David A. Bryan, and the Peer-to-Peer Protocol (P2PP) 410 draft by Salman A. Baset, Henning Schulzrinne, and Marcin 411 Matuszewski. 413 Thanks to the many people who contributed including: Michael Chen, 414 TODO - fill in. 416 11. References 418 11.1. Normative References 420 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 421 Requirement Levels", BCP 14, RFC 2119, March 1997. 423 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 424 Protocol (SIP): Locating SIP Servers", RFC 3263, 425 June 2002. 427 [I-D.ietf-p2psip-base] 428 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 429 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 430 Base Protocol", draft-ietf-p2psip-base-00 (work in 431 progress), October 2008. 433 11.2. Informative References 435 [I-D.ietf-p2psip-concepts] 436 Bryan, D., Matthews, P., Shim, E., Willis, D., and S. 437 Dawkins, "Concepts and Terminology for Peer to Peer SIP", 438 draft-ietf-p2psip-concepts-02 (work in progress), 439 July 2008. 441 Appendix A. Change Log 443 A.1. Changes since draft-ietf-p2psip-reload-00 445 o Split SIP Usage from combined draft into new draft. 447 Authors' Addresses 449 Cullen Jennings 450 Cisco 451 170 West Tasman Drive 452 MS: SJC-21/2 453 San Jose, CA 95134 454 USA 456 Phone: +1 408 421-9990 457 Email: fluffy@cisco.com 459 Bruce B. Lowekamp (editor) 460 SIPeerior Technologies 461 5251-18 John Tyler Highway #330 462 Williamsburg, VA 23185 463 USA 465 Email: bbl@lowekamp.net 466 Eric Rescorla 467 Network Resonance 468 2064 Edgewood Drive 469 Palo Alto, CA 94303 470 USA 472 Phone: +1 650 320-8549 473 Email: ekr@networkresonance.com 475 Salman A. Baset 476 Columbia University 477 1214 Amsterdam Avenue 478 New York, NY 479 USA 481 Email: salman@cs.columbia.edu 483 Henning Schulzrinne 484 Columbia University 485 1214 Amsterdam Avenue 486 New York, NY 487 USA 489 Email: hgs@cs.columbia.edu