From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5627.txt | 2243 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2243 insertions(+) create mode 100644 doc/rfc/rfc5627.txt (limited to 'doc/rfc/rfc5627.txt') diff --git a/doc/rfc/rfc5627.txt b/doc/rfc/rfc5627.txt new file mode 100644 index 0000000..0ed7f5e --- /dev/null +++ b/doc/rfc/rfc5627.txt @@ -0,0 +1,2243 @@ + + + + + + +Network Working Group J. Rosenberg +Request for Comments: 5627 Cisco Systems +Category: Standards Track October 2009 + + + Obtaining and Using Globally Routable User Agent URIs (GRUUs) + in the Session Initiation Protocol (SIP) + +Abstract + + Several applications of the Session Initiation Protocol (SIP) require + a user agent (UA) to construct and distribute a URI that can be used + by anyone on the Internet to route a call to that specific UA + instance. A URI that routes to a specific UA instance is called a + Globally Routable UA URI (GRUU). This document describes an + extension to SIP for obtaining a GRUU from a registrar and for + communicating a GRUU to a peer within a dialog. + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + + + +Rosenberg Standards Track [Page 1] + +RFC 5627 GRUU Mechanism October 2009 + + + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rosenberg Standards Track [Page 2] + +RFC 5627 GRUU Mechanism October 2009 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 + 3.1. Structure of GRUUs . . . . . . . . . . . . . . . . . . . . 5 + 3.1.1. GRUUs That Expose the Underlying AOR . . . . . . . . . 6 + 3.1.2. GRUUs That Hide the Underlying AOR . . . . . . . . . . 6 + 3.2. Obtaining a GRUU . . . . . . . . . . . . . . . . . . . . . 7 + 3.3. Using a GRUU . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.4. Dereferencing a GRUU . . . . . . . . . . . . . . . . . . . 8 + 4. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 9 + 4.1. Generating a REGISTER Request . . . . . . . . . . . . . . 9 + 4.2. Learning GRUUs from REGISTER Responses . . . . . . . . . . 10 + 4.3. Constructing a Self-Made GRUU . . . . . . . . . . . . . . 11 + 4.4. Using One's Own GRUUs . . . . . . . . . . . . . . . . . . 12 + 4.4.1. Considerations for Multiple AORs . . . . . . . . . . . 13 + 4.5. Dereferencing a GRUU . . . . . . . . . . . . . . . . . . . 14 + 4.6. Rendering GRUUs on a User Interface . . . . . . . . . . . 14 + 5. Registrar Behavior . . . . . . . . . . . . . . . . . . . . . . 14 + 5.1. Processing a REGISTER Request . . . . . . . . . . . . . . 14 + 5.2. Generating a REGISTER Response . . . . . . . . . . . . . . 16 + 5.3. Timing Out a Registration . . . . . . . . . . . . . . . . 16 + 5.4. Creation of a GRUU . . . . . . . . . . . . . . . . . . . . 17 + 5.5. Registration Event Support . . . . . . . . . . . . . . . . 19 + 6. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 19 + 6.1. Request Targeting . . . . . . . . . . . . . . . . . . . . 19 + 6.2. Record-Routing . . . . . . . . . . . . . . . . . . . . . . 21 + 7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 8. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 9. Example Call Flow . . . . . . . . . . . . . . . . . . . . . . 24 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 29 + 10.1. Outside Attacks . . . . . . . . . . . . . . . . . . . . . 29 + 10.2. Inside Attacks . . . . . . . . . . . . . . . . . . . . . . 30 + 10.3. Privacy Considerations . . . . . . . . . . . . . . . . . . 31 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 + 11.1. Header Field Parameter . . . . . . . . . . . . . . . . . . 33 + 11.2. URI Parameter . . . . . . . . . . . . . . . . . . . . . . 33 + 11.3. SIP Option Tag . . . . . . . . . . . . . . . . . . . . . . 33 + 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 + 13.1. Normative References . . . . . . . . . . . . . . . . . . . 34 + 13.2. Informative References . . . . . . . . . . . . . . . . . . 35 + Appendix A. Example GRUU Construction Algorithms . . . . . . . . 37 + A.1. Public GRUU . . . . . . . . . . . . . . . . . . . . . . . 37 + A.2. Temporary GRUU . . . . . . . . . . . . . . . . . . . . . . 37 + Appendix B. Network Design Considerations . . . . . . . . . . . . 39 + + + + +Rosenberg Standards Track [Page 3] + +RFC 5627 GRUU Mechanism October 2009 + + +1. Introduction + + In the Session Initiation Protocol (SIP), RFC 3261 [1], the basic + unit of reference is the Address of Record (AOR). However, in SIP + systems a single user can have a number of user agents (handsets, + softphones, voicemail accounts, etc.) that are all referenced by the + same AOR. There are a number of contexts in which it is desirable to + have an identifier that addresses a single user agent rather than the + group of user agents indicated by an AOR. + + As an example, consider a blind transfer application (see RFC 5589 + [19]). User A is talking to user B. User A wants to transfer the + call to user C. So, user A sends a REFER to user C. That REFER + looks like, in part: + + REFER sip:C@example.com SIP/2.0 + From: sip:A@example.com;tag=99asd + To: sip:C@example.com + Refer-To: (URI that identifies B's UA) + + The Refer-To header field needs to contain a URI that can be used by + user C to place a call to user B. However, this call needs to route + to the specific UA instance that user B is using to talk to user A. + If it doesn't, the transfer service will not execute properly. For + example, if A provides C with B's AOR, the call might be routed to + B's voicemail rather than B's current handset. + + In order to enable this functionality, user B provides an instance- + specific URI to user A in the Contact header of their SIP exchange. + This URI refers to the user agent B is currently using, and it can be + dereferenced by C's user agent. Because user B doesn't know in + advance who user A will transfer the call to, the URI has to be + usable by anyone. + + Many current clients attempt to meet the need for an instance- + specific identifier by using explicit IP addresses in the values they + provide in the Contact header field. However, this interacts poorly + with NATs and firewalls, and as a practical matter, these URIs cannot + be used by arbitrary external clients. Usage of hostnames has proven + problematic for similar reasons. In addition, many SIP clients do + not have or cannot obtain a hostname for themselves at all. + + This specification describes a mechanism for providing a unique user- + agent identifier which is still globally routable. This identifier + is called a Globally Routable User Agent (UA) URI (GRUU). + + + + + + +Rosenberg Standards Track [Page 4] + +RFC 5627 GRUU Mechanism October 2009 + + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [4]. + + This specification defines the following additional terms: + + contact: The term "contact", when used in all lowercase, refers to a + URI that is bound to an AOR and GRUU by means of a registration. + A contact is usually a SIP URI, and is bound to the AOR and GRUU + through a REGISTER request by appearing as a value of the Contact + header field. The contact URI identifies a specific UA. + + remote target: The term "remote target" refers to a URI that a user + agent uses to identify itself for receipt of both mid-dialog and + out-of-dialog requests. A remote target is established by placing + a URI in the Contact header field of a dialog-forming request or + response and is updated by target refresh requests or responses. + + Contact header field: The term "Contact header field", with a + capitalized C, refers to the header field that can appear in + REGISTER requests and responses, redirects, or dialog-creating + requests and responses. Depending on the semantics, the Contact + header field sometimes conveys a contact, and sometimes conveys a + remote target. + +3. Overview of Operation + + The basic idea behind a GRUU is simple. GRUUs are issued by SIP + domains and always route back to a proxy in that domain. In turn, + the domain maintains the binding between the GRUU and the particular + UA instance. When a GRUU is dereferenced while sending a SIP + request, that request arrives at the proxy. It maps the GRUU to the + contact for the particular UA instance, and sends the request there. + +3.1. Structure of GRUUs + + A GRUU is a SIP URI that has two properties: + + o It routes to a specific UA instance. + + o It can be successfully dereferenced by any user agent on the + Internet, not just ones in the same domain or IP network as the UA + instance to which the GRUU points. + + + + + + +Rosenberg Standards Track [Page 5] + +RFC 5627 GRUU Mechanism October 2009 + + + In principle, a GRUU can be constructed in any way the domain + chooses, as long as it meets the criteria above. However, all GRUUs + contain the "gr" URI parameter (either with or without a value), so + that a recipient of a GRUU can tell that it has these two properties. + + In practice, there are two different types of GRUUs: + + 1. GRUUs that expose the underlying AOR + + 2. GRUUs that hide the underlying AOR + +3.1.1. GRUUs That Expose the Underlying AOR + + In many cases, it is desirable to construct the GRUU in such a way + that the mapping to the AOR is apparent. For example, many user + agents retain call logs, which keep track of incoming and outgoing + call attempts. If the UA had made a call to a GRUU (perhaps as a + consequence of a transfer request), the call log will contain the + GRUU. Since the call log is rendered to the user, it would be useful + to be able to present the user with the AOR instead, since the AOR is + meaningful to users as an identifier. + + This type of GRUU is called a public GRUU. It is constructed by + taking the AOR, and adding the "gr" URI parameter with a value chosen + by the registrar in the domain. The value of the "gr" URI parameter + contains a representation of the UA instance. For instance, if the + AOR was "sip:alice@example.com", the GRUU might be: + + sip:alice@example.com;gr=kjh29x97us97d + + If a UA removes the "gr" URI parameter, the result is the AOR. Since + many systems ignore unknown parameters anyway, a public GRUU will + "look" like the AOR to those systems. + +3.1.2. GRUUs That Hide the Underlying AOR + + In other cases, it is desirable to construct a GRUU that obfuscates + the AOR such that it cannot be extracted by a recipient of the GRUU. + Such a GRUU is called a temporary GRUU. The most obvious reason to + do this is to protect the user's privacy. In such cases, the GRUU + can have any content, provided that it meets the requirements in + Sections 3.1 and 5.4, and the AOR cannot be readily determined from + the GRUU. The GRUU will have the "gr" URI parameter, either with or + without a value. In order to avoid creating excessive state in the + registrar, it is often desirable to construct cryptographically + protected "stateless" GRUUs using an algorithm like that described in + Appendix A. + + + + +Rosenberg Standards Track [Page 6] + +RFC 5627 GRUU Mechanism October 2009 + + + An example of a temporary GRUU constructed using a stateful algorithm + would be: + + sip:asd887f9dfkk76690@example.com;gr + +3.2. Obtaining a GRUU + + A user agent can obtain a GRUU in one of several ways: + + o As part of its REGISTER transaction. + + o By constructing one locally, using the IP address or hostname of + the user agent instance as the domain part of the URI. These are + called self-made GRUUs, and are only really GRUUs when constructed + by UAs that know they are globally reachable using their IP + address or hostname. + + o Via some locally specified administrative mechanism. + + A UA that wants to obtain a GRUU via its REGISTER request does so by + providing an instance ID in the "+sip.instance" Contact header field + parameter, defined in RFC 5626 [14]. For example: + + Contact: + ;+sip.instance="" + + The registrar detects this header field parameter and provides two + GRUUs in the REGISTER response. One of these is a temporary GRUU, + and the other is the public GRUU. These two GRUUs are returned in + the "temp-gruu" and "pub-gruu" Contact header field parameters in the + response, respectively. For example: + + + Contact: + ;pub-gruu="sip:callee@example.com;gr=urn: + uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" + ;temp-gruu="sip:tgruu.7hs== + jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr" + ;+sip.instance="" + ;expires=3600 + + + Note that the tag is used as defined in [17]. + + When a user agent refreshes this registration prior to its + expiration, the registrar will return back the same public GRUU, but + will create a new temporary GRUU. Despite the fact that each refresh + provides the UA with a new temporary GRUU, all of the temporary GRUUs + + + +Rosenberg Standards Track [Page 7] + +RFC 5627 GRUU Mechanism October 2009 + + + learned from previous REGISTER responses during the lifetime of a + contact remain valid as long as (1) a contact with that instance ID + remains registered, and (2) the UA doesn't change the Call-ID in its + REGISTER request compared to previous ones for the same reg-id [14]. + When the last contact for the instance expires, either through + explicit de-registration or timeout, all of the temporary GRUUs + become invalidated. Similarly, if a register refresh for a contact + (or, if RFC 5626 is being used, for a reg-id) changes the Call-ID + compared to previous register refreshes, all of the previous + temporary GRUUs are invalidated. When the user agent later creates a + new registration with the same instance ID, the public GRUU is the + same. The temporary GRUU will be new (as it is with refreshes), and + it will be the only valid temporary GRUU for the instance until the + next refresh, at which point a second one becomes valid too. + Consequently, temporary GRUUs "accumulate" during the lifetime of a + registration. + +3.3. Using a GRUU + + Once a user agent obtains GRUUs from the registrar, it uses them in + several ways. First, it uses them as the contents of the Contact + header field in non-REGISTER requests and responses that it emits + (for example, an INVITE request and 200 OK response). According to + RFC 3261 [1], the Contact header field is supposed to contain a URI + that routes to that user agent. Prior to this specification, there + hasn't been a way to really meet that requirement. The user agent + would use one of its temporary GRUUs for anonymous calls, and use its + public GRUU otherwise. + + Second, the UA can use the GRUU in any other place it needs to use a + URI that resolves to itself, such as a webpage. + +3.4. Dereferencing a GRUU + + Because a GRUU is simply a URI, a UA dereferences it in exactly the + same way as it would any other URI. However, once the request has + been routed to the appropriate proxy, the behavior is slightly + different. The proxy will map the GRUU to the AOR and determine the + set of contacts that the particular UA instance has registered. The + GRUU is then mapped to those contacts, and the request is routed + towards the UA. + + + + + + + + + + +Rosenberg Standards Track [Page 8] + +RFC 5627 GRUU Mechanism October 2009 + + +4. User Agent Behavior + + This section defines the normative behavior for user agents. + +4.1. Generating a REGISTER Request + + When a UA compliant to this specification generates a REGISTER + request (initial or refresh), it MUST include the Supported header + field in the request. The value of that header field MUST include + "gruu" as one of the option tags. This alerts the registrar for the + domain that the UA supports the GRUU mechanism. + + Furthermore, for each contact for which the UA desires to obtain a + GRUU, the UA MUST include a "sip.instance" media feature tag (see RFC + 5626 [14]) as a UA characteristic (see [7]), whose value MUST be the + instance ID that identifies the UA instance being registered. Each + such Contact header field SHOULD NOT contain a "pub-gruu" or "temp- + gruu" header field. The contact URI MUST NOT be equivalent, based on + the URI equality rules in RFC 3261 [1], to the AOR in the To header + field. If the contact URI is a GRUU, it MUST NOT be a GRUU for the + AOR in the To header field. + + As in RFC 3261 [1], the Call-ID in a REGISTER refresh SHOULD be + identical to the Call-ID used to previously register a contact. With + GRUU, an additional consideration applies. If the Call-ID changes in + a register refresh, the server will invalidate all temporary GRUUs + associated with that UA instance; the only valid one will be the new + one returned in that REGISTER response. When RFC 5626 is in use, + this rule applies to the reg-ids: If the Call-ID changes for the + registration refresh for a particular reg-id, the server will + invalidate all temporary GRUUs associated with that UA instance as a + whole. Consequently, if a UA wishes its previously obtained + temporary GRUUs to remain valid, it MUST utilize the same Call-ID in + REGISTER refreshes. However, it MAY change the Call-ID in a refresh + if invalidation is the desired objective. + + Note that, if any dialogs are in progress that utilize a temporary + GRUU as a remote target, and a UA performs a registration refresh + with a change in Call-ID, those temporary GRUUs become invalid, and + the UA will not be reachable for subsequent mid-dialog messages. + + If a UA instance is trying to register multiple contacts for the same + instance for the purposes of redundancy, it MUST use the procedures + defined in RFC 5626 [14]. + + A UA utilizing GRUUs can still perform third-party registrations + and can include contacts that omit the "+sip.instance" Contact + header field parameter. + + + +Rosenberg Standards Track [Page 9] + +RFC 5627 GRUU Mechanism October 2009 + + + If a UA wishes to guarantee that the REGISTER request is not + processed unless the domain supports and uses this extension, it MAY + include a Require header field in the request with a value that + contains the "gruu" option tag. This is in addition to the presence + of the Supported header field, also containing the "gruu" option tag. + The use of Proxy-Require is not necessary and is NOT RECOMMENDED. + +4.2. Learning GRUUs from REGISTER Responses + + If the REGISTER response is a 2xx, each Contact header field that + contains the "+sip.instance" Contact header field parameter can also + contain a "pub-gruu" and "temp-gruu" Contact header field parameter. + These header field parameters convey the public and a temporary GRUU + for the UA instance, respectively. A UA MUST be prepared for a + Contact header field to contain just a "pub-gruu", just a "temp- + gruu", neither, or both. The temporary GRUU will be valid for the + duration of the registration (that is, through refreshes), while the + public GRUU persists across registrations. The UA will receive a new + temporary GRUU in each successful REGISTER response, while the public + GRUU will typically be the same. However, a UA MUST be prepared for + the public GRUU to change from a previous one, since the persistence + property is not guaranteed with complete certainty. If a UA changed + its Call-ID in this REGISTER request compared to a previous REGISTER + request for the same contact or reg-id, the UA MUST discard all + temporary GRUUs learned through prior REGISTER responses. A UA MAY + retain zero, one, some, or all of the temporary GRUUs that it is + provided during the time over which at least one contact or reg-id + remains continuously registered. If a UA stores any temporary GRUUs + for use during its registration, it needs to be certain that the + registration does not accidentally lapse due to clock skew between + the UA and registrar. Consequently, the UA MUST refresh its + registration such that the REGISTER refresh transaction will either + complete or timeout prior to the expiration of the registration. For + default transaction timers, this would be at least 32 seconds prior + to expiration, assuming the registration expiration is larger than 64 + seconds. If the registration expiration is less than 64 seconds, the + UA SHOULD refresh its registration halfway prior to expiration. + + Note that, when [14] is in use, and the UA is utilizing multiple + flows for purposes of redundancy, the temporary GRUUs remain valid as + long as at least one flow is registered. Thus, even if the + registration of one flow expires, the temporary GRUUs learned + previously remain valid. + + In cases where registrars forcefully shorten registration intervals, + the registration event package, RFC 3680 [24], is used by user agents + to learn of these changes. A user agent implementing both RFC 3680 + [24] and GRUU MUST also implement the extensions to RFC 3680 [24] for + + + +Rosenberg Standards Track [Page 10] + +RFC 5627 GRUU Mechanism October 2009 + + + conveying information on GRUU, as defined in RFC 5628 [28], as these + are necessary to keep the set of temporary GRUUs synchronized between + the UA and the registrar. More generally, the utility of temporary + GRUUs depends on the UA and registrar being in sync on the set of + valid temporary GRUUs at any time. Without support of RFC 3680 [24] + and its extension for GRUU, the client will remain in sync only as + long as it always re-registers well before the registration + expiration. Besides forceful de-registrations, other events (such as + network outages, connection failures, and short refresh intervals) + can lead to potential inconsistencies in the set of valid temporary + GRUUs. For this reason, it is RECOMMENDED that a UA that utilizes + temporary GRUUs implement RFC 3680 [24] and RFC 5628 [28]. + + A non-2xx response to the REGISTER request has no impact on any + existing GRUUs previously provided to the UA. Specifically, if a + previously successful REGISTER request provided the UA with a GRUU, a + subsequent failed request does not remove, delete, or otherwise + invalidate the GRUU. + + The user and host parts of the GRUU learned by the UA in the REGISTER + response MUST be treated opaquely by the UA. That is, the UA MUST + NOT modify them in any way. A UA MUST NOT modify or remove URI + parameters it does not recognize. Furthermore, the UA MUST NOT add, + remove, or modify URI parameters relevant for receipt and processing + of request at the proxy, including the transport, lr, maddr, ttl, + user, and comp (see RFC 3486 [25]) URI parameters. The other URI + parameter defined in RFC 3261 [1], method, would not typically be + present in a GRUU delivered from a registrar, and a UA MAY add a + method URI parameter to the GRUU before handing it out to another + entity. Similarly, the URI parameters defined in RFC 4240 [26] and + RFC 4458 [27] are meant for consumption by the UA. These would not + be included in the GRUU returned by a registrar and MAY be added by a + UA wishing to provide services associated with those URI parameters. + + Note, however, that should another UA dereference the GRUU, the + parameters will be lost at the proxy when the Request-URI is + translated into the registered contact, unless some other means is + provided for the attributes to be delivered to the UA. Mechanisms + for such delivery are currently the subject of future standardization + activity (see "Delivery of Request-URI Targets to User Agents" [29]). + +4.3. Constructing a Self-Made GRUU + + Many user agents (such as gateways to the Public Switched Telephone + Network (PSTN), conferencing servers, and media servers) do not + perform registrations, and cannot obtain GRUUs through that + mechanism. These types of user agents can be publicly reachable. + This would mean that the policy of the domain is that requests can + + + +Rosenberg Standards Track [Page 11] + +RFC 5627 GRUU Mechanism October 2009 + + + come from anywhere on the public Internet and be delivered to the + user agent without requiring processing by intervening proxies within + the domain. Furthermore, firewall and NAT policies administered by + the domain would allow such requests into the network. When a user + agent is certain that these conditions are met, a UA MAY construct a + self-made GRUU. Of course, a user agent that does REGISTER, but for + whom these conditions are met regardless, MAY also construct a self- + made GRUU. However, usage of GRUUs obtained by the registrar is + RECOMMENDED instead. + + A self-made GRUU is one whose domain part equals the IP address or + hostname of the user agent. The user part of the SIP URI is chosen + arbitrarily by the user agent. Like all other GRUUs, the URI MUST + contain the "gr" URI parameter, with or without a value, indicating + it is a GRUU. + + If a user agent does not register, but is not publicly reachable, it + would need to obtain a GRUU through some other means. Typically, the + UA would be configured with a GRUU, the GRUU would be configured into + the proxy, and the proxy will be configured with a mapping from the + GRUU to the IP address (or hostname) and port of the UA. + +4.4. Using One's Own GRUUs + + A UA SHOULD use a GRUU when populating the Contact header field of + dialog-forming and target refresh requests and responses. In other + words, a UA compliant to this specification SHOULD use one of its + GRUUs as its remote target. This includes: + + o the INVITE request + + o a 2xx or 18x response to an INVITE which contains a To tag + + o the SUBSCRIBE request (see [5]) + + o a 2xx response to a SUBSCRIBE which contains a To tag + + o the NOTIFY request + + o the REFER request (see [6]) + + o a 2xx response to NOTIFY + + o the UPDATE request + + o a 2xx response to NOTIFY + + + + + +Rosenberg Standards Track [Page 12] + +RFC 5627 GRUU Mechanism October 2009 + + + The only reason not to use a GRUU would be privacy considerations; + see Section 10.3. + + When using a GRUU obtained through registrations, a UA MUST have an + active registration prior to using a GRUU, and MUST use a GRUU + learned through that registration. It MUST NOT reuse a GRUU learned + through a previous registration that has lapsed (in other words, one + obtained when registering a contact that has expired). The UA MAY + use either the public or one of its temporary GRUUs provided by its + registrar. A UA MUST NOT use a temporary GRUU learned in a REGISTER + response whose Call-ID differs from the one in the most recent + REGISTER request generated by the UA for the same AOR and instance ID + (and, if RFC 5626 [14] is in use, reg-id). When a UA wishes to + construct an anonymous request as described in RFC 3323 [15], it + SHOULD use a temporary GRUU. See Section 10.3 for a more complete + discussion on the level of privacy afforded by temporary GRUUs. + + As per RFC 3261 [1], a UA SHOULD include a Supported header with the + option tag "gruu" in requests and responses it generates. + +4.4.1. Considerations for Multiple AORs + + In some SIP networks, a user agent can have a multiplicity of AORs, + either in different domains or within the same domain. In such + cases, additional considerations apply. + + When a UA sends a request, the request will be sent 'using' one of + its AORs. This AOR will typically show up in the From header field + of the request, and credentials unique to that AOR will be used to + authenticate the request. The GRUU placed into the Contact header + field of such a request SHOULD be one that is associated with the AOR + used to send the request. In cases where the UA uses a tel URI (as + defined in [11]) to populate the From header field, the UA typically + has a SIP AOR that is treated as an alias for the tel URI. The GRUU + associated with that SIP AOR SHOULD be used in the Contact header + field. + + When a UA receives a request, the GRUU placed into the Contact header + field of a 2xx response SHOULD be the one associated with the AOR or + GRUU to which the request was most recently targeted. There are + several ways to determine the AOR or GRUU to which a request was + sent. For example, if a UA registered a different contact to each + AOR (by using a different user part of the URI), the Request-URI + (which contains that contact) will indicate the AOR. + + + + + + + +Rosenberg Standards Track [Page 13] + +RFC 5627 GRUU Mechanism October 2009 + + +4.5. Dereferencing a GRUU + + A GRUU is identified by the presence of the "gr" URI parameter, and + this URI parameter might or might not have a value. A UA that wishes + to send a request to a URI that contains a GRUU knows that the + request will be delivered to a specific UA instance without further + action on the part of the requestor. + + Some UAs implement non-standard URI-handling mechanisms that + compensate for the fact that heretofore many contact URIs have not + been globally routable. Since any URI containing the "gr" URI + parameter is known to be globally routable, a UA SHOULD NOT apply + such mechanisms when a contact URI contains the "gr" URI parameter. + + Because the instance ID is a callee capabilities parameter, a UA + might be tempted to send a request to the AOR of a user, and + include an Accept-Contact header field (defined in [12]) that + indicates a preference for routing the request to a UA with a + specific instance ID. Although this would appear to have the same + effect as sending a request to the GRUU, it does not. The caller + preferences expressed in the Accept-Contact header field are just + preferences. Their efficacy depends on a UA constructing an + Accept-Contact header field that interacts with domain-processing + logic for an AOR, to cause a request to route to a particular + instance. Given the variability in routing logic in a domain (for + example, time-based routing to only selected contacts), this + doesn't work for many domain-routing policies. However, this + specification does not forbid a client from attempting such a + request, as there can be cases where the desired operation truly + is a preferential routing request. + +4.6. Rendering GRUUs on a User Interface + + When rendering a GRUU to a user through a user interface, it is + RECOMMENDED that the "gr" URI parameter be removed. For public + GRUUs, this will produce the AOR, as desired. For temporary GRUUs, + the resulting URI will be seemingly random. Future work might + provide improved mechanisms that would allow an automaton to know + that a URI is anonymized, and therefore inappropriate to render. + +5. Registrar Behavior + +5.1. Processing a REGISTER Request + + A REGISTER request might contain a Require header field with the + "gruu" option tag; this indicates that the registrar has to + understand this extension in order to process the request. It does + not require the registrar to create GRUUs, however. + + + +Rosenberg Standards Track [Page 14] + +RFC 5627 GRUU Mechanism October 2009 + + + As the registrar is processing the contacts in the REGISTER request + according to the procedures of step 7 in Section 10.3 of RFC 3261 + [1], the registrar checks whether each Contact header field in the + REGISTER message contains a "+sip.instance" header field parameter. + If present with a non-zero expiration, the contact is processed + further based on the rules in the remainder of this section. + Otherwise, the contact is processed based on normal RFC 3261 [1] + rules. + + Note that handling of a REGISTER request containing a Contact + header field with value "*" and an expiration of zero still + retains the meaning defined in RFC 3261 [1] -- all contacts, not + just those with a specific instance ID, are deleted. As described + in Section 5.4, this removes the binding of each contact to the + AOR and the binding of each contact to its GRUUs. + + If the contact URI is equivalent (based on URI equivalence in RFC + 3261 [1]) to the AOR, the registrar MUST reject the request with a + 403, since this would cause a routing loop. If the contact URI is a + GRUU for the AOR in the To header field of the REGISTER request, the + registrar MUST reject the request with a 403, for the same reason. + If the contact is not a SIP URI, the REGISTER request MUST be + rejected with a 403. + + Next, the registrar checks if there is already a valid public GRUU + for the AOR (present in the To header field of the REGISTER request) + and the instance ID (present as the content of the "+sip.instance" + Contact header field parameter). If there is no valid public GRUU, + the registrar SHOULD construct a public GRUU at this time according + to the procedures of Section 5.4. The public GRUU MUST be + constructed by adding the "gr" URI parameter, with a value, to the + AOR. If the contact contained a "pub-gruu" Contact header field + parameter, the header field parameter MUST be ignored by the + registrar. A UA cannot suggest or otherwise provide a public GRUU to + the registrar. + + Next, the registrar checks for any existing contacts registered to + the same AOR, instance ID, and if the contact in the REGISTER request + is registering a flow [14], reg-id. If there is at least one, the + registrar finds the one that was most recently registered, and + examines the Call-ID value associated with that registered contact. + If it differs from the one in the REGISTER request, the registrar + MUST invalidate all previously generated temporary GRUUs for the AOR + and instance ID. A consequence of this invalidation is that requests + addressed to those GRUUs will be rejected by the domain with a 404 + from this point forward. + + + + + +Rosenberg Standards Track [Page 15] + +RFC 5627 GRUU Mechanism October 2009 + + + Next, the registrar SHOULD create a new temporary GRUU for the AOR + and instance ID with the characteristics described in Section 5.4. + The temporary GRUU construction algorithm MUST have the following two + properties: + + 1. The likelihood that the temporary GRUU is equal to another GRUU + that the registrar has created MUST be vanishingly small. + + 2. Given a pair of GRUUs, it MUST be computationally infeasible to + determine whether they were issued for the same AOR or instance + ID or for different AORs and instance IDs. + + If the contact contained a "temp-gruu" Contact header field + parameter, the header field parameter MUST be ignored by the + registrar. A UA cannot suggest or otherwise provide a temporary GRUU + to the registrar. + +5.2. Generating a REGISTER Response + + When generating the 200 (OK) response to the REGISTER request, the + procedures of step 8 of Section 10.3 of RFC 3261 [1] are followed. + Furthermore, for each Contact header field value placed in the + response, if the registrar has stored an instance ID associated with + that contact, that instance ID is returned as a Contact header field + parameter. If the REGISTER request contained a Supported header + field that included the "gruu" option tag, and the registrar has at + least one temporary GRUU assigned to the instance ID and AOR, the + registrar MUST add a "temp-gruu" Contact header field parameter to + that Contact header field. The value of the "temp-gruu" parameter is + a quoted string, and MUST contain the most recently created temporary + GRUU for that AOR and instance ID. In addition, if the registrar has + a public GRUU assigned to the instance ID and AOR (and the client + supports GRUUs), the registrar MUST add a "pub-gruu" Contact header + field parameter to that Contact header field. The value of the "pub- + gruu" Contact header field parameter is the public GRUU. + + The registrar SHOULD NOT include the "gruu" option tag in the Require + or Supported header field of the response. + +5.3. Timing Out a Registration + + When a registered contact expires (either due to timeout or explicit + de-registration), its binding to the AOR is removed as usual. In + addition, its binding to its GRUUs are removed at the same time, as a + consequence of the relationships described in Section 5.4 + + + + + + +Rosenberg Standards Track [Page 16] + +RFC 5627 GRUU Mechanism October 2009 + + + If, as a consequence of the expiration of the contact, a particular + GRUU no longer has any registered contacts bound to it, and the GRUU + is a temporary GRUU, the GRUU MUST be invalidated. This means that + all of the accumulated temporary GRUUs get invalidated once the last + contact for a given instance ID expires. + + If, however, the GRUU was a public GRUU, the registrar SHOULD + continue to treat the GRUU as valid. Consequently, subsequent + requests targeted to the GRUU, prior to re-registration of a contact + to the GRUU, SHOULD return a 480 (Temporarily Unavailable) response. + In addition, since the GRUU remains valid, the rules in Section 5.1 + will cause it to be retained when a contact with that instance ID is + once again registered to the AOR. + + These rules give a public GRUU a semi-permanent property. The + intent is that the registrar make every attempt to retain validity + of the GRUU for as long as the AOR itself is known within the + domain. The requirements for doing so are at SHOULD strength and + not MUST strength because of the difficulty in meeting a MUST + strength requirement; registrar failures could cause the set of + valid GRUUs to be lost, and this specification requires the UA to + be robust against such cases. That said, it is possible for a + public GRUU to be constructed such that a registrar does not need + to retain any additional state for it, yet the GRUU still meets + the requirements described here. + +5.4. Creation of a GRUU + + This section defines additional behaviors associated with the + construction and maintenance of a GRUU that are specific to a + registrar. These rules do not apply to self-made GRUUs or GRUUs not + obtained through registrations. + + When a registrar creates a GRUU, it is required to maintain certain + information associated with the GRUU, regardless of whether it is a + public or temporary GRUU. Every GRUU is associated with a single AOR + and a single instance ID. A registrar MUST be able to determine the + instance ID and AOR when presented with a GRUU. In addition, the + GRUU, like an AOR, resolves to zero or more contacts. While the AOR + resolves to all registered contacts for an AOR, a GRUU resolves only + to those contacts whose instance ID matches the one associated with + the GRUU. For this reason, a contact with an instance ID is always + bound to both a GRUU and its AOR, never just an AOR or just a GRUU. + This is shown pictorially in Figure 1. The figure shows three + contacts registered to a single AOR. One of the contacts has an + instance ID of 1, and the other two have an instance ID of 2. There + are two GRUUs for this AOR. One is associated with instance ID 1, + and the other with instance ID 2. The first GRUU resolves only to + + + +Rosenberg Standards Track [Page 17] + +RFC 5627 GRUU Mechanism October 2009 + + + contacts whose instance ID is 1, and the second resolves only to + contacts whose instance ID is 2. There will typically be multiple + contacts for a given instance ID if a UA has crashed, rebooted, and + re-registered with the same instance ID, or is using the mechanisms + of RFC 5626 [14] to have multiple registrations for redundancy. If + the contact for instance ID 1 expires, the AOR would resolve to two + contacts, but the GRUU associated with instance ID 1 would resolve to + zero. + + +----------+ +----------+ +----------+ + | GRUU | | | | GRUU | + | | | AOR | | | + |Instance:1| | | |Instance:2| + +----------+ +----------+ +----------+ + | / | \ / | + | / | \ / | + | / | \ / | + | / | \ / | + | / | \ / | + | / | \ / | + | / | X | + | / | / \ | + | / | / \ | + | / | / \ | + V V V V V V + +----------+ +----------+ +----------+ + | Contact | | Contact | | Contact | + | | | | | | + |Instance:1| |Instance:2| |Instance:2| + +----------+ +----------+ +----------+ + + Figure 1 + + There can be multiple GRUUs with the same instance ID and AOR. + Indeed, this specification requires registrars to maintain many -- + one that is public, and several that are temporary. However, if two + GRUUs are associated with different AORs or different instance IDs or + both, the GRUUs MUST be different based on URI equality comparison. + A GRUU in a domain MUST NOT be equivalent, based on URI comparison, + to any AOR in a domain except for the one associated with the GRUU. + + A public GRUU will always be equivalent to the AOR based on URI + equality rules. The reason is that the rules in RFC 3261 [1] + cause URI parameters that are in one URI, but not in the other, to + be ignored for equality purposes. Since a public GRUU differs + from an AOR only by the presence of the "gr" URI parameter, the + two URIs are equivalent based on those rules. + + + + +Rosenberg Standards Track [Page 18] + +RFC 5627 GRUU Mechanism October 2009 + + + Once a temporary GRUU is constructed, it MUST be considered valid by + the registrar until invalidated based on the rules described + previously. Once a public GRUU is constructed, it MUST be considered + valid for the duration that the AOR itself is valid. Once an AOR is + no longer valid within a domain, all of its GRUUs MUST be considered + invalid as well. + + This specification does not mandate a particular mechanism for + construction of the GRUU. Example algorithms for public and + temporary GRUUs that work well are given in Appendix A. However, in + addition to the properties described in Section 3.1, a GRUU + constructed by a registrar MUST exhibit the following properties: + + o The domain part of the URI is an IP address present on the public + Internet, or, if it is a hostname, the resolution procedures of + RFC 3263 [2], once applied, result in an IP address on the public + Internet. + + o When a request is sent to the GRUU, it routes to a proxy that can + access the registration data generated by the registrar. Such a + proxy is called an authoritative proxy, defined in RFC 5626 [14]. + +5.5. Registration Event Support + + RFC 3680 [24] defines an event package that allows a client to learn + about registration events at the registrar. This package allows + registrars to alter registrations forcefully (for example, shortening + them to force a re-registration). If a registrar is supporting RFC + 3680 [24] and GRUU, it MUST also support RFC 5628 [28]. + +6. Proxy Behavior + + Proxy behavior is fully defined in Section 16 of RFC 3261 [1]. GRUU + processing impacts that processing in two places -- request targeting + at the authoritative proxy and record-routing. + +6.1. Request Targeting + + When a proxy receives a request, owns the domain in the Request-URI, + and is supposed to access a location service in order to compute + request targets (as specified in Section 16.5 of RFC 3261 [1]), the + proxy examines the Request-URI. If it contains the "gr" URI + parameter but is not equivalent, based on URI comparison, to a + currently valid GRUU within the domain, it SHOULD be rejected with a + 404 (Not Found) response; this is the same behavior a proxy would + exhibit for any other URI within the domain that is not valid. + + + + + +Rosenberg Standards Track [Page 19] + +RFC 5627 GRUU Mechanism October 2009 + + + If the Request-URI contains the "gr" URI parameter and is equivalent, + based on URI comparison, to a GRUU which is currently valid within + the domain, processing proceeds as it would for any other URI present + in the location service, as defined in Section 16.5 of RFC 3261 [1], + except that the "gr" URI parameter is not removed as part of the + canonicalization process. This is the case for both out-of-dialog + requests targeted to the GRUU, and mid-dialog requests targeted to + the GRUU (in which case the incoming request would have a Route + header field value containing the URI that the proxy used for record- + routing.). + + Note that the "gr" URI parameter is retained just for the purposes of + finding the GRUU in the location service; if a match is found, the + Request-URI will be rewritten with the registered contacts, replacing + the GRUU and its "gr" URI parameter. The "gr" URI parameter is not + carried forward into the rewritten Request-URI. + + If there are no registered contacts bound to the GRUU, the server + MUST return a 480 (Temporarily Unavailable) response. If there are + more than one, there are two cases: + + 1. The client is using RFC 5626 [14] and registering multiple + contacts for redundancy. In that case, these contacts contain + "reg-id" Contact header field parameters, and the rules described + in Section 7 of RFC 5626 [14] for selecting a single registered + contact apply. + + 2. The client was not using RFC 5626 [14], in which case there would + only be multiple contacts with the same instance ID if the client + had rebooted, restarted, and re-registered. In this case, these + contacts would not contain the "reg-id" Contact header field + parameter. The proxy MUST select the most recently refreshed + contact. As with RFC 5626, if a request to this target fails + with a 408 (Request Timeout) or 430 (Flow Failed) response, the + proxy SHOULD retry with the next most recently refreshed contact. + Furthermore, if the request fails with any other response, the + proxy MUST NOT retry on any other contacts for this instance. + + Any caller preferences in the request (as defined in RFC 3841 [12]) + SHOULD be processed against the contacts bound to the GRUU. + + In essence, to select a registered contact, the GRUU is processed + just like it was the AOR, but with only a subset of the contacts + bound to the AOR. + + Special considerations apply to the processing of any Path headers + stored in the registration (see RFC 3327 [3]). If the received + request has Route header field values beyond the one pointing to the + + + +Rosenberg Standards Track [Page 20] + +RFC 5627 GRUU Mechanism October 2009 + + + authoritative proxy itself (this will happen when the request is a + mid-dialog request), the Path URI MUST be discarded. This is + permitted by RFC 3327 [3] as a matter of local policy; usage of GRUUs + will require this policy in order to avoid call spirals and likely + call failures. + + A proxy MAY apply other processing to the request, such as execution + of called party features, as it might do for requests targeted to an + AOR. For requests that are outside of a dialog, it is RECOMMENDED to + apply screening types of functions, both automated (such as blacklist + and whitelist screening) and interactive (such as interactive voice + response (IVR) applications that confer with the user to determine + whether to accept a call). In many cases, the new request is related + to an existing dialog, and might be an attempt to join it (using the + Join header field defined in RFC 3911 [21]) or replace it (using the + Replaces header field defined in RFC 3891 [22]). When the new + request is related to an existing dialog, the UA will typically make + its own authorization decisions; bypassing screening services at the + authoritative proxy might make sense, but needs to be carefully + considered by network designers, as the ability to do so depends on + the specific type of screening service. + + However, forwarding services, such as call forwarding, SHOULD NOT be + provided for requests sent to a GRUU. The intent of the GRUU is to + target a specific UA instance, and this is incompatible with + forwarding operations. + + If the request is a mid-dialog request, a proxy SHOULD only apply + services that are meaningful for mid-dialog requests, generally + speaking. This excludes screening and forwarding functions. + + In addition, a request sent to a GRUU SHOULD NOT be redirected. In + many instances, a GRUU is used by a UA in order to assist in the + traversal of NATs and firewalls, and a redirection might prevent such + a case from working. + +6.2. Record-Routing + + There are two distinct requirements for record-routing -- in the + originating domain and in the terminating domain. These requirements + avoid unnecessary, and possibly problematic, spirals of requests. + + If: + + o an originating authoritative proxy receives a dialog-forming + request, + + + + + +Rosenberg Standards Track [Page 21] + +RFC 5627 GRUU Mechanism October 2009 + + + o AND the Contact header field contains a GRUU in the domain of the + proxy, + + o AND that GRUU is a valid one in the domain of the proxy, + + o AND that GRUU is associated with the AOR matching the + authenticated identity of the requestor (assuming such + authentication has been performed), + + o AND the request contains Record-Route header fields, + + then the authoritative proxy MUST record-route. If all of these + conditions are true, except that the GRUU is associated with an AOR + that did not match the authenticated identity of the requestor, it is + RECOMMENDED that the proxy reject the request with a 403 (Forbidden) + response. + + If: + + o a terminating authoritative proxy receives a dialog-forming + request, + + o AND the Request-URI contains a URI in the location service (either + a GRUU or an AOR), + + o AND the contact selected for sending the request has an instance + ID and is bound to a GRUU, + + o AND the registration contain Path URI, + + then the authoritative proxy MUST record-route. + + If a proxy is in either the originating or terminating domains but is + not an authoritative proxy, the proxy MAY record-route. + + If a proxy in the terminating domain requires mid-dialog requests to + pass through it for whatever reason (firewall traversal, accounting, + etc.), the proxy MUST still record-route, and MUST NOT assume that a + UA will utilize its GRUU in the Contact header field of its response + (which would cause mid-dialog requests to pass through the proxy + without record-routing). + + Implementors should note that, if a UA uses a GRUU in its contact, + and a proxy inserted itself into the Path header field of a + registration, that proxy will be receiving mid-dialog requests + regardless of whether it record-routes or not. The only + distinction is what URI the proxy will see in the topmost Route + + + + +Rosenberg Standards Track [Page 22] + +RFC 5627 GRUU Mechanism October 2009 + + + header field of mid-dialog requests. If the proxy record-routes, + it will see that URI. If it does not, it will see the Path URI it + inserted. + +7. Grammar + + This specification defines two new Contact header field parameters + ("temp-gruu" and "pub-gruu") by extending the grammar for "contact- + params" as defined in RFC 3261 [1]. It also defines a new SIP URI + parameter ("gr") by extending the grammar for "uri-parameter" as + defined in RFC 3261 [1]. The ABNF [13] is as follows: + + contact-params =/ temp-gruu / pub-gruu + temp-gruu = "temp-gruu" EQUAL quoted-string + pub-gruu = "pub-gruu" EQUAL quoted-string + + uri-parameter =/ gr-param + gr-param = "gr" ["=" pvalue] ; defined in RFC 3261 + + The quoted strings for temp-gruu and pub-gruu MUST contain a SIP URI. + However, they are encoded like all other quoted strings and can + therefore contain quoted-pair escapes when represented this way. + +8. Requirements + + This specification was created in order to meet the following + requirements: + + REQ 1: When a UA invokes a GRUU, it must cause the request to be + routed to the specific UA instance to which the GRUU refers. + + REQ 2: It must be possible for a GRUU to be invoked from anywhere on + the Internet, and still cause the request to be routed + appropriately. That is, a GRUU must not be restricted to use + within a specific addressing realm. + + REQ 3: It must be possible for a GRUU to be constructed without + requiring the network to store additional state. + + REQ 4: It must be possible for a UA to obtain a multiplicity of + GRUUs that each route to that UA instance. For example, this is + needed to support ad hoc conferencing where a UA instance needs a + different URI for each conference it is hosting. NOTE: This + requirement is not met by this specification, and is being + addressed in a separate specification (currently, "Delivery of + Request-URI Targets to User Agents" [29]). + + + + + +Rosenberg Standards Track [Page 23] + +RFC 5627 GRUU Mechanism October 2009 + + + REQ 5: When a UA receives a request sent to a GRUU, it must be + possible for the UA to know the GRUU that was used to invoke the + request. This is necessary as a consequence of REQ 4. NOTE: This + requirement is not met by this specification, and is being + addressed in a separate specification (currently, "Delivery of + Request-URI Targets to User Agents" [29]). + + REQ 6: It must be possible for a UA to add opaque content to a GRUU. + This content is not interpreted or altered by the network, and is + used only by the UA instance to whom the GRUU refers. This + provides a basic cookie type of functionality, allowing a UA to + build a GRUU with the state embedded. NOTE: This requirement is + not met by this specification, and is being addressed in a + separate specification (currently, "Delivery of Request-URI + Targets to User Agents" [29]). + + REQ 7: It must be possible for a proxy to execute services and + features on behalf of a UA instance represented by a GRUU. As an + example, if a user has call-blocking features, a proxy might want + to apply those call-blocking features to calls made to the GRUU, + in addition to calls made to the user's AOR. + + REQ 8: It must be possible for a UA in a dialog to inform its peer + of its GRUU, and for the peer to know that the URI represents a + GRUU. This is needed for the conferencing and dialog reuse + applications of GRUUs, where the URIs are transferred within a + dialog. + + REQ 9: When transferring a GRUU per REQ 8, it must be possible for + the UA receiving the GRUU to be assured of its integrity and + authenticity. + + REQ 10: It must be possible for a server that is authoritative for a + domain to construct a GRUU that routes to a UA instance bound to + an AOR in that domain. In other words, the proxy can construct a + GRUU, too. This is needed for the presence application. + +9. Example Call Flow + + The following call flow, shown in Figure 2, shows a basic + registration and call setup, followed by a subscription directed to + the GRUU. It then shows a failure of the callee, followed by a re- + registration. The conventions of RFC 4475 [17] are used to describe + the representation of long message lines. + + + + + + + +Rosenberg Standards Track [Page 24] + +RFC 5627 GRUU Mechanism October 2009 + + + Caller Proxy Callee + | |(1) REGISTER | + | |<--------------------| + | |(2) 200 OK | + | |-------------------->| + |(3) INVITE | | + |-------------------->| | + | |(4) INVITE | + | |-------------------->| + | |(5) 200 OK | + | |<--------------------| + |(6) 200 OK | | + |<--------------------| | + |(7) ACK | | + |-------------------->| | + | |(8) ACK | + | |-------------------->| + |(9) SUBSCRIBE | | + |-------------------->| | + | |(10) SUBSCRIBE | + | |-------------------->| + | |(11) 200 OK | + | |<--------------------| + |(12) 200 OK | | + |<--------------------| | + | |(13) NOTIFY | + | |<--------------------| + |(14) NOTIFY | | + |<--------------------| | + |(15) 200 OK | | + |-------------------->| | + | |(16) 200 OK | + | |-------------------->| + | | |Crashes, + | |(17) REGISTER | Reboots + | |<--------------------| + | |(18) 200 OK | + | |-------------------->| + + Figure 2 + + + + + + + + + + + +Rosenberg Standards Track [Page 25] + +RFC 5627 GRUU Mechanism October 2009 + + + The callee supports the GRUU extension. As such, its REGISTER (1) + looks like: + + REGISTER sip:example.com SIP/2.0 + Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 + Max-Forwards: 70 + From: Callee ;tag=a73kszlfl + Supported: gruu + To: Callee + Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 + CSeq: 1 REGISTER + Contact: + ;+sip.instance="" + Content-Length: 0 + + The registrar assigns a temporary and a public GRUU. The REGISTER + response (message 2) would look like: + + SIP/2.0 200 OK + Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 + From: Callee ;tag=a73kszlfl + To: Callee ;tag=b88sn + Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 + CSeq: 1 REGISTER + + Contact: + ;pub-gruu="sip:callee@example.com + ;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" + ;temp-gruu="sip:tgruu.7hs== + jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr" + ;+sip.instance="" + ;expires=3600 + + Content-Length: 0 + + The Contact header field in the REGISTER response contains the "pub- + gruu" Contact header field parameter with the public GRUU sip:callee@ + example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6, and the + "temp-gruu" header field parameter with the temporary GRUU + sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr. Both + are valid GRUUs for the AOR and instance ID, and both translate to + the contact sip:callee@192.0.2.1. + + The INVITE from the caller (message 3) is a normal SIP INVITE. + However, the 200 OK generated by the callee (message 5) now contains + a GRUU as the remote target. The UA has chosen to use its public + GRUU. + + + + +Rosenberg Standards Track [Page 26] + +RFC 5627 GRUU Mechanism October 2009 + + + SIP/2.0 200 OK + Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKnaa8 + Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK99a + From: Caller ;tag=n88ah + To: Callee ;tag=a0z8 + Call-ID: 1j9FpLxk3uxtma7@host.example.com + CSeq: 1 INVITE + Supported: gruu + Allow: INVITE, OPTIONS, CANCEL, BYE, ACK, SUBSCRIBE + + Contact: + + + Content-Length: -- + Content-Type: application/sdp + + [SDP Not shown] + + At some point later in the call, the caller decides to subscribe to + the dialog event package (defined in [16]) at that specific UA. To + do that, it generates a SUBSCRIBE request (message 9), but directs it + towards the remote target, which is a GRUU: + + + SUBSCRIBE sip:callee@example.com;gr=urn:uuid:f8 + 1d4fae-7dec-11d0-a765-00a0c91e6bf6 + SIP/2.0 + + Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK9zz8 + From: Caller ;tag=kkaz- + + To: + + Call-ID: faif9a@host.example.com + CSeq: 2 SUBSCRIBE + Supported: gruu + Event: dialog + Allow: INVITE, OPTIONS, CANCEL, BYE, ACK, NOTIFY + Contact: + Content-Length: 0 + + In this example, the caller itself supports the GRUU extension and is + using its own GRUU to populate its remote target. + + + + + + +Rosenberg Standards Track [Page 27] + +RFC 5627 GRUU Mechanism October 2009 + + + This request is routed to the proxy, which proceeds to perform a + location lookup on the Request-URI. It is translated into the + contact for that instance, and then proxied to that contact. + + SUBSCRIBE sip:callee@192.0.2.1 SIP/2.0 + Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK9555 + Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK9zz8 + From: Caller ;tag=kkaz- + + To: + + Call-ID: faif9a@host.example.com + CSeq: 2 SUBSCRIBE + Supported: gruu + Event: dialog + Allow: INVITE, OPTIONS, CANCEL, BYE, ACK, NOTIFY + Contact: + Content-Length: 0 + + The SUBSCRIBE generates a 200 response (message 11), which is + followed by a NOTIFY (message 13 and 14) and its response (message 15 + and 16). At some point after message 16 is received, the callee's + machine crashes and recovers. It obtains a new IP address, + 192.0.2.2. Unaware that it had previously had an active + registration, it creates a new one (message 17 below). Notice how + the instance ID remains the same, as it persists across reboot + cycles: + + REGISTER sip:example.com SIP/2.0 + Via: SIP/2.0/UDP 192.0.2.2;branch=z9hG4bKnasbba + Max-Forwards: 70 + From: Callee ;tag=ha8d777f0 + Supported: gruu + To: Callee + Call-ID: hf8asxzff8s7f@192.0.2.2 + CSeq: 1 REGISTER + + Contact: + ;+sip.instance="" + + Content-Length: 0 + + The registrar notices that a different contact, sip:callee@192.0.2.1, + is already associated with the same instance ID. It registers the + new one too and returns both in the REGISTER response. Both have the + same public GRUUs, but the registrar has generated a second temporary + GRUU for this AOR and instance ID combination. Both contacts are + + + +Rosenberg Standards Track [Page 28] + +RFC 5627 GRUU Mechanism October 2009 + + + included in the REGISTER response, and the temporary GRUU for each is + the same -- the most recently created one for the instance ID and + AOR. The registrar then generates the following response: + + SIP/2.0 200 OK + Via: SIP/2.0/UDP 192.0.2.2;branch=z9hG4bKnasbba + From: Callee ;tag=ha8d777f0 + To: Callee ;tag=99f8f7 + Call-ID: hf8asxzff8s7f@192.0.2.2 + CSeq: 1 REGISTER + + Contact: + ;pub-gruu="sip:callee@example.com;gr=urn: + uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" + ;temp-gruu="sip:tgruu.7hatz6cn-098shfyq193= + ajfux8fyg7ajqqe7@example.com;gr" + ;+sip.instance="" + ;expires=3600 + + + Contact: + ;pub-gruu="sip:callee@example.com;gr=urn: + uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" + ;temp-gruu="sip:tgruu.7hatz6cn-098shfyq193= + ajfux8fyg7ajqqe7@example.com;gr" + ;+sip.instance="" + ;expires=400 + + Content-Length: 0 + + There is no need for the UA to remove the stale registered contact; + the request targeting rules in Section 6.1 will cause the request to + be delivered to the most recent one. + +10. Security Considerations + + Attacks in SIP networks using GRUUs can be divided into outside + attacks (where a third party is trying to attack the system) and + inside attacks (where the attacker is a valid participant in the + system but is malicious). In addition, there are privacy + considerations with using GRUUs. + +10.1. Outside Attacks + + It is important for a UA to be assured of the integrity of a GRUU + given in a REGISTER response. If the GRUU is tampered with by an + attacker, the result could be denial of service (DoS) to the UA. As + a result, it is RECOMMENDED that a UA use the SIPS URI scheme in the + + + +Rosenberg Standards Track [Page 29] + +RFC 5627 GRUU Mechanism October 2009 + + + Request-URI when registering. Proxies and registrars MUST support + the SIPS URI and MUST support TLS. This does not represent a change + from the requirements in RFC 3261 [1]. + + The example GRUU construction algorithm in Appendix A.1 makes no + attempt to create a GRUU that hides the AOR and instance ID + associated with the GRUU. In general, determination of the AOR + associated with a GRUU is considered a good property, since it allows + for easy tracking of the target of a particular call. Learning the + instance ID provides little benefit to an attacker. To register or + otherwise impact registrations for the user, an attacker would need + to obtain the credentials for the user. Knowing the instance ID is + insufficient. + + The example GRUU construction algorithm in Appendix A.1 makes no + attempt to create a GRUU that prevents users from guessing a GRUU + based on knowledge of the AOR and instance ID. A user that is able + to do that will be able to direct a new request at a particular + instance. However, this specification recommends that service + treatment (in particular, screening features) be given to requests + that are sent to a GRUU. That treatment will make sure that the GRUU + does not provide a back door for attackers to contact a user that has + tried to block the attacker. + +10.2. Inside Attacks + + As a consequence of this specification, a UA will begin using GRUUs + in the dialog forming and target refresh requests and responses it + emits. These GRUUs will be passed to another UA (called the + correspondent), which then uses them in requests that they emit. + + If a malicious correspondent removes the "gr" URI parameter, the + request will be routed to the authoritative proxy. If the GRUU had + been temporary, removal of the "gr" URI parameter produces a URI that + is not recognized as a GRUU and is not equal to any AOR. The request + will be rejected. If the GRUU had been public, removing the "gr" URI + parameter would have produced the AOR. Therefore, the request is + treated like a call to the AOR. Since it is a desired goal to allow + users to extract the AOR from the GRUU, this is not an attack, and + the call will be handled normally. + + A malicious user in the system might try to use a GRUU for launching + a DoS attack against another SIP UA. To do that, it would wait for a + call from that UA, and from it, observe their GRUU. Once the GRUU is + obtained, the UA would launch a SIP request to an entity, such as a + presence server, which will generate many requests back towards the + UA. However, the attacker will use the target's GRUU in the Contact + header field of that SUBSCRIBE request. This will cause the traffic + + + +Rosenberg Standards Track [Page 30] + +RFC 5627 GRUU Mechanism October 2009 + + + to be directed towards the target instead. Since the GRUU is + globally routable, such traffic is more likely to be delivered to the + target than traffic sent to its IP address. This specification helps + mitigate this attack by requiring proxies to validate that the GRUU + in the Contact of a request matches the authenticated identity of the + sender of the request. This check requires the use of an outbound + proxy. SIP does not require outbound proxies, and this does leave a + potential area of vulnerability. However, in practice, nearly all + deployments of SIP utilize an outbound proxy, and therefore this + vulnerability is not likely to be a concern. + +10.3. Privacy Considerations + + RFC 3323 [15] defines mechanisms for privacy. It distinguishes + between network-provided privacy and user-provided privacy. In the + former, the user requests privacy services from the network by + including a Privacy header field in the request. In the latter, the + UA follows a basic set of guidelines for construction of its request, + so a certain level of privacy is afforded. + + The guidelines in Section 4.1 of RFC 3323 [15] for user-provided + privacy request that a UA construct its Contact header field with a + URI that omits a user part, and utilizes the IP address or hostname + of the UA. Such recommendations are in conflict with the rules + defined in this specification, which require the usage of a GRUU in + the Contact header field. + + However, the temporary GRUUs provided by the registrar can be used in + place of the Contact URI format described in RFC 3323 [15]. A user + agent would gather the temporary GRUU returned in each REGISTER + response, and keep a small number of them cached. When it makes or + receives a call, a temporary GRUU is used to populate the Contact + header field. + + A UA can either elect to use the same temporary GRUU in each call, or + it can use a different temporary GRUU in each call. The choice + depends on the level of privacy desired: + + o A UA utilizing the same temporary GRUU for each call will allow a + correspondent, based solely on investigation of the Contact header + field, to correlate calls as coming from the same UA. This is + also true for the user-provided privacy procedures in RFC 3323 + [15], since the IP address or hostname in the Contact URI provides + a similar correlator. + + + + + + + +Rosenberg Standards Track [Page 31] + +RFC 5627 GRUU Mechanism October 2009 + + + o A UA utilizing a different temporary GRUU for each call will not + allow a correspondent, based solely on investigation of the + Contact header field, to correlate calls as coming from the same + UA. + + o In both cases, absent network-provided privacy, IP address and + port information in the Session Description Protocol (SDP) + (defined in [10]) will allow a correspondent to correlate calls as + coming from the same UA. + + o In both cases, if a user makes a call, the correspondent will be + able to call back by directing requests towards the GRUU in the + Contact header field. Similarly, features such as transfer and + digit collection by network application servers (see RFC 4730 + [20]), which depend on a Contact with the GRUU property, will also + be possible. These kinds of inbound requests will be possible + until the registration for that UA lapses. A UA that wishes to + invalidate its previous temporary GRUU in order to limit + reachability MAY do so by generating a REGISTER refresh with a + Call-ID that differs from ones used previously. A UA SHOULD NOT + forcefully expire its registration and then re-register in order + to invalidate a temporary GRUU; this results in a brief period of + unreachability and will often produce excess load on the network. + Refreshing with a new Call-ID is more efficient and is meant as + the technique for coarse-grained control over the validity of + temporary GRUUs. A UA wishing to not be disturbed by a specific + call back will need to implement manual or automated call-handling + procedures to reject it. This specification does not provide the + UA the ability to manually invalidate individual temporary GRUUs. + If a UA insists on not receiving any such inbound requests + (including ones generated by network applications, such as those + used for collecting digits), the UA can place a non-GRUU into the + Contact header field. However, this is NOT RECOMMENDED. Usage of + a GRUU coupled with automated call rejection features is far + superior. + + o As long as a temporary GRUU is used to populate the Contact header + field, a correspondent will not be able to ascertain any + information about the AOR or instance ID of the UA by inspection + of the Contact header field. However, absent a network-provided + privacy service, the IP address in the SDP can be used to + determine information about the UA, such as its geographic + location and ISP. + + o In all cases, regardless of whether the UA uses a temporary or + public GRUU in the Contact, regardless of whether it utilizes GRUU + at all, and regardless of whether it invokes a network-provided + privacy service, a correspondent will be able to determine the SIP + + + +Rosenberg Standards Track [Page 32] + +RFC 5627 GRUU Mechanism October 2009 + + + service provider of the UA. + +11. IANA Considerations + + This specification defines two new Contact header field parameters, + one SIP URI parameter, and a SIP option tag. + +11.1. Header Field Parameter + + This specification defines two new header field parameters, as per + the registry created by RFC 3968 [8]. The required information is as + follows: + + Header field in which the parameter can appear: Contact + Name of the Parameter: pub-gruu + Predefined Values: none + RFC Reference: RFC 5627 + + Header field in which the parameter can appear: Contact + Name of the Parameter: temp-gruu + Predefined Values: none + RFC Reference: RFC 5627 + +11.2. URI Parameter + + This specification defines one new SIP URI parameter, as per the + registry created by RFC 3969 [9]. + + Name of the Parameter: gr + Predefined Values: none + RFC Reference: RFC 5627 + +11.3. SIP Option Tag + + This specification registers a new SIP option tag, as per the + guidelines in Section 27.1 of RFC 3261 [1]. + + Name: gruu + + Description: This option tag is used to identify the Globally + Routable User Agent URI (GRUU) extension. When used in a + Supported header, it indicates that a User Agent understands the + extension. When used in a Require header field of a REGISTER + request, it indicates that the registrar is not expected to + process the registration unless it supports the GRUU extension. + + + + + + +Rosenberg Standards Track [Page 33] + +RFC 5627 GRUU Mechanism October 2009 + + +12. Acknowledgments + + The author would like to thank Eric Rescorla, Robert Sparks, Rohan + Mahy, Paul Kyzivat, Alan Johnston, Ya-Ching Tan, Dale Worley, Jeroen + van Bemmel, Vijay Gurbani, Andrew Allen, Alan Hawrylyshen, Francois + Audet, Fredrik Thulin, Dean Willis, David Hancock, Keith Drage, and + Cullen Jennings for their comments and contributions to this work. + Eric Rescorla provided the text for the introduction and the GRUU + construction algorithm in the appendix. + +13. References + +13.1. Normative References + + [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., + Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: + Session Initiation Protocol", RFC 3261, June 2002. + + [2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol + (SIP): Locating SIP Servers", RFC 3263, June 2002. + + [3] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) + Extension Header Field for Registering Non-Adjacent Contacts", + RFC 3327, December 2002. + + [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event + Notification", RFC 3265, June 2002. + + [6] Sparks, R., "The Session Initiation Protocol (SIP) Refer + Method", RFC 3515, April 2003. + + [7] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating + User Agent Capabilities in the Session Initiation Protocol + (SIP)", RFC 3840, August 2004. + + [8] Camarillo, G., "The Internet Assigned Number Authority (IANA) + Header Field Parameter Registry for the Session Initiation + Protocol (SIP)", BCP 98, RFC 3968, December 2004. + + [9] Camarillo, G., "The Internet Assigned Number Authority (IANA) + Uniform Resource Identifier (URI) Parameter Registry for the + Session Initiation Protocol (SIP)", BCP 99, RFC 3969, + December 2004. + + + + + +Rosenberg Standards Track [Page 34] + +RFC 5627 GRUU Mechanism October 2009 + + + [10] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session + Description Protocol", RFC 4566, July 2006. + + [11] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, + December 2004. + + [12] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller + Preferences for the Session Initiation Protocol (SIP)", + RFC 3841, August 2004. + + [13] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, January 2008. + + [14] Jennings, C., Ed. and R. Mahy, Ed., "Managing Client-Initiated + Connections in the Session Initiation Protocol (SIP)", + RFC 5626, October 2009. + +13.2. Informative References + + [15] Peterson, J., "A Privacy Mechanism for the Session Initiation + Protocol (SIP)", RFC 3323, November 2002. + + [16] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- + Initiated Dialog Event Package for the Session Initiation + Protocol (SIP)", RFC 4235, November 2005. + + [17] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and + H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test + Messages", RFC 4475, May 2006. + + [18] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCP- + for-IPv4) Option for Session Initiation Protocol (SIP) + Servers", RFC 3361, August 2002. + + [19] Sparks, R., Johnston, A., and D. Petrie, "Session Initiation + Protocol (SIP) Call Control - Transfer", BCP 149, RFC 5589, + June 2009. + + [20] Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP) + Event Package for Key Press Stimulus (KPML)", RFC 4730, + November 2006. + + [21] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) + "Join" Header", RFC 3911, October 2004. + + [22] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation + Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. + + + + +Rosenberg Standards Track [Page 35] + +RFC 5627 GRUU Mechanism October 2009 + + + [23] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) + Extension Header Field for Service Route Discovery During + Registration", RFC 3608, October 2003. + + [24] Rosenberg, J., "A Session Initiation Protocol (SIP) Event + Package for Registrations", RFC 3680, March 2004. + + [25] Camarillo, G., "Compressing the Session Initiation Protocol + (SIP)", RFC 3486, February 2003. + + [26] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media + Services with SIP", RFC 4240, December 2005. + + [27] Jennings, C., Audet, F., and J. Elwell, "Session Initiation + Protocol (SIP) URIs for Applications such as Voicemail and + Interactive Voice Response (IVR)", RFC 4458, April 2006. + + [28] Kyzivat, P., "Registration Event Package Extension for Session + Initiation Protocol (SIP) Globally Routable User Agent URIs + (GRUUs)", RFC 5628, October 2009. + + [29] Rosenberg, J., van Elburg, J., Holmberg, C., Audet, F., and S. + Schubert, Ed., "Delivery of Request-URI Targets to User + Agents", Work in Progress, June 2009. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rosenberg Standards Track [Page 36] + +RFC 5627 GRUU Mechanism October 2009 + + +Appendix A. Example GRUU Construction Algorithms + + The mechanism for constructing a GRUU is not subject to + specification. This appendix provides an example that can be used by + a registrar to construct a public and a temporary GRUU. Of course, + others are permitted, as long as they meet the constraints defined + for a GRUU. + +A.1. Public GRUU + + The most basic approach for constructing a public GRUU is to take the + AOR and place the actual value of the instance ID into the contents + of the "gr" URI parameter. + +A.2. Temporary GRUU + + This specification requires a registrar to create a new temporary + GRUU on each registration refresh. If a registration is very long + lived, this can quickly result in hundreds or even thousands of + temporary GRUUs being created and allocated to a UA. Consequently, + it is important to have an algorithm for constructing temporary GRUUs + that does not require additional storage that grows in size with the + number of temporary GRUUs. The following algorithm meets this goal. + + The registrar maintains a counter, I. This counter is 48 bits and is + initialized to zero. The counter is persistently stored, using a + backend database or other similar technique. When the registrar + creates the first temporary GRUU for a particular AOR and instance + ID, the registrar notes the current value of the counter, I_i, and + increments the counter in the database. The registrar then maps I_i + to the AOR and instance ID using the database, a persistent hashmap + or similar technology. If the registration expires such that there + are no longer any contacts with that particular instance ID bound to + the GRUU, the registrar removes the mapping. Similarly, if the + temporary GRUUs are invalidated due to a change in Call-ID, the + registrar removes the current mapping from I_i to the AOR and + instance ID, notes the current value of the counter I_j, and stores a + mapping from I_j to the AOR and instance ID. Based on these rules, + the hashmap will contain a single mapping for each AOR and instance + ID for which there is a currently valid registration. + + The usage of a counter in a 48-bit space with sequential assignment + allows for a compact representation of the hashmap key, which is + important for generating GRUUs of reasonable size. The counter + starts at zero when the system is initialized. Persistent and + reliable storage of the counter is required to avoid misrouting of a + GRUU to the wrong AOR and instance ID. Similarly, persistent storage + of the hashmap is required, even through proxy and registrar + + + +Rosenberg Standards Track [Page 37] + +RFC 5627 GRUU Mechanism October 2009 + + + restarts. If the hashmap is reset, all previous temporary GRUUs + become invalidated. This might cause dialogs in progress to fail, or + future requests towards a temporary GRUU to fail when they normally + would not. The same hashmap needs to be accessible by all proxies + and registrars that can field requests for a particular AOR and + instance ID. + + The registrar maintains a pair of local symmetric keys K_e and K_a. + These are regenerated every time the counter is reset. When the + counter rolls over or is reset, the registrar remembers the old + values of K_e and K_a for a time. Like the hashmap itself, these + keys need to be shared across all proxy and registrars that can + service requests for a particular AOR and instance ID. + + To generate a new temporary GRUU, the registrar generates a random + 80-bit distinguisher value D. It then computes: + + M = D || I_i + E = AES-ECB-Encrypt(K_e, M) + A = HMAC-SHA256-80(K_a, E) + + Temp-Gruu-userpart = "tgruu." || base64(E) || base64(A) + + where || denotes concatenation, and AES-ECB-Encrypt represents AES + encryption in electronic codebook mode. M will be 128 bits long, + producing a value of E that is 128 bits and A that is 80 bits. This + produces a user part which has 42 characters. + + When a proxy receives a request whose user part begins with "tgruu.", + it extracts the remaining portion, and splits it into 22 characters + (E') and the remaining 14 characters (A'). It then computes A and E + by performing a base64 decode of A' and E' respectively. Next, it + computes: + + Ac = HMAC-SHA256-80(K_a, E) + + If the counter has rolled over or reset, this computation is + performed with the current and previous K_a. If the Ac value(s) that + are computed do not match the value of A extracted from the GRUU, the + GRUU is rejected as invalid. Next, the proxy computes: + + M = AES-ECB-Decrypt(K_e, E) + + If the counter has rolled over, this computation is done using the + value of K_e that goes with the value of K_a, which produced a valid + Ac in the previous HMAC validation. The leading 80 bits (the + distinguisher D) are discarded, leaving an index I_i in the hashmap. + This index is looked up. If it exists, the proxy now has the AOR and + + + +Rosenberg Standards Track [Page 38] + +RFC 5627 GRUU Mechanism October 2009 + + + instance ID corresponding to this temporary GRUU. If there is + nothing in the hashmap for the key I_i, the GRUU is no longer valid + and the request is rejected. + + The usage of a 48-bit counter allows for the registrar to have as + many as a billion AORs, with 10 instances per AOR, and cycle through + 10,000 Call-ID changes for each instance through the duration of a + single registration. These numbers reflect the average; the system + works fine if a particular AOR has more than 10 instances or a + particular instance cycles through more than 10,000 Call-IDs in its + registration, as long as the average meets these constraints. + +Appendix B. Network Design Considerations + + The GRUU specification works properly based on logic implemented at + the user agents and in the authoritative proxies on both sides of a + call. Consequently, it is possible to construct network deployments + in which GRUUs will not work properly. + + One important assumption made by the GRUU mechanism is that, if a + request passes through any proxies in the originating domain prior to + visiting the terminating domain, one of those proxies will be the + authoritative proxy for the User Agent Client (UAC). Administrators + of SIP networks will need to make sure that this property is + retained. There are several ways it can be accomplished: + + 1. If the user agents support the service-route mechanism [23], the + registrar can implement it and return a service route that points + to the authoritative proxy. This will cause requests originated + by the user agent to pass through the authoritative proxy. + + 2. The user agents can be configured to never use an outbound proxy, + and send requests directly to the domain of the terminating + party. This configuration is not practical in many use cases, + but it is a solution to this requirement. + + 3. The user agents can be configured with an outbound proxy in the + same domain as the authoritative proxy, and this outbound proxy + forwards requests to the authoritative proxy by default. This + works very well in cases where the clients are not roaming; in + such cases, the outbound proxy in a visited network may be + discovered dynamically through DHCP [18]. + + 4. In cases where the client discovers a local outbound proxy via a + mechanism such as DHCP, and is not implementing the service route + mechanism, the UA can be configured to automatically add an + additional Route header field after the outbound proxy, which + points to a proxy in the home network. This has the same net + + + +Rosenberg Standards Track [Page 39] + +RFC 5627 GRUU Mechanism October 2009 + + + effect of the service route mechanism, but is accomplished + through static configuration. + +Author's Address + + Jonathan Rosenberg + Cisco Systems + Edison, NJ + US + + EMail: jdrosen@cisco.com + URI: http://www.jdrosen.net + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rosenberg Standards Track [Page 40] + -- cgit v1.2.3