Individual niksrameilgreen D. Niks, A. RameilGreen Internet Draft Vodafone, Intended status: Proposed Vodafone Document: draft-sip-userlocationinfo-00.txt Expires: December 2015 June 2015 The SIP P-User-Location-Info Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem Status of this Memo This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft 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. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code components extracted from this document must include Simplified BSD License text as described in Section 4.c of the Trust Legal Provisions and are provided without warrenty as described in the Simplified BSD License. This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Niks Expires - December 2015 [Page 1] The SIP P-User-Location-Info Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem June 2015 Abstract This document specifies the SIP P-User-Location-Info P-header. This header field addresses an issue that was identified when non-3GPP access and non-trusted networks are integrated to IMS (IP Multimedia Subsystem) networks. This header field conveys the trusted network determined location information of a served user when the user is registered for IMS services via non-3GPP access networks. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. Table of Contents 1. Introduction ................................................ 3 2. Definitions ................................................. 4 2.1 User Location ........................................... 4 2.2 Served user ............................................. 4 2.3 End-point ............................................... 4 3. Scenarios ................................................... 4 3.1 General ................................................. 4 3.2 Registration ............................................ 5 3.3 Originating communication ................................ 5 3.4 Terminating communication ................................ 5 3.5 Flight mode ............................................. 6 3.6 Visiting Country Identification .......................... 6 3.7 Dual attach ............................................. 6 4. Requirements ................................................ 6 5. Proxy and application server behavior ........................ 7 5.1 Generate the P-User-Location-Information header........... 7 5.2 Consuming the P-User-Location-Info header ................ 7 6. P-User-Location-info header field definition ................. 8 7. Applicability ............................................... 9 8. Security Considerations ..................................... 10 References .................................................... 11 Acknowledgments ............................................... 13 Author's Addresses ............................................ 13 Niks Expires - December 2015 [Page 2] The SIP P-User-Location-Info Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem June 2015 1. Introduction The 3rd Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) uses SIP (RFC-3261 [2]) as its main signalling protocol.(For more information on the IMS, a detailed description can be found in 3GPP TS 23.228 [3] and 3GPP TS 24.229 [4].) It has been identified that trusted location information required by 3GPP operators is not available when a user is registered for IMS services over non-3GPP access. Therefore the network should retrieve location and insert this information into the session signalling. The header existing in current standards (P-ANI header reference RFC3455 [5]) is not appropriate as the location information contained within this header is directly related to the access network passed within the same header. Typically location information is populated into signalling by the end-point and contains information of the IP connectivity access network (IP_CAN) used. If the particular IP-CAN is a 3GPP network then the end-point can populate the header with 3GPP user location (e.g. cell-id / tracking area as per RFC 3455 [5]). If the end-point is making use of non-3GPP IP-CAN than the access info related to this IP-CAN type does not contain 3GPP user location. In both of these cases the end-point populated access network information is non-trusted. In order to provide trusted network access info / location info (aka Network Provided Access Network Info) a SIP proxy or application server in the trusted domain can retrieve network access information using non-SIP mechanisms and then insert the information into the SIP requests / responses. If the user provided access information and network provided access information are not on the same access type then it is not clear for any application utilizing the PANI header whether the user provided access type can be trusted in order to confirm that the end-point is really making use of this access type (e.g.. it may be manipulated by the client application running on the end-point). For example when the 3GPP user location is a requirement for the trusted network to process SIP messages a SIP proxy can retrieve the 3GPP user location via a different channel regardless of the actual IP-CAN used, and populate the PANI header with this information. However this violates the reliability of a network provided access info header since information in that header should not contain contradictory information and hence the SIP proxy must modify the access-type and access info header to be consistent (see RFC 3455 [5] and 3GPP TS 24.229 [4] section 7.2A4 for syntax and coding rules). This will lead into either loss of the real IP-CAN used, since the IP-CAN is modified in order to populate the access info with 3GPP user location or the IP-CAN type is not overwritten but the 3GPP user location is added as additional access info. The latter is a problem for applications in IMS that need to understand how to Niks Expires - December 2015 [Page 3] The SIP P-User-Location-Info Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem June 2015 interpret the access info based on the access type (IP-CAN type). Another problem with the population of trusted network determined access information is the reliability of the information received in terms of the age of the information. Typically access information populated by the end-point is real-time since it is generated upon sending requests or responses. Hence, the current header does not give provision to populate any information of the age of the network provided access info. Age is useful to determine the reliability of the provisioned network access info location part. The problem is most appropriately resolved by defining a new SIP P- header solely designed for user location and/or location info beyond 3GPP user location. The remainder of this document is organized as follows. Section 3 outlines the problem by using particular service scenarios, and Section 4 discusses the requirements derived from these scenarios. Section 6 defines the P-User-Location-Info header field, which meets those requirements, Section 5 specifies the SIP proxy and application server behaviour for the new header field, and Section 7 discusses the applicability and scope of this new header field. Section 8 discusses the security properties of the environment where this header field is intended to be used. 2. Definitions 2.1 User Location The user location to an IMS network is a representation of the geographical location of the user's end-point. 2.2 Served user The served user to a proxy or AS (Application Server) is the user whose service profile is accessed by that proxy or AS when an initial request is received that is originated by, originated on behalf of, or terminated to that user. This profile in turn provides some useful information (preferences or permissions) for processing at a proxy and, potentially, at an AS. 2.3 End-point The end-point is the physical device that is running the SIP User Agent Client. End-points may be SIM or SIM-less devices. 3. Scenarios 3.1 General Niks Expires - December 2015 [Page 4] The SIP P-User-Location-Info Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem June 2015 In the 3GPP IMS, the user's location information is required for emergency calling and a variety of applications like location based barring, differential charging and location tracking purposes. In the 3GPP IMS, location is retrieved by mapping access information (provided by either the user or the network) into a real location by potentially the recipient (3GPP TS 24.229 [4]). In case a non-3GPP network is used the access technology has no access information associated that can be used by the recipient, most probably a SIP proxy or application server, for mapping into a real location. For example if a user is attached to WiFi access. The focus of this RFC is to provide a solution for providing trusted and reliable location information for users camping on non-3GPP access network, by defining a new SIP header to convey (already mapped) real user location and making use of the existing PANI header to convey network provided access information related to access used. 3.2 Registration Upon SIP registrations sent from the end-point a SIP proxy, facing the end-point, can insert network provided access information and additional location information prior to forwarding to the next hop. The location information inserted may be unrelated to the access information. 3.3 Originating communication Upon SIP requests or responses from an end-point a SIP proxy facing the end-point can insert network provided access information and additional location information prior to forwarding to the next hop. 3.4 Terminating communication Initial requests to a UE do not contain location information of the terminating user. Location information in the form of a PANI header can be inserted in responses from the terminating UE. However if an application needs to act on the location of the called-party in order to decide whether or not to deliver an incoming call or (temporary) redirect an incoming call to a voice response system, if the application relies on the population by the terminating UE this will result with poor user experience as the end-point must have rung before the location of the end-point is known. To overcome this issue a SIP application can rely on location information included in 3rd party register requests. However this location information might be outdated due to long expiry timer for re-registration. And in case the end-point is camped on a CS network Niks Expires - December 2015 [Page 5] The SIP P-User-Location-Info Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem June 2015 there is no 3rd party register at all. The SIP proxy can retrieve the location information for the user from a 3rd part server and represent this information in operations that requires such information. If the signalling needs to traverse multiple SIP proxies it is convenient that the user location for the terminating user can be passed on to the next hop. This will avoid that multiple application servers need to deploy interfaces for location retrieval and in general reduce call setup time due to avoid unnecessarily location dips which could be otherwise performed once within the chain of application servers. 3.5 Flight mode In this example the end-point is in flight-mode and hence is not camped on a cellular access. The end-point can still camp on a PS network using WiFi access. In this scenario the active location cannot be retrieved. The network however knows about the last known location of the user, which may or may not reflect their active location. The sip proxy retrieving the location information from a 3rd party server has the capability to utilize the age of the retrieved location information and MUST pass this information in the user location header. It is then an operator policy as to whether the retrieved location information should be considered given the age of the last known location information. 3.6 Visiting Country Identification In this example the end-point is using wifi for calling in a foreign country, and in this case the visited-network-id is inserted by the home SIP proxy. The home SIP proxy retrieves location information and inserts information about the geo-graphical location retrieved from the cellular network. Often location queries from home network to foreign network nodes are not permitted, but as a minimum the home network has an indication of the network the user is visiting. 3.7 Dual attach In this example the end-point is attached to 2/3G and 4G. The sip proxy can insert CS and EPS locations. 4. Requirements This section lists the requirements derived from the previous scenarios: Niks Expires - December 2015 [Page 6] The SIP P-User-Location-Info Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem June 2015 1. To be able to offer trusted user location and access info to application services, it is required that the network provided user location and access info can be conveyed on the ISC interface. 2. To be able to offer reliable user location, it is required that in addition to the user location the age and the time-stamp of retrieval is added. The age is relative to the time-stamp. 5. Proxy and application server behavior 5.1 Generate the P-User-Location-Information header Proxies and application servers that support the header MUST only insert the header in requests and responses for a dialog or in standalone requests when the following conditions hold: The proxy or application server has the capability to determine the served user for the current location retrieval request. The next hop is part of the same Trust Domain for the served user The proxy or application server has the capability to retrieve trusted location information from the network or 3rd part server The proxy or application server has the capability to set a time stamp of the location information based on the age value received from the network or 3rd party server The operator policy requires this information be captured The request was sent over non-cellular access, e.g. WiFi When the above conditions do not hold, the proxy or applications server MUST NOT insert the header. Proxies that support the header MAY insert a user location for any user identifiable within the current request. Proxies that support the header MAY re-generate the user location info with more up to date information. Proxies that support the header MUST generate the time-stamp value based on the age information received upon retrieval. 5.2 Consuming the P-User-Location-Info header Niks Expires - December 2015 [Page 7] The SIP P-User-Location-Info Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem June 2015 A proxy or application server that supports the header MUST, upon receiving from a trusted node the P-User-Location-info header in any requests or response, take the value of P-User-Location-info header to represent the user location in operations that require such information. A proxy or application server that supports the header MUST remove the header from requests or responses when the header was received from a node outside the Trust Domain for P-User-Location-Info before further forwarding the message. A proxy or application server that supports the header MUST remove the header from requests or responses when the next hop is a node outside the Trust Domain for P-User-Location-Info before further forwarding the message. Should a UE facing proxy or application server receive this header within a request or response that was generated by the UE or non- trusted domain, the proxy or application server MUST remove the header. 6. P-User-Location-info header field definition The augmented Backus-Naur Form (BNF) (RFC 5234 [6])syntax of the P- User-Location-Info header is described as follows. P-User-Location-Info = "P-User-Location-Info" HCOLON PServedUser-value (SEMI-visited-network-id-param) SEMI location-info-param *(COMMA location-info-param) PServedUser-value = name-addr / addr-spec visited-network-id-param = "visited-network-id" EQUAL vnetwork-spec*(COMMA vnetwork-spec) location-info-param = location-info (SEMI date-time-value) Location-info = cgi-3gpp / utran-cell-id-3gpp / extension-access-info extension-access-info = gen-value cgi-3gpp = "cgi-3gpp" EQUAL Niks Expires - December 2015 [Page 8] The SIP P-User-Location-Info Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem June 2015 (token / quoted-string) utran-cell-id-3gpp = "utran-cell-id-3gpp" EQUAL (token / quoted-string) local-time-zone = "local-time-zone" EQUAL (token / quoted-string) date-time-value = "date-time" EQUAL date time vnetwork-spec, access type , access info ,cgi-3gpp and utran-cell-id- 3gpp are defined in RFC 3455 [5]. Date and time are specified in RFC 1123 [7] (time contains a time zone). Age shall contain the elapsed time in minutes since the last network contact of the user equipment. For details, see 3GPP TS 29.002 [8]. EQUAL, HCOLON, SEMI, name-addr, addr-spec, and generic-param are defined in RFC-3261 [9]. Example: P-User-Location-Info: ; "visited-network-id"= "Visited network number 1" ; "utran-cell-id-3gpp" = "MCC MNC ECT" ; "date-time"= "dd mm yyyy hh:mm:ss "GMT"" 7. Applicability According to RFC-3427 [10], 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 use of the P-User-Location-Info header field extensions is only applicable inside a Trust Domain for the served user. Nodes in such a Trust Domain explicitly trust each other to convey the served user and to be responsible for withholding that information outside of the Trust Domain. The means by which the network determines the location of a user and the policies that are executed for a specific user location is outside the scope of this document. Niks Expires - December 2015 [Page 9] The SIP P-User-Location-Info Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem June 2015 The user location information lacks an indication of who or what specifically provided the location, and so it must be assumed that the Trust Domain provided the user location. Therefore, the information is only meaningful when securely received from a node known to be a member of the Trust Domain. Because the user location typically only has validity in one administrative domain, it is in general not suitable for inter-domain use or use in the Internet at large. Despite these limitations, there are sufficiently useful specialized deployments that meet the assumptions described above, and that can accept the limitations that result, to warrant informational publication of this mechanism. An example deployment would be a closed network like 3GPP IMS. 8. Security Considerations The P-User-Location-Info header field 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. The Spec(T) that defines the Trust Domain for P-User-Location-Info header MUST require that member nodes understand the P-User-Location- Info extension. There is a security risk if a P-User-Location-Info header field is allowed to propagate out of the Trust Domain where it was generated. In that case, user-sensitive information would be revealed. To prevent such a breach from happening, proxies MUST NOT insert the header when forwarding requests to a hop that is located outside the Trust Domain. When forwarding the request to a node in the Trust Domain, proxies MUST NOT insert the header unless they have sufficient knowledge that the route set includes another proxy or application server in the Trust Domain that understands the header, such as the home proxy or application server. There is no automatic mechanism to learn the support for this specification. Proxies and application servers MUST remove the header when forwarding requests to nodes that Niks Expires - December 2015 [Page 10] The SIP P-User-Location-Info Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem June 2015 are not in the Trust Domain or when the proxy or application server does not have knowledge of any other proxy or application server included in the route set that will remove it before it is routed to any node that is not in the Trust Domain. An end-point MUST NOT create and populate the P-User-Location-Info header. Should a SIP proxy detect an end-point has created and populated this, the SIP proxy MUST remove the header. Note, the SIP proxy MAY then generate its own trusted P-User-Location-Info header for onward forwarding. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 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] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 V10 [4] 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 V12 [5] Garcia-Martin, M.,Henrikson, E., Mills, D., .," Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)", RFC 3455, January 2003 [6] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [7] Braden, R., "Requirements for Internet Hosts -- Application and Support", RFC 1123, October 1989 [8] 3GPP, "Mobile Application Part (MAP) specification, 3GPP TS 29.002 V10" Niks Expires - December 2015 [Page 11] The SIP P-User-Location-Info Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem June 2015 [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[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. [10] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., Rosen, B., "Change Process for the Session Initiation Protocol (SIP)", RFC 3427, December 2002 The SIP P-User-Location-Info Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem June 2015 Acknowledgments Author's Addresses David Niks Vodafone Group Services GmbH Ferdinand-Braun-Platz 1, 40549, Duesseldorf Phone: Email: David.Niks@vodafone.com Andre Rameil-Green Vodafone Group Services GmbH Ferdinand-Braun-Platz 1, 40549, Duesseldorf Phone: Email: andre.rameilgreen@vodafone.com Niks Expires - December 2015 [Page 13]