idnits 2.17.1 draft-ietf-p2psip-sip-03.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 (October 22, 2009) is 5298 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) == 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 (~~), 5 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: April 25, 2010 MYMIC LLC 6 E. Rescorla 7 Network Resonance 8 S. Baset 9 H. Schulzrinne 10 Columbia University 11 October 22, 2009 13 A SIP Usage for RELOAD 14 draft-ietf-p2psip-sip-03 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 April 25, 2010. 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 it is being stored at. 268 o The certificate contains a Node-ID that is the same as the 269 dictionary key it is 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, so that it will fetch all the stored values. 292 3. If any of the results of the Fetch are non-GRUU AORs, then repeat 293 step 1 for that AOR. 294 4. Once only GRUUs and destination lists remain, the peer removes 295 duplicate destination lists and GRUUs from the list and forms a 296 SIP connection to the appropriate peers as described in the 297 following sections. If there are also external AORs, the peer 298 follows the appropriate procedure for contacting them as well. 300 5. Forming a Direct Connection 302 Once the peer has translated the AOR into a set of destination lists, 303 it then uses the overlay to route AppAttach messages to each of those 304 peers. The "application" field MUST be 5060 to indicate SIP. If 305 certificate-based authentication is in use, the responding peer MUST 306 present a certificate with a Node-ID matching the terminal entry in 307 the route list. Note that it is possible that the peers already have 308 a RELOAD connection between them. This MUST NOT be used for SIP 309 messages. However, if a SIP connection already exists, that MAY be 310 used. Once the AppAttach succeeds, the peer sends SIP messages over 311 the connection as in normal SIP. 313 6. GRUUs 315 GRUUs do not require storing data in the Overlay Instance. Rather, 316 they are constructed by embedding a base64-encoded destination list 317 in the gr URI parameter of the GRUU. The base64 encoding is done 318 with the alphabet specified in table 1 of RFC 4648 with the exception 319 that ~ is used in place of =. An example GRUU is 320 "sip:alice@example.com;gr=MDEyMzQ1Njc4OTAxMjM0NTY3ODk~". When a peer 321 needs to route a message to a GRUU in the same P2P network, it simply 322 uses the destination list and connects to that peer. 324 Because a GRUU contains a destination list, it MAY have the same 325 contents as a destination list stored elsewhere in the resource 326 dictionary. 328 Anonymous GRUUs are done in roughly the same way but require either 329 that the enrollment server issue a different Node-ID for each 330 anonymous GRUU required or that a destination list be used that 331 includes a peer that compresses the destination list to stop the 332 Node-ID from being revealed. 334 7. SIP-REGISTRATION Kind Definition 336 This section defines the SIP-REGISTRATION kind. 338 Name SIP-REGISTRATION 340 Kind IDs The Resource Name for the SIP-REGISTRATION Kind-ID is the 341 AOR of the user. The data stored is a SipRegistrationData, which 342 can contain either another URI or a destination list to the peer 343 which is acting for the user. 345 Data Model The data model for the SIP-REGISTRATION Kind-ID is 346 dictionary. The dictionary key is the Node-ID of the storing 347 peer. This allows each peer (presumably corresponding to a single 348 device) to store a single route mapping. 350 Access Control USER-NODE-MATCH. 352 Data stored under the SIP-REGISTRATION kind is of type 353 SipRegistration. This comes in two varieties: 355 sip_registration_uri 356 a URI which the user can be reached at. 358 sip_registration_route 359 a destination list which can be used to reach the user's peer. 361 8. Security Considerations 363 8.1. Overview 365 RELOAD provides a generic storage service, albeit one designed to be 366 useful for P2PSIP. In this section we discuss security issues that 367 are likely to be relevant to any usage of RELOAD. In Section 8.2 we 368 describe issues that are specific to SIP. 370 8.2. SIP-Specific Issues 372 8.2.1. Fork Explosion 374 Because SIP includes a forking capability (the ability to retarget to 375 multiple recipients), fork bombs are a potential DoS concern. 376 However, in the SIP usage of RELOAD, fork bombs are a much lower 377 concern because the calling party is involved in each retargeting 378 event and can therefore directly measure the number of forks and 379 throttle at some reasonable number. 381 8.2.2. Malicious Retargeting 383 Another potential DoS attack is for the owner of an attractive number 384 to retarget all calls to some victim. This attack is difficult to 385 ameliorate without requiring the target of a SIP registration to 386 authorize all stores. The overhead of that requirement would be 387 excessive and in addition there are good use cases for retargeting to 388 a peer without there explicit cooperation. 390 8.2.3. Privacy Issues 392 All RELOAD SIP registration data is public. Methods of providing 393 location and identity privacy are still being studied. 395 9. IANA Considerations 397 IANA [shall register/has registered] code point TBD to represent the 398 SIP-REGISTRATION kind, as described in Section 7. 400 10. Acknowledgments 402 This draft is a merge of the "REsource LOcation And Discovery 403 (RELOAD)" draft by David A. Bryan, Marcia Zangrilli and Bruce B. 404 Lowekamp, the "Address Settlement by Peer to Peer" draft by Cullen 405 Jennings, Jonathan Rosenberg, and Eric Rescorla, the "Security 406 Extensions for RELOAD" draft by Bruce B. Lowekamp and James Deverick, 407 the "A Chord-based DHT for Resource Lookup in P2PSIP" by Marcia 408 Zangrilli and David A. Bryan, and the Peer-to-Peer Protocol (P2PP) 409 draft by Salman A. Baset, Henning Schulzrinne, and Marcin 410 Matuszewski. 412 Thanks to Michael Chen for his contributions. 414 11. References 416 11.1. Normative References 418 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 419 Requirement Levels", BCP 14, RFC 2119, March 1997. 421 [I-D.ietf-p2psip-base] 422 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 423 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 424 Base Protocol", draft-ietf-p2psip-base-00 (work in 425 progress), October 2008. 427 11.2. Informative References 429 [I-D.ietf-p2psip-concepts] 430 Bryan, D., Matthews, P., Shim, E., Willis, D., and S. 431 Dawkins, "Concepts and Terminology for Peer to Peer SIP", 432 draft-ietf-p2psip-concepts-02 (work in progress), 433 July 2008. 435 Appendix A. Change Log 437 A.1. Changes since draft-ietf-p2psip-reload-00 439 o Split SIP Usage from combined draft into new draft. 441 Authors' Addresses 443 Cullen Jennings 444 Cisco 445 170 West Tasman Drive 446 MS: SJC-21/2 447 San Jose, CA 95134 448 USA 450 Phone: +1 408 421-9990 451 Email: fluffy@cisco.com 453 Bruce B. Lowekamp (editor) 454 MYMIC LLC 455 1040 University Blvd., Suite 100 456 Portsmouth, VA 23703 457 USA 459 Email: bbl@lowekamp.net 461 Eric Rescorla 462 Network Resonance 463 2064 Edgewood Drive 464 Palo Alto, CA 94303 465 USA 467 Phone: +1 650 320-8549 468 Email: ekr@networkresonance.com 469 Salman A. Baset 470 Columbia University 471 1214 Amsterdam Avenue 472 New York, NY 473 USA 475 Email: salman@cs.columbia.edu 477 Henning Schulzrinne 478 Columbia University 479 1214 Amsterdam Avenue 480 New York, NY 481 USA 483 Email: hgs@cs.columbia.edu