SIP D. Worley Internet-Draft Pingtel Expires: August 23, 2007 February 19, 2007 Guidelines for Implementing the GRUU Support in User Agents draft-worley-sip-gruu-implement-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 23, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Worley Expires August 23, 2007 [Page 1] Internet-Draft Guidelines for GRUU Support February 2007 Abstract Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI which can be used by anyone on the Internet to route a request to that specific UA instance. A URI which routes to a specific UA instance is called a Globally Routable UA URI (GRUU). An Internet-Draft is progressing toward standardization that specifies procedures for proxies and UAs by which proxies can construct and delver GRUUs to UAs that request them. This document summarizes for UA implementors how to obtain "public" GRUUs and gives guidance on effectively using public GRUUs. Table of Contents 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Feature Tag . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Requesting and Receiving a GRUU . . . . . . . . . . . . . . . 7 5. Using a GRUU . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Revision history . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 13 7.2. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. Normative References . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Worley Expires August 23, 2007 [Page 2] Internet-Draft Guidelines for GRUU Support February 2007 1. Background (This section is largely copied from an earlier version of [1].) The Session Initiation Protocol, RFC 3261 is used to establish and maintain a dialog between a pair of user agents in order to manage a communications session. Messages within the dialog are sent from one user agent to another using a series of proxy hops called the route set, eventually being delivered to the remote target - the user agent on the other side of the dialog. This remote target is identified by a SIP URI obtained from the value of the Contact header field in INVITE requests and responses. RFC 3261 mandates that a user agent populate the Contact header field in INVITE requests and responses with a URI that is global (meaning that it can be used from any element connected to the Internet), and that routes to the user agent which inserted it. RFC 3261 also mandates that this URI be valid for requests sent outside of the dialog in which the Contact URI was inserted. In practice, these requirements have proven very difficult to meet. Few endpoints have a hostname that is is present in DNS. Many endpoints have an IP address that is private because the user agent is behind a NAT. Techniques like the Simple Traversal of UDP Through NAT (STUN) can be used to obtain IP addresses on the public Internet. However, many firewalls will prohibit incoming SIP requests from reaching a user agent unless they first pass through a proxy sitting in the DMZ of the network. Thus URIs using STUN-obtained IP addresses often do not work. Because of these difficulties, most UAs have actually been inserting URIs into the Contact header field of requests and responses with the form sip:{IP-address}. These have the property of routing to the UA, but they are generally only reachable from the proxy to which the user is directly connected. This limitation does not prevent SIP calls to an Address-of-Record (AOR) from proceeding, since the user's proxy can usually reach these private addresses, and the proxy itself is generally reachable over the public network. However, this issue has adversely affected several other SIP mechanisms and applications. A number of important applications depend on contact URIs being globally routable, including call transfer (via REFER or INVITE with the Replaces header), conferencing, presence applications, and end- point call control (EPCC) features (call pick-up, call park, etc.). All of these applications require a user agent to present a URI that not only routes solely to that user agent, but is usable by other entities anywhere on the Internet as a target for further SIP Worley Expires August 23, 2007 [Page 3] Internet-Draft Guidelines for GRUU Support February 2007 requests. Many of these applications require that dialog event packages [8] can report globally routable contact URIs. The GRUU features proposed in [1] alleviate these problems by providing a method for UAs to obtain globally routable URIs from the registrars for the AORs they serve. At first sight, achieving this seems improbable, but of necessity (1) a proxy is globally routable from the Internet, and (2) a proxy knows how to reach any UA registered for an AOR in its domain. Together, these facts allow the proxy to construct URIs which globally route to it, and allow the proxy to forward requests to those URIs to the corresponding UAs. Because of the importance of the GRUU mechanism for implementing features that are of great practical value, this memo summarizes the requirements for a UA to support and exploit GRUUs as an aid to UA implementers. This memo is specialized for the commonest case, where a UA with one IP address services one or more AORs. Except for some tightening of optional behaviors, it is entirely derived from [1]. This document is not intended to advance toward standardization. However, if it proves valuable to implementors, it may evolve into a statement of best common practice. This document is revised to align with version 11 of the GRUU draft [1]. It does not address the use of "temporary GRUUs" to provide enhanced privacy; it only discusses use of "public GRUUs". Worley Expires August 23, 2007 [Page 4] Internet-Draft Guidelines for GRUU Support February 2007 2. Terminology A URI is said to be "globally routable" if it can be resolved using the standard rules for resolving SIP URIs [9] by any host on the public Internet to reach a proxy that knows how to route requests for that URI to their intended destination. A URI is a "user agent URI" if it routes to only one user agent, and if it continues to route to that user agent even if the UA changes its contact address. A URI is a "GRUU" if it is both globally routable and is a user agent URI. "GRUU" also refers to the SIP extension defined in [1], and to the GRUU URIs that UAs obtain via that extension. There are two types of GRUUs issued by proxies: "public GRUUs" which are intended to have an indefinite lifetime and manifest the AOR that they are associated with, and "temporary GRUUs" which are intended to be difficult to associate with their underlying AOR and to have a limited lifetime. The use of temporary GRUUs is outside the scope of this document. Worley Expires August 23, 2007 [Page 5] Internet-Draft Guidelines for GRUU Support February 2007 3. Feature Tag The feature tag for the GRUU extension is "gruu". Guideline 1: The UA should add "Supported: gruu" to its requests and responses, and accept "Require: gruu" in requests. Worley Expires August 23, 2007 [Page 6] Internet-Draft Guidelines for GRUU Support February 2007 4. Requesting and Receiving a GRUU GRUUs that are issued by proxies represent a combination of a specific user agent and a specific AOR. A UA can possess one (public) GRUU for each AOR that it services, and each UA that services a particular AOR will have a distinct GRUU for that AOR. Conceptually, GRUUs have an unlimited lifetime. When a GRUU's UA has a contact registered for the GRUU's AOR, the GRUU routes to that contact. Less commonly, a UA may have more than one contact for an AOR, in which case the GRUU can route to any of those contacts according to the policies in [1] and [7]. GRUUs are constructed by proxies by attaching the "gr" URI-parameter to the GRUU's AOR. The value of the "gr" parameter is determined by the proxy. Some examples of possible GRUUs are: sip:gruu~foo@example.com;gr=RWFjaCBVQSBpbnN sip:foo@example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 Guideline 2: Some UAs implement non-standard mechanisms for handling URIs that compensate for the fact that heretofore many contact URIs have not been globally routable. Since any URI containing the "gr" parameter is known to be globally routable, a UA should not apply such mechanisms to any URI containing the "gr" parameter. Guideline 3: All GRUUs exist both in the "sip" and the "sips" URI schemes, and UAs must be capable of processing both varieties of their GRUUs (to the extent that they are capable of processing any contact URIs in those schemes). Each UA is identified by an "instance ID". Guideline 4: Each UA instance has an "instance ID" which is globally unique through all space and time. An instance ID persists through all ordinary operations, especially restarting and changes in network connectivity. An instance ID is a URN [2]. URNs can be created and assigned by many mechanisms. For a network host that is a dedicated UA ("SIP phone"), it is recommended that it uses "version 1" of the UUID URN [3] (which contains the UA's MAC address) as an instance ID. Because the UA's instance ID is sent in its REGISTER requests, it makes it possible for the proxy to correlate the UA's contact URI with its MAC address, which in many environments is used as the UA's identifier for configuration and Worley Expires August 23, 2007 [Page 7] Internet-Draft Guidelines for GRUU Support February 2007 provisioning. Guideline 5: Hosts that are dedicated UAs should use as their instance IDs Version 1 of the UUID URN, which is derived from the MAC address of the UA's network interface [3]. Guideline 6: UAs that are not embodied in dedicated UA devices must generate their instance IDs in a manner that guarantees global uniqueness. (E.g., a more complex use of Version 1 UUIDs, a name-based UUID derived from a suitable identification string, or an object-id assigned administratively [4].) The "tel" namespace and similar namespaces should not be used, as conceptually they are AORs, not unique identifiers for swarms of user agents. Guideline 7: As other SIP agents may use the instance ID and/or GRUU as a key to cache information about the UA and its capabilities, it is recommended that when a new version of software is installed into the UA, the UA should obtain a new instance ID. (Do we really want to do that?) In principle, the registrar should compare an instance ID string with other instance ID strings using the proper comparison method for the URN scheme of the instance IDs, but in practice the UA cannot depend on the registrar knowing the proper comparison method for the URN scheme of its instance ID. Guideline 8: The UA should always use the same character string to represent its instance ID (e.g., normalizing the case of letters), even if the URN scheme permits several different character strings to represent the same URN. Guideline 9: A UA requests a GRUU for its instance ID and a particular AOR by extending its ordinary REGISTER requests for that AOR by: (1) adding a "Supported: gruu" header, and (2) adding an "instance" media feature tag to the Contact giving the UA's instance ID as its value. If the registrar understands the GRUU extension, it may (but is not guaranteed to): (3) append to the returned Contact the same "instance" media feature tag and/or a "pub-gruu" field parameter giving the assigned GRUU. Note that due to the format requirements for media feature tags [5], Worley Expires August 23, 2007 [Page 8] Internet-Draft Guidelines for GRUU Support February 2007 the syntax of the "instance" tag is a field parameter '+sip.instance="<{instance ID URN}>"'. As '<' cannot appear in a "token" [6], the value of the '+sip.instance' parameter must be quoted with '"'. The instance ID value itself must be contained between '<' and '>' due to the rules of [5]. In addition, due to the syntax of "quoted-string" in [6] and "qdtext-no-abkt" in [5], any occurrence of '"', '<', '>', or '\' in the instance ID must be quoted by preceding it with '\'. Using '\' to quote other characters, while allowed by [6], should be avoided to ensure unique representation of instance IDs. A typical registration request is: REGISTER sips:example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 Max-Forwards: 70 From: Callee ;tag=a73kszlfl To: Callee Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 CSeq: 1 REGISTER Contact: ;+sip.instance="" Supported: gruu Content-Length: 0 A possible response is: 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: ;gruu="sip:callee@example.com;gr=RWFjaCBVQSBpbnN" ;+sip.instance="" ;expires=3600 Supported: gruu Content-Length: 0 For obtaining GRUUs, the contact URI is treated nearly opaquely. The contact URI can even be a GRUU itself, if that is what is appropriate for the application. (But the contact URI must not be a GRUU for the AOR for which it is being registered, as that would guarantee a routing loop. The registrar is required to reject such registrations with a 403 response.) Worley Expires August 23, 2007 [Page 9] Internet-Draft Guidelines for GRUU Support February 2007 Guideline 10: The UA should not attempt to recommend a GRUU to the registrar (by providing a "gr", "pub-gruu", or "temp- gruu" field parameter on the Contact header in the request). The registrar constructs the GRUU by appending a "gr" parameter that it chooses. However, for robustness: Guideline 11: The GRUU should be treated opaquely by the UA. The proxy should construct GRUUs in a way that ensures that every time a registration is done for a particular AOR with a particular instance ID, the same GRUU will be returned. But as it is impossible to guarantee this behavior, a UA should be prepared for the returned GRUU to change. Guideline 12: If a REGISTER returns a new GRUU for an AOR/instance ID combination, the UA must use the new GRUU. The GRUU will be returned with the "sip" or "sips" scheme as specified in the registered AOR (in the To header). Nonetheless, registration associates both versions of the GRUU with the contact address and each version will route to the contact address using its scheme. As detailed below, when responding to requests, the UA should use as its contact URI the GRUU associated with the AOR through which the request was routed to the UA. The request-URI is almost never this AOR, of course. And the From header cannot be depended upon to supply the AOR, as the From header may contain a URI that routed to the AOR in a complex way. Guideline 13: The UA should register distinct contact URIs for each AOR it services, so that incoming request-URIs uniquely identify the AOR through which the request was routed. Note that it is not a sufficient policy to generate from each AOR a contact 'sips:{user-part}@ {IP-address}', since it is common for a UA to service two AORs with the same user part but different host parts. One common method to construct multiple contact addresses is to use the "line" URI-parameter to apply a unique value to what would otherwise be identical contact URIs. Worley Expires August 23, 2007 [Page 10] Internet-Draft Guidelines for GRUU Support February 2007 5. Using a GRUU Since the GRUU is routable by the ordinary SIP mechanisms, the GRUU may be used just like any other SIP URI. But to gain the benefits of GRUUs, the UA needs to use GRUUs in particular ways. For ordinary requests and responses, that is, those that would in the absence of GRUUs be made using pre-existing contact addresses, the rules only involve identifying the correct GRUU to use in each circumstance: Guideline 14: When making an out-of-dialog request, the UA should use as Contact the GRUU corresponding to the AOR that it places in the To header. Guideline 15: When responding to an out-of-dialog request, the UA should determine, based on the request-URI, the AOR through which the request was routed, and use as Contact the GRUU corresponding to that AOR. Non-target-refresh in-dialog requests and responses will use the existing route set, so their Contacts will automatically adhere to these guidelines. Guideline 16: If a Contact value is a GRUU, target refresh requests will not change it, because the routing changes that would be otherwise be effected by modifying the target URI are effected by the proxy modifying how it routes requests addressed to the GRUU. [1] [7] Worley Expires August 23, 2007 [Page 11] Internet-Draft Guidelines for GRUU Support February 2007 6. Security Considerations As stated in [1]: Guideline 17: 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 to the UA. As a result, it is RECOMMENDED that a UA use the SIPS URI scheme in the Request-URI when registering. Proxies and registrars MUST support the sips URI and MUST support TLS. Note that this does not represent a change from the requirements in RFC 3261. UAs' instance IDs and GRUUs are not hidden from the public. This does not present a security risk, as an instance ID is not authentication credentials. But it does represent a reduction in privacy, as instance IDs and GRUUs may be more specific or more persistent over time than AORs and the IP-based URIs that have previously been used as contact URIs. Guideline 18: Since GRUUs are publicly visible, any screening of unwanted communications which is applied to an AOR must be applied to its GRUUs. In addition, since an AOR's forking may be used to implicitly screen requests for one of its targets, it may be desirable to apply additional screening for requests to a GRUU for such an AOR. If the user of the UA desires a degree of anonymity, the UA should use the "temporary GRUU" mechanism, rather than the "global GRUU" mechanism described here. [1] Worley Expires August 23, 2007 [Page 12] Internet-Draft Guidelines for GRUU Support February 2007 7. Revision history 7.1. Changes from -00 to -01 Replace reference to draft-ietf-sip-gruu-05.txt with draft-ietf-sip-gruu-06.txt. Add a statement regarding the intended future of this draft. Made allowances for UAs that cannot process one of the "sip" or "sips" URI schemes. Number the guidelines for ease of reference. Promote some statements from commentary to guidelines. Relax the requirements on Supported and Require headers per changes in the GRUU I-D. Various edits to improve clarity. Removed the section "Avoiding routing circularity", which dealt with the "edge router problem". This is per (1) revised solutions to the edge router problem to appear in the GRUU I-D, and (2) the observation by Rohan Mahy that in complex networks without global routability, the burden should be placed on the routers, as they are aware of the network topology, rather than the end devices, which would otherwise have to be capable of dealing with all such network topologies. Clarify that more than one contact may be associated with a GRUU, per the latest GRUU I-D. Added "Security Considerations" section. Show REGISTER examples using sips: URIs, to conform with the security recommendations. 7.2. Changes from -01 to -02 Replace reference to draft-ietf-sip-gruu-06.txt with draft-ietf-sip-gruu-09.txt. Correct reference to RFC 3261. Moved "Revision History" below "Security Considerations". Use to number the guidelines automatically. Worley Expires August 23, 2007 [Page 13] Internet-Draft Guidelines for GRUU Support February 2007 Use the current definition of "opaque" and "gruu" URI-parameters. Note that non-standard mechanisms to cope with non-global-routability should not be applied to URIs with "gruu" parameter. Revised discussion of Require and Supported headers to the current usage. Added discussion that the contact URI can itself be a GRUU. Removed requirement that UA recognize its GRUUs as request-URIs or Route values, as this circumstance should not be seen now. Update discussion of "grid" parameter. Split Using a GRUU section into several sections. Marked advice in Security Considerations section as guidelines. Updated contact information. Added references to RFC 3263 [9], RFC 4235 [8], and sip-outbound [7]. Separated into its own guideline advice that a UA should change instance IDs when its software is updated. Added question as to whether this is a good idea. Detailed that target refresh requests will not modify a GRUU target because such routing changes are done by modifying how the proxy routes to the GRUU. State that the UA must provide a value for the grid parameter. Update reference to version 11 (draft-ietf-sip-gruu-11). Update to match version 11, especially using the term "public GRUU", ensuring the AOR is visible in public GRUUs, and using the new parameter names. Add guideline about what to do if the GRUU returned by a REGISTER changes. Delete the "grid" URI-parameter. Delete the discussion of call processing in re calls directed to GRUUs, as call processing is expected to be done at the proxy. Call processing done at the UA is expected to be done in the same way as to requests made to the AOR or contact address. Worley Expires August 23, 2007 [Page 14] Internet-Draft Guidelines for GRUU Support February 2007 8. Acknowledgements The author would like to thank Michael Procter for his comments and contributions to this work. Worley Expires August 23, 2007 [Page 15] Internet-Draft Guidelines for GRUU Support February 2007 9. Normative References [1] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", draft-ietf-sip-gruu-11 (work in progress), October 2006. [2] Moats, R., "URN Syntax", RFC 2141, May 1997. [3] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005. [4] Mealling, M., "A URN Namespace of Object Identifiers", RFC 4122, February 2001. [5] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004. [6] 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. [7] Jennings, C. and R. Mahy, "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", draft-ietf-sip-outbound-07 (work in progress), January 2007. [8] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005. [9] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. Worley Expires August 23, 2007 [Page 16] Internet-Draft Guidelines for GRUU Support February 2007 Author's Address Dale R. Worley Pingtel Corp. 400 West Cummings Park, Suite 2200 Woburn, MA 01801 US Phone: +1 781 938 5306 x173 Email: dworley@pingtel.com URI: http://www.pingtel.com Worley Expires August 23, 2007 [Page 17] Internet-Draft Guidelines for GRUU Support February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Worley Expires August 23, 2007 [Page 18]