Internet DRAFT - draft-sip-userlocationinfo
draft-sip-userlocationinfo
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:<sip:user@example> ; "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]
