idnits 2.17.1 draft-ietf-sipping-gruu-reg-event-07.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 563. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 574. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 581. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 587. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 13, 2006) is 6398 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '5' is defined on line 526, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-10 -- Obsolete informational reference (is this intentional?): RFC 3455 (ref. '6') (Obsoleted by RFC 7315) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Sipping P. Kyzivat 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Informational October 13, 2006 5 Expires: April 16, 2007 7 Registration Event Package Extension for Session Initiation Protocol 8 (SIP) Globally Routable User Agent URIs (GRUUs) 9 draft-ietf-sipping-gruu-reg-event-07 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 16, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 RFC 3680 defines a Session Initiation Protocol (SIP) event package 43 for registration state. This package allows a watcher to learn about 44 information stored by a SIP registrar, including its registered 45 contact. 47 However, the registered contact is frequently unreachable and thus 48 not useful for watchers. The Globally Routable User Agent URI 49 (GRUU), defined in RFC YYYY [3], is a URI that is capable of reaching 50 a particular contact. However this URI is not included in the 51 document format defined in RFC 3680. This specification defines an 52 extension to the registration event package to include GRUUs assigned 53 by the registrar. 55 [[NOTE TO RFC-EDITOR/IANA: Please replace YYYY throughout this 56 document with the RFC number assigned to the referenced draft [3] 57 when it is published.]] 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Notifier Processing of SUBSCRIBE Requests . . . . . . . . . . 4 65 5. Notifier Generation of NOTIFY Requests . . . . . . . . . . . . 4 66 6. Subscriber Processing of NOTIFY Requests . . . . . . . . . . . 5 67 7. Sample reginfo Document . . . . . . . . . . . . . . . . . . . 5 68 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 8.1. Example: Welcome Notice . . . . . . . . . . . . . . . . . 6 70 8.2. Example: Implicit Registration . . . . . . . . . . . . . . 7 71 9. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 10 72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 10.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 10 74 10.2. XML Schema Registration . . . . . . . . . . . . . . . . . 11 75 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 77 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 13.1. Normative References . . . . . . . . . . . . . . . . . . . 12 79 13.2. Informative References . . . . . . . . . . . . . . . . . . 13 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 Intellectual Property and Copyright Statements . . . . . . . . . . 14 83 1. Introduction 85 RFC 3680 [2] defines a Session Initiation Protocol (SIP) event 86 package for registration state. This package allows a watcher to 87 learn about information stored by a SIP registrar, including the 88 registered contacts. 90 However, a registered contact is frequently unreachable from hosts 91 outside of the domain of the user agent. It is commonly a private 92 address, or even when public direct access to it may be blocked by 93 firewalls. 95 The Globally Routable User Agent URI (GRUU), defined in RFC YYYY [3], 96 is a URI that reaches a particular UA instance, but is reachable by 97 any host on the Internet. GRUUs assigned by the registrar represent 98 additional registration state. However, GRUUs assigned by the 99 registrar are not included in the notifications provided by RFC 3680. 100 For many applications of the registration event package, a GRUU is 101 needed, and not the registered contact. 103 For example, the Welcome Notices example in [2] will only operate 104 correctly if the contact address in the "reg" event notification is 105 reachable by the sender of the welcome notice. When the registering 106 device is using the GRUU extension, it is likely that the registered 107 contact address will not be globally addressable, and a GRUU should 108 be used as the target address for the MESSAGE. 110 Another case where this feature may be helpful is within the 3GPP IP 111 Multimedia Subsystem (IMS). IMS employs a technique where a REGISTER 112 of a contact address to one Address of Record (AOR) causes the 113 implicit registration of the same contact to other associated AORs. 114 If GRUUs are requested and obtained as part of the registration 115 request, then additional GRUUs will also be needed for the implicit 116 registrations. While assigning the additional GRUUs is 117 straightforward, informing the registering UA of them is not. In 118 IMS, UAs typically subscribe to the "reg" event, and subscriptions to 119 the "reg" event for an AOR result in notifications containing 120 registration state for all the associated AORs. The proposed 121 extension provides a way to easily deliver the GRUUs for the 122 associated AORs. 124 The "reg" event package has provision for including extension 125 elements within the element. This document defines new 126 elements that may be used in that context to deliver the public and 127 anonymous GRUUs corresponding to the contact. 129 2. Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC 2119. [1] 135 3. Description 137 Two new elements ( and ) are defined, each of 138 which contains a GRUU. 140 These optional elements may be included within the body of a NOTIFY 141 for the "reg" event package when GRUUs are associated with the 142 contact. The contact URI and the GRUUs are then all available to the 143 watcher. 145 4. Notifier Processing of SUBSCRIBE Requests 147 Unchanged from RFC 3680 [2]. 149 5. Notifier Generation of NOTIFY Requests 151 A notifier for the "reg" event package [2] SHOULD include the element when a contact has an Instance ID and a public GRUU is 153 associated with the combination of the AOR and the Instance ID. When 154 present, the element MUST be be positioned as a child of 155 the element. 157 A notifier for the "reg" event package [2] MAY include the element when a contact has an Instance ID and an anonymous GRUU 159 is associated with the combination of the AOR and the Instance ID. 160 This element SHOULD be included if the subscriber is also authorized 161 to register to the AOR. This element SHOULD NOT be included if the 162 subscriber is not authorized to register to the AOR, unless there is 163 an explicitly configured policy directing that it be included. When 164 present, the element MUST be be positioned as a child of 165 the element. 167 Note that it is possible for multiple registered contacts to share 168 the same instance ID. In such a case, each element will 169 have child and elements, and those child 170 elements of each element will be identical. Since a 171 particular contact can not be associated with more than one instance 172 ID, a element will never have more than one and 173 one child element. 175 The content of the element is the public GRUU that is 176 associated with the instance ID and AOR of the registered contact. 178 The content of the element is the anonymous GRUU that is 179 associated with the instance ID and AOR of the registered contact. 181 6. Subscriber Processing of NOTIFY Requests 183 When a subscriber receives a "reg" event notification [2] with a 184 containing a and/or , it SHOULD use 185 one of the GRUUs in preference to the corresponding when 186 sending SIP requests to the contact. 188 Subscribers that are unaware of this extension will, as required by 189 [2], ignore the and elements. 191 7. Sample reginfo Document 193 Note: This example and others in the following section are 194 indented for readability by the addition of a fixed amount of 195 whitespace to the beginning of each line. This whitespace is not 196 part of the example. The conventions of [7] are used to describe 197 representation of long message lines. 199 The following is an example registration information document 200 including the new element: 202 203 206 208 211 sip:user@192.0.2.1 212 213 214 "<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>" 215 216 217 218 sip:user@example.com 219 ;gr;aor-qual=hha9s8d-999a 220 221 222 sip:8ffkas08af7fasklzi9@example.com 223 ;gr 224 225 226 227 229 8. Examples 231 Note: In the following examples the SIP messages have been 232 simplified, removing headers that are not pertinent to the example. 234 When the value of the Content-Length header field is "..." this means 235 that the value should be whatever the computed length of the body is. 237 8.1. Example: Welcome Notice 239 Consider the Welcome Notices example in [2]. When the application 240 server receives a notification of a new registration containing the 241 reginfo shown in Section 7 it should address messages using the 242 contained public GRUU as follows: 244 MESSAGE sip:user@example.com;gr;aor-qual=hha9s8d-999a SIP/2.0 245 To: 246 From: "SIPland Notifier" ;tag=7xy8 247 Content-Type: text/plain 248 Content-Length: ... 250 Welcome to SIPland! 251 Blah, blah, blah. 253 8.2. Example: Implicit Registration 255 In an 3GPP IMS setting, a UA may send a single register message, 256 requesting assignment of GRUUs, as follows: 258 REGISTER sip:example.net SIP/2.0 259 From: ;tag=5ab4 260 To: 261 Contact: 262 ;expires=3600 263 ;+sip.instance="" 264 Supported: path, gruu 265 Content-Length: 0 267 The response reports success of the registration and returns the 268 GRUUs assigned for the combination of AOR, Instance ID, and Contact. 269 It also indicates (via the P-Associated-URI header [6]) that there 270 are two other associated AORs that may have been implicitly 271 registered using the same contact. Each of those implicitly 272 registered AORs will have unique GRUUs assigned. The REGISTER 273 response will not include those GRUUs; it will only include the GRUUs 274 for the AOR and instance ID explicitly included in the registration. 276 SIP/2.0 200 OK 277 From: ;tag=5ab4 278 To: ;tag=373392 279 Path: 280 Service-Route: 281 Contact: 282 ;expires=3600 283 ;+sip.instance="" 284 ;pub-gruu="sip:user_aor_1@example.net;gr;aor-qual=hha9s8d-999a" 285 ;anon-gruu="sip:8ffkas08af7fasklzi9@example.net;gr" 286 P-Associated-URI: , 287 288 Content-Length: 0 290 The UA then subscribes to the "reg" event package as follows: 292 SUBSCRIBE sip:user_aor_1@example.net SIP/2.0 293 From: ;tag=27182 294 To: 295 Route: 296 Event: reg 297 Expires: 3600 298 Accept: application/reginfo+xml 299 Contact: 300 Content-Length: 0 302 (The successful response to the subscription is not shown.) Once the 303 subscription is established an initial notification is sent giving 304 registration status. In IMS deployments the response includes, in 305 addition to the status for the requested URI, the status for the 306 other associated URIs. 308 NOTIFY sip:user_aor_1@example.net;gr;aor-qual=hha9s8d-999a SIP/2.0 309 From: ;tag=27182 310 To: ;tag=262281 311 Subscription-State: active;expires=3600 312 Event: reg 313 Content-Type: application/reginfo+xml 314 Contact: 315 Content-Length: ... 317 318 321 323 325 326 sip:ua.example.com 327 328 329 330 "<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>" 331 332 333 334 sip:user_aor_1@example.net 335 ;gr;aor-qual=hha9s8d-999a 336 337 338 sip:8ffkas08af7fasklzi9@example.net 339 ;gr 340 341 342 343 345 347 348 sip:ua.example.com 349 350 351 352 "<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>" 353 354 355 356 sip:user_aor_2@example.net 357 ;gr;aor-qual=hha9s8d-999b 358 359 360 sip:07hcovy36vp6vngvbia@example.net 361 ;gr 362 363 364 365 369 371 372 sip:ua.example.com 373 374 375 376 "<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>" 377 378 379 380 sip:+358504821437@example.net;user=phone 381 ;gr;aor-qual=hha9s8d-999c 382 383 384 sip:h99egjbv17fe8ibvlka@example.net 385 ;gr 386 387 389 390 392 The status indicates that the associated URIs all have the same 393 contact registered. It also includes the unique GRUUs that have been 394 assigned to each. The UA may then retain those GRUUs for use when 395 establishing dialogs using the corresponding AORs. 397 9. XML Schema Definition 399 The and elements are defined within a new XML 400 namespace URI. This namespace is "urn:ietf:params:xml:ns:gruuinfo". 401 The schema for these elements is: 403 404 409 410 411 413 10. IANA Considerations 415 There are two IANA considerations associated with this specification. 417 10.1. URN Sub-Namespace Registration 419 This section registers a new XML namespace, per the guidelines in 420 [4]. 422 URI: The URI for this namespace is urn:ietf:params:xml:ns:gruuinfo 424 Registrant Contact: IETF, SIPPING working group, , 425 Paul Kyzivat 427 XML: 429 BEGIN 430 431 433 434 435 437 Reg Information GRUU Extension Namespace 438 439 440

Namespace for Reg Information GRUU Extension

441

urn:ietf:params:xml:ns:gruuinfo

442

See RFCXXXX [[NOTE 443 TO RFC-EDITOR/IANA: Please replace XXXX with the RFC Number of 444 this specification]].

445 446 447 END 449 10.2. XML Schema Registration 451 This section registers an XML schema per the procedures in [4]. 453 URI: urn:ietf:params:xml:schema:gruuinfo. 455 Registrant Contact: IETF, SIPPING working group, , 456 Paul Kyzivat 458 The XML for this schema can be found in Section 9. 460 11. Security Considerations 462 Security considerations for the registration event package are 463 discussed in RFC 3680 [2], and those considerations apply here. 465 If a contact address obtained via subscription to the registration 466 event package is not reachable by the subscriber then its disclosure 467 may arguably be considered a minimal security risk. In that case the 468 inclusion of a GRUU may be considered to increase the risk by 469 providing a reachable address. On the other hand requests addressed 470 to a GRUU are always first processed by the servicing proxy before 471 they reach the intended user agent. The proxy may control access as 472 desired, just as it may for the AOR. For instance, the proxy 473 servicing a GRUU may accept requests from senders whose identity 474 appears on a white list, and reject other requests. In this respect 475 disclosing a GRUU presents no more risk than disclosing the AOR. 477 Anonymous GRUUs have an additional security consideration. The 478 intent of the anonymous GRUU is to provide a contact address that 479 cannot be correlated to the identity of the calling party. The 480 recipient of a call using an anonymous GRUU may guess the identity of 481 the calling party and then attempt to obtain the anonymous GRUUs 482 assigned to that caller to confirm the conjecture. Two possible 483 approaches to obtaining the anonymous GRUUs are: 485 o Send a REGISTER request to a conjectured caller. 486 o Send a SUBSCRIBE request for the "reg" event package to the 487 conjectured caller. 489 Typically REGISTER is restricted to devices or users that are 490 authorized to originate and received calls with the AOR. Anonymity 491 among users of the same AOR is hard to achieve and typically 492 unnecessary. It is recommended (see Section 5) that the 493 authorization policy for the "reg" event package permit only those 494 subscribers authorized to register to the AOR to receive anonymous 495 GRUUs. With this policy, the confidentiality of the anonymous GRUU 496 will be the same with and without the "reg" event package. User 497 agents that use an anonymous GRUU should note that confidentiality 498 does not extend to parties that are permitted to register to the AOR 499 or obtain the anonymous GRUU when subscribing the "reg" event 500 package. 502 12. Acknowledgements 504 The author would like to thank Jonathan Rosenberg for help with this 505 draft, and Jari Urpalainen for assistance with the XML. 507 13. References 509 13.1. Normative References 511 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 512 Levels", BCP 14, RFC 2119, March 1997. 514 [2] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 515 Package for Registrations", RFC 3680, March 2004. 517 [3] Rosenberg, J., "Obtaining and Using Globally Routable User Agent 518 (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", 519 draft-ietf-sip-gruu-10 (work in progress), August 2006. 521 [4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 522 January 2004. 524 13.2. Informative References 526 [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 527 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 528 Session Initiation Protocol", RFC 3261, June 2002. 530 [6] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private Header 531 (P-Header) Extensions to the Session Initiation Protocol (SIP) 532 for the 3rd-Generation Partnership Project (3GPP)", RFC 3455, 533 January 2003. 535 [7] Sparks, R., "Session Initiation Protocol Torture Test Messages", 536 draft-ietf-sipping-torture-tests-09 (work in progress), 537 November 2005. 539 Author's Address 541 Paul H. Kyzivat 542 Cisco Systems, Inc. 543 1414 Massachusetts Avenue 544 Boxborough, MA 01719 545 USA 547 Email: pkyzivat@cisco.com 549 Full Copyright Statement 551 Copyright (C) The Internet Society (2006). 553 This document is subject to the rights, licenses and restrictions 554 contained in BCP 78, and except as set forth therein, the authors 555 retain all their rights. 557 This document and the information contained herein are provided on an 558 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 559 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 560 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 561 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 562 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 563 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 565 Intellectual Property 567 The IETF takes no position regarding the validity or scope of any 568 Intellectual Property Rights or other rights that might be claimed to 569 pertain to the implementation or use of the technology described in 570 this document or the extent to which any license under such rights 571 might or might not be available; nor does it represent that it has 572 made any independent effort to identify any such rights. Information 573 on the procedures with respect to rights in RFC documents can be 574 found in BCP 78 and BCP 79. 576 Copies of IPR disclosures made to the IETF Secretariat and any 577 assurances of licenses to be made available, or the result of an 578 attempt made to obtain a general license or permission for the use of 579 such proprietary rights by implementers or users of this 580 specification can be obtained from the IETF on-line IPR repository at 581 http://www.ietf.org/ipr. 583 The IETF invites any interested party to bring to its attention any 584 copyrights, patents or patent applications, or other proprietary 585 rights that may cover technology that may be required to implement 586 this standard. Please address the information to the IETF at 587 ietf-ipr@ietf.org. 589 Acknowledgment 591 Funding for the RFC Editor function is provided by the IETF 592 Administrative Support Activity (IASA).