idnits 2.17.1 draft-ietf-p2psip-sip-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 224 has weird spacing: '...ionType type...' == Line 226 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 (July 7, 2011) is 4648 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-16 == Outdated reference: A later version (-09) exists of draft-ietf-p2psip-concepts-03 Summary: 0 errors (**), 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: January 8, 2012 Skype 6 E. Rescorla 7 RTFM, Inc. 8 S. Baset 9 H. Schulzrinne 10 Columbia University 11 July 7, 2011 13 A SIP Usage for RELOAD 14 draft-ietf-p2psip-sip-06 16 Abstract 18 This document defines a SIP Usage for REsource LOcation And Discovery 19 (RELOAD), The SIP Usage provides the functionality of a SIP proxy or 20 registrar in a fully-distributed system. The SIP Usage provides 21 lookup service for AoRs stored in the overlay. The SIP Usage also 22 defines GRUUs that allow the registrations to map an AoR to a 23 specific node reachable through the overlay. The AppAttach method is 24 used to establish a direct connection between nodes through which SIP 25 messages are exchanged. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 8, 2012. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 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 "bob@dht.example.com". When Alice wants to call Bob, she queries the 114 overlay for "bob@dht.example.com" and gets back Node-ID 1234. She 115 then uses the overlay to establish a direct connection with Bob and 116 can use that direct connection to perform a standard SIP INVITE. The 117 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., "bob@dht.example.com -> 1234". 121 2. Alice, operating Node-ID 5678, decides to call Bob. She looks up 122 "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 "bob@dht.example.com -> charlie@dht.example.com". 159 When Alice wants to call Bob, she retrieves this mapping and can then 160 fetch Charlie's AOR to retrieve his Node-ID. 162 2. Terminology 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in RFC 2119 [RFC2119]. 168 We use the terminology and definitions from Concepts and Terminology 169 for Peer to Peer SIP [I-D.ietf-p2psip-concepts] and the RELOAD Base 170 Protocol [I-D.ietf-p2psip-base] extensively in this document. 172 The term AOR is the SIP "Address of Record" used to inditify a user 173 in SIP. For example, alice@example.com could be the AOR for Alice. 174 For the purposes of this specification, an AOR is consiered not to 175 include the scheme (e.g sip:) as the AOR needs to match the 176 rfc822Name in the X509v3 certificates. 178 3. Registering AORs 180 In ordinary SIP, a UA registers its AOR and location with a 181 registrar. In RELOAD, this registrar function is provided by the 182 overlay as a whole. To register its location, a RELOAD peer stores a 183 SipRegistration structure under its own AOR. This uses the SIP- 184 REGISTRATION Kind-ID, which is formally defined in Section 7. 185 Note: GRUUs are handled via a separate mechanism, as described in 186 Section 6. 188 As a simple example, if Alice's AOR were "alice@dht.example.com" and 189 her Node-ID were "1234", she might store the mapping 190 "alice@example.org -> 1234". This would tell anyone who wanted to 191 call Alice to contact node "1234". 193 RELOAD peers MAY store two kinds of SIP mappings: 195 o From AORs to destination lists (a single Node-ID is just a trivial 196 destination list.) 197 o From AORs to other AORs. 199 The meaning of the first kind of mapping is "in order to contact me, 200 form a connection with this peer." The meaning of the second kind of 201 mapping is "in order to contact me, dereference this AOR". This 202 allows for forwarding. For instance, if Alice wants calls to her to 203 be forwarded to her secretary, Sam, she might insert the following 204 mapping "alice@dht.example.org -> sam@dht.example.org". 206 The contents of a SipRegistration structure are as follows: 208 enum {sip_registration_uri (1), sip_registration_route (2), 209 (255)} SipRegistrationType; 211 select (SipRegistration.type) { 212 case sip_registration_uri: 213 opaque uri<0..2^16-1>; 215 case sip_registration_route: 216 opaque contact_prefs<0..2^16-1>; 217 Destination destination_list<0..2^16-1>; 219 /* This type can be extended */ 221 } SipRegistrationData; 223 struct { 224 SipRegistrationType type; 225 uint16 length; 226 SipRegistrationData data; 227 } SipRegistration; 229 The contents of the SipRegistration PDU are: 231 type 232 the type of the registration 234 length 235 the length of the rest of the PDU 237 data 238 the registration data 240 o If the registration is of type "sip_registration_uri", then the 241 contents are an opaque string containing the URI. 242 o If the registration is of type "sip_registration_route", then the 243 contents are an opaque string containing the callee's contact 244 preferences and a destination list for the peer. 246 RELOAD explicitly supports multiple registrations for a single AOR. 247 The registrations are stored in a Dictionary with the dictionary keys 248 being Node-IDs. Consider, for instance, the case where Alice has two 249 peers: 251 o her desk phone (1234) 252 o her cell phone (5678) 254 Alice might store the following in the overlay at resource 255 "alice@dht.example.com". 257 o A SipRegistration of type "sip_registration_route" with dictionary 258 key "1234" and value "1234". 259 o A SipRegistration of type "sip_registration_route" with dictionary 260 key "5678" and value "5678". 262 Note that this structure explicitly allows one Node-ID to forward to 263 another Node-ID. For instance, Alice could set calls to her desk 264 phone to ring at her cell phone. It's not clear that this is useful 265 in this case, but may be useful if Alice has two AORs. 267 In order to prevent hijacking, registrations are subject to access 268 control rules. Before a Store is permitted, the storing peer MUST 269 check that: 271 o The certificate contains a username that is a SIP AOR that hashes 272 to the Resource-ID it is being stored at. 273 o The certificate contains a Node-ID that is the same as the 274 dictionary key it is being stored at. 276 Note that these rules permit Alice to forward calls to Bob without 277 his permission. However, they do not permit Alice to forward Bob's 278 calls to her. See Section 8.2.2 for more on this point. 280 4. Looking up an AOR 282 When a RELOAD user wishes to call another user, starting with a non- 283 GRUU AOR, he follows the following procedure. (GRUUs are discussed 284 in Section 6). 286 1. Check to see if the domain part of the AOR matches the domain 287 name of an overlay of which he is a member. If not, then this is 288 an external AOR, and he MUST do one of the following: 289 * Fail the call. 290 * Use ordinary SIP procedures. 291 * Attempt to become a member of the overlay indicated by the 292 domain part, if that overlay is a RELOAD overlay.) 293 2. Perform a Fetch for kind SIP-REGISTRATION at the Resource-ID 294 corresponding to the AOR. This Fetch SHOULD NOT indicate any 295 dictionary keys, so that it will fetch all the stored values. 297 3. If any of the results of the Fetch are non-GRUU AORs, then repeat 298 step 1 for that AOR. 299 4. Once only GRUUs and destination lists remain, the peer removes 300 duplicate destination lists and GRUUs from the list and forms a 301 SIP connection to the appropriate peers as described in the 302 following sections. If there are also external AORs, the peer 303 follows the appropriate procedure for contacting them as well. 305 5. Forming a Direct Connection 307 Once the peer has translated the AOR into a set of destination lists, 308 it then uses the overlay to route AppAttach messages to each of those 309 peers. The "application" field MUST be 5060 to indicate SIP. If 310 certificate-based authentication is in use, the responding peer MUST 311 present a certificate with a Node-ID matching the terminal entry in 312 the route list. Note that it is possible that the peers already have 313 a RELOAD connection between them. This MUST NOT be used for SIP 314 messages. However, if a SIP connection already exists, that MAY be 315 used. Once the AppAttach succeeds, the peer sends SIP messages over 316 the connection as in normal SIP. 318 6. GRUUs 320 GRUUs do not require storing data in the Overlay Instance. Rather, 321 they are constructed by embedding a base64-encoded destination list 322 in the gr URI parameter of the GRUU. The base64 encoding is done 323 with the alphabet specified in table 1 of RFC 4648 with the exception 324 that ~ is used in place of =. An example GRUU is 325 "alice@example.com;gr=MDEyMzQ1Njc4OTAxMjM0NTY3ODk~". When a peer 326 needs to route a message to a GRUU in the same P2P network, it simply 327 uses the destination list and connects to that peer. 329 Because a GRUU contains a destination list, it MAY have the same 330 contents as a destination list stored elsewhere in the resource 331 dictionary. 333 Anonymous GRUUs are done in roughly the same way but require either 334 that the enrollment server issue a different Node-ID for each 335 anonymous GRUU required or that a destination list be used that 336 includes a peer that compresses the destination list to stop the 337 Node-ID from being revealed. 339 7. SIP-REGISTRATION Kind Definition 341 This section defines the SIP-REGISTRATION kind. 343 Name SIP-REGISTRATION 345 Kind IDs The Resource Name for the SIP-REGISTRATION Kind-ID is the 346 AOR of the user. The data stored is a SipRegistration, which can 347 contain either another URI or a destination list to the peer which 348 is acting for the user. 350 Data Model The data model for the SIP-REGISTRATION Kind-ID is 351 dictionary. The dictionary key is the Node-ID of the storing 352 peer. This allows each peer (presumably corresponding to a single 353 device) to store a single route mapping. 355 Access Control USER-NODE-MATCH. Note that this matches the SIP AOR 356 against the rfc822Name in the X509v3 certificate. The rfc822Name 357 does not include the scheme so that "sip:" prefix needs to be 358 removed from the SIP AOR before matching. 360 Data stored under the SIP-REGISTRATION kind is of type 361 SipRegistration. This comes in two varieties: 363 sip_registration_uri 364 a URI which the user can be reached at. 366 sip_registration_route 367 a destination list which can be used to reach the user's peer. 369 8. Security Considerations 371 8.1. Overview 373 RELOAD provides a generic storage service, albeit one designed to be 374 useful for P2PSIP. In this section we discuss security issues that 375 are likely to be relevant to any usage of RELOAD. In Section 8.2 we 376 describe issues that are specific to SIP. 378 8.2. SIP-Specific Issues 380 8.2.1. Fork Explosion 382 Because SIP includes a forking capability (the ability to retarget to 383 multiple recipients), fork bombs are a potential DoS concern. 384 However, in the SIP usage of RELOAD, fork bombs are a much lower 385 concern because the calling party is involved in each retargeting 386 event and can therefore directly measure the number of forks and 387 throttle at some reasonable number. 389 8.2.2. Malicious Retargeting 391 Another potential DoS attack is for the owner of an attractive number 392 to retarget all calls to some victim. This attack is difficult to 393 ameliorate without requiring the target of a SIP registration to 394 authorize all stores. The overhead of that requirement would be 395 excessive and in addition there are good use cases for retargeting to 396 a peer without there explicit cooperation. 398 8.2.3. Privacy Issues 400 All RELOAD SIP registration data is public. Methods of providing 401 location and identity privacy are still being studied. 403 9. IANA Considerations 405 IANA [shall register/has registered] code point TBD to represent the 406 SIP-REGISTRATION kind, as described in Section 7. 408 10. Acknowledgments 410 This draft is a merge of the "REsource LOcation And Discovery 411 (RELOAD)" draft by David A. Bryan, Marcia Zangrilli and Bruce B. 412 Lowekamp, the "Address Settlement by Peer to Peer" draft by Cullen 413 Jennings, Jonathan Rosenberg, and Eric Rescorla, the "Security 414 Extensions for RELOAD" draft by Bruce B. Lowekamp and James Deverick, 415 the "A Chord-based DHT for Resource Lookup in P2PSIP" by Marcia 416 Zangrilli and David A. Bryan, and the Peer-to-Peer Protocol (P2PP) 417 draft by Salman A. Baset, Henning Schulzrinne, and Marcin 418 Matuszewski. 420 Thanks to Michael Chen for his contributions. 422 11. References 424 11.1. Normative References 426 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 427 Requirement Levels", BCP 14, RFC 2119, March 1997. 429 [I-D.ietf-p2psip-base] 430 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 431 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 432 Base Protocol", draft-ietf-p2psip-base-16 (work in 433 progress), July 2011. 435 11.2. Informative References 437 [I-D.ietf-p2psip-concepts] 438 Bryan, D., Matthews, P., Shim, E., Willis, D., and S. 439 Dawkins, "Concepts and Terminology for Peer to Peer SIP", 440 draft-ietf-p2psip-concepts-03 (work in progress), 441 October 2010. 443 Appendix A. Change Log 445 A.1. Changes since draft-ietf-p2psip-reload-00 447 o Split SIP Usage from combined draft into new draft. 449 Authors' Addresses 451 Cullen Jennings 452 Cisco 453 170 West Tasman Drive 454 MS: SJC-21/2 455 San Jose, CA 95134 456 USA 458 Phone: +1 408 421-9990 459 Email: fluffy@cisco.com 461 Bruce B. Lowekamp (editor) 462 Skype 463 Palo Alto, CA 464 USA 466 Email: bbl@lowekamp.net 468 Eric Rescorla 469 RTFM, Inc. 470 2064 Edgewood Drive 471 Palo Alto, CA 94303 472 USA 474 Phone: +1 650 678 2350 475 Email: ekr@rtfm.com 476 Salman A. Baset 477 Columbia University 478 1214 Amsterdam Avenue 479 New York, NY 480 USA 482 Email: salman@cs.columbia.edu 484 Henning Schulzrinne 485 Columbia University 486 1214 Amsterdam Avenue 487 New York, NY 488 USA 490 Email: hgs@cs.columbia.edu