2014 47th Hawaii International Conference on System Science

Vulnerability Analysis of LTE Location Services

Mark Hofer, John McEachen, Murali Tummala

Dept. of Electrical and Computer Engineering
Naval Postgraduate School
Monterey, California, United States of America
mark@thehof.com, {mceachen, mtummala}@nps.edu

Abstract
To meet government requirements for positioning
emergency services, Long Term Evolution (LTE), the latest
generation of mobile communications popular in North
America and Europe, incorporates the ability to ascertain the
position of the user equipment via the network. This additional
signaling means that there is also the chance that the user
position may be vulnerable to being intercepted by
unauthorized
parties.
Several
different
potential
vulnerabilities are explored in this paper and is a proof of
concept for three vulnerabilities, including the presence of
location data on the network when there is no authorized
request for that data active. A series of simulations were
constructed to analyze and test the logical flow of messages
through the LTE core network and to see what vulnerabilities
existed. The first simulation established a baseline, and each
additional simulation examined a possible vulnerability.
Index Terms3GPP, LTE, Vulnerability Assessment, mobile
positioning

1. Introduction
The consumer demand for higher data rates on mobile
devices has been pushing the suppliers of wireless service and
wireless equipment to the development of ever-evolving
mobile wireless standards to meet the demand. The leading
standard in North America and Europe is developed by Third
Generation Partnership Project (3GPP), a collection of
government
bodies
(e.g.,
Federal
Communications
Commission), telecommunications companies, and equipment
suppliers. The 3GPP standard for the high speed mobile
communications is Long Term Evolution (LTE) Release 10
and later, known as LTE-Advanced [1].
LTE has undergone several different releases. In Release 9,
the 3GPP started to introduce positioning of individual mobile
devices, known in LTE as user equipment (UE) via the core
network [2]. This was to meet various United States and
European regulations regarding emergency services,
collectively known as Enhanced 911 (E911) [3]. When a user
of this system dials 911 for emergency services, the users
location will be sent by the phone to the network to aid in quick
emergency response. Alternatively, if a person is known to be
in trouble the authorities may initiate a query of the phones
location by sending it a request through the network.
978-1-4799-2504-9 2014
U.S. Government Work Not Protected by U.S. Copyright
DOI 10.1109/HICSS.2014.635

Since most advanced model phones on the market include a

Global Positioning System (GPS) receiver, the information
often has highly accurate GPS positioning data. The ability to
locate someone using their phone, potentially without their
knowledge, makes securing this pathway an obvious concern.
If this was done by an adversary, accurate locations of key
personnel or of various military units (given the ubiquity of
mobile phones and their use for other types of communication
than just voice) would be available for use in planning. It is in
the interest of North American and European countries to
ensure that this information is secure for both national security
and public privacy reasons.

2. Related Work
Work in three separate areas is related in this work. The
first is geolocation of the user equipment using LTE. The
second is the use of Diameter as an Authentication,
Authorization, and Accounting (AAA) protocol. Finally, there
is the work on network vulnerability analysis in general. While
there is work in each of these areas, there is a paucity of work
relating the three areas, and to the authors knowledge there is
no related work in the area of vulnerability analysis of
Diameter messages on an LTE network.
The physical layer of LTE requires accurate timing of
arrival information to ensure proper transmission of data. This
information in contained in the timing advance field sent by the
eNB to the UE. With only timing advance measurements, it is
possible to generate a series of range bins from different towers
and get a fairly accurate location estimate for the UE [4].
The Diameter protocol [5] has been examined for use in
several areas as a replacement for RADIUS [6] or other
security schemes. Diameter has been proposed for use in
Internet Protocol version 6 (IPv6) networks [7], charging
mobile users for use of services from a different network
operator (e.g., wireless hot-spot) [8], and as the authentication
piece of a peer-to-peer session initiation protocol (SIP) voice
service [9]. There is an absence of published work on any
vulnerabilities of the Diameter protocol itself. This work
partially fills this gap in the research.
There has been a lot of work done on network
vulnerabilities. Work by Hill [10] has looked at Diameters
predecessor protocol, RADIUS. In it he identifies nine different
attacks and vulnerabilities in RADIUS. Some of these
vulnerabilities are addressed by the Diameter base protocol,
5162

the subscriber to be overridden by an authorized agent. The

specification is silent on the reason for the incorporation of this
feature, but it is assumed that this is done to allow for lawful
intercepts and to comply with court orders.
The Mobility Management Entity (MME) handles the
negotiation between the User Equipment (UE) and the GMLC
and preforms functions related to charging and billing and local
resource allocation. The MME serves as the last element on the
core network before the radio access network.
The Home Subscriber Server (HSS) houses LCS
subscription and routing information. As the UE moves around
the network, its location on the network gets updated at the
HSS so that phone calls and data can be routed to the user. This
information is necessary for the R-GMLC and the H-GMLC to
determine where next to route the location request.
LCS Clients are users of the location information generated
by the LCS location request. LCS Clients may be internal or
external to the service network. Internal clients would use the
information to improve network performance. External clients
would use the information for applications unrelated to
operating, maintaining, and improving the network. These uses
could include E911, tracking children, tracking company
personnel (e.g., salesmen or delivery vehicles), or any other
number of services. The standard does not specify any possible
external uses outside of emergency services and leaves the
creation of policy around use of location data up to the
individual service providers and their respective reg There are
two main types of LCS Service Requests that are handled on
the core network. They are Location Immediate Request and
Location Deferred Request. An immediate request asks for the
current location at the time of the request. A deferred request
asks for the UEs location at some time in the future, either at
some regular interval or when a particular event happens, such
as leaving an area [12].
LCS Service Requests are also categorized as mobile
originated or mobile terminated [12]. Mobile originated
requests are when the information is supplied by the UE in
anticipation of need by a LCS Client. An example is when
dialing emergency services; the location data is supplied with
the expectation that it will be used by emergency services to
respond faster. Mobile terminating service requests,
conversely, are initiated by a LCS Client via the network and
are answered by the UE when the request is validated and
dispatched to the mobile device.

Fig. 1. Logical layout of LCS on the LTE network.

others are delegated to Diameter applications, and still more are

addressed by the use of Internet Protocol Security (IPsec) [11].
Hill demonstrated the need for a move away from RADIUS
and, subsequently, the creation of Diameter.

3. Background
A. LTE Location Services
The LTE core network is composed of several different
logical devices operating on an internet protocol (IP) based
network. Each of these has specified functions and links on the
network. The LTE standard does not specify that each logical
device will be a unique physical device. The logical functions
as if they are separate units in keeping with the logical flow of
information as specified or implied in the standard are covered
in this section. Also, the LTE standard is extensive and only
how the units relate to LTE Location Services (LCS) are
focused on in this section. Other aspects of LTE, such as the
radio access network and the routing of user data (i.e., web
requests) are not covered. A high-level network topography for
LTE LCS is shown in Fig. 1.
The Gateway Mobile Location Centre (GMLC) is
fundamental to the operation of LCS on the network. All
routing data for the location request is handled by the GMLCs.
Since several GMLCs are involved in handling a single
request, they are further designated by their function in relation
to a specific request. The location request is transmitted to the
GMLC servicing the requestor and becomes the RequestingGMLC (R-GMLC). The R-GMLC then determines which
GMLC is acting as the home base for the user (i.e., which is the
Home-GMLC or H-GMLC) and forwards the request to that
server. The H-GMLC then determines which GMLC is
servicing the part of the network where the user is visiting (the
Visited-GMLC or V-GMLC) and forwards the request. Once
determined the location data flows back using the same path.
The Privacy Profile Register (PPR) is where the privacy
preferences of the subscriber are stored. These preferences are
checked to ensure the entity requesting the users location has
the right to know that location. The technical specifications
allow this functionality to be incorporated into the H-GMLC
[12]. The technical specifications also describe a Privacy
Override Indicator (POI) that allows for the privacy settings of

B. Diameter Base Protocol

The Diameter protocol is an extensible Authentication,
Authorization, and Accounting (AAA) protocol that is loosely
based on RADIUS (Remote Authentication Dial-In User
Service) [6]. RADIUS is not extensible, a shortcoming that
Diameter sought to address. Diameter is split into two
protocols: the Diameter Base Protocol and the Diameter
Extensions.
The Diameter Base Protocol is defined in RFC3588 [5]. It
is the core of the protocol on which all extensions operate. It
meets the requirements needed for a AAA protocol as specified
in [13]. The Base Protocol specifies the message format,

5163

transport, error reporting, accounting, and security services for

use by all Diameter applications [5].
Diameter Extensions add additional features onto the
Diameter Base. There is no central standard for extensions, but
any given extension may have its own standard. The LTE
extension of Diameter is discussed in the following section.
Authentication and authorization are always handled by
extensions of the Base Protocol for a specific application [14].
C. LTE use of the Diameter Protocol
LTE has settled on the use of Diameter to handle many of
its control messages on the core network. For example, [15]
deals with the Diameter messages between an HSS and two
other network elements not a part of LCS and [16] is concerned
with authentication of the UE to the HSS via bootstrapping
using Diameter messages. RFC 3589 is dedicated to reserving
command code numbers 300 through 313 [17]. AVP code
values and application ID values are designated in several
3GPP technical specifications (TS) in the 29 series.
A near complete list of all LTE specific AVPs is available
in 3GPP TS 32.299, [18]. In it each AVP is listed with its AVP
code number and the format of information it contains in the
value field. It often also gives the technical specification where
more information on that particular AVP can be found.
The data format itself can give insight into how the AVP
will be implemented. For example, the Location-Estimate AVP
is a string value [27]. The location estimate may be either
derived from radio measurements or from the GPS receiver at
the UE. This means that the location estimate may be human
readable and not require machine translation once it is
extracted from the Diameter message.
The Diameter interface between the MME and the GMLC
(SLg) is specified in 3GPP TS 29.172 [28]. The Diameter
command codes, AVPs, and application ID for the SLg
interface is specified in this specification.
The Diameter interface between the HSS and the GMLC
(SLh) is specified in 3GPP TS 29.173 [29]. In it the Diameter
command codes, AVPs, and application ID for the SLh
interface is specified. The decision tree and error codes for
handling the routing information request from the GMLC at the
HSS is also defined in this specification.
Several other interfaces are covered in the 29 series of
3GPP technical specifications. However, the interfaces covered
by the standard as of Release 10 are not exhaustive. Several
interfaces specified explicitly stated in the standard as present
are not defined as they relate to the Diameter protocol. For
example, the Lr interface is between two GLMCs, Le interface
is between an external LCS client and a GLMC, and the Lpp
interface is between a PPR and GMLC are they not specified
anywhere in the published standard. Many of the attributes of
the interface may be inferred from other interfaces.

Fig. 2.

Request spoofing legitimate LCS Client using forgetful R-GMLC for

stealth.

along with the discussion on why it may be a vulnerability and

the implications of the vulnerability are described. Some of the
vulnerabilities were tested in the simulations in this work.
A. Deferred Request Privacy Check
The technical specification concerning a mobile terminating
deferred request [12] is vague concerning a whether a privacy
check should occur on the initial request and it appears to have
only one privacy check. This takes place after the location of
the UE is already traversing the network. Consequently, if a
request originates with a LCS Client that does not have rights
to see the subscribers location data, it will still be filled, but
not make it back to the client. This is only half secure.
If an attacker has control of a LCS Client and a node on the
network closer to the actual location of the UE, the attacker can
send a deferred request and have it filled. Then by purely
passive means, the attacker can retrieve the location data at the
second controlled node (e.g., the Visited GMLC).
B. Privacy Override Indicator (POI)
The technical specifications are silent on how to implement
the POI and only state that it shall override or not override
and it shall not be transmitted to the MME [12]. This means
that the authenticity of POIs is left up to the vendor and the
security of the Diameter messages. The specifications do not
address how or even whether to validate a POI. This leaves
open the possibility that a POI will be spoofed or captured and
replayed.
C. Forgetful GMLC
It was determined necessary to keep a list of active LCS
Service Requests because the technical specifications did not
provide a way to include routing information for the LCS
Service Response in the Diameter messages. If an attacker
compromises a GMLC, he can alter the list of active requests.
By removing an active request from the list, he can make the
GMLC selectively forgetful. When the LCS Service Response
comes back to the forgetful GMLC, it will drop the packet, and
the originator will not receive the LCS Service Response.
The attacker could spoof legitimate requestor when sending
a request. The spoofed request can either be sent to the

4. Vulnerabilities in LTE Location Services

Over the course of this research, several potential
vulnerabilities were discovered in the technical specifications.
In his section, each of the proposed vulnerabilities discovered,

5164

H-GMLC or the R-GMLC; the attack is illustrated in Fig. 2

with the request going to the H-GMLC. Then, with a
compromised R-GMLC, the attacker can make sure that the
LCS Client that he is masquerading as will not receive the
response. This improves the attacks stealth and does not alert
the spoofed client that his identity has been compromised.
Alternatively, an attacker can use this as a denial-of-service
attack on the LCS Client.
D. Piggybacking on a Valid Request
Since each GMLC keeps a list of active LCS Service
Requests, if a valid request exists for a target UE, then there is
the possibility of piggybacking on that request. An attacker can
add his own request into the database of the R-GMLC or
H-GMLC. When a response to the valid request comes to the
GMLC, a response should be sent to both the originator of the
legitimate request and to the attacker who placed the phony
request in the database. If the R-GMLC is compromised with
this attack, the privacy check is bypassed regardless of the
implementation of the check. If the H-GMLC is compromised
instead, then the attacker may be able to exfiltrate the data
through other means or simply compromise the privacy check
itself.
E. Duplicate and Void AVPs
Because of the fairly open architecture of Diameter
messages, it is possible to have more than one of an AVP; i.e.,
a single message may have two AVPs with a code of 1 (UserName). This can be useful if transmitting information where
there are two different entries for a single field. However, in
most Diameter messages in LTE, duplicate AVPs are not
expected.
There is no requirement to check for duplicate AVPs when
they are not expected, nor is there a requirement to check to see
if all the AVPs in a message are valid. The AVP code 308 is
void [19] and is never to be transmitted. Should either of these
occur, it is likely that they will just be ignored or the earlier
value will be overwritten, depending on how the message
parsing is implemented.
This leaves open the possibility that the duplicate or void
AVPs could be used by an infiltrator on the network as a covert
channel between two nodes. These nodes would already
communicate with each other via Diameter messages and the
additional AVPs would ride on another, legitimate message.
Since this covert channel would ride on existing traffic,
detecting it by network analysis would be extremely difficult if
not impossible. The original Diameter message would also still
serve its function, helping maintain the covert nature of the
communication in the extra AVP.

5. Simulations and Results

A Java software package was written to test the
vulnerabilities in the discovered since the LTE Release 10
equipment was not available when the research was conducted.
The software used Java Diameter [20] to manage the Diameter
message format and transmission. The software allowed

several simulations to be run to test the logical flow of the LTE

LCS service messages.
The first simulation was a simplified mobile terminating
deferred request with the first series of acknowledgements
removed and the privacy check happening only upon the when
the location data was received at the H-GMLC. The simulation
demonstrated the first vulnerability discussed is present.
The next simulation was for the forgetful GMLC
vulnerability. The R-GMLC failed to store the LCS Service
Requests when it received and processed them. When the LCS
Service Response was received, the R-GMLC was unable to
determine the next address to forward the message on to and
the message was dropped.
Finally, two simulations were run to test a hypothetical
failed POI check. The first confirmed that a valid POI worked
in the software. The second provided an invalid POI (modulo
five not equal to zero) in an attempt to gain access to denied
location data. The POI check happened at the time when the
privacy check would happen and we determine that if
successful it would only return a value grating access to the
information without notification to the user. The failed check
prevented the LCS Client from receiving any location data and
returned an error message to the LCS Client.

6. Conclusions
The Long Term Evolution Location Services handling of
requests for location data and the transmission of that data on
the core network were analyzed in this thesis. The LCS
Location Requests and LCS Location Responses are in the
form of Diameter messages. Java code was written to simulate
the flow of Diameter messages from one logical LCS network
element to another. The software limited communication
between network elements to the transmission of Diameter
messages. Using the simulation software and the technical
specifications, we discovered five vulnerabilities. Three were
simulated using the software developed.
A. Significant Contributions
Three major contributions were made in this work. First, a
software package was developed to simulate the flow of
Diameter messages on the LTE LCS network. The software
was written in Java and made full use of object oriented
programming. Consequently, the software is able to be
extended to simulate other behaviors of LCS on the core
network
Additionally, we provided a basic proof of concept for three
of five vulnerabilities. Preforming a privacy check only on the
return of the location data means that a compromised node can
exfiltrate that location data without the request for it ever being
validated. The Privacy Override Indicator is a feature of LCS,
but the technical specifications do not outline or require the
authentication of a POI. This leads to the possibility of an
attacker spoofing a POI to get at location data he would
otherwise not be able to access. Finally, the need for each node
in the network to keep list of active LCS Service Requests
meant that it is vulnerable to alteration of that list.

5165

The other two vulnerabilities were discussed by this thesis.

By placing a false record at the R-GMLC, an attacker could
bypass the privacy check if an already validated request exists
for the target subscriber. Also, the presence of AVP codes
voided in the technical specifications and the use of duplicate
AVP codes in the same message leaves open the possibility of
using AVPs with those codes as a covert channel.
B. Remarks
Over the course of developing the Java code for the
simulations and running the simulations, several pieces of
information became apparent to the author. These are
discoveries of the implications of the way the technical
specifications are written. This includes what is left out of the
specifications or what is not yet written into the specifications.
Diameter messages generated by the simulations were all
small in size, usually 150260 bytes. LTE requires the use of
Stream Control Transmission Protocol (SCTP) for Diameter
messages. These small sizes mean that each Diameter message
is contained in one SCTP packet. Therefore, any attacker
sniffing the network either gets the whole message or misses it
entirely.
The structure of a deferred request is particularly vulnerable
to the capture of location data from unauthorized requests. We
can see from the results of the first simulation that, when a
privacy check does not occur on the original request, location
data from the UE can be present on the network before any
privacy check takes place. In this situation we still see the
location data on the network, even when there is no validated
need for the information. This issue is eliminated when a
problem with the request is found early as in simulation three
(unauthorized realm making the request).
Implementing POI check in the same manner as described
in this work keeps most of the rest of the network ignorant of
its use. Only those network elements between the LCS Client
and the PPR (i.e., the R-GMLC and H-GMLC) are aware that it
is even being transmitted. That means that any collection of the
subscribers location data for authorized government
surveillance (i.e., legal wiretap order) will keep the user in the
dark about the execution of the order except where the users
phone logs, if at all

References
[1] 3GPP. (2010, October) Lteportal.com. [Online].
http://lteportal.com/MediaChannel/Articles/LTE__LTEAdvanced;6/Regulation,_Standards,_Spectrum;31/ITUR_Confers_IMTAdvanced_%284G%29_Status_to_3GPP_LTE;1735?2
[2] 3GPP, "3GPP activities on Location Services," V0.0.1,
March 2012.
[3] 47 U.S.C. 615. (2011) Support for universal emergency
telephone
number.
[Online].
http://www.gpoaccess.gov/uscode/
[4] L. Jarvis, "Geolocation of LTE subscriber stations based

on the timing advance ranging parameter," Naval

Postgraduate School, Monterey, California, M.S. Thesis
December 2010.
[5] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, and J.
Arkko, "Diameter base protocol," IETF, RFC 3588,
September 2003.
[6] C. Rigney, S. Willens, A. Rubens, and W. Simpson,
"Remote Authentication Dial in User Service
(RADIUS)," IETF, RFC 2865 June 2000.
[7] R.M. Lopez, G.M. Perez, and A.F. Gomez Skarmeta,
"Implementing RADIUS and Diameter AAA systems in
IPv6-based scenarios," in Proc. 19th Int.l Conf. on
Advanced Information Networking and Applications, vol.
2, 2005, pp. 851855.
[8] F. Eyermann, P. Racz, C. Schaefer, B. Stiller, and T.
Walter, "Service-oriented accounting configuration
management based on Diameter," in Proc. IEEE Conf. on
Local Computer Networks, 2005, pp. 621623.
[9] L. Yu, X.i Liao, H. Jin, and P. Qin, "A hierachical VoIP
system based on peer-to-peer SIP: a manageable
approach," in Proc. 10th IEEE Int.l Conf. on Computer
and Information Technology, 2010, pp. 24942500.
[10] J. Hill. (2001, November) An analysis of the RADIUS
authentication
protocol.
[Online].
http://www.untruth.org/~josh/security/radius/radiusauth.html
[11] R. Atkinson and S. Kent, "Security architecture of the
Internet Protocol," IETF, RFC 2401, November 1998.
[12] 3GPP TS 23.271, "Functional stage 2 description of
Location Services," V10.2.0, March 2011.
[13] B. Aboba et al., "Criteria for evaluating AAA protocols
for network access," IETF, RFC 2989, November 2000.
[14] D. Matijaevi, I. Gizdi, and D. Huljeni, "Mechanisms
for Diameter service performance enhancement," in Proc.
17th Int. Conf. on Software, Telecommunications &
Computer Networks, September 2009, pp. 302306.
[15] 3GPP TS 29.329, "Sh interface based on the Diameter
protocol; Protocol details," V10.4.0, December 2012.
[16] 3GPP TS 29.109, "Zh and Zn Interfaces based on the
Diameter protocol," V10.0.0, March 2011.
[17] J. Loughney, "Diameter command codes for Third
Generation Partnership Project (3GPP) Release 5," IETF,
RFC 3589, September 2003.
[18] 3GPP TS 32.299, "Diameter charging applications,"
V10.5.0, March 2012.
[19] 3GPP TS 29.234, "3GPP system to Wireless Local Area
Network (WLAN) interworking," V10.2.0, September
2009.
[20] I. Jrgensen. (2012, June) Java Diameter Library.
[Online]. http://i1.dk/JavaDiameter/

5166