idnits 2.17.1 draft-ietf-p2psip-sip-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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 516. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 527. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 534. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 540. 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 Copyright Line does not match the current year == Line 209 has weird spacing: '...ionType type...' == Line 211 has weird spacing: '...ionData data...' -- 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 (October 27, 2008) is 5661 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 (==), 8 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 30, 2009 SIPeerior Technologies 6 E. Rescorla 7 Network Resonance 8 S. Baset 9 H. Schulzrinne 10 Columbia University 11 October 27, 2008 13 A SIP Usage for RELOAD 14 draft-ietf-p2psip-sip-00 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on April 30, 2009. 41 Abstract 43 This document defines a SIP Usage for REsource LOcation And Discovery 44 (RELOAD), The SIP Usage provides the functionality of a SIP proxy or 45 registrar in a fully-distributed system. The SIP Usage provides 46 lookup service for AoRs stored in the overlay. The SIP Usage also 47 defines GRUUs that allow the registrations to map an AoR to a 48 specific node reachable through the overlay. The Attach method is 49 used to establish a direct connection between nodes through which SIP 50 messages are exchanged. 52 Table of Contents 54 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. Registering AORs . . . . . . . . . . . . . . . . . . . . . . . 5 57 4. Looking up an AOR . . . . . . . . . . . . . . . . . . . . . . 7 58 5. Forming a Direct Connection . . . . . . . . . . . . . . . . . 8 59 6. GRUUs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 7. SIP-REGISTRATION Kind Definition . . . . . . . . . . . . . . . 8 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 8.2. SIP-Specific Issues . . . . . . . . . . . . . . . . . . . 10 64 8.2.1. Fork Explosion . . . . . . . . . . . . . . . . . . . . 10 65 8.2.2. Malicious Retargeting . . . . . . . . . . . . . . . . 10 66 8.2.3. Privacy Issues . . . . . . . . . . . . . . . . . . . . 10 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 71 11.2. Informative References . . . . . . . . . . . . . . . . . . 11 72 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 11 73 A.1. Changes since draft-ietf-p2psip-reload-00 . . . . . . . . 11 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 75 Intellectual Property and Copyright Statements . . . . . . . . . . 14 77 1. Overview 79 The SIP Usage of RELOAD allows SIP user agents to provide a peer-to- 80 peer telephony service without the requirement for permanent proxy or 81 registration servers. In such a network, the RELOAD overlay itself 82 performs the registration and rendezvous functions ordinarily 83 associated with such servers. 85 The SIP Usage involves two basic functions: 86 Registration: SIP UAs can use the RELOAD data storage 87 functionality to store a mapping from their AOR to their Node-ID 88 in the overlay, and to retrieve the Node-ID of other UAs. 89 Rendezvous: Once a SIP UA has identified the Node-ID for an AOR it 90 wishes to call, it can use the RELOAD message routing system to 91 set up a direct connection which can be used to exchange SIP 92 messages. 94 For instance, Bob could register his Node-ID, "1234", under his AOR, 95 "sip:bob@dht.example.com". When Alice wants to call Bob, she queries 96 the overlay for "sip:bob@dht.example.com" and gets back Node-ID 1234. 97 She then uses the overlay to establish a direct connection with Bob 98 and can use that direct connection to perform a standard SIP INVITE. 99 The way this works is as follows: 101 1. Bob, operating Node-ID 1234, stores a mapping from his URI to his 102 Node-ID in the overlay. I.e., "sip:bob@dht.example.com -> 1234". 103 2. Alice, operating Node-ID 5678, decides to call Bob. She looks up 104 "sip:bob@dht.example.com" in the overlay and retrieves "1234". 105 3. Alice uses the overlay to route an Attach message to Bob's peer. 106 Bob responds with his own Attach and they set up a direct 107 connection, as shown below. 109 Alice Peer1 Overlay PeerN Bob 110 (5678) (1234) 111 ------------------------------------------------- 112 Attach -> 113 Attach -> 114 Attach -> 115 Attach -> 116 <- Attach 117 <- Attach 118 <- Attach 119 <- Attach 121 <------------------ ICE Checks -----------------> 122 INVITE -----------------------------------------> 123 <--------------------------------------------- OK 124 ACK --------------------------------------------> 125 <------------ ICE Checks for media -------------> 126 <-------------------- RTP ----------------------> 128 It is important to note that RELOAD's only role here is to set up the 129 direct connection between Alice and Bob. As soon as the ICE checks 130 complete and the connection is established, then ordinary SIP is 131 used. In particular, the establishment of the media channel for the 132 phone call happens via the usual SIP mechanisms, and RELOAD is not 133 involved. Media never goes over the overlay. After the successful 134 exchange of SIP messages, call peers run ICE connectivity checks for 135 media. 137 As well as allowing mappings from AORs to Node-IDs, the SIP Usage 138 also allows mappings from AORs to other AORs. For instance, if Bob 139 wanted his phone calls temporarily forwarded to Charlie, he could 140 store the mapping "sip:bob@dht.example.com -> 141 sip:charlie@dht.example.com". When Alice wants to call Bob, she 142 retrieves this mapping and can then fetch Charlie's AOR to retrieve 143 his Node-ID. 145 The SIP usage allows a RELOAD overlay to be used as a distributed SIP 146 registrar/proxy network augmenting the functionality of [RFC3263]. 147 This entails three primary operations: 149 o Registering one's own AOR with the overlay. 150 o Looking up a given AOR in the overlay. 151 o Forming a direct connection to a given peer. 153 2. Terminology 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in RFC 2119 [RFC2119]. 159 We use the terminology and definitions from Concepts and Terminology 160 for Peer to Peer SIP [I-D.ietf-p2psip-concepts] and the RELOAD Base 161 Protocol [I-D.ietf-p2psip-base] extensively in this document. 163 3. Registering AORs 165 In ordinary SIP, a UA registers its AOR and location with a 166 registrar. In RELOAD, this registrar function is provided by the 167 overlay as a whole. To register its location, a RELOAD peer stores a 168 SipRegistration structure under its own AOR. This uses the SIP- 169 REGISTRATION Kind-ID, which is formally defined in Section 7. 170 Note: GRUUs are handled via a separate mechanism, as described in 171 Section 6. 173 As a simple example, if Alice's AOR were "sip:alice@dht.example.com" 174 and her Node-ID were "1234", she might store the mapping 175 "sip:alice@example.org -> 1234". This would tell anyone who wanted 176 to call Alice to contact node "1234". 178 RELOAD peers MAY store two kinds of SIP mappings: 180 o From AORs to destination lists (a single Node-ID is just a trivial 181 destination list.) 182 o From AORs to other AORs. 184 The meaning of the first kind of mapping is "in order to contact me, 185 form a connection with this peer." The meaning of the second kind of 186 mapping is "in order to contact me, dereference this AOR". This 187 allows for forwarding. For instance, if Alice wants calls to her to 188 be forwarded to her secretary, Sam, she might insert the following 189 mapping "sip:alice@dht.example.org -> sip:sam@dht.example.org". 191 The contents of a SipRegistration structure are as follows: 193 enum {sip_registration_uri (1), sip_registration_route (2), 194 (255)} SipRegistrationType; 196 select (SipRegistration.type) { 197 case sip_registration_uri: 198 opaque uri<0..2^16-1>; 200 case sip_registration_route: 201 opaque contact_prefs<0..2^16-1>; 202 Destination destination_list<0..2^16-1>; 204 /* This type can be extended */ 206 } SipRegistrationData; 208 struct { 209 SipRegistrationType type; 210 uint16 length; 211 SipRegistrationData data; 212 } SipRegistration; 214 The contents of the SipRegistration PDU are: 216 type 217 the type of the registration 219 length 220 the length of the rest of the PDU 222 data 223 the registration data 225 o If the registration is of type "sip_registration_uri", then the 226 contents are an opaque string containing the URI. 227 o If the registration is of type "sip_registration_route", then the 228 contents are an opaque string containing the callee's contact 229 preferences and a destination list for the peer. 231 RELOAD explicitly supports multiple registrations for a single AOR. 232 The registrations are stored in a Dictionary with the dictionary keys 233 being Node-IDs. Consider, for instance, the case where Alice has two 234 peers: 236 o her desk phone (1234) 237 o her cell phone (5678) 239 Alice might store the following in the overlay at resource 240 "sip:alice@dht.example.com". 242 o A SipRegistration of type "sip_registration_route" with dictionary 243 key "1234" and value "1234". 244 o A SipRegistration of type "sip_registration_route" with dictionary 245 key "5678" and value "5678". 247 Note that this structure explicitly allows one Node-ID to forward to 248 another Node-ID. For instance, Alice could set calls to her desk 249 phone to ring at her cell phone. It's not clear that this is useful 250 in this case, but may be useful if Alice has two AORs. 252 In order to prevent hijacking, registrations are subject to access 253 control rules. Before a Store is permitted, the storing peer MUST 254 check that: 256 o The certificate contains a username that is a SIP AOR that hashes 257 to the Resource-ID being stored at. 258 o The certificate contains a Node-ID that is the same as the 259 dictionary key being stored at. 261 Note that these rules permit Alice to forward calls to Bob without 262 his permission. However, they do not permit Alice to forward Bob's 263 calls to her. See Section 8.2.2 for more on this point. 265 4. Looking up an AOR 267 When a RELOAD user wishes to call another user, starting with a non- 268 GRUU AOR, he follows the following procedure. (GRUUs are discussed 269 in Section 6). 271 1. Check to see if the domain part of the AOR matches the domain 272 name of an overlay of which he is a member. If not, then this is 273 an external AOR, and he MUST do one of the following: 274 * Fail the call. 275 * Use ordinary SIP procedures. 276 * Attempt to become a member of the overlay indicated by the 277 domain part, if that overlay is a RELOAD overlay.) 278 2. Perform a Fetch for kind SIP-REGISTRATION at the Resource-ID 279 corresponding to the AOR. This Fetch SHOULD NOT indicate any 280 dictionary keys, which will result in fetching all the stored 281 values. 283 3. If any of the results of the Fetch are non-GRUU AORs, then repeat 284 step 1 for that AOR. 285 4. Once only GRUUs and destination lists remain, the peer removes 286 duplicate destination lists and GRUUs from the list and forms a 287 SIP connection to the appropriate peers as described in the 288 following sections. If there are also external AORs, the peer 289 follows the appropriate procedure for contacting them as well. 291 5. Forming a Direct Connection 293 Once the peer has translated the AOR into a set of destination lists, 294 it then uses the overlay to route Attach messages to each of those 295 peers. The "application" field MUST be 5060 to indicate SIP. If 296 certificate-based authentication is in use, the responding peer MUST 297 present a certificate with a Node-ID matching the terminal entry in 298 the route list. Note that it is possible that the peers already have 299 a RELOAD connection between them. This MUST NOT be used for SIP 300 messages. However, if a SIP connection already exists, that MAY be 301 used. Once the Attach succeeds, the peer sends SIP messages over the 302 connection as in normal SIP. 304 6. GRUUs 306 GRUUs do not require storing data in the Overlay Instance. Rather, 307 they are constructed by embedding a base64-encoded destination list 308 in the gr URI parameter of the GRUU. The base64 encoding is done 309 with the alphabet specified in table 1 of RFC 4648 with the exception 310 that ~ is used in place of =. An example GRUU is 311 "sip:alice@example.com;gr=MDEyMzQ1Njc4OTAxMjM0NTY3ODk~". When a peer 312 needs to route a message to a GRUU in the same P2P network, it simply 313 uses the destination list and connects to that peer. 315 Because a GRUU contains a destination list, it MAY have the same 316 contents as a destination list stored elsewhere in the resource 317 dictionary. 319 Anonymous GRUUs are done in roughly the same way but require either 320 that the enrollment server issue a different Node-ID for each 321 anonymous GRUU required or that a destination list be used that 322 includes a peer that compresses the destination list to stop the 323 Node-ID from being revealed. 325 7. SIP-REGISTRATION Kind Definition 327 The first mapping is provided using the SIP-REGISTRATION Kind-ID: 329 Kind IDs The Resource Name for the SIP-REGISTRATION Kind-ID is the 330 AOR of the user. The data stored is a SipRegistrationData, which 331 can contain either another URI or a destination list to the peer 332 which is acting for the user. 334 Data Model The data model for the SIP-REGISTRATION Kind-ID is 335 dictionary. The dictionary key is the Node-ID of the storing 336 peer. This allows each peer (presumably corresponding to a single 337 device) to store a single route mapping. 339 Access Control If certificate-based access control is being used, 340 stored data of Kind-ID SIP-REGISTRATION must be signed by a 341 certificate which (1) contains user name matching the storing URI 342 used as the Resource Name for the Resource-ID and (2) contains a 343 Node-ID matching the storing dictionary key. 345 Data stored under the SIP-REGISTRATION kind is of type 346 SipRegistration. This comes in two varieties: 348 sip_registration_uri 349 a URI which the user can be reached at. 351 sip_registration_route 352 a destination list which can be used to reach the user's peer. 354 8. Security Considerations 356 8.1. Overview 358 RELOAD provides a generic storage service, albeit one designed to be 359 useful for P2PSIP. In this section we discuss security issues that 360 are likely to be relevant to any usage of RELOAD. In Section 8.2 we 361 describe issues that are specific to SIP. 363 In any Overlay Instance, any given user depends on a number of peers 364 with which they have no well-defined relationship except that they 365 are fellow members of the Overlay Instance. In practice, these other 366 nodes may be friendly, lazy, curious, or outright malicious. No 367 security system can provide complete protection in an environment 368 where most nodes are malicious. The goal of security in RELOAD is to 369 provide strong security guarantees of some properties even in the 370 face of a large number of malicious nodes and to allow the overlay to 371 function correctly in the face of a modest number of malicious nodes. 373 P2PSIP deployments require the ability to authenticate both peers and 374 resources (users) without the active presence of a trusted entity in 375 the system. We describe two mechanisms. The first mechanism is 376 based on public key certificates and is suitable for general 377 deployments. The second is an admission control mechanism based on 378 an overlay-wide shared symmetric key. 380 8.2. SIP-Specific Issues 382 8.2.1. Fork Explosion 384 Because SIP includes a forking capability (the ability to retarget to 385 multiple recipients), fork bombs are a potential DoS concern. 386 However, in the SIP usage of RELOAD, fork bombs are a much lower 387 concern because the calling party is involved in each retargeting 388 event and can therefore directly measure the number of forks and 389 throttle at some reasonable number. 391 8.2.2. Malicious Retargeting 393 Another potential DoS attack is for the owner of an attractive number 394 to retarget all calls to some victim. This attack is difficult to 395 ameliorate without requiring the target of a SIP registration to 396 authorize all stores. The overhead of that requirement would be 397 excessive and in addition there are good use cases for retargeting to 398 a peer without there explicit cooperation. 400 8.2.3. Privacy Issues 402 All RELOAD SIP registration data is public. Methods of providing 403 location and identity privacy are still being studied. 405 9. IANA Considerations 407 This section contains the new code points registered by this 408 document. 410 TODO define SIP usage specific kinds, etc here. 412 10. Acknowledgments 414 This draft is a merge of the "REsource LOcation And Discovery 415 (RELOAD)" draft by David A. Bryan, Marcia Zangrilli and Bruce B. 416 Lowekamp, the "Address Settlement by Peer to Peer" draft by Cullen 417 Jennings, Jonathan Rosenberg, and Eric Rescorla, the "Security 418 Extensions for RELOAD" draft by Bruce B. Lowekamp and James Deverick, 419 the "A Chord-based DHT for Resource Lookup in P2PSIP" by Marcia 420 Zangrilli and David A. Bryan, and the Peer-to-Peer Protocol (P2PP) 421 draft by Salman A. Baset, Henning Schulzrinne, and Marcin 422 Matuszewski. 424 Thanks to the many people who contributed including: Michael Chen, 425 TODO - fill in. 427 11. References 429 11.1. Normative References 431 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 432 Requirement Levels", BCP 14, RFC 2119, March 1997. 434 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 435 Protocol (SIP): Locating SIP Servers", RFC 3263, 436 June 2002. 438 [I-D.ietf-p2psip-base] 439 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 440 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 441 Base Protocol", draft-ietf-p2psip-base-00 (work in 442 progress), October 2008. 444 11.2. Informative References 446 [I-D.ietf-p2psip-concepts] 447 Bryan, D., Matthews, P., Shim, E., Willis, D., and S. 448 Dawkins, "Concepts and Terminology for Peer to Peer SIP", 449 draft-ietf-p2psip-concepts-02 (work in progress), 450 July 2008. 452 Appendix A. Change Log 454 A.1. Changes since draft-ietf-p2psip-reload-00 456 o Split SIP Usage from combined draft into new draft. 458 Authors' Addresses 460 Cullen Jennings 461 Cisco 462 170 West Tasman Drive 463 MS: SJC-21/2 464 San Jose, CA 95134 465 USA 467 Phone: +1 408 421-9990 468 Email: fluffy@cisco.com 470 Bruce B. Lowekamp (editor) 471 SIPeerior Technologies 472 5251-18 John Tyler Highway #330 473 Williamsburg, VA 23185 474 USA 476 Email: bbl@lowekamp.net 478 Eric Rescorla 479 Network Resonance 480 2064 Edgewood Drive 481 Palo Alto, CA 94303 482 USA 484 Phone: +1 650 320-8549 485 Email: ekr@networkresonance.com 487 Salman A. Baset 488 Columbia University 489 1214 Amsterdam Avenue 490 New York, NY 491 USA 493 Email: salman@cs.columbia.edu 494 Henning Schulzrinne 495 Columbia University 496 1214 Amsterdam Avenue 497 New York, NY 498 USA 500 Email: hgs@cs.columbia.edu 502 Full Copyright Statement 504 Copyright (C) The IETF Trust (2008). 506 This document is subject to the rights, licenses and restrictions 507 contained in BCP 78, and except as set forth therein, the authors 508 retain all their rights. 510 This document and the information contained herein are provided on an 511 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 512 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 513 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 514 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 515 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 516 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 518 Intellectual Property 520 The IETF takes no position regarding the validity or scope of any 521 Intellectual Property Rights or other rights that might be claimed to 522 pertain to the implementation or use of the technology described in 523 this document or the extent to which any license under such rights 524 might or might not be available; nor does it represent that it has 525 made any independent effort to identify any such rights. Information 526 on the procedures with respect to rights in RFC documents can be 527 found in BCP 78 and BCP 79. 529 Copies of IPR disclosures made to the IETF Secretariat and any 530 assurances of licenses to be made available, or the result of an 531 attempt made to obtain a general license or permission for the use of 532 such proprietary rights by implementers or users of this 533 specification can be obtained from the IETF on-line IPR repository at 534 http://www.ietf.org/ipr. 536 The IETF invites any interested party to bring to its attention any 537 copyrights, patents or patent applications, or other proprietary 538 rights that may cover technology that may be required to implement 539 this standard. Please address the information to the IETF at 540 ietf-ipr@ietf.org.