SIPPING Working Group G. Camarillo Internet-Draft G. Blanco Expires: August 12, 2005 Ericsson February 11, 2005 The Session Initiation Protocol (SIP) P-User-Database Private-Header (P-Header) draft-camarillo-sipping-user-database-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 12, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document specifies the SIP P-User-Database P-header. This header field is used in the 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) to provide SIP registrars and SIP proxy servers with the address of the database that contains the user profile of the user that generated a particular request. Camarillo & Blanco Expires August 12, 2005 [Page 1] Internet-Draft INVITE-Contained Lists February 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1 User Registering to the IMS . . . . . . . . . . . . . . . 3 3.2 Incoming Request for an Unregistered User . . . . . . . . 4 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. P-User-Database header field Definition . . . . . . . . . . . 5 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 7 10.2 Informational References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . 8 Camarillo & Blanco Expires August 12, 2005 [Page 2] Internet-Draft INVITE-Contained Lists February 2005 1. Introduction The 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) uses SIP [3] as its main signalling protocol. 3GPP has identified a set of requirements that can be met, according to the procedures in RFC 3427 [4], by defining a new SIP P-header. The remainder of this document is organized as follows. Section 2 defines the terminology used in this document. Section 3 describes the scenarios considered by 3GPP and Section 4 discusses the requirements derived from these scenarios. Section 5 defines the P-User-Database header field, which meets those requirements, and Section 6 discusses the applicability and scope of this new header field. Section 7 registers the P-User-Database header field and a related parameter and Section 8 discusses the security properties of the environment where this header field is intended to be used. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations. 3. Scenarios In the 3GPP IMS, there are two scenarios where a set of proxies handling a request need to consult the same user database. These scenarios consist of a user registering to the IMS network and an unregistered user receiving an incoming request that triggers a service (e.g., a voice mail service). 3.1 User Registering to the IMS In the 3GPP IMS, SIP REGISTER requests generated by a UA (User Agent) traverse a set of SIP proxy servers before reaching the SIP registrar. A REGISTER request sent by a UA is routed to the outbound proxy of the UA, which is referred to as the P-CSCF (Proxy-Call/ Session Control Function). The P-CSCF routes the REGISTER request to another proxy, which is always located in the home domain of the user, which is referred to as the I-CSCF (Interrogating-CSCF). The I-CSCF consults the user database of the domain, which is referred to as the HSS (Home Subscriber Server), in order to choose the registrar that will process the REGISTER request. Camarillo & Blanco Expires August 12, 2005 [Page 3] Internet-Draft INVITE-Contained Lists February 2005 With the information received from the HSS, the I-CSCF routes the REGISTER request to the appropriate registrar, which is referred to as the S-CSCF (Serving-CSCF). At this point, the S-CSCF needs to contact the same HSS that was previously contacted by the I-CSCF in order to fetch the user profile of the user that generated the REGISTER request. The interface between the I-CSCF and the HSS and between the S-CSCF and the HSS is called Cx interface, and it is based on Diameter [5]. When there is a single HSS (i.e., user database) handling all the users in the domain, both the I-CSCF and the S-CSCF can be configured with its address so that they contact it when necessary. However, some domains have several HSSs, each of which handles a particular set of users. When dealing with a REGISTER request, the I-CSCF and the S-CSCF need to discover which is the HSS that contains the profile of user that generated the REGISTER request. In networks with more than one HSS, a Diameter redirect agent referred to as SLF (Subscription Locator Function) is implemented. The interface between the I-CSCF and the SLF and between the S-CSCF and the SLF is called Dx interface and, like the CX interface, is based on Diameter. The SLF provides the I-CSCF and the S-CSCF with the address of the HSS that handles the user they are dealing with. Therefore, in a network with more than one HSS, the SLF is consulted twice per REGISTER request. First by the I-CSCF, and later by the S-CSCF. If the I-CSCF could provide the S-CSCF with the address of the HSS handling the user that generated the REGISTER request, the S-CSCF could contact directly that HSS. That is, the S-CSCF would not need to contact the SLF in order to obtain the address of the HSS. 3.2 Incoming Request for an Unregistered User In the 3GPP IMS, incoming requests for a user traverse an I-CSCF in the home domain of the user. This I-CSCF consults the HSS, using the Diameter-based Cx interface, in order to decide which S-CSCF should handle the request. After consulting the HSS, the I-CSCF forwards the request to a S-CSCF, which is also located in the home domain of the user. If the user the request is addressed to is registered to the IMS network, the S-CSCF receiving the request knows which HSS handles the user. The S-CSCF stored this information when the user registered. However, if the user is not registered, the S-CSCF needs to consult the SLF (assuming more than one HSS in the network) in order to discover the HSS handling the user. Camarillo & Blanco Expires August 12, 2005 [Page 4] Internet-Draft INVITE-Contained Lists February 2005 Therefore, like in the previous scenario, in a network with more than one HSS, the SLF is consulted twice per incoming request addresses to an unregistered user. First by the I-CSCF, and later by the S-CSCF. If the I-CSCF could provide the S-CSCF with the address of the HSS handling the user that generated the request, the S-CSCF could contact directly that HSS. That is, the S-CSCF would not need to contact the SLF in order to obtain the address of the HSS. 4. Requirements This section lists the requirements derived from the previous scenarios: 1. It is necessary to optimize the registration process in the 3GPP IMS by reducing the time it takes for a UA to register to the IMS network. 2. It is necessary to optimize the handling of incoming requests to unregistered users in the 3GPP IMS by reducing the time it takes for a domain to handle these requests. 3. It is necessary to improve the scalability of SLFs in the 3GPP IMS by reducing the amount of traffic the SLF of a network needs to handle. 5. P-User-Database header field Definition This document defines the SIP P-User-Database P-header. This header field can be added to requests routed from an I-CSCF to a S-CSCF. The P-User-Database P-header contains the address of the HSS handling the user that generated the request. The augmented Backus-Naur Form (BNF) [2] syntax of the P-User-Database header field is the following (some of the definitions are taken from RFC 3261 [3]): P-User-Database = "P-User-Database" HCOLON user-database-host *( SEMI user-database-param ) user-database-host = host user-database-param = user-database-realm / generic-param user-database-realm = "realm" EQUAL hostname 6. Applicability According to RFC 3427 [4], P-headers have a limited applicability. Specifications on P-headers such as this document need to clearly document the useful scope of the proposal, and explain its Camarillo & Blanco Expires August 12, 2005 [Page 5] Internet-Draft INVITE-Contained Lists February 2005 limitations and why it is not suitable for the general use of SIP on the Internet. The P-User-Database header field is intended to be used in 3GPP IMS networks. This header field carries the HSS's host and, optionally, the HSS's realm between an I-CSCF and a S-CSCF. When SIP is used on the Internet, there are typically no proxies querying a user database between the UA sending a REGISTER request and the registrar. Consequently, the P-User-Database header field does not seem useful in a general Internet environment. 7. IANA Considerations This document defines a new SIP header field: P-User-Database. This header field needs to be registered by the IANA in the SIP Parameters registry under the Header Fields subregistry. This document defines a parameter for the P-User-Database header field: realm. This header field parameter needs to be registered by the IANA in the "SIP/SIPS URI Parameters" subregistry, which is located under the "Session Initiation Protocol (SIP) Parameters" registry. The reference should appear in single-brackets, as indicated in RFC 3969 [6]. The resulting entry should be: Parameter Name Predefined Values Reference -------------- ----------------- --------- realm No [RFCxxxx] 8. Security Considerations The P-User-Database defined in this document is to be used in an environment where elements are trusted and where attackers are not supposed to have access to the protocol messages between those elements. Traffic protection between network elements is sometimes achieved by using IPsec and sometimes by physically protecting the network. In any case, the environment where the P-User-Database header field will be used ensures the integrity and the confidentiality of the contents of this header field. 9. Acknowledgements Nuria Esteban and Stephen Terrill provided comments on this document. Camarillo & Blanco Expires August 12, 2005 [Page 6] Internet-Draft INVITE-Contained Lists February 2005 10. References 10.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [3] 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. [4] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J. and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, December 2002. [5] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [6] 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. 10.2 Informational References Authors' Addresses Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland EMail: Gonzalo.Camarillo@ericsson.com German Blanco Ericsson Via de los Poblados 13 Madrid 28035 Spain EMail: german.blanco@ericsson.com Camarillo & Blanco Expires August 12, 2005 [Page 7] Internet-Draft INVITE-Contained Lists February 2005 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Camarillo & Blanco Expires August 12, 2005 [Page 8]