idnits 2.17.1 draft-ietf-sip-gruu-13.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, updated by RFC 4748 on line 1746. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1757. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1764. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1770. 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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 6 characters 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 IETF Trust 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 (April 9, 2007) is 6228 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) ** Obsolete normative reference: RFC 4566 (ref. '10') (Obsoleted by RFC 8866) == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-07 == Outdated reference: A later version (-12) exists of draft-ietf-sipping-cc-transfer-07 == Outdated reference: A later version (-09) exists of draft-ietf-sipping-gruu-reg-event-08 == Outdated reference: A later version (-02) exists of draft-rosenberg-sip-ua-loose-route-00 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP J. Rosenberg 3 Internet-Draft Cisco 4 Intended status: Standards Track April 9, 2007 5 Expires: October 11, 2007 7 Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the 8 Session Initiation Protocol (SIP) 9 draft-ietf-sip-gruu-13 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 October 11, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 Several applications of the Session Initiation Protocol (SIP) require 43 a user agent (UA) to construct and distribute a URI that can be used 44 by anyone on the Internet to route a call to that specific UA 45 instance. A URI that routes to a specific UA instance is called a 46 Globally Routable UA URI (GRUU). This document describes an 47 extension to SIP for obtaining a GRUU from a registrar and for 48 communicating a GRUU to a peer within a dialog. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 55 3.1. Structure of GRUUs . . . . . . . . . . . . . . . . . . . . 5 56 3.1.1. GRUUs Which Expose the Underlying AOR . . . . . . . . 6 57 3.1.2. GRUUs Which Hide the Underlying AOR . . . . . . . . . 6 58 3.2. Obtaining a GRUU . . . . . . . . . . . . . . . . . . . . . 7 59 3.3. Using a GRUU . . . . . . . . . . . . . . . . . . . . . . . 8 60 3.4. Dereferencing a GRUU . . . . . . . . . . . . . . . . . . . 8 61 4. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 8 62 4.1. Generating a REGISTER Request . . . . . . . . . . . . . . 8 63 4.2. Learning GRUUs from REGISTER Responses . . . . . . . . . . 9 64 4.3. Constructing a Self-Made GRUU . . . . . . . . . . . . . . 11 65 4.4. Using Ones Own GRUUs . . . . . . . . . . . . . . . . . . . 12 66 4.4.1. Considerations for Multiple AORs . . . . . . . . . . . 12 67 4.5. Dereferencing a GRUU . . . . . . . . . . . . . . . . . . . 13 68 4.6. Rendering GRUUs on a User Interface . . . . . . . . . . . 13 69 5. Registrar Behavior . . . . . . . . . . . . . . . . . . . . . . 14 70 5.1. Processing a REGISTER Request . . . . . . . . . . . . . . 14 71 5.2. Generating a REGISTER Response . . . . . . . . . . . . . . 15 72 5.3. Timing Out a Registration . . . . . . . . . . . . . . . . 15 73 5.4. Creation of a GRUU . . . . . . . . . . . . . . . . . . . . 16 74 5.5. Registration Event Support . . . . . . . . . . . . . . . . 18 75 6. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 18 76 6.1. Request Targeting . . . . . . . . . . . . . . . . . . . . 18 77 6.2. Record-Routing . . . . . . . . . . . . . . . . . . . . . . 20 78 7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 79 8. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 22 80 9. Example Call Flow . . . . . . . . . . . . . . . . . . . . . . 23 81 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 82 10.1. Outside Attacks . . . . . . . . . . . . . . . . . . . . . 28 83 10.2. Inside Attacks . . . . . . . . . . . . . . . . . . . . . . 29 84 10.3. Privacy Considerations . . . . . . . . . . . . . . . . . . 30 85 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 86 11.1. Header Field Parameter . . . . . . . . . . . . . . . . . . 32 87 11.2. URI Parameter . . . . . . . . . . . . . . . . . . . . . . 32 88 11.3. SIP Option Tag . . . . . . . . . . . . . . . . . . . . . . 32 89 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 90 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 91 13.1. Normative References . . . . . . . . . . . . . . . . . . . 33 92 13.2. Informative References . . . . . . . . . . . . . . . . . . 34 93 Appendix A. Example GRUU Construction Algorithms . . . . . . . . 35 94 A.1. Public GRUU . . . . . . . . . . . . . . . . . . . . . . . 35 95 A.2. Temporary GRUU . . . . . . . . . . . . . . . . . . . . . . 35 96 Appendix B. Network Design Considerations . . . . . . . . . . . . 38 97 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38 98 Intellectual Property and Copyright Statements . . . . . . . . . . 40 100 1. Introduction 102 In the Session Initiation Protocol (SIP), RFC 3261 [1], the basic 103 unit of reference is the Address-Of-Record (AOR). However, in SIP 104 systems a single user can have a number of user agents (handsets, 105 softphones, voicemail accounts, etc.) which are all referenced by the 106 same AOR. There are a number of contexts in which it is desirable to 107 have an identifier which addresses a single user agent rather than 108 the group of user agents indicated by an AOR. 110 As an example, consider a blind transfer application [18]. User A is 111 talking to user B. User A wants to transfer the call to user C. So, 112 user A sends a REFER to user C. That REFER looks like, in part: 114 REFER sip:C@example.com SIP/2.0 115 From: sip:A@example.com;tag=99asd 116 To: sip:C@example.com 117 Refer-To: (URI that identifies B's UA) 119 The Refer-To header field needs to contain a URI that can be used by 120 user C to place a call to user B. However, this call needs to route 121 to the specific UA instance that user B is using to talk to user A. 122 If it doesn't, the transfer service will not execute properly. For 123 example, if A provides C with B's AOR, the call might be routed to 124 B's voice mail rather than B's current handset. 126 In order to enable this functionality, User B provides an instance- 127 specific URI to User A in the Contact header of their SIP exchange. 128 This URI refers only the the user agent B is currently using and can 129 be provided to user C. Because user B doesn't know in advance who 130 user A will transfer the call to, the URI has to be usable by anyone. 132 Many current clients attempt to meet the need for an instance- 133 specific identifier by using explicit IP addresses in the values they 134 provide in the Contact header field. However, this interacts poorly 135 with NATs and firewalls, and as a practical matter these URIs cannot 136 be used by arbitrary external clients. Similarly, usage of hostnames 137 has proven problematic for similar reasons. In addition, many SIP 138 clients do not have or cannot obtain a hostname for themselves at 139 all. 141 This specification describes a mechanism for providing a unique user- 142 agent identifier which is still globally routable. This identifier 143 is called a Globally Routable User Agent (UA) URI (GRUU). 145 2. Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [4]. 151 This specification defines the following additional terms: 153 contact: The term "contact", when used in all lowercase, refers to a 154 URI that is bound to an AOR and GRUU by means of a registration. 155 A contact is usually a SIP URI, and is bound to the AOR and GRUU 156 through a REGISTER request by appearing as a value of the Contact 157 header field. The contact URI identifies a specific UA. 159 remote target: The term "remote target" refers to a URI that a user 160 agent uses to identify itself for receipt of both mid-dialog and 161 out-of-dialog requests. A remote target is established by placing 162 a URI in the Contact header field of a dialog-forming request or 163 response and updated by target refresh requests or responses. 165 Contact header field: The term "Contact header field", with a 166 capitalized C, refers to the header field which can appear in 167 REGISTER requests and responses, redirects, or in dialog-creating 168 requests and responses. Depending on the semantics, the Contact 169 header field sometimes conveys a contact, and sometimes conveys a 170 remote target. 172 3. Overview of Operation 174 The basic idea behind a GRUU is simple. GRUUs are issued by SIP 175 domains and always route back to a proxy in that domain. The domain 176 in turn maintains the binding between the GRUU and the particular UA 177 instance. When a GRUU is de-referenced when sending a SIP request, 178 that request arrives at the proxy. It maps the GRUU to the contact 179 for the particular UA instance, and sends the request there. 181 3.1. Structure of GRUUs 183 A GRUU is a SIP URI that has two properties: 185 o It routes to a specific UA instance. 187 o It can be successfully de-referenced by any user agent on the 188 Internet, not just ones in the same domain or IP network as the UA 189 instance to which the GRUU points. 191 In principle, a GRUU can be constructed in any way the domain 192 chooses, as long as it meets the criteria above. However, all GRUUs 193 contain the "gr" URI parameter (either with or without a value), so 194 that a recipient of a GRUU can tell that it has these two properties. 196 In practice, there are two different types of GRUUs: 198 1. GRUUs which expose the underlying AOR 200 2. GRUUs which hide the underlying AOR 202 3.1.1. GRUUs Which Expose the Underlying AOR 204 In many cases it is desirable to construct the GRUU in such a way 205 that the mapping to the AOR is apparent. For example, many user 206 agents retain call logs, which keep track of incoming and outgoing 207 call attempts. If the UA had made a call to a GRUU (perhaps as a 208 consequence of a transfer request), the call log will contain the 209 GRUU. Since the call log is rendered to the user, it would be useful 210 to be able to present the user with the AOR instead, since the AOR is 211 meaningful to users as an identifier. 213 This type of GRUU is called a public GRUU. It is constructed by 214 taking the AOR, and adding the "gr" URI parameter with a value chosen 215 by the registrar in the domain. The value of the "gr" parameter 216 contains a representation of the UA instance. For instance, if the 217 AOR was "sip:alice@example.com", the GRUU might be: 219 sip:alice@example.com;gr=kjh29x97us97d 221 If a UA removes the "gr" parameter, the result is the AOR. Since 222 many systems ignore unknown parameters anyway, a public GRUU will 223 "look" like the AOR to those systems. 225 3.1.2. GRUUs Which Hide the Underlying AOR 227 In other cases it is desirable to construct a GRUU that obfuscates 228 the AOR such that it cannot be extracted by a recipient of the GRUU. 229 Such a GRUU is called a temporary GRUU. The most obvious reason to 230 do this is to protect the user's privacy. In such cases, the GRUU 231 may have any content provided that it meets the requirements in 232 Section 3.1 and Section 5.4, and the AOR cannot be readily determined 233 from the GRUU. The GRUU will have the "gr" parameter, either with or 234 without a value. In order to avoid creating excessive state in the 235 registrar, it is often desirable to construct cryptographically 236 protected "stateless" GRUUs using an algorithm like that described in 237 Appendix A. 239 An example of a temporary GRUU constructed using a stateful algorithm 240 would be: 242 sip:asd887f9dfkk76690@example.com;gr 244 3.2. Obtaining a GRUU 246 A User Agent can obtain a GRUU in one of several ways: 248 o As part of its REGISTER transaction. 250 o By constructing one locally, using the IP address or hostname of 251 the user agent instance as the domain part of the URI. These are 252 called self-made GRUUs, and are only really GRUUs when constructed 253 by UA that know they are globally reachable using their IP address 254 or hostname. 256 o Via some locally-specified Administrative mechanism. 258 A UA which wants to obtain a GRUU via its REGISTER request does so by 259 providing an instance ID in the "+sip.instance" parameter in the 260 Contact header field [12]. For example: 262 Contact: 263 ;+sip.instance="" 265 The registrar detects this parameter and provides two GRUUs in the 266 REGISTER response. One of these is a temporary GRUU, and the other 267 is the public GRUU. These two GRUUs are returned in the "temp-gruu" 268 and "pub-gruu" parameters, respectively, in the Contact header field 269 of the response. For example: 271 Contact: 272 ;pub-gruu="sip:callee@example.com;gr=urn: 273 uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" 274 ;temp-gruu="sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr" 275 ;+sip.instance="" 276 ;expires=3600 278 When a user agent refreshes this registration prior to its 279 expiration, the registrar will return back the same public GRUU, but 280 will create a new temporary GRUU. Despite the fact that each refresh 281 provides the UA with a new temporary GRUU, all of the temporary GRUUs 282 learned from previous REGISTER responses during the lifetime of a 283 contact remain valid as long as (1) that contact remains registered, 284 and (2) the UA doesn't change the Call-ID in its REGISTER request 285 compared to previous ones. When the contact expires, either through 286 explicit de-registration or timeout, all of the temporary GRUUs be 287 invalidated. Similarly, if a register refresh changes the Call-ID 288 compared to previous register refreshes, all of the previous 289 temporary GRUUs are invalidated. When the user agent later creates a 290 new registration with the same instance ID, the public GRUU is the 291 same. The temporary GRUU will be new (as it is with refreshes), and 292 it will be the only valid temporary GRUU for the instance until the 293 next refresh, at which point a second one becomes valid too. 294 Consequently, temporary GRUUs "accumulate" during the lifetime of a 295 registration. 297 3.3. Using a GRUU 299 Once a user agent obtains GRUUs from the registrar, it uses them in 300 several ways. First, it uses them as the contents of the Contact 301 header field in non-REGISTER requests and responses that it emits 302 (for example, an INVITE request and 200 OK response). According to 303 RFC 3261, the Contact header field is supposed to contain a URI that 304 routes to that user agent. Prior to this specification, there hasn't 305 been a way to really meet that requirement. The user agent would use 306 one of its temporary GRUUs for anonymous calls, and use its public 307 GRUU otherwise. 309 Second, the UA can use the GRUU in any other place it needs to use a 310 URI that resolves to itself, such as a webpage. 312 3.4. Dereferencing a GRUU 314 Because a GRUU is simply a URI, a UA dereferences it in exactly the 315 same way as it would any other URI. However, once the request has 316 been routed to the appropriate proxy, the behavior is slightly 317 different. The proxy will map the GRUU to the AOR and determine the 318 set of contacts that the particular UA instance has registered. The 319 GRUU is then mapped to those contacts, and the request is routed 320 towards the UA. 322 4. User Agent Behavior 324 This section defines the normative behavior for user agents. 326 4.1. Generating a REGISTER Request 328 When a UA compliant to this specification generates a REGISTER 329 request (initial or refresh), it MUST include the Supported header 330 field in the request. The value of that header field MUST include 331 "gruu" as one of the option tags. This alerts the registrar for the 332 domain that the UA supports the GRUU mechanism. 334 Furthermore, for each contact for which the UA desires to obtain a 335 GRUU, the UA MUST include a "sip.instance" media feature tag [12] as 336 a UA characteristic [7], whose value MUST be the instance ID that 337 identifies the UA instance being registered. Each such Contact 338 header field SHOULD NOT contain a "pub-gruu" or "temp-gruu" header 339 field. The contact URI MUST NOT be equivalent, based on the URI 340 equality rules in RFC 3261, to the AOR in the To header field. If 341 the contact URI is a GRUU, it MUST NOT be a GRUU for the AOR in the 342 To header field. 344 As in RFC 3261, the Call-ID in a REGISTER refresh SHOULD be identical 345 to the Call-ID used to previously register a contact. With GRUU, an 346 additional consideration applies. If the Call-ID changes in a 347 register refresh, the server will invalidate all temp-gruu associated 348 with that UA instance; the only valid one will be the new one 349 returned in that REGISTER response. Consequently, if a UA wishes its 350 previously obtained temporary GRUUs to remain valid, it MUST utilize 351 the same Call-ID in REGISTER refreshes. However, it MAY change the 352 Call-ID in a refresh if invalidation is the desired objective. Note 353 that, if any dialogs are in progress that utilize a temporary GRUU as 354 a remote target, and a UA performs a registration refresh with a 355 change in Call-ID, those temporary GRUU become invalid, and the UA 356 will not be reachable for subsequent mid-dialog messages. 358 If a UA instance is trying to register multiple contacts for the same 359 instance for the purposes of redundancy, it MUST use the procedures 360 defined in [12]. 362 A UA utilizing GRUUs can still perform third party registrations 363 and can include contacts which omit the "+sip.instance" Contact 364 header field parameter. 366 If a UA wishes to guarantee that the REGISTER request is not 367 processed unless the domain supports and uses this extension, it MAY 368 include a Require header field in the request with a value that 369 contains the "gruu" option tag. This is in addition to the presence 370 of the Supported header field also containing the "gruu" option tag. 371 The use of Proxy-Require is not necessary and is NOT RECOMMENDED. 373 4.2. Learning GRUUs from REGISTER Responses 375 If the REGISTER response is a 2xx, each Contact header field that 376 contains the "+sip.instance" Contact header field parameter may also 377 contain a "pub-gruu" and "temp-gruu" Contact header field parameter. 378 These parameters convey the public and a temporary GRUU for the UA 379 instance, respectively. A UA MUST be prepared for a Contact header 380 field to contain just a "pub-gruu", just a "temp-gruu", neither, or 381 both. The temporary GRUU will be valid for the duration of the 382 registration (that is, through refreshes) , while the public GRUU 383 persists across registrations. The UA will receive a new temporary 384 GRUU in each successful REGISTER response, while the public GRUU will 385 typically be the same. However, a UA MUST be prepared for the public 386 GRUU to change from a previous one, since the persistence property is 387 not guaranteed with complete certainty. If a UA changed its Call-ID 388 in this REGISTER request compared to a previous REGISTER request for 389 the same contact, the UA MUST discard all temporary GRUU learned 390 through prior REGISTER responses. A UA MAY retain zero, one, some, 391 or all of the temporary GRUUs that it is provided during the time 392 over which its contact remains registered. If a UA stores any 393 temporary GRUUs for use during its registration, it needs to be 394 certain that the registration does not accidentally lapse due to 395 clock skew between the UA and registrar. Consequently, the UA MUST 396 refresh its registration such that the REGISTER refresh transaction 397 will either complete or timeout prior to the expiration of the 398 registration. For default transaction timers, this would be at least 399 32 seconds prior to expiration, assuming the registration expiration 400 is larger than 64 seconds. If the registration expiration is less 401 than 64 seconds, the UA SHOULD refresh its registration halfway prior 402 to expiration. 404 In cases where registrars forcefully shorten registration intervals, 405 the registration event package, RFC 3860 [23] is used by user agents 406 to learn of these changes. A user agent implementing both RFC 3680 407 and GRUU MUST also implement the extensions to RFC 3680 for conveying 408 information on GRUU [27], as these are necessary to keep the set of 409 temporary GRUU synchronized between the UA and the registrar. More 410 generally, the utility of temporary GRUU depends on the UA and 411 registrar being in sync on the set of valid temporary GRUU at any 412 time. Without support of RFC 3680 and its extension for GRUU, the 413 client will remain in sync only as long as it always re-registers 414 well before the registration expiration. Besides forceful de- 415 registrations, other events, such as network outages, connection 416 failures, and short refresh intervals, can lead to potential 417 inconsistencies about the set of valid temporary GRUU. For this 418 reason, it is RECOMMENDED that a UA that utilizes temporary GRUU 419 implement RFC 3680 and [27]. 421 A non-2xx response to the REGISTER request has no impact on any 422 existing GRUUs previously provided to the UA. Specifically, if a 423 previously successful REGISTER request provided the UA with a GRUU, a 424 subsequent failed request does not remove, delete, or otherwise 425 invalidate the GRUU. 427 The user and host parts of the GRUU learned by the UA in the REGISTER 428 response MUST be treated opaquely by the UA. That is, the UA MUST 429 NOT modify them in any way. A UA MUST NOT modify or remove URI 430 parameters it does not recognize. Furthermore, the UA MUST NOT add, 431 remove or modify URI parameters relevant for receipt and processing 432 of request at the proxy, including the transport, lr, maddr, ttl, 433 user, and comp [24] parameters. The other parameter defined in RFC 434 3261 - method, would not typically be present in a GRUU delivered 435 from a registrar, and a UA MAY add a method parameter to the GRUU 436 before handing it out to another entity. Similarly, the parameters 437 defined in RFC 4240 [25] and RFC 4458 [26] are meant for consumption 438 by the UA. These would not be included in the GRUU returned by a 439 registrar and MAY be added by a UA wishing to provide services 440 associated with those parameters. Note, however, that should another 441 UA dereference the GRUU, the parameters will be lost at the proxy 442 when the Request-URI is translated into the registered contact, 443 unless some other means is provided for the attributes to be 444 delivered to the UA. Mechanisms for such delivery are currently the 445 subject of future standardization activity [28]. 447 4.3. Constructing a Self-Made GRUU 449 Many user agents, such as gateways to the Public Switched Telephone 450 Network (PSTN), conferencing servers and media servers, do not 451 perform registrations, and cannot obtain GRUUs through that 452 mechanism. These types of user agents may be publicly reachable. 453 This would mean that the policy of the domain is that requests can 454 come from anywhere on the public Internet and be delivered to the 455 user agent without requiring processing by intervening proxies within 456 the domain. Furthermore, firewall and NAT policies administered by 457 the domain would allow such requests into the network. When a user 458 agent is certain that these conditions are met, a UA MAY construct a 459 self-made GRUU. Of course, a user agent which does REGISTER, but for 460 whom these conditions are met regardless, MAY also construct a self- 461 made GRUU. However, usage of GRUUs obtained by the registrar is 462 RECOMMENDED instead. 464 A self-made GRUU is one whose domain part equals the IP address or 465 hostname of the user agent. The user part of the SIP URI is chosen 466 arbitrarily by the user agent. Like all other GRUUs, the URI MUST 467 contain the "gr" URI parameter, with or without a value, indicating 468 it is a GRUU. 470 If a user agent does not register, but it is not publicly reachable, 471 it would need to obtain a GRUU through some other means. Typically, 472 the UA would be configured with a GRUU, and the GRUU would also be 473 configured into the proxy which will receive requests targeted to the 474 GRUU, along with a static mapping to the IP address and port of the 475 UA. 477 4.4. Using Ones Own GRUUs 479 A UA SHOULD use a GRUU when populating the Contact header field of 480 dialog-forming and target refresh requests and responses. In other 481 words, a UA compliant to this specification SHOULD use one of its 482 GRUUs as its remote target. This includes the INVITE request, its 483 2xx response or 18x response with a To tag, the SUBSCRIBE [5] 484 request, its 2xx response with a To tag, the NOTIFY request, the 485 REFER [6] request, its 2xx response, and the UPDATE request and its 486 2xx response. The only reason not to use a GRUU would be privacy 487 considerations; see Section 10.3. 489 When using a GRUU obtained through registrations, a UA MUST have an 490 active registration prior to using a GRUU, and MUST use a GRUU 491 learned through that registration. It MUST NOT reuse a GRUU learned 492 through a previous registration which has lapsed (in other words, one 493 obtained when registering a contact which has expired). The UA MAY 494 use either the public or one of its temporary GRUUs provided by its 495 registrar. A UA MUST NOT use a temporary GRUU learned in a REGISTER 496 response whose Call-ID differs from the one in the most recent 497 REGISTER request generated by the UA for the same AOR and instance 498 ID. When a UA wishes to construct an anonymous request as described 499 in RFC 3323 [13], it SHOULD use a temporary GRUU. See Section 10.3 500 for a more complete discussion on the level of privacy afforded by 501 temporary GRUUs. 503 As per RFC 3261, a UA SHOULD include a Supported header with the 504 option tag "gruu" in requests and responses it generates. 506 4.4.1. Considerations for Multiple AORs 508 In some SIP networks, a user agent may have a multiplicity of AOR, 509 either in different domains, or within the same domain. In such 510 cases, additional considerations apply. 512 When a UA sends a request, the request will be sent 'using' one of 513 its AOR. This AOR will typically show up in the From header field of 514 the request, and credentials unique to that AOR will be used to 515 authenticate the request. The GRUU placed into the Contact header 516 field of such a request SHOULD be one that is associated with the AOR 517 used to send the request. In cases where the UA uses a tel URI [11] 518 to populate the From header field, the UA typically has a SIP AOR 519 that is treated as an alias for the tel URI. The GRUU associated 520 with that SIP AOR SHOULD be used in the Contact header field. 522 When a UA receives a request, the GRUU placed into the Contact header 523 field of a 2xx response SHOULD be the one associated with the AOR or 524 GRUU to which the request was most recently targeted. There are 525 several ways to determine the AOR or GRUU to which a request was 526 sent. For example, if a UA registered a different contact to each 527 AOR (by using a different user part of the URI), the Request-URI 528 (which contains that contact) will indicate the AOR. 530 4.5. Dereferencing a GRUU 532 A GRUU is identified by the presence of the "gr" URI parameter, and 533 this parameter may or may not have a value. A UA that wishes to send 534 a request to a URI that contains a GRUU knows that the request will 535 be delivered to a specific UA instance without further action on the 536 part of the requestor. 538 Some UAs implement non-standard mechanisms for handling URIs that 539 compensate for the fact that heretofore many contact URIs have not 540 been globally routable. Since any URI containing the "gr" parameter 541 is known to be globally routable, a UA SHOULD NOT apply such 542 mechanisms when contact URI contain the "gr" parameter. 544 Because the instance ID is a callee capabilities parameter, a UA 545 might be tempted to send a request to the AOR of a user, and 546 include an Accept-Contact header field [16] that indicates a 547 preference for routing the request to a UA with a specific 548 instance ID. Although this would appear to have the same effect 549 as sending a request to the GRUU, it does not. The caller 550 preferences expressed in the Accept-Contact header field are just 551 preferences. Their efficacy depends on a UA constructing an 552 Accept-Contact header field that interacts with domain-processing 553 logic for an AOR, to cause a request to route to a particular 554 instance. Given the variability in routing logic in a domain (for 555 example, time-based routing to only selected contacts), this 556 doesn't work for many domain-routing policies. However, this 557 specification does not forbid a client from attempting such a 558 request, as there may be cases where the desired operation truly 559 is a preferential routing request. 561 4.6. Rendering GRUUs on a User Interface 563 When rendering a GRUU to a user through a user interface, it is 564 RECOMMENDED that the "gr" parameter be removed. For public GRUUs, 565 this will produce the AOR, as desired. For temporary GRUUs, the 566 resulting URI will be seemingly random. Future work may provide 567 improved mechanisms that would allow an automaton to know that a URI 568 is anonymized and thus should not be rendered. 570 5. Registrar Behavior 572 5.1. Processing a REGISTER Request 574 A REGISTER request might contain a Require header field with the 575 "gruu" option tag; this indicates that the registrar has to 576 understand this extension in order to process the request. It does 577 not require the registrar to create GRUUs, however. 579 As the registrar is processing the contacts in the REGISTER request 580 according to the procedures of step 7 in Section 10.3 of RFC 3261, 581 the registrar checks whether each Contact header field in the 582 REGISTER message contains a "+sip.instance" header field parameter. 583 If present with a non-zero expiration, the contact is processed 584 further based on the rules in the remainder of this section. 585 Otherwise, the contact is processed based on normal RFC 3261 rules. 587 Note that handling of a REGISTER request containing a Contact 588 header field with value "*" and an expiration of 0 still retains 589 the meaning defined in RFC 3261 -- all contacts, not just those 590 with a specific instance ID, are deleted. As described in 591 Section 5.4, this removes the binding of each contact to the AOR 592 and the binding of each contact to its GRUUs. 594 If the contact URI is equivalent (based on URI equivalence in RFC 595 3261) to the AOR, the registrar MUST reject the request with a 403, 596 since this would cause a routing loop. If the contact URI is a GRUU 597 for the AOR in the To header field of the REGISTER request, the 598 registrar MUST reject the request with a 403, for the same reason. 599 If the contact is not a SIP URI, the REGISTER request MUST be 600 rejected with a 403. 602 Next, the registrar checks if there is already a valid public GRUU 603 for the AOR (present in the To header field of the REGISTER request) 604 and the instance ID (present as the content of the "+sip.instance" 605 Contact header field parameter). If there is no valid public GRUU, 606 the registrar SHOULD construct a public GRUU at this time according 607 to the procedures of Section 5.4. The public GRUU MUST be 608 constructed by adding the "gr" URI parameter, with a value, to the 609 AOR. If the contact contained a "pub-gruu" Contact header field 610 parameter, the parameter MUST be ignored by the registrar. A UA 611 cannot suggest or otherwise provide a public GRUU to the registrar. 613 Next, the registrar checks for any existing contacts registered to 614 the AOR and instance ID. If there is at least one, the registrar 615 finds the one that was most recently registered, and examines the 616 Call-ID value associated with that registered contact. If it differs 617 from the one in the REGISTER request, the registrar MUST invalidate 618 all previously generated temporary GRUU for the AOR and instance ID. 619 A consequence of this invalidation is that requests addressed to 620 those GRUU will be rejected by the domain with a 404 from this point 621 forward. 623 Next, the registrar SHOULD create a new temporary GRUU for the AOR 624 and instance ID with the characteristics described in Section 5.4. 625 The temporary GRUU construction algorithm MUST have the following two 626 properties: 628 1. The likelihood that the temporary GRUU is equal to another GRUU 629 which the registrar has created MUST be vanishingly small. 631 2. Given a pair of GRUUs, it MUST be computationally infeasible to 632 determine whether they were issued for the same AOR or instance 633 ID or different AORs and instance IDs. 635 If the contact contained a "temp-gruu" Contact header field 636 parameter, the parameter MUST be ignored by the registrar. A UA 637 cannot suggest or otherwise provide a temporary GRUU to the 638 registrar. 640 5.2. Generating a REGISTER Response 642 When generating the 200 (OK) response to the REGISTER request, the 643 procedures of step 8 of Section 10.3 of RFC 3261 are followed. 644 Furthermore, for each Contact header field value placed in the 645 response, if the registrar has stored an instance ID associated with 646 that contact, that instance ID is returned as a Contact header field 647 parameter. If the REGISTER request contained a Supported header 648 field that included the "gruu" option tag, and the registrar has at 649 least one temporary GRUU assigned to the instance ID and AOR, the 650 registrar MUST add an "temp-gruu" Contact header field parameter to 651 that Contact header field. The value of the "temp-gruu" parameter is 652 a quoted string, and MUST contain the mostly recently created 653 temporary GRUU for that AOR and instance ID. In addition, if the 654 registrar has a public GRUU assigned to the instance ID and AOR (and 655 the client supports GRUUs), the registrar MUST add a "pub-gruu" 656 Contact header field parameter to that Contact header field. The 657 value of the "pub-gruu" parameter is the public GRUU. 659 The registrar SHOULD NOT include the "gruu" option tag in the Require 660 or Supported header field of the response. 662 5.3. Timing Out a Registration 664 When a registered contact expires (either due to timeout or explicit 665 de-registration), its binding to the AOR is removed as usual. In 666 addition, its binding to its GRUUs are removed at the same time as a 667 consequence of the relationships described in Section 5.4 669 If, as a consequence of the expiration of the contact, a particular 670 GRUU no longer has any registered contacts bound to it, and the GRUU 671 is a temporary GRUU, the GRUU MUST be invalidated. This means that 672 all of the accumulated temporary GRUUs get invalidated once the last 673 contact for a given instance ID expires. 675 If, however, the GRUU was a public GRUU, the registrar SHOULD 676 continue to treat the GRUU as valid. Consequently, subsequent 677 requests targeted to the GRUU, prior to re-registration of a contact 678 to the GRUU, SHOULD return a 480. In addition, since the GRUU 679 remains valid, the rules in Section 5.1 will cause it to be retained 680 when a contact with that instance ID is once again registered to the 681 AOR. 683 These rules give a public GRUU a semi-permanent property. The 684 intent is that the registrar make every attempt to retain validity 685 of the GRUU for as long as the AOR itself is known within the 686 domain. The requirements for doing so are at SHOULD strength and 687 not MUST strength because of the difficulty in meeting a MUST 688 strength requirement; registrar failures could cause the set of 689 valid GRUUs to be lost and this specification requires the UA to 690 be robust against such cases. That said, it is possible for a 691 public GRUU to be constructed such that a registrar does not need 692 to retain any additional state for it, yet the GRUU still meets 693 the requirements described here. 695 5.4. Creation of a GRUU 697 This section defines additional behaviors associated with the 698 construction and maintenance of a GRUU which are specific to a 699 registrar. These rules do not apply to self-made GRUU or GRUU not 700 obtained through registrations. 702 When a registrar creates a GRUU, it is required to maintain certain 703 information associated with the GRUU, regardless of whether it is a 704 public or temporary GRUU. Every GRUU is associated with a single AOR 705 and a single instance ID. A registrar MUST be able to determine the 706 instance ID and AOR when presented with a GRUU. In addition, the 707 GRUU, like an AOR, resolves to zero or more contacts. While the AOR 708 resolves to all registered contacts for an AOR, a GRUU resolves only 709 to those contacts whose instance ID matches the one associated with 710 the GRUU. For this reason, a contact with an instance ID is always 711 bound to both a GRUU and its AOR, never just an AOR or just a GRUU. 712 This is shown pictorially in Figure 6. The figure shows three 713 contacts registered to a single AOR. One of the contacts has an 714 instance ID of 1, and the other two have an instance ID of 2. There 715 are two GRUUs for this AOR. One is associated with instance ID 1, 716 and the other with instance ID 2. The first GRUU resolves only to 717 contacts whose instance ID is one, and the second resolves only to 718 contacts whose instance ID is two. There will typically be multiple 719 contacts for a given instance ID if a UA has crashed, rebooted and 720 re-registered with the same instance ID, or is using the mechanisms 721 of [12] to have multiple registrations for redundancy. If the 722 contact for instance ID 1 should expire, the AOR would resolve to two 723 contacts, but the GRUU associated with instance ID 1 would resolve to 724 zero. 726 +----------+ +----------+ +----------+ 727 | GRUU | | | | GRUU | 728 | | | AOR | | | 729 |Instance:1| | | |Instance:2| 730 +----------+ +----------+ +----------+ 731 | / | \ / | 732 | / | \ / | 733 | / | \ / | 734 | / | \ / | 735 | / | \ / | 736 | / | \ / | 737 | / | X | 738 | / | / \ | 739 | / | / \ | 740 | / | / \ | 741 V V V V V V 742 +----------+ +----------+ +----------+ 743 | Contact | | Contact | | Contact | 744 | | | | | | 745 |Instance:1| |Instance:2| |Instance:2| 746 +----------+ +----------+ +----------+ 748 Figure 6 750 There can be multiple GRUUs with the same instance ID and AOR. 751 Indeed, this specification requires registrars to maintain many - one 752 that is public, and several that are temporary. However, if two 753 GRUUs are associated with different AOR or different instance IDs or 754 both, the GRUUs MUST be different based on URI equality comparison. 755 A GRUU in a domain MUST NOT be equivalent, based on URI comparison, 756 to any AOR in a domain except for the one associated with the GRUU. 758 A public GRUU will always be equivalent to the AOR based on URI 759 equality rules. The reason is that the rules in RFC 3261 cause 760 URI parameters that are in one URI, but not in the other, to be 761 ignored for equality purposes. Since a public GRUU differs from 762 an AOR only by the presence of the "gr" URI parameter, the two URI 763 are equivalent based on those rules. 765 Once a temporary GRUU is constructed, it MUST be considered valid by 766 the registrar until invalidated based on the rules described 767 previously. Once a public GRUU is constructed, it MUST be considered 768 valid for the duration that the AOR itself is valid. Once an AOR is 769 no longer valid within a domain, any of its GRUU MUST be considered 770 invalid as well. 772 This specification does not mandate a particular mechanism for 773 construction of the GRUU. Example algorithms for public and 774 temporary GRUU that work well are given in Appendix A. However, in 775 addition to the properties described in Section 3.1, a GRUU 776 constructed by a registrar MUST exhibit the following properties: 778 o The domain part of the URI is an IP address present on the public 779 Internet, or, if it is a host name, the resolution procedures of 780 RFC 3263 [2], once applied, result in an IP address on the public 781 Internet. 783 o When a request is sent to the GRUU, it routes to a proxy that can 784 access the registration data generated by the registrar. Such a 785 proxy is called a authoritative proxy [12]. 787 5.5. Registration Event Support 789 RFC 3680 [23] defines an event package that allows a client to learn 790 about registration events at the registrar. This package allows 791 registrars to alter registrations forcefully (for example, shortening 792 them to force a re-registration). If a registrar is supporting RFC 793 3680 and GRUU, it MUST also support [27]. 795 6. Proxy Behavior 797 Proxy behavior is fully defined in Section 16 of RFC 3261 [1]. GRUU 798 processing impacts that processing in two places -- request targeting 799 at the authoritative proxy and record routing. 801 6.1. Request Targeting 803 When a proxy receives a request, owns the domain in the Request-URI, 804 and is supposed to access a Location Service in order to compute 805 request targets (as specified in Section 16.5 of RFC 3261 [1]), the 806 proxy examines the Request-URI. If it contains the "gr" URI 807 parameter but is not equivalent, based on URI comparison, to a 808 currently valid GRUU within the domain, it SHOULD be rejected with a 809 404; this is the same behavior a proxy would exhibit for any other 810 URI within the domain that is not valid. 812 If the Request-URI contains a the "gr" URI parameter and is 813 equivalent, based on URI comparison, to a GRUU which is currently 814 valid within the domain, processing proceeds as it would for any 815 other URI present in the location service, as defined in Section 16.5 816 of RFC 3261, except that the "gr" parameter is not removed as part of 817 the canonicalization process. This is the case for both out-of- 818 dialog requests targeted to the GRUU, and mid-dialog requests 819 targeted to the GRUU (in which case the incoming request would have a 820 Route header field value containing the URI that the proxy Record- 821 Routed with). Note that the "gr" parameter is retained just for the 822 purposes of finding the GRUU in the location service; If a match is 823 found, the Request-URI will be rewritten with the registered 824 contacts, replacing the GRUU and its "gr" parameter. The "gr" 825 parameter is not carried forward into the rewritten Request-URI. 827 If there are no registered contacts bound to the GRUU, the server 828 MUST return a 480. If there are more than one, there are two cases: 830 1. The client is using SIP Outbound [12] and registering multiple 831 contacts for redundancy. In that case, these contacts contain 832 reg-id and the rules described in Section 7 of [12] for selecting 833 a single registered contact apply. 835 2. The client was not using SIP outbound, in which case there would 836 only be multiple contacts with the same instance ID if the client 837 had rebooted, restarted and re-registered. In this case, these 838 contacts would not contain the reg-id parameter. The proxy MUST 839 select the most recently refreshed contact. As with SIP 840 outbound, if a request to this target fails with a 408 or 430, 841 the proxy SHOULD retry with the next most recently refreshed 842 contact. Furthermore, if the request fails with any other 843 response, the proxy MUST NOT retry on any other contacts for this 844 instance. 846 Any caller preferences in the request [16] SHOULD be processed 847 against the contacts bound to the GRUU. 849 In essence, to select a registered contact, the GRUU is processed 850 just like it was the AOR, but with only a subset of the contacts 851 bound to the AOR. 853 Special considerations apply to processing of any Path headers stored 854 in the registration [3]. If the received request has Route header 855 field values beyond the one pointing to the authoritative proxy 856 itself (this will happen when the request is a mid-dialog request), 857 the Path URI MUST be discarded. This is permitted by RFC 3327 as a 858 matter of local policy; usage of GRUUs will require this policy in 859 order to avoid call spirals and likely call failures. 861 A proxy MAY apply other processing to the request, such as execution 862 of called party features, as it might do for requests targeted to an 863 AOR. For requests that are outside of a dialog, it is RECOMMENDED to 864 apply screening types of functions, both automated (such as black and 865 white list screening) and interactive (such as interactive voice 866 response (IVR) applications that confer with the user to determine 867 whether to accept a call). In many cases, the new request is related 868 to an existing dialog, and may be an attempt to join it (using the 869 Join header field [20]) or replace it (using the Replaces header 870 field [21]). In such cases, the UA will typically make its own 871 authorization decisions. In such cases, bypassing screening services 872 might make sense, but it needs to be carefully considered by network 873 designers, as it depends on the specific type of screening service. 875 However, forwarding services, such as call forwarding, SHOULD NOT be 876 provided for requests sent to a GRUU. The intent of the GRUU is to 877 target a specific UA instance, and this is incompatible with 878 forwarding operations. 880 If the request is a mid-dialog request, a proxy SHOULD only apply 881 services that are meaningful for mid-dialog requests, generally 882 speaking. This excludes screening functions, as well as forwarding 883 ones. 885 In addition, a request sent to a GRUU SHOULD NOT be redirected. In 886 many instances, a GRUU is used by a UA in order to assist in the 887 traversal of NATs and firewalls, and a redirection may prevent such a 888 case from working. 890 6.2. Record-Routing 892 There are two distinct requirements for record-routing - in the 893 originating domain and in the terminating domain. These requirements 894 avoid unnecessary and possibly problematic spirals of requests. 896 If: 898 o an originating authoritative proxy receives a dialog-forming 899 request, 901 o AND the Contact header field contains a GRUU in the domain of the 902 proxy, 904 o AND that GRUU is a valid one in the domain of the proxy, 906 o AND that GRUU is associated with the AOR matching the 907 authenticated identity of the requestor (assuming such 908 authentication has been performed), 910 o AND the request contains Record-Route header fields, 912 then the authoritative proxy MUST record route. If all of these 913 conditions is true, except that the GRUU is associated with an AOR 914 which did not match the authenticated identity of the requestor, it 915 is RECOMMENDED that the proxy reject the request with a 403. 917 If: 919 o a terminating authoritative proxy receives a dialog-forming 920 request, 922 o AND the Request-URI contains a URI in the location service (either 923 a GRUU or an AOR), 925 o AND the contact selected for sending the request has an instance 926 ID and is bound to a GRUU, 928 o AND the registration contain Path URI, 930 then the authoritative proxy MUST record route. 932 If a proxy in either the originating or terminating domains but is 933 not an authoritative proxy, the proxy MAY record route. 935 If a proxy in the terminating domain requires mid-dialog requests to 936 pass through it for whatever reason (firewall traversal, accounting, 937 etc.), the proxy MUST still record route, and MUST NOT assume that a 938 UA will utilize its GRUU in the Contact header field of its response 939 (which would cause mid-dialog requests to pass through the proxy 940 without record-routing). 942 Implementors should note that, if a UA uses a GRUU in its contact, 943 and a proxy inserted itself into the Path header field of a 944 registration, that proxy will be receiving mid-dialog requests 945 regardless of whether it record routes or not. The only 946 distinction is what URI the proxy will see in the topmost Route 947 header field of mid-dialog requests. If the proxy record-routes, 948 it will see that URI. If it does not, it will see the Path URI it 949 inserted. 951 7. Grammar 953 This specification defines two new Contact header field parameters 954 ("temp-gruu" and "pub-gruu") by extending the grammar for "contact- 955 params" as defined in RFC 3261. It also defines a new SIP URI 956 parameter ("gr") by extending the grammar for "uri-parameter" as 957 defined in RFC 3261. 959 contact-params =/ temp-gruu / pub-gruu 960 temp-gruu = "temp-gruu" EQUAL LDQUOT *(qdtext / quoted-pair ) 961 RDQUOT 962 pub-gruu = "pub-gruu" EQUAL LDQUOT *(qdtext / quoted-pair ) 963 RDQUOT 965 uri-parameter =/ gr-param 966 gr-param = "gr" ["=" pvalue] ; defined in RFC3261 968 The quoted strings for temp-gruu and pub-gruu MUST contain a SIP URI. 969 However, they are encoded like all other quoted strings and can 970 therefore contain quoted-pair escapes when represented this way. 972 8. Requirements 974 This specification was created in order to meet the following 975 requirements: 977 REQ 1: When a UA invokes a GRUU, it must cause the request to be 978 routed to the specific UA instance to which the GRUU refers. 980 REQ 2: It must be possible for a GRUU to be invoked from anywhere on 981 the Internet, and still cause the request to be routed 982 appropriately. That is, a GRUU must not be restricted to use 983 within a specific addressing realm. 985 REQ 3: It must be possible for a GRUU to be constructed without 986 requiring the network to store additional state. 988 REQ 4: It must be possible for a UA to obtain a multiplicity of 989 GRUUs that each route to that UA instance. For example, this is 990 needed to support ad-hoc conferencing where a UA instance needs a 991 different URI for each conference it is hosting. NOTE: This 992 requirement is not met by this specification, and is being 993 addressed in a separate specification. 995 REQ 5: When a UA receives a request sent to a GRUU, it must be 996 possible for the UA to know the GRUU that was used to invoke the 997 request. This is necessary as a consequence of REQ 4. NOTE: This 998 requirement is not met by this specification, and is being 999 addressed in a separate specification. 1001 REQ 6: It must be possible for a UA to add opaque content to a GRUU. 1002 This content is not interpreted or altered by the network, and is 1003 used only by the UA instance to whom the GRUU refers. This 1004 provides a basic cookie type of functionality, allowing a UA to 1005 build a GRUU with the state embedded. NOTE: This requirement is 1006 not met by this specification, and is being addressed in a 1007 separate specification. 1009 REQ 7: It must be possible for a proxy to execute services and 1010 features on behalf of a UA instance represented by a GRUU. As an 1011 example, if a user has call blocking features, a proxy may want to 1012 apply those call blocking features to calls made to the GRUU, in 1013 addition to calls made to the user's AOR. 1015 REQ 8: It must be possible for a UA in a dialog to inform its peer 1016 of its GRUU, and for the peer to know that the URI represents a 1017 GRUU. This is needed for the conferencing and dialog reuse 1018 applications of GRUUs, where the URIs are transferred within a 1019 dialog. 1021 REQ 9: When transferring a GRUU per REQ 8, it must be possible for 1022 the UA receiving the GRUU to be assured of its integrity and 1023 authenticity. 1025 REQ 10: It must be possible for a server that is authoritative for a 1026 domain to construct a GRUU which routes to a UA instance bound to 1027 an AOR in that domain. In other words, the proxy can construct a 1028 GRUU, too. This is needed for the presence application. 1030 9. Example Call Flow 1032 The following call flow, shown in Figure 8, shows a basic 1033 registration and call setup, followed by a subscription directed to 1034 the GRUU. It then shows a failure of the callee, followed by a re- 1035 registration. The conventions of [15] are used to describe 1036 representation of long message lines. 1038 Caller Proxy Callee 1039 | |(1) REGISTER | 1040 | |<--------------------| 1041 | |(2) 200 OK | 1042 | |-------------------->| 1043 |(3) INVITE | | 1044 |-------------------->| | 1045 | |(4) INVITE | 1046 | |-------------------->| 1047 | |(5) 200 OK | 1048 | |<--------------------| 1049 |(6) 200 OK | | 1050 |<--------------------| | 1051 |(7) ACK | | 1052 |-------------------->| | 1053 | |(8) ACK | 1054 | |-------------------->| 1055 |(9) SUBSCRIBE | | 1056 |-------------------->| | 1057 | |(10) SUBSCRIBE | 1058 | |-------------------->| 1059 | |(11) 200 OK | 1060 | |<--------------------| 1061 |(12) 200 OK | | 1062 |<--------------------| | 1063 | |(13) NOTIFY | 1064 | |<--------------------| 1065 |(14) NOTIFY | | 1066 |<--------------------| | 1067 |(15) 200 OK | | 1068 |-------------------->| | 1069 | |(16) 200 OK | 1070 | |-------------------->| 1071 | | |Crashes, 1072 | |(17) REGISTER | Reboots 1073 | |<--------------------| 1074 | |(18) 200 OK | 1075 | |-------------------->| 1077 Figure 8 1079 The Callee supports the GRUU extension. As such, its REGISTER (1) 1080 looks like: 1082 REGISTER sip:example.com SIP/2.0 1083 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 1084 Max-Forwards: 70 1085 From: Callee ;tag=a73kszlfl 1086 Supported: gruu 1087 To: Callee 1088 Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 1089 CSeq: 1 REGISTER 1090 Contact: 1091 ;+sip.instance="" 1092 Content-Length: 0 1094 The registrar assigns a temporary and a public GRUU. The REGISTER 1095 response (message 2) would look like: 1097 SIP/2.0 200 OK 1098 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 1099 From: Callee ;tag=a73kszlfl 1100 To: Callee ;tag=b88sn 1101 Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 1102 CSeq: 1 REGISTER 1103 1104 Contact: 1105 ;pub-gruu="sip:callee@example.com 1106 ;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" 1107 ;temp-gruu="sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr" 1108 ;+sip.instance="" 1109 ;expires=3600 1110 1111 Content-Length: 0 1113 Note how the Contact header field in the REGISTER response contains 1114 the pub-gruu parameter with the public GRUU sip:callee@ 1115 example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6, and the 1116 temp-gruu parameter with the temporary GRUU 1117 sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr. Both 1118 are valid GRUUs for the AOR and instance ID, and both translate to 1119 the contact sip:callee@192.0.2.1. 1121 The INVITE from the caller (message 3) is a normal SIP INVITE. 1122 However, the 200 OK generated by the callee (message 5) now contains 1123 a GRUU as the remote target. The UA has chosen to use its public 1124 GRUU. 1126 SIP/2.0 200 OK 1127 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKnaa8 1128 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK99a 1129 From: Caller ;tag=n88ah 1130 To: Callee ;tag=a0z8 1131 Call-ID: 1j9FpLxk3uxtma7@host.example.com 1132 CSeq: 1 INVITE 1133 Supported: gruu 1134 Allow: INVITE, OPTIONS, CANCEL, BYE, ACK, SUBSCRIBE 1135 1136 Contact: 1137 1139 1140 Content-Length: -- 1141 Content-Type: application/sdp 1143 [SDP Not shown] 1145 At some point later in the call, the caller decides to subscribe to 1146 the dialog event package [14] at that specific UA. To do that, it 1147 generates a SUBSCRIBE request (message 9), but directs it towards the 1148 remote target, which is a GRUU: 1150 1151 SUBSCRIBE sip:callee@example.com;gr=urn:uuid:f8 1152 1d4fae-7dec-11d0-a765-00a0c91e6bf6 1153 SIP/2.0 1154 1155 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK9zz8 1156 From: Caller ;tag=kkaz- 1157 1158 To: 1160 1161 Call-ID: faif9a@host.example.com 1162 CSeq: 2 SUBSCRIBE 1163 Supported: gruu 1164 Event: dialog 1165 Allow: INVITE, OPTIONS, CANCEL, BYE, ACK, NOTIFY 1166 Contact: 1167 Content-Length: 0 1169 In this example, the caller itself supports the GRUU extension, and 1170 is using its own GRUU to populate its remote target. 1172 This request is routed to the proxy, which proceeds to perform a 1173 location lookup on the Request-URI. It is translated into the 1174 contact for that instance, and then proxied to that contact. 1176 SUBSCRIBE sip:callee@192.0.2.1 SIP/2.0 1177 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK9555 1178 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK9zz8 1179 From: Caller ;tag=kkaz- 1180 1181 To: 1183 1184 Call-ID: faif9a@host.example.com 1185 CSeq: 2 SUBSCRIBE 1186 Supported: gruu 1187 Event: dialog 1188 Allow: INVITE, OPTIONS, CANCEL, BYE, ACK, NOTIFY 1189 Contact: 1190 Content-Length: 0 1192 The SUBSCRIBE generates a 200 response (message 11), which is 1193 followed by a NOTIFY (message 13 and 14) and its response (message 15 1194 and 16). At some point after message 16 is received, the callee's 1195 machine crashes and recovers. It obtains a new IP address, 1196 192.0.2.2. Unaware that it had previously had an active 1197 registration, it creates a new one (message 17 below). Notice how 1198 the instance ID remains the same, as it persists across reboot 1199 cycles: 1201 REGISTER sip:example.com SIP/2.0 1202 Via: SIP/2.0/UDP 192.0.2.2;branch=z9hG4bKnasbba 1203 Max-Forwards: 70 1204 From: Callee ;tag=ha8d777f0 1205 Supported: gruu 1206 To: Callee 1207 Call-ID: hf8asxzff8s7f@192.0.2.2 1208 CSeq: 1 REGISTER 1209 1210 Contact: 1211 ;+sip.instance="" 1212 1213 Content-Length: 0 1215 The registrar notices that a different contact, sip:callee@192.0.2.1, 1216 is already associated with the same instance ID. It registers the 1217 new one too and returns both in the REGISTER response. Both have the 1218 same public GRUUs, but the registrar has generated a second temporary 1219 GRUU for this AOR and instance ID combination. Both contacts are 1220 included in the REGISTER response, and the temporary GRUU for each is 1221 the same - the most recently created one for the instance ID and AOR. 1222 The registrar then generates the following response: 1224 SIP/2.0 200 OK 1225 Via: SIP/2.0/UDP 192.0.2.2;branch=z9hG4bKnasbba 1226 From: Callee ;tag=ha8d777f0 1227 To: Callee ;tag=99f8f7 1228 Call-ID: hf8asxzff8s7f@192.0.2.2 1229 CSeq: 1 REGISTER 1230 1231 Contact: 1232 ;pub-gruu="sip:callee@example.com;gr=urn: 1233 uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" 1234 ;temp-gruu="sip:tgruu.7hatz6cn-098shfyq193=ajfux8fyg7ajqqe7@example.com;gr" 1235 ;+sip.instance="" 1236 ;expires=3600 1237 1238 1239 Contact: 1240 ;pub-gruu="sip:callee@example.com;gr=urn: 1241 uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" 1242 ;temp-gruu="sip:tgruu.7hatz6cn-098shfyq193=ajfux8fyg7ajqqe7@example.com;gr" 1243 ;+sip.instance="" 1244 ;expires=400 1245 1246 Content-Length: 0 1248 There is no need for the UA to remove the stale registered contact; 1249 the request targeting rules in Section 6.1 will cause the request to 1250 be delivered to the most recent one. 1252 10. Security Considerations 1254 Attacks in SIP networks using GRUUs can be divided into inside 1255 attacks (where the attacker is a valid participant in the system but 1256 is malicious), and outside attacks, where a third party is trying to 1257 attack the system. In addition, there are privacy considerations 1258 with using GRUUs. 1260 10.1. Outside Attacks 1262 It is important for a UA to be assured of the integrity of a GRUU 1263 given in a REGISTER response. If the GRUU is tampered with by an 1264 attacker, the result could be denial of service to the UA. As a 1265 result, it is RECOMMENDED that a UA use the SIPS URI scheme in the 1266 Request-URI when registering. Proxies and registrars MUST support 1267 the sips URI and MUST support TLS. Note that this does not represent 1268 a change from the requirements in RFC 3261. 1270 The example GRUU construction algorithm in Appendix A.1 makes no 1271 attempt to create a GRUU that hides the AOR and instance ID 1272 associated with the GRUU. In general, determination of the AOR 1273 associated with a GRUU is considered a good property, since it allows 1274 for easy tracking of the target of a particular call. Learning the 1275 instance ID provides little benefit to an attacker. To register or 1276 otherwise impact registrations for the user, an attacker would need 1277 to obtain the credentials for the user. Knowing the instance ID is 1278 insufficient. 1280 The example GRUU construction algorithm in Appendix A.1 makes no 1281 attempt to create a GRUU that prevents users from guessing a GRUU 1282 based on knowledge of the AOR and instance ID. A user that is able 1283 to do that will be able to direct a new request at a particular 1284 instance. However, this specification recommends that service 1285 treatment (in particular, screening features) be given to requests 1286 that are sent to a GRUU. That treatment will make sure that the GRUU 1287 does not provide a back door for attackers to contact a user that has 1288 tried to block the attacker. 1290 10.2. Inside Attacks 1292 As a consequence of this specification, a UA will begin using GRUUs 1293 in the dialog forming and target refresh requests and responses it 1294 emits. These GRUUs will be passed to other UA (called the 1295 correspondent), which then use them in requests that they emit. 1296 These UA might be malicious, and attempt to remove the "gr" parameter 1297 from the URI before using it. Consequently, consideration must be 1298 given to the effect of such removal. 1300 If a malicious correspondent removes the "gr" URI parameter, the 1301 request will be routed to the authoritative proxy. If the GRUU had 1302 been temporary, removal of the "gr" parameter produces a URI that is 1303 not recognized as a GRUU and not equal to any AOR. The request will 1304 be rejected. If the GRUU had been public, the resulting of removing 1305 the "gr" parameter produces the AOR. Therefore, the request is 1306 treated like a call to the AOR. Since it is a desired goal to allow 1307 users to extract the AOR from the GRUU, this is not an attack and the 1308 call will be handled normally. 1310 A malicious user in the system might try to use a GRUU for launching 1311 a DoS attack against another SIP UA. To do that, it would wait for a 1312 call from that UA, from it, observe their GRUU. Once obtained, the 1313 UA would launch a SIP request to an entity, such as a presence 1314 server, which will generate many requests back towards the UA. 1315 However, the attacker will use the target's GRUU in the Contact 1316 header field of that SUBSCRIBE request. This will cause the traffic 1317 to be directed towards the target instead. Since the GRUU is 1318 globally routable, such traffic is more likely to be delivered to the 1319 target than traffic sent to its IP address. This specification helps 1320 mitigate this attack by requiring proxies to validate that the GRUU 1321 in the Contact of a request matches the authenticated identity of the 1322 sender of the request. This check requires the use of an outbound 1323 proxy. 1325 10.3. Privacy Considerations 1327 RFC 3323 defines mechanisms for privacy. It distinguishes between 1328 user-provided privacy and network-provided privacy. In the latter, 1329 the user requests privacy services from the network by including a 1330 Privacy header field in the request. In the former, the UA follows a 1331 basic set of guidelines for construction of its request so let a 1332 certain level of privacy is afforded. 1334 The guidelines in Section 4.1 of RFC 3323 for user-provided privacy 1335 request that a UA construct its Contact header field with a URI that 1336 omits a user part, and utilizes the IP address or hostname of the UA. 1337 Such recommendations are in conflict with the rules defined in this 1338 specification, which require the usage of a GRUU in the Contact 1339 header field. 1341 However, the temporary GRUUs provided by the registrar can be used in 1342 place of the Contact URI format described in RFC 3323. A user agent 1343 would gather the temporary GRUU returned in each REGISTER responses, 1344 and keep a small number of them cached. When it makes or receives a 1345 call, a temporary GRUU is used to populate the Contact header field. 1347 A UA can either elect to use the same temporary GRUU in each call, or 1348 it can use a different temporary GRUU in each call. The choice 1349 depends on the level of privacy desired: 1351 o A UA utilizing the same temporary URI for each call will allow a 1352 correspondent, based solely on investigation of the Contact header 1353 field, to correlate calls as coming from the same UA. Note that 1354 this is also true for the user provided privacy procedures in RFC 1355 3323, since the IP address or hostname in the Contact URI provides 1356 a similar correlator. 1358 o A UA utilizing a different temporary URI for each call will not 1359 allow a correspondent, based solely on investigation of the 1360 Contact header field, to correlate calls as coming from the same 1361 UA. 1363 o In both cases, absent network-provided privacy, IP address and 1364 port information in the Session Description Protocol (SDP) [10] 1365 will allow a correspondent to correlate calls as coming from the 1366 same UA. 1368 o In both cases, if a user makes a call, the correspondent will be 1369 able to call back by directing requests towards the GRUU in the 1370 Contact header field. Similarly, features such as transfer and 1371 digit collection by network application servers [19], which depend 1372 on a Contact with the GRUU property, will also be possible. These 1373 kinds of inbound requests will be possible until the registration 1374 for that UA lapses. A UA that wishes to invalidate its previous 1375 temporary GRUU in order to limit reachability MAY do so by 1376 generating a REGISTER refresh with a Call-ID that differs from 1377 ones used previously. A UA SHOULD NOT forcefully expire its 1378 registration and then re-register in order to invalidate a 1379 temporary GRUU; this results in a brief period of unreachability 1380 and will often produce excess load on the network. Refreshing 1381 with a new Call-ID is more efficient and is meant as the technique 1382 for coarse-grained control over the validity of temporary GRUU. A 1383 UA wishing to not be disturbed by a specific call back will need 1384 to implement manual or automated call handling procedures to 1385 reject it. This specification does not provide the UA the ability 1386 to manually invalidate individual temporary GRUU. If a UA insists 1387 on not receiving any such inbound requests (including ones 1388 generated by network applications, such as those used for 1389 collecting digits), the UA can place a non-GRUU into the Contact 1390 header field. However, this is NOT RECOMMENDED. Usage of a GRUU 1391 coupled with automated call rejection features is far superior. 1393 o As long as a temporary GRUU is used to populate the Contact header 1394 field, a correspondent will not be able to ascertain any 1395 information about the AOR or instance ID of the UA by inspection 1396 of the Contact header field. However, absent a network-provided 1397 privacy service, the IP address in the SDP can be used to 1398 determine information about the UA, such as its geographic 1399 location and ISP. 1401 o In all cases, regardless of whether the UA uses a temporary or 1402 public GRUU in the Contact, regardless of whether it utilizes GRUU 1403 at all, and regardless of whether it invokes a network-provided 1404 privacy service, a correspondent will be able to determine the SIP 1405 service provider of the UA. 1407 11. IANA Considerations 1409 This specification defines two new Contact header field parameters, 1410 one SIP URI parameter, and a SIP option tag. 1412 11.1. Header Field Parameter 1414 This specification defines two new header field parameters, as per 1415 the registry created by [8]. The required information is as follows: 1417 Header field in which the parameter can appear: Contact 1419 Name of the Parameter: pub-gruu 1421 RFC Reference: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the 1422 RFC number of this specification.]] 1424 Header field in which the parameter can appear: Contact 1426 Name of the Parameter: temp-gruu 1428 RFC Reference: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the 1429 RFC number of this specification.]] 1431 11.2. URI Parameter 1433 This specification defines one new SIP URI parameter, as per the 1434 registry created by [9]. 1436 Name of the Parameter: gr 1438 Predefined Values: none 1440 RFC Reference: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the 1441 RFC number of this specification.]] 1443 11.3. SIP Option Tag 1445 This specification registers a new SIP option tag, as per the 1446 guidelines in Section 27.1 of RFC 3261. 1448 Name: gruu 1450 Description: This option tag is used to identify the Globally 1451 Routable User Agent URI (GRUU) extension. When used in a 1452 Supported header, it indicates that a User Agent understands the 1453 extension. When used in a Require header field of a REGISTER 1454 request, it indicates that the registrar shouldn't process the 1455 registration unless it supports the GRUU extension. 1457 12. Acknowledgements 1459 The author would like to thank Eric Rescorla, Robert Sparks, Rohan 1460 Mahy, Paul Kyzivat, Alan Johnston, Ya-Ching Tan, Dale Worley, Jeroen 1461 van Bemmel, Vijay Gurbani, Andrew Allen, Alan Hawrylyshen, Francois 1462 Audet, Fredrik Thulin, Dean Willis, David Hancock, Keith Drage, and 1463 Cullen Jennings for their comments and contributions to this work. 1464 Eric Rescorla provided the text for the introduction and the GRUU 1465 construction algorithm in the appendix. 1467 13. References 1469 13.1. Normative References 1471 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1472 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1473 Session Initiation Protocol", RFC 3261, June 2002. 1475 [2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 1476 (SIP): Locating SIP Servers", RFC 3263, June 2002. 1478 [3] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) 1479 Extension Header Field for Registering Non-Adjacent Contacts", 1480 RFC 3327, December 2002. 1482 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1483 Levels", BCP 14, RFC 2119, March 1997. 1485 [5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1486 Notification", RFC 3265, June 2002. 1488 [6] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1489 Method", RFC 3515, April 2003. 1491 [7] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating 1492 User Agent Capabilities in the Session Initiation Protocol 1493 (SIP)", RFC 3840, August 2004. 1495 [8] Camarillo, G., "The Internet Assigned Number Authority (IANA) 1496 Header Field Parameter Registry for the Session Initiation 1497 Protocol (SIP)", BCP 98, RFC 3968, December 2004. 1499 [9] Camarillo, G., "The Internet Assigned Number Authority (IANA) 1500 Uniform Resource Identifier (URI) Parameter Registry for the 1501 Session Initiation Protocol (SIP)", BCP 99, RFC 3969, 1502 December 2004. 1504 [10] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1505 Description Protocol", RFC 4566, July 2006. 1507 [11] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, 1508 December 2004. 1510 [12] Jennings, C. and R. Mahy, "Managing Client Initiated 1511 Connections in the Session Initiation Protocol (SIP)", 1512 draft-ietf-sip-outbound-07 (work in progress), January 2007. 1514 13.2. Informative References 1516 [13] Peterson, J., "A Privacy Mechanism for the Session Initiation 1517 Protocol (SIP)", RFC 3323, November 2002. 1519 [14] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- 1520 Initiated Dialog Event Package for the Session Initiation 1521 Protocol (SIP)", RFC 4235, November 2005. 1523 [15] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and 1524 H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test 1525 Messages", RFC 4475, May 2006. 1527 [16] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 1528 Preferences for the Session Initiation Protocol (SIP)", 1529 RFC 3841, August 2004. 1531 [17] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCP- 1532 for-IPv4) Option for Session Initiation Protocol (SIP) 1533 Servers", RFC 3361, August 2002. 1535 [18] Sparks, R., "Session Initiation Protocol Call Control - 1536 Transfer", draft-ietf-sipping-cc-transfer-07 (work in 1537 progress), October 2006. 1539 [19] Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP) 1540 Event Package for Key Press Stimulus (KPML)", RFC 4730, 1541 November 2006. 1543 [20] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) 1544 "Join" Header", RFC 3911, October 2004. 1546 [21] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 1547 Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. 1549 [22] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) 1550 Extension Header Field for Service Route Discovery During 1551 Registration", RFC 3608, October 2003. 1553 [23] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 1554 Package for Registrations", RFC 3680, March 2004. 1556 [24] Camarillo, G., "Compressing the Session Initiation Protocol 1557 (SIP)", RFC 3486, February 2003. 1559 [25] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media 1560 Services with SIP", RFC 4240, December 2005. 1562 [26] Jennings, C., Audet, F., and J. Elwell, "Session Initiation 1563 Protocol (SIP) URIs for Applications such as Voicemail and 1564 Interactive Voice Response (IVR)", RFC 4458, April 2006. 1566 [27] Kyzivat, P., "Registration Event Package Extension for Session 1567 Initiation Protocol (SIP) Globally Routable User Agent URIs 1568 (GRUUs)", draft-ietf-sipping-gruu-reg-event-08 (work in 1569 progress), October 2006. 1571 [28] Rosenberg, J., "Applying Loose Routing to Session Initiation 1572 Protocol (SIP) User Agents (UA)", 1573 draft-rosenberg-sip-ua-loose-route-00 (work in progress), 1574 October 2006. 1576 Appendix A. Example GRUU Construction Algorithms 1578 The mechanism for constructing a GRUU is not subject to 1579 specification. This appendix provides an example that can be used by 1580 a registrar to construct a public and a temporary GRUU. Of course, 1581 others are permitted, as long as they meet the constraints defined 1582 for a GRUU. 1584 A.1. Public GRUU 1586 The most basic approach for constructing a public GRUU is to take the 1587 AOR, and place the actual value of the instance ID into the contents 1588 of the "gr" URI parameter. 1590 A.2. Temporary GRUU 1592 This specification requires a registrar to create a new temporary 1593 GRUU on each registration refresh. If a registration is very long 1594 lived, this can quickly result in hundreds or even thousands of 1595 temporary GRUUs being created and allocated to a UA. Consequently, 1596 it is important to have an algorithm for constructing temporary GRUUs 1597 which does not require additional storage that grows in size with the 1598 number of temporary GRUUs. The following algorithm meets this goal. 1600 The registrar maintains a counter, I. This counter is 48 bits, and is 1601 initialized to zero. The counter is persistently stored, using a 1602 backend database or other similar technique. When the registrar 1603 creates the first temporary GRUU for a particular AOR and instance 1604 ID, the registrar notes the current value of the counter, I_i, and 1605 increments the counter in the database. The registrar then maps I_i 1606 to the AOR and instance ID using the database, a persistent hashmap 1607 or similar technology. If the registration expires such that there 1608 are no longer any contacts with that particular instance ID bound to 1609 the GRUU, the registrar removes the mapping. Similarly, if the 1610 temporary GRUU are invalidated due to a change in Call-ID, the 1611 registrar removes the current mapping from I_i to the AOR and 1612 instance ID, notes the current value of the counter I_j, and stores a 1613 mapping from I_j to the AOR and instance ID. Based on these rules, 1614 the hashmap will contain a single mapping for each AOR and instance 1615 ID for which there is a currently valid registration. 1617 The usage of a counter in a 48 bit space with sequential assignment 1618 allows for a compact representation of the hashmap key, which is 1619 important for generating GRUUs of reasonable size. The counter 1620 starts at zero when the system is initialized. Persistent and 1621 reliable storage of the counter is required to avoid misrouting of a 1622 GRUU to the wrong AOR and instance ID. Similarly, persistent storage 1623 of the hashmap is required, even through proxy and registrar 1624 restarts. If the hashmap is reset, all previous temporary GRUU 1625 become invalidated. This might cause dialogs in progress to fail, or 1626 future requests towards a temporary GRUU to fail when they should 1627 not. The same hashmap needs to be accessible by all proxies and 1628 registrars that can field requests for a particular AOR and instance 1629 ID. 1631 The registrar maintains a pair of local symmetric keys K_e and K_a. 1632 These are re-generated every time the counter is reset. When the 1633 counter rolls over or is reset, the registrar remembers the old 1634 values of K_e and K_a for a time. Like the hashmap itself, these 1635 keys need to be shared across all proxy and registrars that can 1636 service requests for a particular AOR and instance ID. 1638 To generate a new temporary GRUU, the registrar generates a random 1639 80-bit distinguisher value D. It then computes: 1641 M = D || I_i 1642 E = AES-ECB-Encrypt(K_e, M) 1643 A = HMAC-SHA256-80(K_a, E) 1645 Temp-Gruu-userpart = "tgruu." || base64(E) || base64(A) 1647 Where || denotes concatenation, AES-ECB-Encrypt represents AES 1648 encryption in electronic codebook mode. M will be 128 bits long, 1649 producing a value of E that is 128 bits and A that is 80 bits. This 1650 produces a user part which has 42 characters. 1652 When a proxy receives a request whose user part begins with "tgruu.", 1653 it extracts the remaining portion, and splits it into 22 characters 1654 E' and the remaining 14 characters A'. It then computes A and E by 1655 performing a base64 decode of A' and E' respectively. Next, it 1656 computes: 1658 Ac = HMAC-SHA256-80(K_a, E) 1660 If the counter has rolled over or reset, this computation is 1661 performed with the current and previous K_a. If the Ac value(s) that 1662 are computed do not match the value of A extracted from the GRUU, the 1663 GRUU is rejected as invalid. Next, the proxy computes: 1665 M = AES-ECB-Decrypt(K_e, E) 1667 If the counter had rolled over, this computation is done using the 1668 value of K_e that goes with the value of K_a which produced a valid 1669 Ac in the previous HMAC validation. The leading 80 bits (the 1670 distinguisher D) are discarded, leaving an index I_i in the hashmap. 1671 This index is looked up. If it exists, the proxy now has the AOR and 1672 instance ID corresponding to this temporary GRUU. If there is 1673 nothing in the hashmap for the key I_i, the GRUU is no longer valid 1674 and the request is rejected. 1676 The usage of a 48 bit counter allows for the registrar to have as 1677 many as a billion AORs, with 10 instances per each AOR, and cycle 1678 through 10,000 Call-ID changes for each instance through the duration 1679 of a single registration. These numbers reflect the average; the 1680 system works fine if a particular AOR has more than 10 instances or a 1681 particular instance cycles through more than 10,000 Call-IDs in its 1682 registration, as long as the average meets these constraints. 1684 Appendix B. Network Design Considerations 1686 The GRUU specification works properly based on logic implemented at 1687 the user agents and in the authoritative proxies on both sides of a 1688 call. Consequently, it is possible to construct network deployments 1689 in which GRUUs will not work properly. 1691 One important assumption made by the GRUU mechanism is that, if a 1692 request passes through any proxies in the originating domain prior to 1693 visiting the terminating domain, one of those proxies will be the 1694 authoritative proxy for the UAC. Administrators of SIP networks will 1695 need to make sure that this property is retained. There are several 1696 ways it can be accomplished: 1698 1. If the user agents support the service route mechanism [22], the 1699 registrar can implement it and return a service route that points 1700 to the authoritative proxy. This will cause requests originated 1701 by the user agent to pass through the authoritative proxy. 1703 2. The user agents can be configured to never use an outbound proxy, 1704 and send requests directly to the domain of the terminating 1705 party. This configuration is not practical in many use cases but 1706 it is a solution to this requirement. 1708 3. The user agents can be configured with an outbound proxy in the 1709 same domain as the authoritative proxy, and this outbound proxy 1710 forwards requests to the authoritative proxy by default. This 1711 works very well in cases where the clients are not roaming; in 1712 such cases the outbound proxy in a visited network may be 1713 discovered dynamically through DHCP [17]. 1715 4. In cases where the client discovers a local outbound proxy via a 1716 mechanism such as DHCP, and is not implementing service route, 1717 the UA can be configured to automatically add an additional Route 1718 header field after the outbound proxy, which points to a proxy in 1719 the home network. This has the same net effect of service route, 1720 but is accomplished through static configuration. 1722 Author's Address 1724 Jonathan Rosenberg 1725 Cisco 1726 Edison, NJ 1727 US 1729 Email: jdrosen@cisco.com 1730 URI: http://www.jdrosen.net 1732 Full Copyright Statement 1734 Copyright (C) The IETF Trust (2007). 1736 This document is subject to the rights, licenses and restrictions 1737 contained in BCP 78, and except as set forth therein, the authors 1738 retain all their rights. 1740 This document and the information contained herein are provided on an 1741 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1742 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1743 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1744 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1745 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1746 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1748 Intellectual Property 1750 The IETF takes no position regarding the validity or scope of any 1751 Intellectual Property Rights or other rights that might be claimed to 1752 pertain to the implementation or use of the technology described in 1753 this document or the extent to which any license under such rights 1754 might or might not be available; nor does it represent that it has 1755 made any independent effort to identify any such rights. Information 1756 on the procedures with respect to rights in RFC documents can be 1757 found in BCP 78 and BCP 79. 1759 Copies of IPR disclosures made to the IETF Secretariat and any 1760 assurances of licenses to be made available, or the result of an 1761 attempt made to obtain a general license or permission for the use of 1762 such proprietary rights by implementers or users of this 1763 specification can be obtained from the IETF on-line IPR repository at 1764 http://www.ietf.org/ipr. 1766 The IETF invites any interested party to bring to its attention any 1767 copyrights, patents or patent applications, or other proprietary 1768 rights that may cover technology that may be required to implement 1769 this standard. Please address the information to the IETF at 1770 ietf-ipr@ietf.org. 1772 Acknowledgment 1774 Funding for the RFC Editor function is provided by the IETF 1775 Administrative Support Activity (IASA).