SIP J. Rosenberg Internet-Draft dynamicsoft Expires: April 19, 2004 October 20, 2003 Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP) draft-rosenberg-sip-gruu-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 April 19, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. 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 call to that specific UA instance. A URI which 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 server, and for communicating a GRUU to a peer within a dialog. Rosenberg Expires April 19, 2004 [Page 1] Internet-Draft GRUU Mechanism October 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview of Operation . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 4. User Agent Behavior . . . . . . . . . . . . . . . . . . . . 4 4.1 REGISTER Processing . . . . . . . . . . . . . . . . . . . . 4 4.2 Using the GRUU . . . . . . . . . . . . . . . . . . . . . . . 4 5. Registrar Behavior . . . . . . . . . . . . . . . . . . . . . 5 6. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 7 7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . 11 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 10.1 Header Field Parameter . . . . . . . . . . . . . . . . . . . 12 10.2 URI Parameter . . . . . . . . . . . . . . . . . . . . . . . 12 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 Normative References . . . . . . . . . . . . . . . . . . . . 12 Informative References . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . 14 Rosenberg Expires April 19, 2004 [Page 2] Internet-Draft GRUU Mechanism October 2003 1. Introduction Several applications of the Session Initiation Protocol (SIP) [1] require a user agent (UA) to construct and distribute a URI which can be used by anyone on the Internet to route a call to that specific UA instance. An example of such an application is call transfer, based on the REFER method [4]. Another application is the usage of endpoint-hosted conferences within the conferencing framework [7]. We call these URIs Globally Routable UA URIs (GRUU). Requirements [8] have been defined which identify the capabilities that any mechanism for obtaining and using a GRUU has to provide. This specification describes a mechanism that meets these requirements. 2. Overview of Operation This section is tutorial in nature, and does not specify any normative behavior. This extension allows a UA to obtain a GRUU, and to use a GRUU. These two mechanisms are separate, in that a UA can obtain a GRUU in any way it likes, and use the mechanisms in this specification to use them. Similarly, a UA can obtain a GRUU but never use it. A UA can obtain a GRUU by generating a normal REGISTER request, as specified in RFC 3261 [1]. This request contains a Supported header field with the value "gruu", indicating to the registrar that the UA supports this extension. If the domain that the user is registering against also supports GRUU, the REGISTER responses will contain the "gruu" parameter in each Contact header field. This parameter contains a GRUU which the domain guarantees will route to that specific Contact URI. Since the GRUU is a URI like any other, it can be handed out by a UA by placing it in any header field which can contain a GRUU. A UA will normally place the GRUU into the Contact header field of dialog creating requests and responses it generates. However, it is important for the UA receiving the message to know whether the Contact URI is a GRUU or not. To make this determination, the UA looks for the presence of the Supported header field in the request or response. If it is present with a value of "gruu", it means that the Contact URI is a GRUU. When a UA uses a GRUU, it has the option of adding the "grid" URI parameter to the GRUU. This parameter is opaque to the proxy server handling the domain. However, when the server maps the GRUU to the corresponding Contact URI, the server will copy the grid parameter into the Contact URI. As a result, when the UA receives the request, the Request URI will contain the grid parameter it placed in the Rosenberg Expires April 19, 2004 [Page 3] Internet-Draft GRUU Mechanism October 2003 corresponding GRUU. 3. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and indicate requirement levels for compliant implementations. 4. User Agent Behavior User agent behavior is divided into two separate parts - REGISTER processing, and GRUU usage. 4.1 REGISTER Processing When a UA wishes to obtain a GRUU within the domain of its AOR, when it 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. Besides the presence of this option tag in the Supported header field, the REGISTER request is constructed identically to the case where this extension was not understood. Specifically, the Contact URI in the REGISTER request SHOULD NOT contain the gruu Contact header field parameter. If a UA wishes to guarantee that the 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. If the response is a 2xx, each Contact header field may contain a "gruu" parameter. This parameter contains a SIP URI that represents a GRUU corresponding to that Contact URI. Any requests sent to the GRUU URI will be routed by the domain to the Contact URI. 4.2 Using the GRUU A UA first obtains a GRUU. It can do this using the procedures of Section 4.1, or, in cases where the UA is certain that it can locally construct a URI meeting the properties of Section 4.1, it can construct one using its own IP address or host name as the domain part. However, local construction of a GRUU is NOT RECOMMENDED, since it is hard for a UA to generally know whether its IP address is globally routable. Rosenberg Expires April 19, 2004 [Page 4] Internet-Draft GRUU Mechanism October 2003 OPEN ISSUE: Another option is to use session independent policies [9] to inform a UA about whether it needs to obtain a GRUU from the provider, or whether it is safe to try and construct one on its own. It may still be hard for the provider to determine whether or not the UA can use a locally generated GRUU. A UA can use the GRUU in the same way it would use any other SIP URI. However, a UA compliant to this specification MUST use a GRUU when populating the Contact header field of dialog-creating requests and responses. This includes the INVITE request and its 2xx response, the SUBSCRIBE [3] request, its 2xx response, and the NOTIFY request, and the REFER [4] request and its 2xx response. Similarly, in those requests and responses where the GRUU is used in the Contact header field, the UA MUST include a Supported header field that contains the option tag "gruu". However, it is not necessary for a UA to know whether or not its peer in the dialog uses a GRUU before inserting one into the Contact header field. When placing a GRUU into the Contact header field of a request or response, a UA MAY add the "grid" URI parameter to the GRUU. This parameter MAY take on any value permitted by the grammar for the parameter, but MUST NOT exceed 128 characters. When a UA sends a request to the GRUU, the proxy for the domain that owns the GRUU will copy this parameter from the GRUU into the Contact URI matching that GRUU. This allows the UA to effectively manufacture an infinite supply of GRUU, each of which differs by the value of the "grid" parameter. When a UA receives a request that was sent to the GRUU, it will be able to tell which GRUU was invoked by the "grid" parameter. When a UA (UA 1) wishes to generate a request to another UA, UA 2, and UA 1 and UA 2 are involved in an active dialog, and the request is not associated with the existing dialog, and UA 2 indicated support for this extension, UA 1 SHOULD send the request to the remote target URI if UA 2. Examples of such requests are SUBSCRIBE and REFER. Currently, RFC 3261 describes the notion of dialog sharing, which would advocate generation of these requests within the context of the existing dialog. This specification supercedes that behavior. In cases where UA 1 wishes to send the request, but UA 2 has not indicated support for GRUU, UA 1 SHOULD send the request on the existing dialog. 5. Registrar Behavior When a registrar compliant to this specification receives a REGISTER request, it checks for the presence of the Require header field in the request. If present, and if it contains the "gruu" option tag, the registrar MUST follow the procedures in the next paragraph for inclusion of the "gruu" parameter in a 2xx response to REGISTER. If Rosenberg Expires April 19, 2004 [Page 5] Internet-Draft GRUU Mechanism October 2003 not present, but a Supported header field was present with the "gruu" option tag, the registrar SHOULD follow the procedures in the next paragraph for inclusion of the "gruu" parameter in a 2xx response to REGISTER. If the Supported header field was not present, or it if was present but did not contain the value "gruu", the registrar SHOULD NOT follow the procedures of the next paragraph for inclusion of the "gruu" parameter in a 2xx response to REGISTER. When the registrar generates a 2xx response to the REGISTER request, if it wishes to provide a GRUU to the UA, it includes a "gruu" Contact header field parameter for each value of the Contact header field. The value of this parameter is a quoted string containing the URI that is the GRUU for the associated Contact URI. This specification does not mandate a particular mechanism for construction of the GRUU. However, the GRUU 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 host name, exists in the global DNS and corresponds to an IP address present on the public Internet. o When a request is sent to this URI, it routes to a proxy server in the same domain as that of the registrar. o A proxy server in the domain can determine that the URI is a GRUU. o When a proxy server in this domain translates this URI, the result is equal to the Contact URI corresponding to the GRUU. o It MUST NOT be possible, based on inspection of the URI, to determine the associated Contact URI or Address of Record. One mechanism for constructing this GRUU is to set the user part of the URI in the following fashion: user-part = "GRUU" + BASE64(E(K, (salt + Contact URI + AOR))) Where E(K,X) represents a suitable encryption function with key K applied to data block X, and the "+" operator implies concatenation. Salt represents a random string that prevents a client from obtaining pairs of known plaintext and ciphertext. The benefit of this mechanism is that a server need not store additional information on mapping a GRUU to its corresponding Contact URI. The user part of the GRUU can itself contain the Contact URI. Encryption is needed to prevent attacks whereby the server is sent requests with faked GRUU, causing the server to direct requests to any named URI. Rosenberg Expires April 19, 2004 [Page 6] Internet-Draft GRUU Mechanism October 2003 OPEN ISSUE: Need some more work on the details of the encryption. Probably we want to recommend rotating the key. Do we also need a signature? 6. Proxy Behavior When a proxy server receives a request, and the proxy owns the domain in the Request URI, and the proxy 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 MUST check if the Request URI is a GRUU created by that domain. If the URI is a GRUU, the proxy MUST determine if the Contact URI associated with the GRUU is still registered to the AOR it was registered to when the GRUU was constructed. If that AOR no longer has any registered contacts, or if it does have registered contacts, but none of them equal the Contact URI associated with the GRUU, the proxy MUST generate a 404 (Not Found) response to the request. Otherwise, the proxy MUST populate the target set with a single URI. This URI MUST be equal to the Contact URI associated with that GRUU. Furthermore, if the GRUU contained a "grid" URI parameter, the URI in the target set MUST also contain the same parameter with the same value. A proxy MAY apply other processing to the request, such as execution of called party features. In particular, it is RECOMMENDED that non-routing called party features, such as call logging and screening, that are associated with the AOR are also applied to requests for the GRUU. In many cases, a proxy will record-route an initial INVITE request, and the user agents will insert a GRUU into the Contact header field. When this happens, a mid-dialog request will arrive at the proxy with a Route header field that was inserted by the proxy, and a Request-URI that represents a GRUU. Proxies follow normal processing this this case; they will strip the Route header field, and then process the Request URI as described above. The procedures of RFC 3261 are then followed to proxy the request. OPEN ISSUE: Do we allow redirects on a GRUU? Could be bad, if the problem was firewall/NAT traversal in the first place. Rosenberg Expires April 19, 2004 [Page 7] Internet-Draft GRUU Mechanism October 2003 7. Grammar This specification defines a new Contact header field parameter, gruu, and a new URI parameter, grid. contact-params = c-p-q / c-p-expires / c-p-gruu / contact-extension c-p-gruu = "gruu" EQUAL SWS DQUOTE SIP-URI DQUOTE uri-parameter = transport-param / user-param / method-param / ttl-param / maddr-param / lr-param / grid-param / other-param grid-param = "grid=" pvalue 8. Examples The following call flow shows a basic registration and call setup, followed by a subscription directed to the GRUU. Rosenberg Expires April 19, 2004 [Page 8] Internet-Draft GRUU Mechanism October 2003 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 | | |-------------------->| 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 client.example.com;branch=z9hG4bKnashds7 Max-Forwards: 70 From: Callee ;tag=a73kszlfl Supported: gruu To: Callee Call-ID: 1j9FpLxk3uxtm8tn@client.example.com CSeq: 1 REGISTER Contact: Content-Length: 0 Rosenberg Expires April 19, 2004 [Page 9] Internet-Draft GRUU Mechanism October 2003 The REGISTER response would look like: SIP/2.0 200 OK Via: SIP/2.0/UDP client.example.com;branch=z9hG4bKnashds7 From: Callee ;tag=a73kszlfl To: Callee ;tag=b88sn Call-ID: 1j9FpLxk3uxtm8tn@client.example.com CSeq: 1 REGISTER Contact: ;gruu="sip:hha9s8d=-999a@example.com" Content-Length: 0 Note how the Contact header field in the REGISTER response contains the gruu parameter with the URI sip:hha9s8d=-999a@example.com. This represents a GRUU associated with the Contact URI sip:callee@client.example.com. The INVITE from the caller is a normal SIP INVITE. The 200 OK generated by the callee, however, now contains a GRUU in the Contact header field. The UA has also chosen to include a grid URI parameter into the GRUU. 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 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 [10] at that specific UA. To do that, it generates a SUBSCRIBE request (message 9), but directs it towards the GRUU contained in the Contact header field. Rosenberg Expires April 19, 2004 [Page 10] Internet-Draft GRUU Mechanism October 2003 SUBSCRIBE sip:hha9s8d=-999a@example.com;grid=99a SIP/2.0 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK9zz8 From: Caller ;tag=kkaz- To: Callee Call-ID: faif9a@host.example.com CSeq: 2 SUBSCRIBE Supported: gruu Event: dialog Allow: INVITE, OPTIONS, CANCEL, BYE, ACK Contact: Content-Length: 0 In this example, the caller itself supports the GRUU extension, and is using its own GRUU to populate the Contact header field of the SUBSCRIBE. This request is routed to the proxy, which proceeds to perform a location lookup on the request URI. It is translated into the Contact URI bound to that GRUU, and then proxied there (message 10). Note how the grid parameter is maintained. SUBSCRIBE sip:callee@client.example.com;grid=99a 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: Callee Call-ID: faif9a@host.example.com CSeq: 2 SUBSCRIBE Supported: gruu Event: dialog Allow: INVITE, OPTIONS, CANCEL, BYE, ACK Contact: Content-Length: 0 9. Security Considerations Users interested in anonymity can make use of GRUUs. Since GRUUs do not reveal information about the identity of the associated address-of-record or Contact URI, they provide routability without identity. It is important for a UA to be assured of the integrity of a GRUU when it is given one 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 when registering. Rosenberg Expires April 19, 2004 [Page 11] Internet-Draft GRUU Mechanism October 2003 10. IANA Considerations This specification defines a new Contact header field parameter and URI parameter. 10.1 Header Field Parameter This specification defines a new header field parameter, as per the registry created by [5]. The required information is as follows: Header field in which the parameter can appear: Contact Name of the Parameter gruu RFC Reference RFC XXXX [[NOTE TO IANA: Please replace XXXX with the RFC number of this specification.]] 10.2 URI Parameter This specification defines a new SIP URI parameter, as per the registry created by [6]. Name of the Parameter grid RFC Reference RFC XXXX [[NOTE TO IANA: Please replace XXXX with the RFC number of this specification.]] 11. Acknowledgements The author would like to thank Rohan Mahy, Paul Kyzivat, Alan Johnston, and Cullen Jennings for their contributions to this work. 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] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [4] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. Rosenberg Expires April 19, 2004 [Page 12] Internet-Draft GRUU Mechanism October 2003 [5] Camarillo, G., "The Internet Assigned Number Authority Header Field Parameter Registry for the Session Initiation Protocol", draft-ietf-sip-parameter-registry-00 (work in progress), August 2003. [6] Camarillo, G., "The Internet Assigned Number Authority Universal Resource Identifier Parameter Registry for the Session Initiation Protocol", draft-ietf-sip-uri-parameter-reg-00 (work in progress), August 2003. Informative References [7] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol", draft-ietf-sipping-conferencing-framework-00 (work in progress), May 2003. [8] Rosenberg, J., "Requirements for Construction and Usage of Globally Routable User Agent (UA) URIs for the Session Initiation Protocol (SIP)", draft-rosenberg-sipping-gruu-reqs-00 (work in progress), July 2003. [9] Hilt, V., Camarillo, G. and J. Rosenberg, "A Framework for Session-Independent Intermediary Session Policies in SIP", draft-hilt-sipping-session-indep-policy-00 (work in progress), October 2003. [10] Rosenberg, J. and H. Schulzrinne, "An INVITE Inititiated Dialog Event Package for the Session Initiation Protocol (SIP", draft-ietf-sipping-dialog-package-02 (work in progress), July 2003. Author's Address Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054 US Phone: +1 973 952-5000 EMail: jdrosen@dynamicsoft.com URI: http://www.jdrosen.net Rosenberg Expires April 19, 2004 [Page 13] Internet-Draft GRUU Mechanism October 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Rosenberg Expires April 19, 2004 [Page 14] Internet-Draft GRUU Mechanism October 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Rosenberg Expires April 19, 2004 [Page 15]