idnits 2.17.1 draft-ietf-sip-gruu-11.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1582. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1559. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1566. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1572. ** 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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 23, 2006) is 6392 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3265 (ref. '5') (Obsoleted by RFC 6665) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '11') ** Obsolete normative reference: RFC 4566 (ref. '12') (Obsoleted by RFC 8866) == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-04 -- Possible downref: Non-RFC (?) normative reference: ref. '15' == Outdated reference: A later version (-12) exists of draft-ietf-sipping-cc-transfer-06 Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP J. Rosenberg 3 Internet-Draft Cisco Systems 4 Expires: April 26, 2007 October 23, 2006 6 Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the 7 Session Initiation Protocol (SIP) 8 draft-ietf-sip-gruu-11 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 26, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 Several applications of the Session Initiation Protocol (SIP) require 42 a user agent (UA) to construct and distribute a URI that can be used 43 by anyone on the Internet to route a call to that specific UA 44 instance. A URI that routes to a specific UA instance is called a 45 Globally Routable UA URI (GRUU). This document describes an 46 extension to SIP for obtaining a GRUU from a registrar and for 47 communicating a GRUU to a peer within a dialog. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4 54 3.1. Structure of GRUUs . . . . . . . . . . . . . . . . . . . . 4 55 3.1.1. GRUUs Which Expose the Underlying AOR . . . . . . . . 5 56 3.1.2. GRUUs Which Hide the Underlying AOR . . . . . . . . . 5 57 3.2. Obtaining a GRUU . . . . . . . . . . . . . . . . . . . . . 6 58 3.3. Using a GRUU . . . . . . . . . . . . . . . . . . . . . . . 7 59 3.4. Dereferencing a GRUU . . . . . . . . . . . . . . . . . . . 7 60 4. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 7 61 4.1. Generating a REGISTER Request . . . . . . . . . . . . . . 7 62 4.2. Learning GRUUs from REGISTER Responses . . . . . . . . . . 8 63 4.3. Constructing a Self-Made GRUU . . . . . . . . . . . . . . 9 64 4.4. Using Ones Own GRUUs . . . . . . . . . . . . . . . . . . . 9 65 4.4.1. Considerations for Multiple AORs . . . . . . . . . . . 10 66 4.5. Dereferencing a GRUU . . . . . . . . . . . . . . . . . . . 10 67 4.6. Rendering GRUUs on a User Interface . . . . . . . . . . . 11 68 5. Registrar Behavior . . . . . . . . . . . . . . . . . . . . . . 11 69 5.1. Processing a REGISTER Request . . . . . . . . . . . . . . 11 70 5.2. Generating a REGISTER Response . . . . . . . . . . . . . . 12 71 5.3. Timing Out a Registration . . . . . . . . . . . . . . . . 13 72 5.4. Creation of a GRUU . . . . . . . . . . . . . . . . . . . . 13 73 6. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 15 74 6.1. Request Targeting . . . . . . . . . . . . . . . . . . . . 15 75 6.2. Record-Routing . . . . . . . . . . . . . . . . . . . . . . 17 76 7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 77 8. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 18 78 9. Example Call Flow . . . . . . . . . . . . . . . . . . . . . . 19 79 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 80 10.1. Outside Attacks . . . . . . . . . . . . . . . . . . . . . 24 81 10.2. Inside Attacks . . . . . . . . . . . . . . . . . . . . . . 25 82 10.3. Privacy Considerations . . . . . . . . . . . . . . . . . . 26 83 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 84 11.1. Header Field Parameter . . . . . . . . . . . . . . . . . . 27 85 11.2. URI Parameter . . . . . . . . . . . . . . . . . . . . . . 28 86 11.3. SIP Option Tag . . . . . . . . . . . . . . . . . . . . . . 28 87 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 88 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 89 13.1. Normative References . . . . . . . . . . . . . . . . . . . 29 90 13.2. Informative References . . . . . . . . . . . . . . . . . . 30 91 Appendix A. Example GRUU Construction Algorithms . . . . . . . . 31 92 A.1. Public GRUU Algorithm . . . . . . . . . . . . . . . . . . 31 93 A.2. Temporary GRUU . . . . . . . . . . . . . . . . . . . . . . 31 94 Appendix B. Network Design Considerations . . . . . . . . . . . . 33 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34 96 Intellectual Property and Copyright Statements . . . . . . . . . . 35 98 1. Introduction 100 In the Session Initiation Protocol (SIP), RFC 3261 [1], the basic 101 unit of reference is the Address-Of-Record (AOR). However, in SIP 102 systems a single user can have a number of user agents (handsets, 103 softphones, voicemail accounts, etc.) which are all referenced by the 104 same AOR. There are a number of contexts in which it is desirable to 105 have an identifier which addresses a single user agent rather than 106 the group of user agents indicated by an AOR. 108 As an example, consider a blind transfer application [21]. User A is 109 talking to user B. User A wants to transfer the call to user C. So, 110 user A sends a REFER to user C. That REFER looks like, in part: 112 REFER sip:C@example.com SIP/2.0 113 From: sip:A@example.com;tag=99asd 114 To: sip:C@example.com 115 Refer-To: (URI that identifies B's UA) 117 The Refer-To header field needs to contain a URI that can be used by 118 user C to place a call to user B. However, this call needs to route 119 to the specific UA instance that user B is using to talk to user A. 120 If it doesn't, the transfer service will not execute properly. For 121 example, if A provides C with B's AOR, the call might be routed to 122 B's voice mail rather than B's current handset. 124 In order to enable this functionality, User B provides an instance- 125 specific URI to User A in the Contact header of their SIP exchange. 126 This URI refers only the the user agent B is currently using and can 127 be provided to user C. Because user B doesn't know in advance who 128 user A will transfer the call to, the URI has to be usable by anyone. 130 Many current clients attempt to meet the need for an instance- 131 specific identifier by using explicit IP addresses in the values they 132 provide in the Contact header field. However, this interacts poorly 133 with NATs and firewalls, and as a practical matter these URIs cannot 134 be used by arbitrary external clients. Similarly, usage of hostnames 135 has proven problematic for similar reasons. In addition, many SIP 136 clients do not have or cannot obtain a hostname for themselves at 137 all. 139 This specification describes a mechanism for providing a unique user- 140 agent identifier which is still globally routable. This identifier 141 is called a Globally Routable User Agent (UA) URI (GRUU). 143 2. Terminology 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in RFC 2119 [4]. 149 This specification defines the following additional terms: 151 contact: The term "contact", when used in all lowercase, refers to a 152 URI that is bound to an AOR and GRUU by means of a registration. 153 A contact is usually a SIP URI, and is bound to the AOR and GRUU 154 through a REGISTER request by appearing as a value of the Contact 155 header field. The contact URI identifies a specific UA. 157 remote target: The term "remote target" refers to a URI that a user 158 agent uses to identify itself for receipt of both mid-dialog and 159 out-of-dialog requests. A remote target is established by placing 160 a URI in the Contact header field of a dialog-forming request or 161 response and updated by target refresh requests or responses. 163 Contact header field: The term "Contact header field", with a 164 capitalized C, refers to the header field which can appear in 165 REGISTER requests and responses, redirects, or in dialog-creating 166 requests and responses. Depending on the semantics, the Contact 167 header field sometimes conveys a contact, and sometimes conveys a 168 remote target. 170 3. Overview of Operation 172 The basic idea behind a GRUU is simple. GRUUs are issued by SIP 173 domains and always route back to a proxy in that domain. The domain 174 in turn maintains the binding between the GRUU and the particular UA 175 instance. When a GRUU is de-referenced when sending a SIP request, 176 that request arrives at the proxy. It maps the GRUU to the contact 177 for the particular UA instance, and sends the request there. 179 3.1. Structure of GRUUs 181 A GRUU is a SIP URI that has two properties: 183 o It routes to a specific UA instance. 185 o It can be successfully de-referenced by any user agent on the 186 Internet, not just ones in the same domain or IP network as the UA 187 instance to which the GRUU points. 189 In principle, a GRUU can be constructed in any way the domain 190 chooses, as long as it meets the criteria above. However, all GRUUs 191 contain the "gr" URI parameter (either with or without a value), so 192 that a recipient of a GRUU can tell that it has these two properties. 194 In practice, there are two different types of GRUUs: 196 1. GRUUs which expose the underlying AOR 198 2. GRUUs which hide the underlying AOR 200 3.1.1. GRUUs Which Expose the Underlying AOR 202 In many cases it is desirable to construct the GRUU in such a way 203 that the mapping to the AOR is apparent. For example, many user 204 agents retain call logs, which keep track of incoming and outgoing 205 call attempts. If the UA had made a call towards a GRUU (perhaps as 206 a consequence of a transfer request), the call log will contain the 207 GRUU. Since the call log is rendered to the user, it would be useful 208 to be able to present the user with the AOR instead, since the AOR is 209 meaningful to users as an identifier. 211 This type of GRUU is called a public GRUU. It is constructed by 212 taking the AOR, and adding the "gr" URI parameter with a value chosen 213 by the registrar in the domain. The value of the "gr" parameter 214 contains a representation of the UA instance. For instance, if the 215 AOR was "sip:alice@example.com", the GRUU might be: 217 sip:alice@example.com;gr=kjh29x97us97d 219 If a UA removes the "gr" parameter, the result is the AOR. Since 220 many systems ignore unknown parameters anyway, a public GRUU will 221 "look" like the AOR to those systems. 223 3.1.2. GRUUs Which Hide the Underlying AOR 225 In other cases it is desirable to construct a GRUU that obfuscates 226 the AOR such that it cannot be extracted by a recipient of the GRUU. 227 Such a GRUU is called a temporary GRUU. The most obvious reason to 228 do this is to protect the user's privacy. In such cases, the GRUU 229 may have any content provided that it meets the requirements in 230 Section 3.1, and the AOR cannot be readily determined from the GRUU. 231 The GRUU will have the "gr" parameter, either with or without a 232 value. In order to avoid creating excessive state in the registrar, 233 it is often desirable to construct cryptographically protected 234 "stateless" GRUUs using an algorithm like that described in Appendix 235 A. 237 3.2. Obtaining a GRUU 239 A User Agent can obtain a GRUU in one of several ways: 241 o As part of its REGISTER transaction. 243 o By constructing one locally, using the IP address or hostname of 244 the user agent instance as the domain part of the URI. These are 245 called self-made GRUUs, and are only really GRUUs when constructed 246 by UA that know they are globally reachable using their IP address 247 or hostname. 249 o Via some locally-specified Administrative mechanism. 251 A UA which wants to obtain a GRUU via its REGISTER request does so by 252 providing an instance ID in the "+sip.instance" parameter in the 253 Contact header field [14]. For example: 255 Contact: 256 ;+sip.instance="" 258 The registrar detects this parameter and provides two GRUUs in the 259 REGISTER response. One of these is a temporary GRUU, and the other 260 is the public GRUU. These two GRUUs are returned in the "temp-gruu" 261 and "pub-gruu" parameters, respectively, in the Contact header field 262 of the response. For example: 264 Contact: 265 ;pub-gruu="sip:callee@example.com;gr=urn: 266 uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" 267 ;temp-gruu="sip:8ffkas08af7fasklzi9@example.com;gr" 268 ;+sip.instance="" 269 ;expires=3600 271 When a user agent refreshes this registration prior to its 272 expiration, the registrar will return back the same public GRUU, but 273 will create a new temporary GRUU. Despite the fact that each refresh 274 provides the UA with a new temporary GRUU, all of the temporary GRUUs 275 learned from previous REGISTER responses during the lifetime of a 276 contact remain valid as long as that contact remains registered. 277 Only when the contact expires, either through explicit de- 278 registration or timeout, will all of the temporary GRUUs be 279 invalidated. When the user agent later creates a new registration 280 with the same instance ID, the public GRUU is the same. The 281 temporary GRUU will be new (as it is with refreshes), and it will be 282 the only valid temporary GRUU for the instance until the next 283 refresh, at which point a second one becomes valid too. 284 Consequently, temporary GRUUs "accumulate" during the lifetime of a 285 registration. 287 3.3. Using a GRUU 289 Once a user agent obtains GRUUs from the registrar, it uses them in 290 several ways. Firstly, it uses them as the contents of the Contact 291 header field in non-REGISTER requests and responses that it emits 292 (for example, an INVITE request and 200 OK response). According to 293 RFC 3261, the Contact header field is supposed to contain a URI that 294 routes to that user agent. Prior to this specification, there hasn't 295 been a way to really meet that requirement. The user agent would use 296 one of its temporary GRUUs for anonymous calls, and use its public 297 GRUU otherwise. 299 In addition, the UA can use the GRUU in any other place it needs to 300 use a URI that resolves to itself, such as a webpage. 302 3.4. Dereferencing a GRUU 304 Because a GRUU is simply a URI, a UA dereferences it in exactly the 305 same way as it would any other URI. However, once the request has 306 been routed to the appropriate proxy, the behavior is slightly 307 different. The proxy will map the GRUU to the AOR and determine the 308 set of contacts that the particular UA instance has registered. The 309 GRUU is then mapped to those contacts, and the request is routed 310 towards the UA. 312 4. User Agent Behavior 314 This section defines the normative behavior for user agents. 316 4.1. Generating a REGISTER Request 318 When a UA compliant to this specification generates a REGISTER 319 request (initial or refresh), it MUST include the Supported header 320 field in the request. The value of that header field MUST include 321 "gruu" as one of the option tags. This alerts the registrar for the 322 domain that the UA supports the GRUU mechanism. 324 Furthermore, for each contact for which the UA desires to obtain a 325 GRUU, the UA MUST include a "sip.instance" media feature tag [14] as 326 a UA characteristic [7], whose value MUST be the instance ID that 327 identifies the UA instance being registered. Each such Contact 328 header field SHOULD NOT contain a "pub-gruu" or "temp-gruu" header 329 field. The contact URI MUST NOT be equivalent, based on the URI 330 equality rules in RFC 3261, to the AOR in the To header field. If 331 the contact URI is a GRUU, it MUST NOT be a GRUU for the AOR in the 332 To header field. 334 If a UA instance is trying to register multiple contacts for the same 335 instance for the purposes of redundancy, it MUST use the procedures 336 defined in [14]. 338 A UA utilizing GRUUs can still perform third party registrations 339 and can include contacts which omit the "+sip.instance" Contact 340 header field parameter. 342 If a UA wishes to guarantee that the REGISTER request is not 343 processed unless the domain supports and uses this extension, it MAY 344 include a Require header field in the request with a value that 345 contains the "gruu" option tag. This is in addition to the presence 346 of the Supported header field also containing the "gruu" option tag. 347 The use of Proxy-Require is not necessary and is NOT RECOMMENDED. 349 4.2. Learning GRUUs from REGISTER Responses 351 If the REGISTER response is a 2xx, each Contact header field that 352 contains the "+sip.instance" Contact header field parameter may also 353 contain a "pub-gruu" and "temp-gruu" Contact header field parameter. 354 These parameters convey the public and a temporary GRUU for the UA 355 instance, respectively. A UA MUST be prepared for a Contact header 356 field to contain just a "pub-gruu", just a "temp-gruu", neither, or 357 both. The temporary GRUU will be valid for the duration of the 358 registration, while the public GRUU persists across registrations. 359 The UA will receive a new temporary GRUU in each successful REGISTER 360 response, while the public GRUU will typically be the same. However, 361 a UA MUST be prepared for the public GRUU to change from a previous 362 one, since the persistence property is not guaranteed with complete 363 certainty. A UA MAY retain zero, one, some, or all of the temporary 364 GRUUs that it is provided during the time over which its contact 365 remains registered. If a UA stores any temporary GRUUs for use 366 during its registration, it needs to be certain that the registration 367 does not accidentally lapse due to clock skew between the UA and 368 registrar. Consequently, the UA MUST refresh its registration well 369 in advance of expiration. 371 A non-2xx response to the REGISTER request has no impact on any 372 existing GRUUs previously provided to the UA. Specifically, if a 373 previously successful REGISTER request provided the UA with a GRUU, a 374 subsequent failed request does not remove, delete, or otherwise 375 invalidate the GRUU. 377 4.3. Constructing a Self-Made GRUU 379 Many user agents, such as gateways to the Public Switched Telephone 380 Network (PSTN), conferencing servers and media servers, do not 381 perform registrations, and cannot obtain GRUUs through that 382 mechanism. These types of user agents may be publicly reachable. 383 This would mean that the policy of the domain is that requests can 384 come from anywhere on the public Internet and be delivered to the 385 user agent without requiring processing by intervening proxies within 386 the domain. Furthermore, firewall and NAT policies administered by 387 the domain would allow such requests into the network. When a user 388 agent is certain that these conditions are met, a UA MAY construct a 389 self-made GRUU. Of course, a user agent which does REGISTER, but for 390 whom these conditions are met regardless, MAY also construct a self- 391 made GRUU. However, usage of GRUUs obtained by the registrar is 392 RECOMMENDED instead. 394 A self-made GRUU is one whose domain part equals the IP address or 395 hostname of the user agent. The user part of the SIP URI is chosen 396 arbitrarily by the user agent. Like all other GRUUs, the URI MUST 397 contain the "gr" URI parameter, with or without a value, indicating 398 it is a GRUU. 400 If a user agent does not register, but it is not publicly reachable, 401 it would need to obtain a GRUU through some other means. Typically, 402 the UA would be configured with a GRUU, and the GRUU would also be 403 configured into the proxy which will receive requests targeted to the 404 GRUU, along with a static mapping to the IP address and port of the 405 UA. 407 4.4. Using Ones Own GRUUs 409 A UA SHOULD use a GRUU when populating the Contact header field of 410 dialog-forming and target refresh requests and responses. In other 411 words, a UA compliant to this specification SHOULD use one of its 412 GRUUs as its remote target. This includes the INVITE request, its 413 2xx response or 18x response with a To tag, the SUBSCRIBE [5] 414 request, its 2xx response or 18x response with a To tag, the NOTIFY 415 request, the REFER [6] request, its 2xx response or 18x response with 416 a tag, and the UPDATE request and its 2xx response. The only reason 417 not to use a GRUU would be privacy considerations; see Section 10.3. 419 When using a GRUU obtained through registrations, a UA MUST have an 420 active registration prior to using a GRUU, and MUST use a GRUU 421 learned through that registration. It MUST NOT reuse a GRUU learned 422 through a previous registration which has lapsed (in other words, one 423 obtained when registering a contact which has expired). The UA MAY 424 use either the public or one of its temporary GRUUs provided by its 425 registrar. Of course, when a UA wishes to construct an anonymous 426 request as described in RFC 3323 [16], it SHOULD use a temporary 427 GRUU. See Section 10.3 for a more complete discussion on the level 428 of privacy afforded by temporary GRUUs. 430 As per RFC 3261, a UA SHOULD include a Supported header with the 431 option tag "gruu" in requests and responses it generates. 433 4.4.1. Considerations for Multiple AORs 435 In some SIP networks, a user agent may have a multiplicity of AOR, 436 either in different domains, or within the same domain. In such 437 cases, additional considerations apply. 439 When a UA sends a request, the request will be sent 'using' one of 440 its AOR. This AOR will typically show up in the From header field of 441 the request, and credentials unique to that AOR will be used to 442 authenticate the request. The GRUU placed into the Contact header 443 field of such a request SHOULD be one that is associated with the AOR 444 used to send the request. In cases where the UA uses a tel URI [13] 445 to populate the From header field, the UA typically has a SIP AOR 446 that is treated as an alias for the tel URI. The GRUU associated 447 with that SIP AOR SHOULD be used in the Contact header field. 449 When a UA receives a request, the GRUU placed into the Contact header 450 field of a 2xx response SHOULD be the one associated with the AOR or 451 GRUU to which the request was most recently targeted. There are 452 several ways to determine the AOR or GRUU to which a request was 453 sent. For example, if a UA registered a different contact to each 454 AOR (by using a different user part of the URI), the Request-URI 455 (which contains that contact) will indicate the AOR. 457 4.5. Dereferencing a GRUU 459 A GRUU is identified by the presence of the "gr" URI parameter, and 460 this parameter may or may not have a value. A UA that wishes to send 461 a request to a URI that contains a GRUU knows that the request will 462 be delivered to a specific UA instance without further action on the 463 part of the requestor. 465 Because the instance ID is a callee capabilities parameter, a UA 466 might be tempted to send a request to the AOR of a user, and 467 include an Accept-Contact header field [19] that indicates a 468 preference for routing the request to a UA with a specific 469 instance ID. Although this would appear to have the same effect 470 as sending a request to the GRUU, it does not. The caller 471 preferences expressed in the Accept-Contact header field are just 472 preferences. Its efficacy depends on a UA constructing an Accept- 473 Contact header field that interacts with domain-processing logic 474 for an AOR, to cause a request to route to a particular instance. 475 Given the variability in routing logic in a domain (for example, 476 time-based routing to only selected contacts), this doesn't work 477 for many domain-routing policies. However, this specification 478 does not forbid a client from attempting such a request, as there 479 may be cases where the desired operation truly is a preferential 480 routing request. 482 4.6. Rendering GRUUs on a User Interface 484 When rendering a GRUU to a user through a user interface, it is 485 RECOMMENDED that the "gr" parameter be removed. For public GRUUs, 486 this will produce the AOR, as desired. For temporary GRUUs, the 487 resulting URI will be seemingly random. Future work may provide 488 improved mechanisms that would allow an automata to know that a URI 489 is anonymized and thus should not be rendered. 491 5. Registrar Behavior 493 5.1. Processing a REGISTER Request 495 A REGISTER request might contain a Require header field with the 496 "gruu" option tag; this indicates that the registrar has to 497 understand this extension in order to process the request. It does 498 not require the registrar to create GRUUs, however. 500 As the registrar is processing the contacts in the REGISTER request 501 according to the procedures of step 7 in Section 10.3 of RFC 3261, 502 the registrar checks whether each Contact header field in the 503 REGISTER message contains a "+sip.instance" header field parameter. 504 If present, the contact is processed further based on the rules in 505 the remainder of this section. Otherwise, the contact is processed 506 based on normal RFC 3261 rules. 508 If the contact URI is equivalent (based on URI equivalence in RFC 509 3261) to the AOR, the registrar MUST reject the request with a 403, 510 since this would cause a routing loop. If the contact URI is a GRUU 511 for the AOR in the To header field of the REGISTER request, the 512 registrar MUST reject the request with a 403, for the same reason. 513 If the contact is not a SIP URI, the REGISTER request MUST be 514 rejected with a 403. 516 Next, the registrar checks if there is already a valid public GRUU 517 for the AOR (present in the To header field of the REGISTER request) 518 and the instance ID (present as the content of the "+sip.instance" 519 Contact header field parameter). If there is no valid public GRUU, 520 the registrar SHOULD construct a public GRUU at this time according 521 to the procedures of Section 5.4. The public GRUU MUST be 522 constructed by adding the "gr" URI parameter, with a value, to the 523 AOR. If the contact contained a "pub-gruu" Contact header field 524 parameter, the parameter MUST be ignored by the registrar. A UA 525 cannot suggest or otherwise provide a public GRUU to the registrar. 527 Next, the registrar SHOULD create a new temporary GRUU for the AOR 528 and instance ID with the characteristics described in Section 5.4. 529 The temporary GRUU construction algorithm MUST have the following two 530 properties: 532 1. The likelihood that the temporary GRUU is equal to another GRUU 533 which the registrar has created MUST be vanishingly small. 535 2. Given a pair of GRUUs, it MUST be computationally infeasible to 536 determine whether they were issued for the same AOR or instance 537 ID or different AORs and instance IDs. 539 If the contact contained a "temp-gruu" Contact header field 540 parameter, the parameter MUST be ignored by the registrar. A UA 541 cannot suggest or otherwise provide a temporary GRUU to the 542 registrar. 544 5.2. Generating a REGISTER Response 546 When generating the 200 (OK) response to the REGISTER request, the 547 procedures of step 8 of Section 10.3 of RFC 3261 are followed. 548 Furthermore, for each Contact header field value placed in the 549 response, if the registrar has stored an instance ID associated with 550 that contact, that instance ID is returned as a Contact header field 551 parameter. If the REGISTER request contained a Supported header 552 field that included the "gruu" option tag, and the registrar has at 553 least one temporary GRUU assigned to the instance ID and AOR, the 554 registrar MUST add an "temp-gruu" Contact header field parameter to 555 that Contact header field. The value of the "temp-gruu" parameter is 556 a quoted string, and MUST contain the mostly recently created 557 temporary GRUU for that AOR and instance ID. In addition, if the 558 registrar has a public GRUU assigned to the instance ID and AOR (and 559 the client supports GRUUs), the registrar MUST add a "pub-gruu" 560 Contact header field parameter to that Contact header field. The 561 value of the "pub-gruu" parameter is the public GRUU. 563 Note that handling of a REGISTER request containing a Contact 564 header field with value "*" and an expiration of 0 still retains 565 the meaning defined in RFC 3261 -- all contacts, not just those 566 with a specific instance ID, are deleted. As described in 567 Section 5.4, this removes the binding of each contact to the AOR 568 and the binding of each contact to its GRUUs. 570 The registrar SHOULD NOT include the "gruu" option tag in the Require 571 or Supported header field of the response. 573 5.3. Timing Out a Registration 575 When a registered contact expires (either due to timeout or explicit 576 de-registration), its binding to the AOR is removed as usual. In 577 addition, its binding to its GRUUs are removed at the same time as a 578 consequence of the relationships described in Section 5.4 580 If, as a consequence of the expiration of the contact, a particular 581 GRUU no longer has any registered contacts bound to it, and the GRUU 582 is a temporary GRUU, the GRUU MUST be destroyed. This means that all 583 of the accumulated temporary GRUUs get destroyed once the last 584 contact for a given instance ID expires. A consequence of this 585 destruction is that requests addressed to the GRUU will be rejected 586 by the domain with a 404 from this point forward. 588 If, however, the GRUU was a public GRUU, the registrar SHOULD 589 continue to treat the GRUU as valid. Consequently, subsequent 590 requests targeted to the GRUU, prior to re-registration of a contact 591 to the GRUU, SHOULD return a 480. In addition, since the GRUU 592 remains valid, the rules in Section 5.1 will cause it to be retained 593 when a contact with that instance ID is once again registered to the 594 AOR. 596 These rules give a public GRUU a semi-permanent property. The 597 intent is that the registrar make every attempt to retain validity 598 of the GRUU for as long as the AOR itself is known within the 599 domain. The requirements for doing so are at SHOULD strength and 600 not MUST strength because of the difficulty in meeting a MUST 601 strength requirement; registrar failures could cause the set of 602 valid GRUUs to be lost and this specification requires the UA to 603 be robust against such cases. That said, it is possible for a 604 public GRUU to be constructed such that a registrar does not need 605 to retain any additional state for it, yet still meet the 606 requirements described here. 608 5.4. Creation of a GRUU 610 This section defines additional behaviors associated with the 611 construction and maintenance of a GRUU which are specific to a 612 registrar. These rules do not apply to self-made GRUU or GRUU not 613 obtained through registrations. 615 When a registrar creates a GRUU, it is required to maintain certain 616 information associated with the GRUU, regardless of whether it is a 617 public or temporary GRUU. Every GRUU is associated with a single AOR 618 and a single instance ID. A registrar MUST be able to determine the 619 instance ID and AOR when presented with a GRUU. In addition, the 620 GRUU, like an AOR, resolves to zero or more contacts. While the AOR 621 resolves to all registered contacts for an AOR, a GRUU resolves only 622 to those contacts whose instance ID matches the one associated with 623 the GRUU. For this reason, a contact with an instance ID is always 624 bound to both a GRUU and its AOR, never just an AOR or just a GRUU. 625 This is shown pictorially in Figure 5. The figure shows three 626 contacts registered to a single AOR. One of the contacts has an 627 instance ID of 1, and the other two have an instance ID of 2. There 628 are two GRUUs for this AOR. One is associated with instance ID 1, 629 and the other with instance ID 2. The first GRUU resolves only to 630 contacts whose instance ID is one, and the second resolves only to 631 contacts whose instance ID is two. If the contact for instance ID 1 632 should expire, the AOR would resolve to two contacts, but the GRUU 633 associated with instance ID 1 would resolve to zero. 635 +----------+ +----------+ +----------+ 636 | GRUU | | | | GRUU | 637 | | | AOR | | | 638 |Instance:1| | | |Instance:2| 639 +----------+ +----------+ +----------+ 640 | / | \ / | 641 | / | \ / | 642 | / | \ / | 643 | / | \ / | 644 | / | \ / | 645 | / | \ / | 646 | / | X | 647 | / | / \ | 648 | / | / \ | 649 | / | / \ | 650 V V V V V V 651 +----------+ +----------+ +----------+ 652 | Contact | | Contact | | Contact | 653 | | | | | | 654 |Instance:1| |Instance:2| |Instance:2| 655 +----------+ +----------+ +----------+ 657 Figure 5 659 There can be multiple GRUUs with the same instance ID and AOR. 660 Indeed, this specification requires registrars to maintain many - one 661 that is public, and several that are temporary. However, if two 662 GRUUs are associated with different AOR or different instance IDs or 663 both, the GRUUs MUST be different based on URI equality comparison. 664 A GRUU in a domain MUST NOT be equivalent, based on URI comparison, 665 to any AOR in a domain except for the one associated with the GRUU. 667 A public GRUU will always be equivalent to the AOR based on URI 668 equality rules. The reason is that the rules in RFC 3261 cause 669 URI parameters that are in one URI, but not in the other, to be 670 ignored for equality purposes. Since a public GRUU differs from 671 an AOR only by the presence of the "gr" URI parameter, the two URI 672 are equivalent based on those rules. 674 Once a GRUU is constructed, it MUST be considered valid by the 675 registrar for the duration that any contact with that same instance 676 ID and AOR are registered to the server. As mentioned above, public 677 GRUUs will continue to be valid even after this expiration, and thus 678 persist for the duration that the AOR itself is valid. Once an AOR 679 is no longer valid within a domain, any of its GRUU MUST be 680 considered invalid as well. 682 This specification does not mandate a particular mechanism for 683 construction of the GRUU. Several example approaches are given in 684 Appendix A. However, in addition to the properties described in 685 Section 3.1, a GRUU constructed by a registrar MUST exhibit the 686 following properties: 688 o The domain part of the URI is an IP address present on the public 689 Internet, or, if it is a host name, the resolution procedures of 690 RFC 3263 [2], once applied, result in an IP address on the public 691 Internet. 693 o When a request is sent to the GRUU, it routes to a proxy that can 694 access the registration data generated by the registrar. Such a 695 proxy is called a authoritative proxy [14]. 697 6. Proxy Behavior 699 Proxy behavior is fully defined in Section 16 of RFC 3261 [1]. GRUU 700 processing impacts that processing in two places -- request targeting 701 at the authoritative proxy and record routing. 703 6.1. Request Targeting 705 When a proxy receives a request, owns the domain in the Request-URI, 706 and is supposed to access a Location Service in order to compute 707 request targets (as specified in Section 16.5 of RFC 3261 [1]), the 708 proxy examines the Request-URI. If it contains the "gr" URI 709 parameter but is not equivalent, based on URI comparison, to a 710 currently valid GRUU within the domain, it SHOULD be rejected with a 711 404; this is the same behavior a proxy would exhibit for any other 712 URI within the domain that is not valid. 714 If the Request-URI contains a the "gr" URI parameter and is 715 equivalent, based on URI comparison, to a GRUU which is currently 716 valid within the domain, processing proceeds as it would for any 717 other URI present in the location service, as defined in Section 16.5 718 of RFC 3261, except that the "gr" parameter is not removed as part of 719 the canonicalization process. This is the case for both out-of- 720 dialog requests targeted to the GRUU, and mid-dialog requests 721 targeted to the GRUU (in which case the incoming request would have a 722 Route header field value containing the URI that the proxy Record- 723 Routed with). 725 If there are no registered contacts bound to the GRUU, the server 726 MUST return a 480. If there are more than one, the rules described 727 in Section 7 of [14] for selecting a single registered contact apply. 728 Any caller preferences in the request [19] SHOULD be processed 729 against the contacts bound to the GRUU. 731 In essence, to select a registered contact, the GRUU is processed 732 just like it was the AOR, but with only a subset of the contacts 733 bound to the AOR. 735 Special considerations apply to processing of any Path headers stored 736 in the registration [3]. If the received request has Route header 737 field values beyond the one pointing to the authoritative proxy 738 itself (this will happen when the request is a mid-dialog request), 739 the Path URI MUST be discarded. This is permitted by RFC 3327 as a 740 matter of local policy; usage of GRUUs will require this policy in 741 order to avoid call spirals and likely call failures. 743 A proxy MAY apply other processing to the request, such as execution 744 of called party features, as it might do for requests targeted to an 745 AOR. For requests that are outside of a dialog, it is RECOMMENDED to 746 apply screening types of functions, both automated (such as black and 747 white list screening) and interactive (such as interactive voice 748 response (IVR) applications that confer with the user to determine 749 whether to accept a call). In many cases, the new request is related 750 to an existing dialog, and may be an attempt to join it (using the 751 Join header field [23]) or replace it (using the Replaces header 752 field [24]). In such cases, the UA will typically make its own 753 authorization decisions. In such cases, bypassing screening services 754 might make sense, but it needs to be carefully considered by network 755 designers, as it depends on the specific type of screening service. 757 However, forwarding services, such as call forwarding, SHOULD NOT be 758 provided for requests sent to a GRUU. The intent of the GRUU is to 759 target a specific UA instance, and this is incompatible with 760 forwarding operations. 762 If the request is a mid-dialog request, a proxy SHOULD only apply 763 services that are meaningful for mid-dialog requests, generally 764 speaking. This excludes screening functions, as well as forwarding 765 ones. 767 In addition, a request sent to a GRUU SHOULD NOT be redirected. In 768 many instances, a GRUU is used by a UA in order to assist in the 769 traversal of NATs and firewalls, and a redirection may prevent such a 770 case from working. 772 6.2. Record-Routing 774 There are two distinct requirements for record-routing - in the 775 originating domain and in the terminating domain. These requirements 776 avoid unnecessary and possibly problematic spirals of requests. 778 If an originating authoritative proxy receives a dialog-forming 779 request, and the Contact header field contains a GRUU in the domain 780 of the proxy, and that GRUU is associated with the AOR matching the 781 authenticated identity of the requestor (assuming such authentication 782 has been performed), and the request contains Record-Route header 783 fields, the authoritative proxy MUST record route. If the request 784 contained a GRUU in the domain of the proxy, but this GRUU had an AOR 785 which did not match the authenticated identity of the requestor, it 786 is RECOMMENDED that the proxy reject the request with a 403. 788 If a terminating authoritative proxy receives a dialog-forming 789 request, and the Request-URI contains a URI in the location service 790 (either a GRUU or an AOR), and the contact selected for sending the 791 request has an instance ID and is bound to a GRUU, and the 792 registration contain Path URI, the authoritative proxy MUST record 793 route. 795 If a proxy in either the originating or terminating domains but is 796 not an authoritative proxy, the proxy MAY record route. 798 Implementors should note that, if a UA uses a GRUU in its contact, 799 and a proxy inserted itself into the Path header field of a 800 registration, that proxy will be receiving mid-dialog requests 801 regardless of whether it record routes or not. The only 802 distinction is what URI the proxy will see in the topmost Route 803 header field of mid-dialog requests. If the proxy record-routes, 804 it will see that URI. If it does not, it will see the Path URI it 805 inserted. 807 7. Grammar 809 This specification defines two new Contact header field parameters 810 ("temp-gruu" and "pub-gruu") by extending the grammar for "contact- 811 params" as defined in RFC 3261. It also defines a new SIP URI 812 parameter ("gr") by extending the grammar for "uri-parameter" as 813 defined in RFC 3261. 815 contact-params =/ temp-gruu / pub-gruu 816 temp-gruu = "temp-gruu" EQUAL LDQUOT *(qdtext / quoted-pair ) 817 RDQUOT 818 pub-gruu = "pub-gruu" EQUAL LDQUOT *(qdtext / quoted-pair ) 819 RDQUOT 821 uri-parameter =/ gr-param 822 gr-param = "gr" ["=" pvalue] ; defined in RFC3261 824 The quoted strings for temp-gruu and pub-gruu MUST contain a SIP URI. 825 However, they are encoded like all other quoted strings and can 826 therefore contain quoted-pair escapes when represented this way. 828 8. Requirements 830 This specification was created in order to meet the following 831 requirements: 833 REQ 1: When a UA invokes a GRUU, it must cause the request to be 834 routed to the specific UA instance to which the GRUU refers. 836 REQ 2: It must be possible for a GRUU to be invoked from anywhere on 837 the Internet, and still cause the request to be routed 838 appropriately. That is, a GRUU must not be restricted to use 839 within a specific addressing realm. 841 REQ 3: It must be possible for a GRUU to be constructed without 842 requiring the network to store additional state. 844 REQ 4: It must be possible for a UA to obtain a multiplicity of GRUUs 845 that each route to that UA instance. For example, this is needed 846 to support ad-hoc conferencing where a UA instance needs a 847 different URI for each conference it is hosting. NOTE: This 848 requirement is not met by this specification, and is being 849 addressed in a separate specification. 851 REQ 5: When a UA receives a request sent to a GRUU, it must be 852 possible for the UA to know the GRUU that was used to invoke the 853 request. This is necessary as a consequence of REQ 4. NOTE: This 854 requirement is not met by this specification, and is being 855 addressed in a separate specification. 857 REQ 6: It must be possible for a UA to add opaque content to a GRUU. 858 This content is not interpreted or altered by the network, and is 859 used only by the UA instance to whom the GRUU refers. This 860 provides a basic cookie type of functionality, allowing a UA to 861 build a GRUU with the state embedded. NOTE: This requirement is 862 not met by this specification, and is being addressed in a 863 separate specification. 865 REQ 7: It must be possible for a proxy to execute services and 866 features on behalf of a UA instance represented by a GRUU. As an 867 example, if a user has call blocking features, a proxy may want to 868 apply those call blocking features to calls made to the GRUU, in 869 addition to calls made to the user's AOR. 871 REQ 8: It must be possible for a UA in a dialog to inform its peer of 872 its GRUU, and for the peer to know that the URI represents a GRUU. 873 This is needed for the conferencing and dialog reuse applications 874 of GRUUs, where the URIs are transferred within a dialog. 876 REQ 9: When transferring a GRUU per REQ 8, it must be possible for 877 the UA receiving the GRUU to be assured of its integrity and 878 authenticity. 880 REQ 10: It must be possible for a server that is authoritative for a 881 domain to construct a GRUU which routes to a UA instance bound to 882 an AOR in that domain. In other words, the proxy can construct a 883 GRUU, too. This is needed for the presence application. 885 9. Example Call Flow 887 The following call flow, shown in Figure 7, shows a basic 888 registration and call setup, followed by a subscription directed to 889 the GRUU. It then shows a failure of the callee, followed by a re- 890 registration. The conventions of [18] are used to describe 891 representation of long message lines. 893 Caller Proxy Callee 894 | |(1) REGISTER | 895 | |<--------------------| 896 | |(2) 200 OK | 897 | |-------------------->| 898 |(3) INVITE | | 899 |-------------------->| | 900 | |(4) INVITE | 901 | |-------------------->| 902 | |(5) 200 OK | 903 | |<--------------------| 904 |(6) 200 OK | | 905 |<--------------------| | 906 |(7) ACK | | 907 |-------------------->| | 908 | |(8) ACK | 909 | |-------------------->| 910 |(9) SUBSCRIBE | | 911 |-------------------->| | 912 | |(10) SUBSCRIBE | 913 | |-------------------->| 914 | |(11) 200 OK | 915 | |<--------------------| 916 |(12) 200 OK | | 917 |<--------------------| | 918 | |(13) NOTIFY | 919 | |<--------------------| 920 |(14) NOTIFY | | 921 |<--------------------| | 922 |(15) 200 OK | | 923 |-------------------->| | 924 | |(16) 200 OK | 925 | |-------------------->| 926 | | |Crashes, 927 | |(17) REGISTER | Reboots 928 | |<--------------------| 929 | |(18) 200 OK | 930 | |-------------------->| 932 Figure 7 934 The Callee supports the GRUU extension. As such, its REGISTER (1) 935 looks like: 937 REGISTER sip:example.com SIP/2.0 938 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 939 Max-Forwards: 70 940 From: Callee ;tag=a73kszlfl 941 Supported: gruu 942 To: Callee 943 Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 944 CSeq: 1 REGISTER 945 Contact: 946 ;+sip.instance="" 947 Content-Length: 0 949 The registrar assigns a temporary and a public GRUU. The REGISTER 950 response (message 2) would look like: 952 SIP/2.0 200 OK 953 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 954 From: Callee ;tag=a73kszlfl 955 To: Callee ;tag=b88sn 956 Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 957 CSeq: 1 REGISTER 958 959 Contact: 960 ;pub-gruu="sip:callee@example.com 961 ;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" 962 ;temp-gruu="sip:pig8a788@example.com;gr" 963 ;+sip.instance="" 964 ;expires=3600 965 966 Content-Length: 0 968 Note how the Contact header field in the REGISTER response contains 969 the pub-gruu parameter with the public GRUU sip:callee@ 970 example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6, and the 971 temp-gruu parameter with the temporary GRUU 972 sip:pig8a788@example.com;gr. Both are valid GRUUs for the AOR and 973 instance ID, and both translate to the contact sip:callee@192.0.2.1. 975 The INVITE from the caller (message 3) is a normal SIP INVITE. 976 However, the 200 OK generated by the callee (message 5) now contains 977 a GRUU as the remote target. The UA has chosen to use its public 978 GRUU. 980 SIP/2.0 200 OK 981 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKnaa8 982 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK99a 983 From: Caller ;tag=n88ah 984 To: Callee ;tag=a0z8 985 Call-ID: 1j9FpLxk3uxtma7@host.example.com 986 CSeq: 1 INVITE 987 Supported: gruu 988 Allow: INVITE, OPTIONS, CANCEL, BYE, ACK, SUBSCRIBE 989 990 Contact: 991 993 994 Content-Length: -- 995 Content-Type: application/sdp 997 [SDP Not shown] 999 At some point later in the call, the caller decides to subscribe to 1000 the dialog event package [17] at that specific UA. To do that, it 1001 generates a SUBSCRIBE request (message 9), but directs it towards the 1002 remote target, which is a GRUU: 1004 1005 SUBSCRIBE sip:callee@example.com;gr=urn:uuid:f8 1006 1d4fae-7dec-11d0-a765-00a0c91e6bf6 1007 SIP/2.0 1008 1009 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK9zz8 1010 From: Caller ;tag=kkaz- 1011 1012 To: 1014 1015 Call-ID: faif9a@host.example.com 1016 CSeq: 2 SUBSCRIBE 1017 Supported: gruu 1018 Event: dialog 1019 Allow: INVITE, OPTIONS, CANCEL, BYE, ACK, NOTIFY 1020 Contact: 1021 Content-Length: 0 1023 In this example, the caller itself supports the GRUU extension, and 1024 is using its own GRUU to populate its remote target. 1026 This request is routed to the proxy, which proceeds to perform a 1027 location lookup on the Request-URI. It is translated into the 1028 contact for that instance, and then proxied to that contact. 1030 SUBSCRIBE sip:callee@192.0.2.1 SIP/2.0 1031 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK9555 1032 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK9zz8 1033 From: Caller ;tag=kkaz- 1034 1035 To: 1037 1038 Call-ID: faif9a@host.example.com 1039 CSeq: 2 SUBSCRIBE 1040 Supported: gruu 1041 Event: dialog 1042 Allow: INVITE, OPTIONS, CANCEL, BYE, ACK, NOTIFY 1043 Contact: 1044 Content-Length: 0 1046 The SUBSCRIBE generates a 200 response (message 11), which is 1047 followed by a NOTIFY (message 13 and 14) and its response (message 15 1048 and 16). At some point after message 16 is received, the callee's 1049 machine crashes and recovers. It obtains a new IP address, 1050 192.0.2.2. Unaware that it had previously had an active 1051 registration, it creates a new one (message 17 below). Notice how 1052 the instance ID remains the same, as it persists across reboot 1053 cycles: 1055 REGISTER sip:example.com SIP/2.0 1056 Via: SIP/2.0/UDP 192.0.2.2;branch=z9hG4bKnasbba 1057 Max-Forwards: 70 1058 From: Callee ;tag=ha8d777f0 1059 Supported: gruu 1060 To: Callee 1061 Call-ID: hf8asxzff8s7f@192.0.2.2 1062 CSeq: 1 REGISTER 1063 1064 Contact: 1065 ;+sip.instance="" 1066 1067 Content-Length: 0 1069 The registrar notices that a different contact, sip:callee@192.0.2.1, 1070 is already associated with the same instance ID. It registers the 1071 new one too and returns both in the REGISTER response. Both have the 1072 same public GRUUs, but the registrar has generated a second temporary 1073 GRUU for this AOR and instance ID combination. Both contacts are 1074 included in the REGISTER response, and the temporary GRUU for each is 1075 the same - the most recently created one for the instance ID and AOR. 1076 The registrar then generates the following response: 1078 SIP/2.0 200 OK 1079 Via: SIP/2.0/UDP 192.0.2.2;branch=z9hG4bKnasbba 1080 From: Callee ;tag=ha8d777f0 1081 To: Callee ;tag=99f8f7 1082 Call-ID: hf8asxzff8s7f@192.0.2.2 1083 CSeq: 1 REGISTER 1084 1085 Contact: 1086 ;pub-gruu="sip:callee@example.com;gr=urn: 1087 uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" 1088 ;temp-gruu="sip:asd98fggg7example.com;gr" 1089 ;+sip.instance="" 1090 ;expires=3600 1091 1092 1093 Contact: 1094 ;pub-gruu="sip:callee@example.com;gr=urn: 1095 uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" 1096 ;temp-gruu="sip:asd98fggg7example.com;gr" 1097 ;+sip.instance="" 1098 ;expires=400 1099 1100 Content-Length: 0 1102 There is no need for the UA to remove the stale registered contact; 1103 the request targeting rules in [14] will cause the request to be 1104 delivered to the most recent one. 1106 10. Security Considerations 1108 Attacks in SIP networks using GRUUs can be divided into inside 1109 attacks (where the attacker is a valid participant in the system but 1110 is malicious), and outside attacks, where a third party is trying to 1111 attack the system. In addition, there are privacy considerations 1112 with using GRUUs. 1114 10.1. Outside Attacks 1116 It is important for a UA to be assured of the integrity of a GRUU 1117 given in a REGISTER response. If the GRUU is tampered with by an 1118 attacker, the result could be denial of service to the UA. As a 1119 result, it is RECOMMENDED that a UA use the SIPS URI scheme in the 1120 Request-URI when registering. Proxies and registrars MUST support 1121 the sips URI and MUST support TLS. Note that this does not represent 1122 a change from the requirements in RFC 3261. 1124 The example GRUU construction algorithm in Appendix A.1 makes no 1125 attempt to create a GRUU that hides the AOR and instance ID 1126 associated with the GRUU. In general, determination of the AOR 1127 associated with a GRUU is considered a good property, since it allows 1128 for easy tracking of the target of a particular call. Learning the 1129 instance ID provides little benefit to an attacker. To register or 1130 otherwise impact registrations for the user, an attacker would need 1131 to obtain the credentials for the user. Knowing the instance ID is 1132 insufficient. 1134 The example GRUU construction algorithm in Appendix A.1 makes no 1135 attempt to create a GRUU that prevents users from guessing a GRUU 1136 based on knowledge of the AOR and instance ID. A user that is able 1137 to do that will be able to direct a new request at a particular 1138 instance. However, this specification recommends that service 1139 treatment (in particular, screening features) be given to requests 1140 that are sent to a GRUU. That treatment will make sure that the GRUU 1141 does not provide a back door for attackers to contact a user that has 1142 tried to block the attacker. 1144 10.2. Inside Attacks 1146 As a consequence of this specification, a UA will begin using GRUUs 1147 in the dialog forming and target refresh requests and responses it 1148 emits. These GRUUs will be passed to other UA (called the 1149 correspondent), which then use them in requests that they emit. 1150 These UA might be malicious, and attempt to remove the "gr" parameter 1151 from the URI before using it. Consequently, consideration must be 1152 given to the effect of such removal. 1154 If a malicious correspondent removes the "gr" URI parameter, the 1155 request will be routed to the authoritative proxy. If the GRUU had 1156 been temporary, removal of the "gr" parameter produces a URI that is 1157 not recognized as a GRUU and not equal to any AOR. The request will 1158 be rejected. If the GRUU had been public, the resulting of removing 1159 the "gr" parameter produces the AOR. Therefore, the request is 1160 treated like a call to the AOR. Since it is a desired goal to allow 1161 users to extract the AOR from the GRUU, this is not an attack and the 1162 call will be handled normally. 1164 A malicious user in the system might try to use a GRUU for launching 1165 a DoS attack against another SIP UA. To do that, it would wait for a 1166 call from that UA, from it, observe their GRUU. Once obtained, the 1167 UA would launch a SIP request to an entity, such as a presence 1168 server, which will generate many requests back towards the UA. 1169 However, the attacker will use the target's GRUU in the Contact 1170 header field of that SUBSCRIBE request. This will cause the traffic 1171 to be directed towards the target instead. Since the GRUU is 1172 globally routable, such traffic is more likely to be delivered to the 1173 target than traffic sent to its IP address. This specification helps 1174 mitigate this attack by requiring proxies to validate that the GRUU 1175 in the Contact of a request matches the authenticated identity of the 1176 sender of the request. This check requires the use of an outbound 1177 proxy. 1179 10.3. Privacy Considerations 1181 RFC 3323 defines mechanisms for privacy. It distinguishes between 1182 user-provided privacy and network-provided privacy. In the latter, 1183 the user requests privacy services from the network by including a 1184 Privacy header field in the request. In the former, the UA follows a 1185 basic set of guidelines for construction of its request so let a 1186 certain level of privacy is afforded. 1188 The guidelines in Section 4.1 of RFC 3323 for user-provided privacy 1189 request that a UA construct its Contact header field with a URI that 1190 omits a user part, and utilizes the IP address or hostname of the UA. 1191 Such recommendations are in conflict with the rules defined in this 1192 specification, which require the usage of a GRUU in the Contact 1193 header field. 1195 However, the temporary GRUUs provided by the registrar can be used in 1196 place of the Contact URI format described in RFC 3323. A user agent 1197 would gather the temporary GRUU returned in each REGISTER responses, 1198 and keep a small number of them cached. When it makes or receives a 1199 call, a temporary GRUU is used to populate the Contact header field. 1201 A UA can either elect to use the same temporary GRUU in each call, or 1202 it can use a different temporary GRUU in each call. The choice 1203 depends on the level of privacy desired: 1205 o A UA utilizing the same temporary URI for each call will allow a 1206 correspondent, based solely on investigation of the Contact header 1207 field, to correlate calls as coming from the same UA. Note that 1208 this is also true for the user provided privacy procedures in RFC 1209 3323, since the IP address or hostname in the Contact URI provides 1210 a similar correlator. 1212 o A UA utilizing a different temporary URI for each call will not 1213 allow a correspondent, based solely on investigation of the 1214 Contact header field, to correlate calls as coming from the same 1215 UA. 1217 o In both cases, absent network-provided privacy, IP address and 1218 port information in the Session Description Protocol (SDP) [12] 1219 will allow a correspondent to correlate calls as coming from the 1220 same UA. 1222 o In both cases, if a user makes a call, the correspondent will be 1223 able to call back by directing requests towards the GRUU in the 1224 Contact header field. Similarly, features such as transfer and 1225 digit collection by network application servers [22], which depend 1226 on a Contact with the GRUU property, will also be possible. These 1227 kinds of inbound requests will be possible until the registration 1228 for that UA lapses. A UA SHOULD NOT forcefully expire its 1229 registration and then re-register in order to destroy a GRUU; this 1230 results in a brief period of unreachability and will often produce 1231 excess load on the network. A UA wishing to not be disturbed by a 1232 specific call back will need to implement manual or automated call 1233 handling procedures to reject it. If a UA insists on not 1234 receiving any such inbound requests (including ones generated by 1235 network applications, such as those used for collecting digits), 1236 the UA can place a non-GRUU into the Contact header field. 1237 However, this is NOT RECOMMENDED. Usage of a GRUU coupled with 1238 automated call rejection features is far superior. 1240 o As long as a temporary GRUU is used to populate the Contact header 1241 field, a correspondent will not be able to ascertain any 1242 information about the AOR or instance ID of the UA by inspection 1243 of the Contact header field. However, absent a network-provided 1244 privacy service, the IP address in the SDP can be used to 1245 determine information about the UA, such as its geographic 1246 location and ISP. 1248 o In all cases, regardless of whether the UA uses a temporary or 1249 public GRUU in the Contact, regardless of whether it utilizes GRUU 1250 at all, and regardless of whether it invokes a network-provided 1251 privacy service, a correspondent will be able to determine the SIP 1252 service provider of the UA. 1254 11. IANA Considerations 1256 This specification defines two new Contact header field parameters, 1257 one SIP URI parameter, and a SIP option tag. 1259 11.1. Header Field Parameter 1261 This specification defines two new header field parameters, as per 1262 the registry created by [8]. The required information is as follows: 1264 Header field in which the parameter can appear: Contact 1266 Name of the Parameter: pub-gruu 1268 RFC Reference: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the 1269 RFC number of this specification.]] 1271 Header field in which the parameter can appear: Contact 1273 Name of the Parameter: temp-gruu 1275 RFC Reference: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the 1276 RFC number of this specification.]] 1278 11.2. URI Parameter 1280 This specification defines one new SIP URI parameter, as per the 1281 registry created by [9]. 1283 Name of the Parameter: gr 1285 Predefined Values: none 1287 RFC Reference: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the 1288 RFC number of this specification.]] 1290 11.3. SIP Option Tag 1292 This specification registers a new SIP option tag, as per the 1293 guidelines in Section 27.1 of RFC 3261. 1295 Name: gruu 1297 Description: This option tag is used to identify the Globally 1298 Routable User Agent URI (GRUU) extension. When used in a 1299 Supported header, it indicates that a User Agent understands the 1300 extension. When used in a Require header field of a REGISTER 1301 request, it indicates that the registrar shouldn't process the 1302 registration unless it supports the GRUU extension. 1304 12. Acknowledgements 1306 The author would like to thank Eric Rescorla, Robert Sparks, Rohan 1307 Mahy, Paul Kyzivat, Alan Johnston, Ya-Ching Tan, Dale Worley, Jeroen 1308 van Bemmel, Vijay Gurbani, Andrew Allen, Alan Hawrylyshen, Francois 1309 Audet, Fredrik Thulin, Dean Willis, David Hancock, Keith Drage, and 1310 Cullen Jennings for their comments and contributions to this work. 1311 Eric Rescorla provided the text for the introduction and the GRUU 1312 construction algorithm in the appendix. 1314 13. References 1316 13.1. Normative References 1318 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1319 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1320 Session Initiation Protocol", RFC 3261, June 2002. 1322 [2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 1323 (SIP): Locating SIP Servers", RFC 3263, June 2002. 1325 [3] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) 1326 Extension Header Field for Registering Non-Adjacent Contacts", 1327 RFC 3327, December 2002. 1329 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1330 Levels", BCP 14, RFC 2119, March 1997. 1332 [5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1333 Notification", RFC 3265, June 2002. 1335 [6] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1336 Method", RFC 3515, April 2003. 1338 [7] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating 1339 User Agent Capabilities in the Session Initiation Protocol 1340 (SIP)", RFC 3840, August 2004. 1342 [8] Camarillo, G., "The Internet Assigned Number Authority (IANA) 1343 Header Field Parameter Registry for the Session Initiation 1344 Protocol (SIP)", BCP 98, RFC 3968, December 2004. 1346 [9] Camarillo, G., "The Internet Assigned Number Authority (IANA) 1347 Uniform Resource Identifier (URI) Parameter Registry for the 1348 Session Initiation Protocol (SIP)", BCP 99, RFC 3969, 1349 December 2004. 1351 [10] Housley, R., "Using Advanced Encryption Standard (AES) Counter 1352 Mode With IPsec Encapsulating Security Payload (ESP)", 1353 RFC 3686, January 2004. 1355 [11] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 1356 for Message Authentication", RFC 2104, February 1997. 1358 [12] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1359 Description Protocol", RFC 4566, July 2006. 1361 [13] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, 1362 December 2004. 1364 [14] Jennings, C. and R. Mahy, "Managing Client Initiated 1365 Connections in the Session Initiation Protocol (SIP)", 1366 draft-ietf-sip-outbound-04 (work in progress), June 2006. 1368 [15] "Specification for the Advanced Encryption Standard (AES)", 1369 FIPS 197, November 2001. 1371 13.2. Informative References 1373 [16] Peterson, J., "A Privacy Mechanism for the Session Initiation 1374 Protocol (SIP)", RFC 3323, November 2002. 1376 [17] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- 1377 Initiated Dialog Event Package for the Session Initiation 1378 Protocol (SIP)", RFC 4235, November 2005. 1380 [18] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and 1381 H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test 1382 Messages", RFC 4475, May 2006. 1384 [19] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 1385 Preferences for the Session Initiation Protocol (SIP)", 1386 RFC 3841, August 2004. 1388 [20] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCP- 1389 for-IPv4) Option for Session Initiation Protocol (SIP) 1390 Servers", RFC 3361, August 2002. 1392 [21] Sparks, R., "Session Initiation Protocol Call Control - 1393 Transfer", draft-ietf-sipping-cc-transfer-06 (work in 1394 progress), March 2006. 1396 [22] Dolly, M. and E. Burger, "A Session Initiation Protocol (SIP) 1397 Event Package for Key Press Stimulus (KPML)", 1398 draft-ietf-sipping-kpml-08 (work in progress), July 2006. 1400 [23] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) 1401 "Join" Header", RFC 3911, October 2004. 1403 [24] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 1404 Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. 1406 [25] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) 1407 Extension Header Field for Service Route Discovery During 1408 Registration", RFC 3608, October 2003. 1410 Appendix A. Example GRUU Construction Algorithms 1412 The mechanism for constructing a GRUU is not subject to 1413 specification. This appendix provides two examples that can be used 1414 by a registar. Of course, others are permitted, as long as they meet 1415 the constraints defined for a GRUU. 1417 A.1. Public GRUU Algorithm 1419 The most basic approach for constructing a public GRUU is to take the 1420 AOR, and place the actual value of the instance ID into the contents 1421 of the "gr" URI parameter. 1423 A.2. Temporary GRUU 1425 This specification requires a registrar to create a new temporary 1426 GRUU on each registration refresh. If a registration is very long 1427 lived, this can quickly result in hundreds or even thousands of 1428 temporary GRUUs being created and allocated to a UA. Consequently, 1429 it is important to have an algorithm for constructing temporary GRUUs 1430 which does not require additional storage that grows in size with the 1431 number of temporary GRUUs. The following algorithm meets this goal. 1433 The proxy needs to store two randomly chosen secret keys: 1435 K_e -- used for encryption 1436 K_m -- used for integrity 1438 When the first contact with a specific instance ID is registered, the 1439 proxy generates a fresh initialization vector (IV) I. It also notes 1440 the wallclock time (W) and stores this as part of the registration. 1441 When the registrar wishes to create a new temporary GRUU, it 1442 computes: 1444 EA = E(K_e, AOR || " " || instance_ID || W || T1 || T2 || .. || Tn) 1446 using initialization vector I where || indicates concatenation, and 1447 T1, T2, and so on represent the current expiration times (measured in 1448 absolute time) of each contact with that instance ID. Usage of the 1449 current expiration times allows a new value for EA to be produced 1450 whenever a contact for that particular instance ID is refreshed, 1451 since a refresh always changes the expiration time. 1453 The encryption algorithm SHOULD be chosen so that it is not feasible 1454 for an attacker to distinguish identical plaintexts when they are 1455 encrypted with distinct IVs. The encryption algorithm SHOULD be 1456 chosen to provide at least 80 bits of security. Suitable algorithms 1457 would include AES in cipher-block-chaining (CBC) mode [15] or counter 1458 (CTR) modes [10]. Note that if CTR mode is used, extreme care MUST 1459 be taken to ensure that not only are distinct IVs chosen but that the 1460 same section of keystream is never reused. 1462 Once EA has been computed, the proxy computes: 1464 HM = MAC(K_m, EA) 1466 Where HM is a suitable MAC function, such as HMAC-SHA1 [11]. 1468 The GRUU is then constructed as: 1470 user-part = "GRUU" || BASE64(EA || HM) 1472 This mechanism uses the user-part of the SIP URI to convey the 1473 encrypted AOR and instance ID. The URI contains the "gr" parameter 1474 without a value, and the domain part is the domain of the provider. 1476 When the authoritative proxy receives a request addressed to the 1477 GRUU, it verifies the signature using its key and then decrypts EA. 1478 It then checks the value of W against the current value stored for 1479 that instance ID and AOR. If they match, the GRUU is valid. If the 1480 value of W stored in the GRUU is older than the current value stored 1481 in the database, the GRUU was allocated in a previous registration 1482 cycle and is no longer valid. 1484 The benefit of this mechanism is that a registrar need not store 1485 additional information on mapping a GRUU to its corresponding 1486 contact. The user-part of the GRUU contains the instance ID and AOR. 1487 Assuming that the domain stores registrations in a database indexed 1488 by the AOR, the proxy processing the GRUU would look up the AOR, 1489 extract the currently registered contacts, and find the one that 1490 matches the instance ID encoded in the Request-URI. The contact 1491 whose instance ID is that instance ID is then used as the translated 1492 version of the GRUU. Message integrity is needed to prevent attacks 1493 whereby the proxy is sent requests with fake GRUUs, causing it to 1494 direct requests to any named URI. 1496 While this approach has many benefits, it has the drawback of 1497 producing very long GRUUs due to the non-trivial amount of 1498 information that is encrypted. 1500 Appendix B. Network Design Considerations 1502 The GRUU specification works properly based on logic implemented at 1503 the user agents and in the authoritative proxies on both sides of a 1504 call. Consequently, it is possible to construct network deployments 1505 in which GRUUs will not work properly. 1507 One important assumption made by the GRUU mechanism is that, if a 1508 request passes through any proxies in the originating domain prior to 1509 visiting the terminating domain, one of those proxies will be the 1510 authoritative proxy for the UAC. Administrators of SIP networks will 1511 need to make sure that this property is retained. There are several 1512 ways it can be accomplished: 1514 1. If the user agents support the service route mechanism [25], the 1515 registrar can implement it and return a service route that points 1516 to the authoritative proxy. This will cause requests originated 1517 by the user agent to pass through the authoritative proxy. 1519 2. The user agents can be configured to never use an outbound proxy, 1520 and send requests directly to the domain of the terminating 1521 party. This configuration is not practical in many use cases but 1522 it is a solution to this requirement. 1524 3. The user agents can be configured with an outbound proxy in the 1525 same domain as the authoritative proxy, and this outbound proxy 1526 forwards requests to the authoritative proxy by default. This 1527 works very well in cases where the clients are not roaming; in 1528 such cases the outbound proxy in a visited network may be 1529 discovered dynamically through DHCP [20]. 1531 4. In cases where the client discovers a local outbound proxy via a 1532 mechanism such as DHCP, and is not implementing service route, 1533 the UA can be configured to automatically add an additional Route 1534 header field after the outbound proxy, which points to a proxy in 1535 the home network. This has the same net effect of service route, 1536 but is accomplished through static configuration. 1538 Author's Address 1540 Jonathan Rosenberg 1541 Cisco Systems 1542 600 Lanidex Plaza 1543 Parsippany, NJ 07054 1544 US 1546 Phone: +1 973 952-5000 1547 Email: jdrosen@cisco.com 1548 URI: http://www.jdrosen.net 1550 Intellectual Property Statement 1552 The IETF takes no position regarding the validity or scope of any 1553 Intellectual Property Rights or other rights that might be claimed to 1554 pertain to the implementation or use of the technology described in 1555 this document or the extent to which any license under such rights 1556 might or might not be available; nor does it represent that it has 1557 made any independent effort to identify any such rights. Information 1558 on the procedures with respect to rights in RFC documents can be 1559 found in BCP 78 and BCP 79. 1561 Copies of IPR disclosures made to the IETF Secretariat and any 1562 assurances of licenses to be made available, or the result of an 1563 attempt made to obtain a general license or permission for the use of 1564 such proprietary rights by implementers or users of this 1565 specification can be obtained from the IETF on-line IPR repository at 1566 http://www.ietf.org/ipr. 1568 The IETF invites any interested party to bring to its attention any 1569 copyrights, patents or patent applications, or other proprietary 1570 rights that may cover technology that may be required to implement 1571 this standard. Please address the information to the IETF at 1572 ietf-ipr@ietf.org. 1574 Disclaimer of Validity 1576 This document and the information contained herein are provided on an 1577 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1578 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1579 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1580 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1581 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1582 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1584 Copyright Statement 1586 Copyright (C) The Internet Society (2006). This document is subject 1587 to the rights, licenses and restrictions contained in BCP 78, and 1588 except as set forth therein, the authors retain all their rights. 1590 Acknowledgment 1592 Funding for the RFC Editor function is currently provided by the 1593 Internet Society.