SIPPING Working Group J. van Elburg Internet-Draft Ericsson Telecommunicatie B.V. Expires: October 18, 2007 April 16, 2007 The Session Initiation Protocol (SIP) P-Served-User Private-Header (P-Header) draft-vanelburg-sipping-served-user-00.txt 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 October 18, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document specifies the SIP P-Served-User P-header. This header field addresses an issue that was found in the 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) between an S-CSCF (Serving Call Session Control Function) and an AS (Application Server) on the ISC (IMS Subsystem Service Control) interface to convey the identity of the served user and the session case that applies to this particular communication session and application invocation. van Elburg Expires October 18, 2007 [Page 1]
Internet-Draft The P-Served-User P-Header April 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Diversion; continue on terminating leg, but finish subsequent terminating iFC first . . . . . . . . . . . . . 4 3.3. Diversion; create new originating leg and provide originating iFC processing . . . . . . . . . . . . . . . 6 3.4. Call out of the blue; on behalf of user B, but policies&charging of service identity C . . . . . . . . . 7 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. P-Served-User header field Definition . . . . . . . . . . . . 8 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 Appendix A. Why te History Info header is not suitable to convey the served user information on the ISC interface . . . . . . . . . . . . . . . . . . . . . . 11 A.1. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 11 A.2. Additional Observations . . . . . . . . . . . . . . . . . 11 A.3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 van Elburg Expires October 18, 2007 [Page 2]
Internet-Draft The P-Served-User P-Header April 2007 1. Introduction The 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) uses SIP (RFC3261 [2]) as its main signalling protocol. (For more information on the IMS, a detailed description can be found in 3GPP TS 23.228 [8] and 3GPP TS 24.229 [10].) 3GPP has identified a set of requirements that can be met, according to the procedures in RFC 3427 [5], by defining a new SIP P-header. The remainder of this document is organized as follows. Section 3 describes the scenarios considered and Section 4 discusses the requirements derived from these scenarios. Section 5 defines the P-Served-User header field, which meets those requirements, and Section 6 discusses the applicability and scope of this new header field. Section 7 registers the P-Served-User header field with the IANA and Section 8 discusses the security properties of the environment where this header field is intended to be used. 2. Definitions The terms Identity, Network Asserted Identity and Trust Domain in this document are specified in RFC3324 [3]. 3. Scenarios 3.1. General In the 3GPP IMS the S-CSCF (Serving CSCF) is a SIP proxy that serves as a registrar and handles originating and terminating session states for users allocated to it. This means that any call that is originated by a specific user or any call that is terminated to that specific user will pass throught an S-CSCF that is allocated to that user. At the moment that an S-CSCF is allocated for a specific user, a user profile is downloaded to the S-CSCF from the HSS (Home Subscriber Server) over the Cx interface. This user profile tells the S-CSCF whether the user is allowed to originate or terminate calls or important for this particular document whether an AS needs to be linked in over the ISC interface. The user profile information that determines whether particular initial request need to be sent to a particular AS is called initial Filter Criteria (iFC), see for example 3GPP TS 23.218 [7]. To be able for an S-CSCF to perform its responsibilities it needs to determine on which users behalf it is performing its tasks and which van Elburg Expires October 18, 2007 [Page 3]
Internet-Draft The P-Served-User P-Header April 2007 session case is applicable for the particular request. (For session case see 3GPP TS 29.228 [11]) The session case distinguishes the originating and terminating call cases and whether the particular user is registered or not. When the S-CSCF determines that for an incoming initial request the originating call case applies, it determines the served user by looking at the P-Asserted-Identity header field ( RFC 3325 [4]) which carries the network asserted identity of the originating user. When after processing the iFC for this initial request the S-CSCF decides to forward the request to an AS, the AS has to go through a similar process of determining the session case and the served user. Since it should come to the same conclusion that this is an originating session case it has to look at the P-Asserted-Identy header field as well to determine the served user. When the S-CSCF determines that for an incoming initial request the terminating call case applies, it determines the served user by looking at the Request-URI ( RFC 3261 [2]) which carries the identity of the intended terminating user. When after processing the iFC for this initial request the S-CSCF decides to forward the request to an AS, the AS has to go through a similar process of determining the session case and the served user. Since it should come to the same conclusion that this is a terminating session case it has to look at the Request-URI as well to determine the served user. In the originating case it can be observed that while the P-Asserted- Identity header field just represents the originating user when it enters the S-CSCF, it is overloaded with another meaning when it is sent to an AS over the ISC interface. This other meaning is that it serves as a representation of the served user. In the terminating case a similar overloading happens to the Request- URI, while it first only represented the identity of the intended terminating user, it is overloaded with another meaning when it is sent to an AS over the ISC interface. This other meaning is that it serves as a representation of the served user. In basic call scenarios this does not show up as a problem, but once more complicated service scenarios (notably forwarding services) needs to be realised it poses severe limitations. Such scenarios are brought forward in the following sub sections. 3.2. Diversion; continue on terminating leg, but finish subsequent terminating iFC first Imagine a service scenario where a user B has a terminating service that diverts the call to a different destination, but it is required van Elburg Expires October 18, 2007 [Page 4]
Internet-Draft The P-Served-User P-Header April 2007 that subsequent terminating services for the same user are still executed. This means that this particular user has multiple iFC configured that are applicable for an incoming initial request. When the S-CSCF receives an initial INVITE request it analyses the request and determines that the session case is for a terminating registered user, then it determines the served user to be user B by looking at the Request-URI. Now the S-CSCF starts the iFC processing, the first iFC that matches the INVITE request causes the INVITE to be forwarded over the ISC interface to an AS that hosts user B's diversion service, by adding the AS and S-CSCF's own hostnames to the Route header. The S-CSCF adds an Original Dialog Identifier (ODI) to the S-CSCF's own hostname on the Route header, this allows the S-CSCF to correlate an INVITE coming from an AS over the ISC interface to the existing session that forwarded the INVITE to the AS in the first place. When the AS receives the initial INVITE request it analyses the request and determines that the session case is for a terminating registered user, then it determines the served user to be user B by looking at the Request-URI. Based on some criteria the diversion service concludes that the request needs to be diverted to another user or application C. It does this by changing the Request-URI to C. Optionally it records the Request-URI history by using the History- Info header field (RFC4244 [6]). Then the AS removes itself from the Route header and routes the INVITE request back to the S-CSCF by using the topmost Route header field. When the S-CSCF receives the INVITE over the ISC interface it can see that the Route header contains its own hostname and an ODI that correlates to an existing terminating session for user B. This can be used by the S-CSCF to analyze whether there are still unexecuted iFC. The process repeats itself, the INVITE is forwarded to the AS that is associated with this particular iFC. When the AS receives the initial INVITE request it analyses the request and determines that the session case is for a terminating registered user, then it determines the served user to be user C by looking at the Request- URI. This is clearly wrong as the user being served is still user B. This scenario clearly shows the problem that occurs when the Request- URI is overloaded with the meanings "intended target identity" and "served user" with the operation as described in chapter Section 3.1. And it shows that this use case can not be realised without introducing a mechanism that conveys information about the served user from the S-CSCF to the AS. Use of the History-Info element does not solve this problem as it does not tell the AS which user is being served, but just presents a history of diversions that might not be van Elburg Expires October 18, 2007 [Page 5]
Internet-Draft The P-Served-User P-Header April 2007 even caused by the systems serving this particular user. A more detailed analysis on why the History-Info header field can't be used is provided in Appendix A. 3.3. Diversion; create new originating leg and provide originating iFC processing Imagine a service scenario where a user B has a terminating service that diverts the call to a different destination, it is required that forwarded call leg is handled as an originating call leg and that originating services for user B are executed. This means that this particular user has one or more iFC configured that are applicable for an outgoing initial request. When the S-CSCF receives an initial INVITE request it analyses the request and determines that the session case is for a terminating registered user, then it determines the served user to be user B by looking at the Request-URI. Now the S-CSCF starts the iFC processing, the first iFC that matches the INVITE request causes the INVITE to be forwarded over the ISC interface to an AS that hosts user B's diversion service, by adding the AS and S-CSCF's own hostnames to the Route header. The S-CSCF adds an Original Dialog Identifier (ODI) to the S-CSCF's own hostname on the Route header, this allows the S-CSCF to correlate an INVITE coming from an AS over the ISC interface to the existing session that forwarded the INVITE to the AS in the first place. When the AS receives the initial INVITE request it analyses the request and determines that the session case is for a terminating registered user, then it determines the served user to be user B by looking at the Request-URI. Based on some criteria the diversion service concludes that the request needs to be diverted to another user or application C. It does this by changing the Request-URI to C. Optionally it records the Request-URI history by using the History- Info header field (RFC4244 [6]). Then the AS removes itself from the Route header. To make sure that the request is handled as a new originating call on behalf of user B, the AS adds the "orig" parameter to the topmost route header. Then it routes the INVITE request back to the S-CSCF by using this topmost Route header field. When the S-CSCF receives the INVITE over the ISC interface it can see that the topmost Route header contains its own hostname and an ODI that correlates to an existing terminating session for user B. This can be used by the S-CSCF to determine that the served user is user B. Because the topmost Route header also contains the "orig" parameter the S-CSCF concludes that the INVITE should be handled as if a call is originated by the served user. Since the INVITE was van Elburg Expires October 18, 2007 [Page 6]
Internet-Draft The P-Served-User P-Header April 2007 handled first as a terminating call, a new originating procedure has to be initiated including a restart of the iFC processing now for the originating session case. Now the S-CSCF starts the originating iFC processing, the first iFC that matches the INVITE request causes the INVITE to be forwarded over the ISC interface to an AS that hosts an originating service of user B, by adding the AS and S-CSCF's own hostnames to the Route header. The S-CSCF adds an Original Dialog Identifier (ODI) to the S-CSCF's own hostname on the Route header. The INVITE is forwarded to the AS that is associated with this particular iFC. When the AS receives the initial INVITE request it analyses the request and determines that the session case is for an originating registered user, then it determines the served user to be user A by looking at the P-Asserted-Identity. This is clearly wrong as the user being served is and should be user B. This scenario clearly shows the problem that occurs when the P-Asserted-Identity is overloaded with the meanings "call originator" and "served user" with the operation as described in chapter Section 3.1. And it shows that this use case can not be realised without introducing a mechanism that conveys information about the served user from the S-CSCF to the AS. Use of the History-Info element does not solve this problem as it does not tell the AS which user is being served, but just presents a history of diversions that might not be even caused by the systems serving this particular user. A more detailed analysis on why the History-Info header field can't be used is provided in appendix Appendix A. 3.4. Call out of the blue; on behalf of user B, but policies&charging of service identity C There are services that need to be able to initiate a call, whereby the call appears to be coming from a user B, but policies like charging on behalf of service identity C needs to be executed in the S-CSCF. When a call needs to appear as coming from user B, that means that the P-Asserted-Identity needs to contain B's identity. This is because the Originating Identity Presentation (OIP) service as defined in 3GPP 24.173 [9] uses the P-Asserted-Identity to present the call originator. Which makes sense because that is the main meaning expressed by the P-Asserted-Identity header field. It is clear that no INVITE request can be constructed currently that would achieve both requirements expressed in the first paragraph, because the P-Asserted-Identity is overloaded with two meanings on van Elburg Expires October 18, 2007 [Page 7]
Internet-Draft The P-Served-User P-Header April 2007 the ISC interface, because when the S-CSCF will receive this request it will determine that the served user is user B, which was not what we wanted to achieve. 4. Requirements This section lists the requirements derived from the previous scenarios: 1. To be able to offer real world application services it is required that the identity of the served user can be conveyed on the ISC interface (see 3GPP 23.218 [7]). 2. To be able to offer appropriate services to the served user it is required that in addition to the served user identity the session case is conveyed. 5. P-Served-User header field Definition This document defines the SIP P-Served-User P-header. This header field can be added to initial requests routed from an S-CSCF to an AS or from an AS to an S-CSCF. The P-Served-User P-header contains the IMS Public User Identity of the user that is served by the S-CSCF and on whose behalf an application is invoked. The sessioncase parameter may be used to convey whether the initial request is originated by or destined for the served user. The registration state parameter may be used by the S-CSCF towards an AS to indicate whether the initial request is for a registered or an unregistered user. The augmented Backus-Naur Form (BNF) (RFC2234 [1]) syntax of the P-Served-User header field is the following: P-Served-User = "P-Served-User" HCOLON PServedUser-value [SEMI sessioncase-param] [SEMI registration-state-param] *( SEMI generic-param ) PServedUser-value = name-addr / addr-spec sessioncase-param = "sescase" EQUAL "orig" / "term" registration-state-param = "regstate" EQUAL "unreg" / "reg" EQUAL, HCOLON, name-addr, addr-spec and generic-param are defined in RFC 3261 [2]. The following is an example of a P-Served-User header field: van Elburg Expires October 18, 2007 [Page 8]
Internet-Draft The P-Served-User P-Header April 2007 P-Served-User: <sip:captain@buzz.com> ; sescase=orig; regstate=reg 6. Applicability According to RFC 3427 [5], 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-Served-User header field is intended to be used in 3GPP IMS networks. This header field carries the identity of the served user from an S-CSCF to an IMS application server, which is referred to as AS. Or from an AS to an S-CSCF. The S-CSCF or the AS inserts the P-Served-User 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 involving an application server over an ISC interface. Consequently, the P-Served-User header field does not seem useful in a general Internet environment. 7. IANA Considerations This document defines a new SIP header field: P-Served-User. This header field needs to be registered by the IANA in the SIP Parameters registry under the Header Fields subregistry. 8. Security Considerations The P-Served-User 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-Served-User header field will be used ensures the integrity and the confidentiality of the contents of this header field. There is a security risk if a P-Served-User header field is allowed to propagate out of the trust domain where it was generated. In that case user-sensitive information would be revealed by such a breach. Consequently, operators need to ensure that the P-Served-User header field is always removed from requests before these are sent outside the trust domain. van Elburg Expires October 18, 2007 [Page 9]
Internet-Draft The P-Served-User P-Header April 2007 9. Acknowledgements Alf Heidermark, Hubert Przybysz and Erik Rolin for the discussion that led to the solution written down in this document. Gonzalo Camarillo for suggesting to add an explanation to why the History- Info header is not suitable to fulfill the requirements as expressed in this draft. Nils Haenstroem for pointing out an issue with the way the parameters where defined. 10. References 10.1. Normative References [1] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [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] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002. [4] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. [5] 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. 10.2. Informative References [6] Barnes, M., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005. [7] 3GPP, "IP Multimedia (IM) session handling; IM call model; Stage 2", 3GPP TS 23.218 5.9.0, June 2006. [8] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 5.15.0, June 2006. [9] 3GPP, "IMS Multimedia telephony service and supplementary services; Stage 3", 3GPP TS 24.173 7.0.0, March 2007. [10] 3GPP, "Internet Protocol (IP) multimedia call control protocol van Elburg Expires October 18, 2007 [Page 10]
Internet-Draft The P-Served-User P-Header April 2007 based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3", 3GPP TS 24.229 5.18.0, October 2006. [11] 3GPP, "IP Multimedia (IM) Subsystem Cx and Dx Interfaces; Signalling flows and message contents", 3GPP TS 29.228 5.18.0, December 2006. Appendix A. Why te History Info header is not suitable to convey the served user information on the ISC interface A.1. Semantics The History-Info as specified in (RFC4244 [6]) holds a record of Request-URI's that are put on an initial request during its processing in the network and then particularly when the request is retargeted or forwarded. If it would be possible at all to use the History-Info header for the purpose of communicating the served user, then again the same overloading would occur as the one that we are trying to get rid of (Section 3.2). Because in that case we overload the particular History-Info header field's hi-entry with the meaning "historic target identity" and "served user". Another reason that the History-Info header can not solve the requirements as expressed in this draft is that in originating session case scenarios the served user is currently determined from the P-Asserted-Identity as that one contains the asserted originating users identity. The History-Info header being a record of Request- URI's can never be a solution for this case. Looking at the the call out of the blue scenario (Section 3.4) it is impossible to construct a History-Info header for an INVITE request on behalf of user C appearing to come from user B and targeting user D that would express the served user C without violating the original semantics of the History-Info header according to (RFC4244 [6]). A.2. Additional Observations The purpose of the History-Info header is a header that has an end to end application, for the purpose of informing an AS on the ISC interface this is overkill. At the moment that the AS receives an initial INVITE over the ISC interface, this INVITE may have passed a vast number of proxies that may either have added history information or not. On top of that the van Elburg Expires October 18, 2007 [Page 11]
Internet-Draft The P-Served-User P-Header April 2007 request may have traversed several AS for the same served user in case several subsequent iFC are active all these AS may perform a forwarding. This means that it is not possible to define an algorithm that points out which hi-entry of a History-Info header should represent the served user. In other words a History-Info header field with n entries expressing a branch of depth n; any or none of these elements could be the served user identity. The History-Info header does not comply with the second requirement as expressed in Section 4, as it does not have a means to express the session case in a natural way. A.3. Conclusion All of the observations in the previous sub clauses in isolation are enough to disregard the History-Info header as an information element that is suitable for transporting the served user information over the ISC interface. Note that this does not prohibit the use of the P-Served-User header and the History-Info header in the same request, in fact that will be a quite likely scenario for network based diversion services like for example the Communication Diversion service as specified in (3GPP 24.173 [9]). Author's Address Hans Erik van Elburg Ericsson Telecommunicatie B.V. Ericssonstraat 2 Rijen 5121 ML The Netherlands Email: HansErik (dot) van (dot) Elburg (at) ericsson (dot) com van Elburg Expires October 18, 2007 [Page 12]
Internet-Draft The P-Served-User P-Header April 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). van Elburg Expires October 18, 2007 [Page 13]
