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