idnits 2.17.1 draft-camarillo-sipping-user-database-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 331. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 308. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 315. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 321. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 23, 2005) is 6726 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2234 (ref. '1') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3427 (ref. '3') (Obsoleted by RFC 5727) ** Obsolete normative reference: RFC 3588 (ref. '4') (Obsoleted by RFC 6733) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group G. Camarillo 3 Internet-Draft G. Blanco 4 Expires: May 27, 2006 Ericsson 5 November 23, 2005 7 The Session Initiation Protocol (SIP) P-User-Database Private-Header 8 (P-Header) 9 draft-camarillo-sipping-user-database-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 27, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document specifies the SIP P-User-Database P-header. This 43 header field is used in the 3rd-Generation Partnership Project (3GPP) 44 IMS (IP Multimedia Subsystem) to provide SIP registrars and SIP proxy 45 servers with the address of the database that contains the user 46 profile of the user that generated a particular request. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.1. User Registering to the IMS . . . . . . . . . . . . . . . . 3 53 2.2. Incoming Request for an Unregistered User . . . . . . . . . 4 54 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. P-User-Database header field Definition . . . . . . . . . . . . 5 56 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 59 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 60 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 62 9.2. Informational References . . . . . . . . . . . . . . . . . 7 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 64 Intellectual Property and Copyright Statements . . . . . . . . . . 9 66 1. Introduction 68 The 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia 69 Subsystem) uses SIP [2] as its main signalling protocol. (For more 70 information on the IMS, a detailed description can be found in 3GPP 71 TS 23.228 [5] and 3GPP TS 24.229 [6].) 3GPP has identified a set of 72 requirements that can be met, according to the procedures in RFC 3427 73 [3], by defining a new SIP P-header. 75 The remainder of this document is organized as follows. Section 2 76 describes the scenarios considered by 3GPP and Section 3 discusses 77 the requirements derived from these scenarios. Section 4 defines the 78 P-User-Database header field, which meets those requirements, and 79 Section 5 discusses the applicability and scope of this new header 80 field. Section 6 registers the P-User-Database header field with the 81 IANA and Section 7 discusses the security properties of the 82 environment where this header field is intended to be used. 84 2. Scenarios 86 In the 3GPP IMS, there are two scenarios where a set of proxies 87 handling a request need to consult the same user database. These 88 scenarios consist of a user registering to the IMS network and an 89 unregistered user receiving an incoming request that triggers a 90 service (e.g., a voice mail service). 92 2.1. User Registering to the IMS 94 In the 3GPP IMS, SIP REGISTER requests generated by a UA (User Agent) 95 traverse a set of SIP proxy servers before reaching the SIP 96 registrar. A REGISTER request sent by a UA is routed to the outbound 97 proxy of the UA, which is referred to as the P-CSCF (Proxy-Call/ 98 Session Control Function). 100 The P-CSCF routes the REGISTER request to another proxy, which is 101 referred to as the I-CSCF (Interrogating-CSCF) and is always located 102 in the home domain of the user. The I-CSCF consults the user 103 database of the domain, which is referred to as the HSS (Home 104 Subscriber Server), in order to choose the registrar that will 105 process the REGISTER request. 107 With the information received from the HSS, the I-CSCF routes the 108 REGISTER request to the appropriate registrar, which is referred to 109 as the S-CSCF (Serving-CSCF). At this point, the S-CSCF needs to 110 contact the same HSS that was previously contacted by the I-CSCF in 111 order to fetch the user profile of the user that generated the 112 REGISTER request. 114 The interface between the I-CSCF and the HSS and between the S-CSCF 115 and the HSS is called Cx interface, and is based on Diameter [4]. 117 When there is a single HSS (i.e., user database) handling all the 118 users in the domain, both the I-CSCF and the S-CSCF can be configured 119 with its address so that they contact it when necessary. However, 120 some domains have several HSSs, each of which handles a particular 121 set of users. When dealing with a REGISTER request, the I-CSCF and 122 the S-CSCF need to discover which is the HSS that contains the 123 profile of user that generated the REGISTER request. 125 In networks with more than one HSS, a Diameter redirect agent 126 referred to as SLF (Subscription Locator Function) is implemented. 127 The interface between the I-CSCF and the SLF and between the S-CSCF 128 and the SLF is called Dx interface and, like the CX interface, is 129 based on Diameter. The SLF provides the I-CSCF and the S-CSCF with 130 the address of the HSS that handles the user they are dealing with. 132 Therefore, in a network with more than one HSS, the SLF is consulted 133 twice per REGISTER request. First by the I-CSCF, and later by the 134 S-CSCF. If the I-CSCF could provide the S-CSCF with the address of 135 the HSS handling the user that generated the REGISTER request, the 136 S-CSCF could contact directly that HSS. That is, the S-CSCF would 137 not need to contact the SLF in order to obtain the address of the 138 HSS. 140 2.2. Incoming Request for an Unregistered User 142 In the 3GPP IMS, incoming requests for a user traverse an I-CSCF in 143 the home domain of the user. This I-CSCF consults the HSS, using the 144 Diameter-based Cx interface, in order to decide which S-CSCF should 145 handle the request. After consulting the HSS, the I-CSCF forwards 146 the request to a S-CSCF, which is also located in the home domain of 147 the user. 149 If the user the request is addressed to is registered to the IMS 150 network, the S-CSCF receiving the request knows which HSS handles the 151 user. The S-CSCF stored this information when the user registered. 152 However, if the user is not registered, the S-CSCF needs to consult 153 the SLF (assuming more than one HSS in the network) in order to 154 discover the HSS handling the user. 156 Therefore, like in the previous scenario, in a network with more than 157 one HSS, the SLF is consulted twice per incoming request addresses to 158 an unregistered user. First by the I-CSCF, and later by the S-CSCF. 159 If the I-CSCF could provide the S-CSCF with the address of the HSS 160 handling the user that generated the request, the S-CSCF could 161 contact directly that HSS. That is, the S-CSCF would not need to 162 contact the SLF in order to obtain the address of the HSS. 164 3. Requirements 166 This section lists the requirements derived from the previous 167 scenarios: 169 1. It is necessary to optimize the registration process in the 3GPP 170 IMS by reducing the time it takes for a UA to register to the IMS 171 network. 172 2. It is necessary to optimize the handling of incoming requests to 173 unregistered users in the 3GPP IMS by reducing the time it takes 174 for a domain to handle these requests. 175 3. It is necessary to improve the scalability of SLFs in the 3GPP 176 IMS by reducing the amount of traffic the SLF of a network needs 177 to handle. 179 4. P-User-Database header field Definition 181 This document defines the SIP P-User-Database P-header. This header 182 field can be added to requests routed from an I-CSCF to a S-CSCF. 183 The P-User-Database P-header contains the address of the HSS handling 184 the user that generated the request. 186 The augmented Backus-Naur Form (BNF) [1] syntax of the P-User- 187 Database header field is the following: 189 P-User-Database = "P-User-Database" HCOLON database 190 *( SEMI generic-param ) 191 database = LAQUOT DiameterURI RAQUOT 193 DiameterURI is defined in RFC 3588 [4]. HCOLON, LAQUOT, RAQUOT, and 194 generic-param are defined in RFC 3261 [2]. 196 The following is an example of a P-User-Database header field: 198 P-User-Database: 200 5. Applicability 202 According to RFC 3427 [3], P-headers have a limited applicability. 203 Specifications of P-headers such as this RFC need to clearly document 204 the useful scope of the proposal, and explain its limitations and why 205 it is not suitable for the general use of SIP on the Internet. 207 The P-User-Database header field is intended to be used in 3GPP IMS 208 networks. This header field carries the address of a user database, 209 which is referred to as HSS, between two proxies, which are referred 210 to as I-CSCF and S-CSCF. The I-CSCF and the S-CSCF belong to the 211 same administrative domain and share a common frame of reference to 212 the user database. The I-CSCF inserts the P-User-Dabatase header 213 field into a SIP request and the S-CSCF removes it before routing the 214 request further. 216 When SIP is used on the Internet, there are typically no proxies 217 querying a user database between the UA sending a REGISTER request 218 and the registrar. Consequently, the P-User-Database header field 219 does not seem useful in a general Internet environment. 221 6. IANA Considerations 223 This document defines a new SIP header field: P-User-Database. This 224 header field needs to be registered by the IANA in the SIP Parameters 225 registry under the Header Fields subregistry. 227 7. Security Considerations 229 The P-User-Database defined in this document is to be used in an 230 environment where elements are trusted and where attackers are not 231 supposed to have access to the protocol messages between those 232 elements. Traffic protection between network elements is sometimes 233 achieved by using IPsec and sometimes by physically protecting the 234 network. In any case, the environment where the P-User-Database 235 header field will be used ensures the integrity and the 236 confidentiality of the contents of this header field. 238 There is a slight security risk if a P-User-Database header field is 239 allowed to propagate out of the administrative domain where it was 240 generated. No user-sensitive information would be revealed by such a 241 breach, but this could result in disclosure of information about the 242 topology of the operator network that goes beyond the level of 243 disclosure explicit in SIP messages without this extension. 244 Consequently, operators need to ensure that the P-User-Database 245 header field is removed from requests before these are sent to 246 another administrative domain. 248 8. Acknowledgements 249 Nuria Esteban, Stephen Terrill, and Jeroen van Bemmel provided 250 comments on this document. Dean Willis performed a thorough review 251 of this document. 253 9. References 255 9.1. Normative References 257 [1] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 258 Specifications: ABNF", RFC 2234, November 1997. 260 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 261 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 262 Session Initiation Protocol", RFC 3261, June 2002. 264 [3] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. 265 Rosen, "Change Process for the Session Initiation Protocol 266 (SIP)", BCP 67, RFC 3427, December 2002. 268 [4] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 269 "Diameter Base Protocol", RFC 3588, September 2003. 271 9.2. Informational References 273 [5] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 274 5.14.0, October 2005. 276 [6] 3GPP, "Internet Protocol (IP) multimedia call control protocol 277 based on Session Initiation Protocol (SIP) and Session 278 Description Protocol (SDP); Stage 3", 3GPP TS 24.229 5.14.0, 279 October 2005. 281 Authors' Addresses 283 Gonzalo Camarillo 284 Ericsson 285 Hirsalantie 11 286 Jorvas 02420 287 Finland 289 Email: Gonzalo.Camarillo@ericsson.com 291 German Blanco 292 Ericsson 293 Via de los Poblados 13 294 Madrid 28035 295 Spain 297 Email: german.blanco@ericsson.com 299 Intellectual Property Statement 301 The IETF takes no position regarding the validity or scope of any 302 Intellectual Property Rights or other rights that might be claimed to 303 pertain to the implementation or use of the technology described in 304 this document or the extent to which any license under such rights 305 might or might not be available; nor does it represent that it has 306 made any independent effort to identify any such rights. Information 307 on the procedures with respect to rights in RFC documents can be 308 found in BCP 78 and BCP 79. 310 Copies of IPR disclosures made to the IETF Secretariat and any 311 assurances of licenses to be made available, or the result of an 312 attempt made to obtain a general license or permission for the use of 313 such proprietary rights by implementers or users of this 314 specification can be obtained from the IETF on-line IPR repository at 315 http://www.ietf.org/ipr. 317 The IETF invites any interested party to bring to its attention any 318 copyrights, patents or patent applications, or other proprietary 319 rights that may cover technology that may be required to implement 320 this standard. Please address the information to the IETF at 321 ietf-ipr@ietf.org. 323 Disclaimer of Validity 325 This document and the information contained herein are provided on an 326 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 327 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 328 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 329 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 330 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 331 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 333 Copyright Statement 335 Copyright (C) The Internet Society (2005). This document is subject 336 to the rights, licenses and restrictions contained in BCP 78, and 337 except as set forth therein, the authors retain all their rights. 339 Acknowledgment 341 Funding for the RFC Editor function is currently provided by the 342 Internet Society.