summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4457.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4457.txt')
-rw-r--r--doc/rfc/rfc4457.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc4457.txt b/doc/rfc/rfc4457.txt
new file mode 100644
index 0000000..988be9e
--- /dev/null
+++ b/doc/rfc/rfc4457.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group G. Camarillo
+Request for Comments: 4457 G. Blanco
+Category: Informational Ericsson
+ April 2006
+
+
+ The Session Initiation Protocol (SIP)
+ P-User-Database Private-Header (P-Header)
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document specifies the Session Initiation Protocol (SIP)
+ P-User-Database Private-Header (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.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Scenarios .......................................................2
+ 2.1. User Registering to the IMS ................................2
+ 2.2. Incoming Request for an Unregistered User ..................3
+ 3. Requirements ....................................................4
+ 4. P-User-Database Header Field Definition .........................4
+ 5. Applicability ...................................................5
+ 6. IANA Considerations .............................................5
+ 7. Security Considerations .........................................5
+ 8. Acknowledgements ................................................6
+ 9. References ......................................................6
+ 9.1. Normative References .......................................6
+ 9.2. Informative References .....................................6
+
+
+
+
+
+
+
+
+Camarillo & Blanco Informational [Page 1]
+
+RFC 4457 The P-User-Database P-Header April 2006
+
+
+1. Introduction
+
+ The 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia
+ Subsystem) uses the Session Initiation Protocol (SIP) [2] as its main
+ signalling protocol. (For more information on the IMS, a detailed
+ description can be found in 3GPP TS 23.228 [5] and 3GPP TS 24.229
+ [6].) 3GPP has identified a set of requirements that can be met,
+ according to the procedures in RFC 3427 [3], by defining a new SIP
+ Private-Header (P-header).
+
+ The remainder of this document is organized as follows. Section 2
+ describes the scenarios considered by 3GPP and Section 3 discusses
+ the requirements derived from these scenarios. Section 4 defines the
+ P-User-Database header field, which meets those requirements, and
+ Section 5 discusses the applicability and scope of this new header
+ field. Section 6 registers the P-User-Database header field with the
+ IANA and Section 7 discusses the security properties of the
+ environment where this header field is intended to be used.
+
+2. 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).
+
+2.1. User Registering to the IMS
+
+ In the 3GPP IMS, SIP REGISTER requests generated by a User Agent (UA)
+ 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
+ referred to as the I-CSCF (Interrogating-CSCF) and is always located
+ in the home domain of the user. The I-CSCF consults the user
+ database of the domain, which is referred to as the Home Subscriber
+ Server (HSS), in order to choose the registrar that will process the
+ REGISTER request.
+
+ 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.
+
+
+
+Camarillo & Blanco Informational [Page 2]
+
+RFC 4457 The P-User-Database P-Header April 2006
+
+
+ The interface between the I-CSCF and the HSS and between the S-CSCF
+ and the HSS is called Cx interface and is based on Diameter [4].
+
+ 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 the user that generated the REGISTER request.
+
+ In networks with more than one HSS, a Diameter redirect agent
+ referred to as the Subscription Locator Function (SLF) 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.
+
+2.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 Informational [Page 3]
+
+RFC 4457 The P-User-Database P-Header April 2006
+
+
+ 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.
+
+3. 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.
+
+4. 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 an 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) [1] syntax of the P-User-
+ Database header field is the following:
+
+ P-User-Database = "P-User-Database" HCOLON database
+ *( SEMI generic-param )
+ database = LAQUOT DiameterURI RAQUOT
+
+ DiameterURI is defined in RFC 3588 [4]. HCOLON, LAQUOT, RAQUOT, and
+ generic-param are defined in RFC 3261 [2].
+
+ The following is an example of a P-User-Database header field:
+
+ P-User-Database: <aaa://host.example.com;transport=tcp>
+
+
+
+
+
+
+Camarillo & Blanco Informational [Page 4]
+
+RFC 4457 The P-User-Database P-Header April 2006
+
+
+5. Applicability
+
+ According to RFC 3427 [3], P-headers have a limited applicability.
+ Specifications of P-headers such as this RFC need to clearly document
+ the useful scope of the proposal, and explain its 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 address of a user database,
+ which is referred to as HSS, between two proxies, which are referred
+ to as I-CSCF and S-CSCF. The I-CSCF and the S-CSCF belong to the
+ same administrative domain and share a common frame of reference to
+ the user database. The I-CSCF inserts the P-User-Database header
+ field into a SIP request and the S-CSCF removes it before routing the
+ request further.
+
+ 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.
+
+6. IANA Considerations
+
+ This document defines a new SIP header field: P-User-Database. This
+ header field has been registered by the IANA in the SIP Parameters
+ registry under the Header Fields subregistry.
+
+7. 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 IP Security (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.
+
+ There is a slight security risk if a P-User-Database header field is
+ allowed to propagate out of the administrative domain where it was
+ generated. No user-sensitive information would be revealed by such a
+ breach, but this could result in disclosure of information about the
+ topology of the operator network that goes beyond the level of
+ disclosure explicit in SIP messages without this extension.
+ Consequently, operators need to ensure that the P-User-Database
+ header field is removed from requests before these are sent to
+ another administrative domain.
+
+
+
+
+Camarillo & Blanco Informational [Page 5]
+
+RFC 4457 The P-User-Database P-Header April 2006
+
+
+8. Acknowledgements
+
+ Nuria Esteban, Stephen Terrill, and Jeroen van Bemmel provided
+ comments on this document. Dean Willis performed a thorough review
+ of this document.
+
+9. References
+
+9.1. Normative References
+
+ [1] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005.
+
+ [2] 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.
+
+ [3] 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.
+
+ [4] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
+ "Diameter Base Protocol", RFC 3588, September 2003.
+
+9.2. Informative References
+
+ [5] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228
+ 5.14.0, October 2005.
+
+ [6] 3GPP, "Internet Protocol (IP) multimedia call control protocol
+ based on Session Initiation Protocol (SIP) and Session
+ Description Protocol (SDP); Stage 3", 3GPP TS 24.229 5.14.0,
+ October 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Camarillo & Blanco Informational [Page 6]
+
+RFC 4457 The P-User-Database P-Header April 2006
+
+
+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 Informational [Page 7]
+
+RFC 4457 The P-User-Database P-Header April 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ 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 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Camarillo & Blanco Informational [Page 8]
+