idnits 2.17.1 draft-ietf-p2psip-sip-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 225 has weird spacing: '...ionType type...' == Line 227 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 8, 2010) is 5163 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: September 9, 2010 MYMIC LLC 6 E. Rescorla 7 Network Resonance 8 S. Baset 9 H. Schulzrinne 10 Columbia University 11 March 8, 2010 13 A SIP Usage for RELOAD 14 draft-ietf-p2psip-sip-04 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 to IETF 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), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 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 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on September 9, 2010. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the BSD License. 65 This document may contain material from IETF Documents or IETF 66 Contributions published or made publicly available before November 67 10, 2008. The person(s) controlling the copyright in some of this 68 material may not have granted the IETF Trust the right to allow 69 modifications of such material outside the IETF Standards Process. 70 Without obtaining an adequate license from the person(s) controlling 71 the copyright in such materials, this document may not be modified 72 outside the IETF Standards Process, and derivative works of it may 73 not be created outside the IETF Standards Process, except to format 74 it for publication as an RFC or to translate it into languages other 75 than English. 77 Table of Contents 79 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 3. Registering AORs . . . . . . . . . . . . . . . . . . . . . . . 6 82 4. Looking up an AOR . . . . . . . . . . . . . . . . . . . . . . 8 83 5. Forming a Direct Connection . . . . . . . . . . . . . . . . . 9 84 6. GRUUs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 85 7. SIP-REGISTRATION Kind Definition . . . . . . . . . . . . . . . 9 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 87 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10 88 8.2. SIP-Specific Issues . . . . . . . . . . . . . . . . . . . 10 89 8.2.1. Fork Explosion . . . . . . . . . . . . . . . . . . . . 10 90 8.2.2. Malicious Retargeting . . . . . . . . . . . . . . . . 11 91 8.2.3. Privacy Issues . . . . . . . . . . . . . . . . . . . . 11 92 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 93 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 94 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 95 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 96 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 97 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12 98 A.1. Changes since draft-ietf-p2psip-reload-00 . . . . . . . . 12 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 101 1. Overview 103 The SIP Usage of RELOAD allows SIP user agents to provide a peer-to- 104 peer telephony service without the requirement for permanent proxy or 105 registration servers. In such a network, the RELOAD overlay itself 106 performs the registration and rendezvous functions ordinarily 107 associated with such servers. 109 The SIP Usage involves two basic functions: 110 Registration: SIP UAs can use the RELOAD data storage 111 functionality to store a mapping from their AOR to their Node-ID 112 in the overlay, and to retrieve the Node-ID of other UAs. 113 Rendezvous: Once a SIP UA has identified the Node-ID for an AOR it 114 wishes to call, it can use the RELOAD message routing system to 115 set up a direct connection which can be used to exchange SIP 116 messages. 118 For instance, Bob could register his Node-ID, "1234", under his AOR, 119 "sip:bob@dht.example.com". When Alice wants to call Bob, she queries 120 the overlay for "sip:bob@dht.example.com" and gets back Node-ID 1234. 121 She then uses the overlay to establish a direct connection with Bob 122 and can use that direct connection to perform a standard SIP INVITE. 123 The way this works is as follows: 125 1. Bob, operating Node-ID 1234, stores a mapping from his URI to his 126 Node-ID in the overlay. I.e., "sip:bob@dht.example.com -> 1234". 127 2. Alice, operating Node-ID 5678, decides to call Bob. She looks up 128 "sip:bob@dht.example.com" in the overlay and retrieves "1234". 129 3. Alice uses the overlay to route an AppAttach message to Bob's 130 peer. Bob responds with his own AppAttach and they set up a 131 direct connection, as shown below. 133 Alice Peer1 Overlay PeerN Bob 134 (5678) (1234) 135 ------------------------------------------------- 136 AppAttach -> 137 AppAttach -> 138 AppAttach -> 139 AppAttach -> 140 <- AppAttach 141 <- AppAttach 142 <- AppAttach 143 <- AppAttach 145 <------------------ ICE Checks -----------------> 146 INVITE -----------------------------------------> 147 <--------------------------------------------- OK 148 ACK --------------------------------------------> 149 <------------ ICE Checks for media -------------> 150 <-------------------- RTP ----------------------> 152 It is important to note that RELOAD's only role here is to set up the 153 direct SIP connection between Alice and Bob. As soon as the ICE 154 checks complete and the connection is established, then ordinary SIP 155 is used. In particular, the establishment of the media channel for 156 the phone call happens via the usual SIP mechanisms, and RELOAD is 157 not involved. Media never goes over the overlay. After the 158 successful exchange of SIP messages, call peers run ICE connectivity 159 checks for media. 161 As well as allowing mappings from AORs to Node-IDs, the SIP Usage 162 also allows mappings from AORs to other AORs. For instance, if Bob 163 wanted his phone calls temporarily forwarded to Charlie, he could 164 store the mapping "sip:bob@dht.example.com -> 165 sip:charlie@dht.example.com". When Alice wants to call Bob, she 166 retrieves this mapping and can then fetch Charlie's AOR to retrieve 167 his Node-ID. 169 2. Terminology 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in RFC 2119 [RFC2119]. 175 We use the terminology and definitions from Concepts and Terminology 176 for Peer to Peer SIP [I-D.ietf-p2psip-concepts] and the RELOAD Base 177 Protocol [I-D.ietf-p2psip-base] extensively in this document. 179 3. Registering AORs 181 In ordinary SIP, a UA registers its AOR and location with a 182 registrar. In RELOAD, this registrar function is provided by the 183 overlay as a whole. To register its location, a RELOAD peer stores a 184 SipRegistration structure under its own AOR. This uses the SIP- 185 REGISTRATION Kind-ID, which is formally defined in Section 7. 186 Note: GRUUs are handled via a separate mechanism, as described in 187 Section 6. 189 As a simple example, if Alice's AOR were "sip:alice@dht.example.com" 190 and her Node-ID were "1234", she might store the mapping 191 "sip:alice@example.org -> 1234". This would tell anyone who wanted 192 to call Alice to contact node "1234". 194 RELOAD peers MAY store two kinds of SIP mappings: 196 o From AORs to destination lists (a single Node-ID is just a trivial 197 destination list.) 198 o From AORs to other AORs. 200 The meaning of the first kind of mapping is "in order to contact me, 201 form a connection with this peer." The meaning of the second kind of 202 mapping is "in order to contact me, dereference this AOR". This 203 allows for forwarding. For instance, if Alice wants calls to her to 204 be forwarded to her secretary, Sam, she might insert the following 205 mapping "sip:alice@dht.example.org -> sip:sam@dht.example.org". 207 The contents of a SipRegistration structure are as follows: 209 enum {sip_registration_uri (1), sip_registration_route (2), 210 (255)} SipRegistrationType; 212 select (SipRegistration.type) { 213 case sip_registration_uri: 214 opaque uri<0..2^16-1>; 216 case sip_registration_route: 217 opaque contact_prefs<0..2^16-1>; 218 Destination destination_list<0..2^16-1>; 220 /* This type can be extended */ 222 } SipRegistrationData; 224 struct { 225 SipRegistrationType type; 226 uint16 length; 227 SipRegistrationData data; 228 } SipRegistration; 230 The contents of the SipRegistration PDU are: 232 type 233 the type of the registration 235 length 236 the length of the rest of the PDU 238 data 239 the registration data 241 o If the registration is of type "sip_registration_uri", then the 242 contents are an opaque string containing the URI. 243 o If the registration is of type "sip_registration_route", then the 244 contents are an opaque string containing the callee's contact 245 preferences and a destination list for the peer. 247 RELOAD explicitly supports multiple registrations for a single AOR. 248 The registrations are stored in a Dictionary with the dictionary keys 249 being Node-IDs. Consider, for instance, the case where Alice has two 250 peers: 252 o her desk phone (1234) 253 o her cell phone (5678) 255 Alice might store the following in the overlay at resource 256 "sip:alice@dht.example.com". 258 o A SipRegistration of type "sip_registration_route" with dictionary 259 key "1234" and value "1234". 260 o A SipRegistration of type "sip_registration_route" with dictionary 261 key "5678" and value "5678". 263 Note that this structure explicitly allows one Node-ID to forward to 264 another Node-ID. For instance, Alice could set calls to her desk 265 phone to ring at her cell phone. It's not clear that this is useful 266 in this case, but may be useful if Alice has two AORs. 268 In order to prevent hijacking, registrations are subject to access 269 control rules. Before a Store is permitted, the storing peer MUST 270 check that: 272 o The certificate contains a username that is a SIP AOR that hashes 273 to the Resource-ID it is being stored at. 274 o The certificate contains a Node-ID that is the same as the 275 dictionary key it is being stored at. 277 Note that these rules permit Alice to forward calls to Bob without 278 his permission. However, they do not permit Alice to forward Bob's 279 calls to her. See Section 8.2.2 for more on this point. 281 4. Looking up an AOR 283 When a RELOAD user wishes to call another user, starting with a non- 284 GRUU AOR, he follows the following procedure. (GRUUs are discussed 285 in Section 6). 287 1. Check to see if the domain part of the AOR matches the domain 288 name of an overlay of which he is a member. If not, then this is 289 an external AOR, and he MUST do one of the following: 290 * Fail the call. 291 * Use ordinary SIP procedures. 292 * Attempt to become a member of the overlay indicated by the 293 domain part, if that overlay is a RELOAD overlay.) 294 2. Perform a Fetch for kind SIP-REGISTRATION at the Resource-ID 295 corresponding to the AOR. This Fetch SHOULD NOT indicate any 296 dictionary keys, so that it will fetch all the stored values. 298 3. If any of the results of the Fetch are non-GRUU AORs, then repeat 299 step 1 for that AOR. 300 4. Once only GRUUs and destination lists remain, the peer removes 301 duplicate destination lists and GRUUs from the list and forms a 302 SIP connection to the appropriate peers as described in the 303 following sections. If there are also external AORs, the peer 304 follows the appropriate procedure for contacting them as well. 306 5. Forming a Direct Connection 308 Once the peer has translated the AOR into a set of destination lists, 309 it then uses the overlay to route AppAttach messages to each of those 310 peers. The "application" field MUST be 5060 to indicate SIP. If 311 certificate-based authentication is in use, the responding peer MUST 312 present a certificate with a Node-ID matching the terminal entry in 313 the route list. Note that it is possible that the peers already have 314 a RELOAD connection between them. This MUST NOT be used for SIP 315 messages. However, if a SIP connection already exists, that MAY be 316 used. Once the AppAttach succeeds, the peer sends SIP messages over 317 the connection as in normal SIP. 319 6. GRUUs 321 GRUUs do not require storing data in the Overlay Instance. Rather, 322 they are constructed by embedding a base64-encoded destination list 323 in the gr URI parameter of the GRUU. The base64 encoding is done 324 with the alphabet specified in table 1 of RFC 4648 with the exception 325 that ~ is used in place of =. An example GRUU is 326 "sip:alice@example.com;gr=MDEyMzQ1Njc4OTAxMjM0NTY3ODk~". When a peer 327 needs to route a message to a GRUU in the same P2P network, it simply 328 uses the destination list and connects to that peer. 330 Because a GRUU contains a destination list, it MAY have the same 331 contents as a destination list stored elsewhere in the resource 332 dictionary. 334 Anonymous GRUUs are done in roughly the same way but require either 335 that the enrollment server issue a different Node-ID for each 336 anonymous GRUU required or that a destination list be used that 337 includes a peer that compresses the destination list to stop the 338 Node-ID from being revealed. 340 7. SIP-REGISTRATION Kind Definition 342 This section defines the SIP-REGISTRATION kind. 344 Name SIP-REGISTRATION 346 Kind IDs The Resource Name for the SIP-REGISTRATION Kind-ID is the 347 AOR of the user. The data stored is a SipRegistrationData, which 348 can contain either another URI or a destination list to the peer 349 which is acting for the user. 351 Data Model The data model for the SIP-REGISTRATION Kind-ID is 352 dictionary. The dictionary key is the Node-ID of the storing 353 peer. This allows each peer (presumably corresponding to a single 354 device) to store a single route mapping. 356 Access Control USER-NODE-MATCH. Note that this matches the SIP AOR 357 against the rfc822Name in the X509v3 certificate. The rfc822Name 358 does not include the scheme so that "sip:" prefix needs to be 359 removed from the SIP AOR before matching. 361 Data stored under the SIP-REGISTRATION kind is of type 362 SipRegistration. This comes in two varieties: 364 sip_registration_uri 365 a URI which the user can be reached at. 367 sip_registration_route 368 a destination list which can be used to reach the user's peer. 370 8. Security Considerations 372 8.1. Overview 374 RELOAD provides a generic storage service, albeit one designed to be 375 useful for P2PSIP. In this section we discuss security issues that 376 are likely to be relevant to any usage of RELOAD. In Section 8.2 we 377 describe issues that are specific to SIP. 379 8.2. SIP-Specific Issues 381 8.2.1. Fork Explosion 383 Because SIP includes a forking capability (the ability to retarget to 384 multiple recipients), fork bombs are a potential DoS concern. 385 However, in the SIP usage of RELOAD, fork bombs are a much lower 386 concern because the calling party is involved in each retargeting 387 event and can therefore directly measure the number of forks and 388 throttle at some reasonable number. 390 8.2.2. Malicious Retargeting 392 Another potential DoS attack is for the owner of an attractive number 393 to retarget all calls to some victim. This attack is difficult to 394 ameliorate without requiring the target of a SIP registration to 395 authorize all stores. The overhead of that requirement would be 396 excessive and in addition there are good use cases for retargeting to 397 a peer without there explicit cooperation. 399 8.2.3. Privacy Issues 401 All RELOAD SIP registration data is public. Methods of providing 402 location and identity privacy are still being studied. 404 9. IANA Considerations 406 IANA [shall register/has registered] code point TBD to represent the 407 SIP-REGISTRATION kind, as described in Section 7. 409 10. Acknowledgments 411 This draft is a merge of the "REsource LOcation And Discovery 412 (RELOAD)" draft by David A. Bryan, Marcia Zangrilli and Bruce B. 413 Lowekamp, the "Address Settlement by Peer to Peer" draft by Cullen 414 Jennings, Jonathan Rosenberg, and Eric Rescorla, the "Security 415 Extensions for RELOAD" draft by Bruce B. Lowekamp and James Deverick, 416 the "A Chord-based DHT for Resource Lookup in P2PSIP" by Marcia 417 Zangrilli and David A. Bryan, and the Peer-to-Peer Protocol (P2PP) 418 draft by Salman A. Baset, Henning Schulzrinne, and Marcin 419 Matuszewski. 421 Thanks to Michael Chen for his contributions. 423 11. References 425 11.1. Normative References 427 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 428 Requirement Levels", BCP 14, RFC 2119, March 1997. 430 [I-D.ietf-p2psip-base] 431 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 432 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 433 Base Protocol", draft-ietf-p2psip-base-00 (work in 434 progress), October 2008. 436 11.2. Informative References 438 [I-D.ietf-p2psip-concepts] 439 Bryan, D., Matthews, P., Shim, E., Willis, D., and S. 440 Dawkins, "Concepts and Terminology for Peer to Peer SIP", 441 draft-ietf-p2psip-concepts-02 (work in progress), 442 July 2008. 444 Appendix A. Change Log 446 A.1. Changes since draft-ietf-p2psip-reload-00 448 o Split SIP Usage from combined draft into new draft. 450 Authors' Addresses 452 Cullen Jennings 453 Cisco 454 170 West Tasman Drive 455 MS: SJC-21/2 456 San Jose, CA 95134 457 USA 459 Phone: +1 408 421-9990 460 Email: fluffy@cisco.com 462 Bruce B. Lowekamp (editor) 463 MYMIC LLC 464 1040 University Blvd., Suite 100 465 Portsmouth, VA 23703 466 USA 468 Email: bbl@lowekamp.net 470 Eric Rescorla 471 Network Resonance 472 2064 Edgewood Drive 473 Palo Alto, CA 94303 474 USA 476 Phone: +1 650 320-8549 477 Email: ekr@networkresonance.com 478 Salman A. Baset 479 Columbia University 480 1214 Amsterdam Avenue 481 New York, NY 482 USA 484 Email: salman@cs.columbia.edu 486 Henning Schulzrinne 487 Columbia University 488 1214 Amsterdam Avenue 489 New York, NY 490 USA 492 Email: hgs@cs.columbia.edu