Upload
phamtruc
View
239
Download
1
Embed Size (px)
Citation preview
Eötvös Loránd University
Faculty of Informatics
Signaling traffic based online
topology reconstruction and
visualization in mobile networks
Bálint Molnár Lídia Boglárka Torma
Associate professor at ELTE Computer Science
Bruno Crispo
Associate Professor at University
of Trento, Italy
László Kottyán
Software Developer at Ericsson
Hungary Ltd.
Budapest, 2016.
Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1 Literature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Historical background . . . . . . . . . . . . . . . . . . . . . . 3
1.2 About VoLTE . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Before starting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1 The used topology . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 What a network monitoring tool needs to have . . . . . . . . . 10
3 Diameter protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1 Packet format . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Diameter Source and destination identi�cation methodology . 18
3.3 Targeted messages, interfaces, and nodes . . . . . . . . . . . . 19
4 S1AP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5 GTPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1 Targeted interfaces and nodes using GTPv2 . . . . . . . . . . 30
5.2 Methodology for GTPv2 . . . . . . . . . . . . . . . . . . . . . 31
6 Concluding passive methods on the investigated interfaces . . . . . . 37
7 Anonymization and de-anonymization . . . . . . . . . . . . . . . . . . 39
7.1 Anonymization . . . . . . . . . . . . . . . . . . . . . . . . . . 39
7.2 De-anonymization . . . . . . . . . . . . . . . . . . . . . . . . . 43
8 Security issues with web applications . . . . . . . . . . . . . . . . . . 47
9 Access control: Authentication and authorization . . . . . . . . . . . 51
9.1 Authorization methods . . . . . . . . . . . . . . . . . . . . . . 51
9.2 Authentication in general . . . . . . . . . . . . . . . . . . . . 54
9.3 Authentication in a single page web application (SPA) . . . . 55
9.4 User handling in a Network Monitoring Tool . . . . . . . . . . 59
10 Security Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
i
List of Figures
1 Network functions and interfaces under investigation . . . . . . . . . 9
2 Summary of the Diameter header format[10] . . . . . . . . . . . . . . 13
3 Summary of the Diameter AVP header format[10] . . . . . . . . . . . 14
4 An example for Diameter protocol. The lime brace stands for the
Request �ag, the orange for the Command Code and the dark green
for the Application Id. . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5 Example for S1AP codes . . . . . . . . . . . . . . . . . . . . . . . . . 23
6 GTP-U encapsulation of UE user plane tra�c[15] . . . . . . . . . . . 29
7 Secret key generation for each security classes[22] . . . . . . . . . . . 42
8 Double Submit Cookie[43] . . . . . . . . . . . . . . . . . . . . . . . . 48
9 The basic RBAC model with sessions[34] . . . . . . . . . . . . . . . . 52
10 Authentication with password . . . . . . . . . . . . . . . . . . . . . . 55
11 Responsibilities of the database, server, and client[42] . . . . . . . . . 56
ii
List of Tables
1 Common Diameter command codes . . . . . . . . . . . . . . . . . . . 16
2 Diameter Attribute-names and codes[10] . . . . . . . . . . . . . . . . 17
3 Diameter interfaces and network functions . . . . . . . . . . . . . . . 20
4 Diameter commands with the corresponding interfaces, network func-
tions and directions 1/2 . . . . . . . . . . . . . . . . . . . . . . . . . 21
5 Diameter commands with the corresponding interfaces, network func-
tions and directions 2/2 . . . . . . . . . . . . . . . . . . . . . . . . . 22
6 S1AP procedure codes 1/2 . . . . . . . . . . . . . . . . . . . . . . . . 25
7 S1AP procedure codes 2/2 . . . . . . . . . . . . . . . . . . . . . . . . 26
8 S1AP messages and initiators 1/2 . . . . . . . . . . . . . . . . . . . . 27
9 S1AP messages and initiators 2/2 . . . . . . . . . . . . . . . . . . . . 28
10 GTPv2 messages and corresponding interfaces 1/3 . . . . . . . . . . . 34
11 GTPv2 messages and corresponding interfaces 1/2 . . . . . . . . . . . 35
12 GTPv2 messages and corresponding interfaces 3/3 . . . . . . . . . . . 36
iii
Introduction
The 4G Telecommunication network's complexity lies not only in the numerous
interconnected elements but also in the various protocols used in the communication.
To secure the superior performance of these complex networks, it is essential to
monitor them e�ectively. One of the monitoring methods is to capture all the
messages between network functions (NF). A monitoring system has to gather and
analyze all the relevant messages transmitted between network functions to be able
to point out errors and misbehavior.
In a typical case, the architecture of the network is given as an input for the anal-
ysis of the captured tra�c. The input consists of the network functions, connections
between them and their IP addresses. The description format of the network ar-
chitecture is not standardized and the topology information is not always available,
therefore, it is important to �nd a way to automate the network topology discovery,
in order to construct the topology without prespeci�ed input.
The main problem which is investigated and shall be resolved is to �nd the most
appropriate logic or algorithm which is proper to discover all network functions and
connections among them by using passive methods. Messages transmitted between
network functions using diameter, S1AP, and GTPv2 protocols are to be examined
thoroughly, aiming to �nd a logic or algorithm to clearly specify the sender and
receiver function. Hence, the previously gathered IP addresses can be matched to
the right nodes.
While analyzing the transmitted messages, a monitoring tool user can access
sensitive data which he or she does not have the privilege to see. Hence, anonymiza-
tion and encryption are necessary. That implies a problem which has to be resolved,
that is the need of an extensive security plan and a comprehensive view on security
and privacy issues in a web application, including authentication and authorization,
concerning security issues in web applications and anonymization techniques.
In Section 1 a brief introduction to the evolution of the telecommunication net-
work and VoLTE can be found.
In Section 2 I de�ne the used topology including the network functions and
interfaces. I will also introduce a network monitoring tool in general with some
features and properties they need to have, namely topology reconstruction feature
and secure private data handling with authentication and authorization methods.
In the later sections, I investigate the question how a network topology can be
reconstructed by using passive methods. For this I introduce the protocols S1AP,
1
Diameter, and GTPv2, aiming to �nd a way or logic to clearly identify the source
and destination node of each transmitted message.
In Section 7 I introduce anonymization methods. This section also provides an
overview on the users' privacy details and data handling.
In Section 8 I discuss possible attacks a web application can su�er, like SQL-
injection, XSS and password issues.
Section 9 introduces authorization and authentication. More speci�cally, it dis-
cusses monitoring tool users' access rights and the accessibility of information with
di�erent privacy levels. This section also includes a brief overview of single page
applications and possible authentication problems, paying special attention to the
requirements of a network monitoring tool.
Finally, in Section 10 a summary of the investigated security issues and remedies
is provided.
2
1. LITERATURE 3
1 Literature
1.1 Historical background
A telecommunication network is a collection of network functions and links which are
connected so as to enable telecommunication between the terminals. For instance,
such networks are public switched telephone networks. In my thesis I work with one
of its varieties, namely mobile networks.
The history of mobile telephony dates back to the early twentieth century when
the American Telephone & Telegraph company �rst discussed developing a wireless
phone in 1915.[1] Since then by outgrowing its boundaries a great evolution has
occurred and today's network communication emerged.
The �rst system of mobile communication, the so-called GSM, is a standard
developed by the European Telecommunications Standards Institute (ETSI) to de-
scribe the protocols for second-generation (2G) digital cellular networks used by
mobile phones.[2, p. 529]
To replace �rst generation (1G) analog cellular networks the 2G digital networks
were developed, and by 2014 it has become the default global standard for mo-
bile communications. To include data communications, �rst circuit-switched then
packet-switched data transport was used via GPRS (General Packet Radio Services)
and EDGE (Enhanced Data rates for GSM Evolution or EGPRS). The latter along
with UMTS (Universal Mobile Telecommunications System) and HSPA (High-Speed
Packet Access) form the so-called 3G (digital voice and data) which is developed
and maintained by the 3GPP (3rd Generation Partnership Project).[4, Chapter
2.7] WCDMA (Wideband Code Division Multiple Access) also found in 3G mobile
telecommunications networks and is used in Japan. This is the most commonly used
member of the UMTS family.
At the end of 2004, the 3GPP Standardization Forum started to evaluate a new
radio technology as a successor for WCDMA (Wideband Code Division Multiple
Access). The new approach, the fourth generation (4G), was called Long Term
Evolution (LTE) advanced standards, which do not form part of the ETSI GSM
standard. In 2012 it was the fastest developing mobile system technology ever.[5,
VoLTE]
4
1.2 About VoLTE
But the story does not end here. As subscribers demand more services for less
money, it is vitally important for telecom operators to protect their pro�tability by
reducing delivery costs. The answer is to eliminate the need for separate voice and
data networks.
On the 19th of May in 2014 in Singapore, Singtel, in collaboration with Samsung
and Ericsson, unveiled 4G ClearVoice, the world's �rst commercial full-featured
Voice over LTE (VoLTE) service.[3]
It is a standardized IP Multimedia System (IMS)-based Voice Over IP (VoIP)
service and is designed to replace existing circuit-switched voice. While VoIP is
a generic term for any voice over IP service, VoLTE is a speci�c implementation
in the LTE standards, based on IMS. It unlocks richer conversation services and
lays a foundation for operators to o�er toll-grade quality using well-de�ned quality
of service (QoS) mechanisms.[6] VoLTE is expected to o�er operators a chance to
produce better service quality compared to OTT (Over-the-Top, such as Skype,
GTalk) competitors.
As written in [6, Validating VoLTE 2nd ed.] VoLTE is not just an upgrade, but
a whole new deal. Until it is not supported by all mobile phones in use, operators
need to provide seamless fallback to 2G/3G networks where LTE is not available.
However, VoLTE provides better quality, 3 times more capacity than 3G and
o�ers rich IP communications, including video calling and content sharing[7], the
circuit-switched fallback (CSFB) solution is still preferred by most of the mobile
operators because deploying a completely new system is expensive. CSFB is a
golden mean in a sense that operators use LTE for data tra�c while turning o� the
3G and 2G radios, and switch them on again only for incoming and outcoming calls.
Although this topology can reduce radio units' battery consumption in smartphones,
but call initiation is longer than in fully IP-based systems.[8]
Anite, a part of Keysight Technologies, developed a network monitoring system
called Nemo. In [9] they showed that according to their measurements, circuit-
switched networks deliver very good performance and excellent reliability. In the
case of WCDMA, the average value is slightly better than with GSM. As it was
expected, LTE CS fallback call set-up takes more seconds to establish a call. While
the WCDMA and GSM averages are between 2.4s and 3.3s, the CSFB is constantly
above 3.3s. VoLTE was also tested in di�erent maturity phases. The results show
vast improvement when the technology had been optimized further. The average
1. LITERATURE 5
duration of VoLTE call establishment with the latest version was around 3.2 seconds.
Validating VoLTE
Ensuring a high-quality VoLTE rollout requires end-to-end validation that begins
in the lab and continues into the live network. Throughout the chapters of [6,
Validating VoLTE 2nd ed.] the whole VoLTE network, its elements, the nodes and
certain messages between them are detailed along with the test con�guration for
each partition. The book outlines a VoLTE test plan that ensures a correct, stable,
and e�ective VoLTE deployment.
6
2. BEFORE STARTING 7
2 Before starting
2.1 The used topology
VoLTE, like other networks, consists of network elements: functions and interfaces.
My thesis mainly focuses on the nodes
• eNodeB (E-UTRAN Node B, also known as Evolved Node B)
• MME (Mobility Management Entity)
• S-GW (Serving Gateway)
• P-GW/PDN-GW (Packet Data network Gateway)
• PCRF (Policy Charging and Rules Function)
• HSS (Home Subscriber Server)
• SLF (Subscriber Location Function)
• P-CSCF (Proxy Call Session Control Function)
• I/S-CSCF (Interrogating/Serving Call Session Control Function)
• E-CSCF (Emergency � Call Session Control Function)
• MMTelAS and SCCAS (Multimedia Telephony Application Server and Service
Centralization and Continuity Application Server)
• ePDG (evolved Packet Data Gateway)
• TWAN (Trusted WLAN Access Network)
• 3GPP AAA (3GPP Authentication, Authorization, and Accounting)
• GMLC (Gateway Mobile Location Centre) and
• AP (Application Protocol).
The investigated protocols are Diameter, S1AP, and GTPv2.
Figure 1 shows the above-listed network functions with the interfaces among
them. In this thesis, the mainly targeted nodes are colored in blue, while the green
ones are for further future investigation. The green color is also used to indicate
interfaces which have importance for later jobs. For other interfaces three types of
8
color representations are used: yellow for S1AP, purple for diameter and brown for
GTPv2 protocol (see the bottom right corner for the legend).
There is one more node included in the diagram but not mentioned, yet: SGSN.
We will see in Section 5 that though it is not part of VoLTE, it has importance in
3G, and is possible to get messages sent via GTPv2 interfaces: S3, S4, and S16.
They are highlighted by using gray letters.
2.BEFORESTARTING
9
Figure 1: Network functions and interfaces under investigation
10
2.2 What a network monitoring tool needs to have
Among several properties a network monitoring tool needs to have automated con-
�guration and has to handle private user data.
Methods and environment
For the con�guration, a topology reconstruction algorithm needs to be de�ned.
For this two kinds of network discovery methods exist: active and passive. With
active methods the network can be discovered by sending additional messages in
order to collect IP addresses, and if possible, to discover Network Functions. Passive
monitoring method is used to capture all the messages between network functions,
analyze them, extract the information elements contained by the packages and decide
which IP address corresponds to which sender and receiver node.
In this Thesis, passive methods are investigated. The input consists of a trace
�le with the extension of .pcap, for which we use the program WireShark to open.
It provides a clear view of each message contained by the .pcap �le.
Security in a network monitoring tool
While analyzing the messages and collecting information, a network monitoring tool
user can have access to private data for which he or she does not have the privilege.
For instance, among GTPv2 messages, there are several which contains or condi-
tionally contains IMSI and MSISDN, which are two private data and not to reveal
publicly. Just for a few example, Create Session Request, Delete Session Request,
Downlink Data Noti�cation Acknowledge, Create Indirect Data Forwarding Tunnel
Request, Stop Paging Indication and many other messages contain this information
element.
Other types of sensitive private data can be found in diameter messages mainly
in the AVP header. For instance in User Data Request message contains
� Session-ID
� Origin-Realm
� Origin-Host
� Destination-Realm
� Destination-Host
� User-Identity.
2. BEFORE STARTING 11
Moreover, User Data Answer contains User-Data, and Subscriber Data Request en-
compasses User-Name and Subscription-Data. Most of the messages enclose Origin-
Host and Origin-Realm as well as User-Identity, which is also commonly present.
These pieces of information should be anonymized using cryptographic encryp-
tion functions. A privileged network monitoring tool user needs to see the existence
of these data but can carry out his duties without knowing them, hence, they can
work with encrypted information.
Revealing these private data without any restriction is dangerous. Unauthorized
access can lead to misuse of personal information including but not limited to ha-
rassment, espionage, and impersonation. Also, patterns of user behavior can be
created aiming to track the user and commit varied malicious actions.
Therefore, it is inevitable to deal with security issues, encrypt user data and
store them safely. However encryption can make attackers' job harder, penetration
is still possible and should be preceded by using input sanitization wherever user
input can be submitted, thus prevent unauthorized access to the databases. There
are also several �tricks� and attacks which can lead to unauthorized access.
Next to the above mentioned private data, that is IMSI and MSISDN, there are
equally important sensitive pieces of information that can be found in the network
monitoring tool users' account. For instance, the successful reconstruction of the
topology reveals the detailed structure of the inner network. A broad picture can
be seen by many, but the details like IP addresses and ports should be shown only
for network monitoring tool users who actually use these data for their work.
Therefore, a proper access handout implies the inevitability of an e�ective au-
thentication scheme. Comprehensive authorization and authentication in web ap-
plications are important tasks and needed to be handled.
12
3. DIAMETER PROTOCOL 13
3 Diameter protocol
Diameter is an Authentication, Authorization, and Accounting (AAA) protocol. It
is a message (packet) based protocol, where AAA nodes exchange messages and
receive Positive or Negative acknowledgment for each message exchanged between
nodes. Diameter was initially developed to overcome the limitations of RADIUS,
which is also an AAA protocol, but it had issues with reliability, scalability, security
and �exibility because it supports UDP, that does not use implicit hand-shaking
mechanism for providing the above-mentioned issues. Instead of UDP, Diameter
uses the TCP and SCTP for message exchange, which makes it reliable.[10][11]
3.1 Packet format
There are two types of messages: Request and Answer. Each message consists of a
Diameter header and a variable number of Attribute-Value Pairs (AVPs).
Diameter Header
As is shown in Figure 2, the header �elds are the following:
Figure 2: Summary of the Diameter header format[10]
• Version, to indicate Diameter Version. Now it must be set to 1.
• Message Length, to indicate the message length of the Diameter message in-
cluding the header �elds and the padded AVPs.
14
• Flags : the assigned bits are R (Request), P (Proxiable), E (Error), T (Poten-
tially re-transmitted message) and r (reserved). If the Request bit is set, that
is, R=1, then the message is a request. If cleared, that is, R=0, it indicates
an answer.
• Command code is a unique identi�er for each message. It is di�erent for each
type of request. Though the corresponding answer has the same command
code, the request �ag R is set to 0. The three columns of Table 1 shows the
listed message types, their abbreviations, and the command codes.
• Hop-by-Hop (H2H) Identi�er is a unique integer that aids in matching requests
and replies. The sender of an answer message MUST ensure that the H2H
Identi�er �eld contains the same value that was found in the corresponding
request.
• End-to-End (E2E) Identi�er is used to detect duplicate messages.
Note that the header �elds are mandatory to be present and �lled.
Diameter AVP header
Diameter AVPs carry speci�c authentication, accounting, authorization, and routing
information as well as con�guration details for the request and reply.
Figure 3: Summary of the Diameter AVP header format[10]
Figure 3 shows the format of the AVP header. One message can include several
AVPs, di�erentiated by the Attribute-name or code. Table 2 contains the possible
attribute values.
In my thesis, the most important AVPs are the Origin-Host and Origin-Realm.
These values are mandatory to be present in all Diameter messages. Similar to
3. DIAMETER PROTOCOL 15
the origin values, Destination-Host and Destination-Realm AVPs are also useful
but usually are not contained in the diameter messages. Destination-Host must
be present in all unsolicited agent initiated messages, and may be present in other
request messages, but - along with Destination-Realm - it is forbidden for answers
to contain it.
• Origin-Host identi�es the endpoint that originated the Diameter message. Its
value is guaranteed to be unique within a single host.
• The Origin-Realm contains the Realm of the originator of any Diameter mes-
sage.
• The absence of Destination-Host will cause a message to be sent to any Diame-
ter server supporting the application within the realm speci�ed in Destination-
Realm AVP.
• When Destination-Realm present, the Destination-Realm AVP is used to per-
form message routing decisions.
16
Command name abbr Code Command name abbr Code
AA-Request AAR 265 User-Data-Request UDR 306
AA-Answer AAA 265 User-Data-Answer UDA 306
Diameter-EAP-Request DER 268 Profile-Update-Request PUR 307
Diameter-EAP-Answer DEA 268 Profile-Update-Answer PUA 307
Abort-Session-Request ASR 274 Subscribe-Notifications-Request SNR 308
Abort-Session-Answer ASA 274 Subscribe-Notifications-Answer SNA 308
Accounting-Request ACR 271 Push-Notification-Request PNR 309
Accounting-Answer ACA 271 Push-Notification-Answer PNA 309
Credit-Control-Request CCR 272 Bootstrapping-Info-Request BIR 310
Credit-Control-Answer CCA 272 Bootstrapping-Info-Answer BIA 310
Capabilities-Exchange-Request CER 257 Message-Process-Request MPR 311
Capabilities-Exchange-Answer CEA 257 Message-Process-Answer MPA 311
Device-Watchdog-Request DWR 280 Update-Location-Request ULR 316
Device-Watchdog-Answer DWA 280 Update-Location-Answer ULA 316
Disconnect-Peer-Request DPR 282 Cancel-Location-Request CLR 317
Disconnect-Peer-Answer DPA 282 Cancel-Location-Response CLA 317
Re-Auth-Request RAR 258 Authentication-Information-Request AIR 318
Re-Auth-Answer RAA 258 Authentication-Information-Answer AIA 318
Session-Termination-Request STR 275 Insert-Subscriber-Data-Request IDR 319
Session-Termination-Answer STA 275 Insert-Subscriber-Data-Response IDA 319
User-Authorization-Request UAR 300 Delete-Subscriber-Data-Request DSR 320
User-Authorization-Answer UAA 300 Delete-Subscriber-Data-Response DSA 320
Server-Assignment-Request SAR 301 Purge-UE-Request PUR 321
Server-Assignment-Answer SAA 301 Purge-UE-Response PUA 321
Location-Info-Request LIR 302 Reset-Request RSR
Location-Info-Answer LIA 302 Reset-Answer RSA
Multimedia-Auth-Request MAR 303 Notify-Request NR 323
Multimedia-Auth-Answer MAA 303 Notify-Answer NA 323
Registration-Termination-Request RTR 304 Provide-Location-Request PLR 8388620
Registration-Termination-Answer RTA 304 Provide-Location-Answer PLA 8388620
Push-Profile-Request PPR 305 Routing-Info-Request RIR 8388622
Push-Profile-Answer PPA 305 Routing-Info-Answer RIA 8388622
Table 1: Common Diameter command codes
3. DIAMETER PROTOCOL 17
Attribute-Name Code Firmware-Revision 267Acct-Interim-Interval 85 Host-IP-Address 257Accounting-Realtime-Required 483 Inband-Security-Id 299Acct-Multi-Session-Id 50 Multi-Round-Time-Out 272Accounting-Record-Number 485 Origin-Host 264Accounting-Record-Type 480 Origin-Realm 296Accounting-Session-Id 44 Origin-State-Id 278Accounting-Sub-Session-Id 287 Product-Name 269Acct-Application-Id 259 Proxy-Host 280Auth-Application-Id 258 Proxy-Info 284Auth-Request-Type 274 Proxy-State 33Authorization-Lifetime 291 Redirect-Host 292Auth-Grace-Period 276 Redirect-Host-Usage 261Auth-Session-State 277 Redirect-Max-Cache-Time 262Re-Auth-Request-Type 285 Result-Code 268Class 25 Route-Record 282Destination-Host 293 Session-Id 263Destination-Realm 283 Session-Timeout 27Disconnect-Cause 273 Session-Binding 270E2E-Sequence 300 Session-Server-Failover 271Error-Message 281 Supported-Vendor-Id 265Error-Reporting-Host 294 Termination-Cause 295Event-Timestamp 55 User-Name 1Experimental-Result 297 Vendor-Id 266Experimental-Result-Code 298 Vendor-Specific-Application-Id 260Failed-AVP 279
Table 2: Diameter Attribute-names and codes[10]
18
3.2 Diameter Source and destination identi�cation method-
ology
To �nd a way or logic to clearly identify the source and destination network function
(NF), we mainly use the Application-ID. As is said in the beginning of this subsec-
tion, it is mandatory to be included in the diameter header. From the Application-
ID, we clearly can tell on which interface the message was transmitted. An example
for the Application-ID format is
ApplicationId: 3GPP Gx (16777238),
where '3GPP Sh` is the full name and 16777238 is the Application-ID, see Figure 4.
By knowing the interface we know the two nodes the message is transmitted
across. Most of the messages can be sent by only one of the endpoints. In this case
by knowing the Command Code, the value of �ag bit R and the Application-ID, we
can determine the source and destination unequivocally.
As shown in Figure 4, the Command Code is 272, which stands for Credit Con-
trol. The Request bit is not set, thus, the message is an Answer. As we know, Credit
Control Answer can be transmitted in multiple interfaces, hence, we need to know,
which one was used. From Application ID, we can read that the used interface is
Gx. From that it is obvious that the source NF is PGW and the destination node
is PCRF.
Figure 4: An example for Diameter protocol. The lime brace stands for the Request
�ag, the orange for the Command Code and the dark green for the Application Id.
In other cases, when in the same interface both directions or multiple senders
are possible, other methods are needed.
3. DIAMETER PROTOCOL 19
With the help ofOrigin-Host andOrigin-Realm, by subtracting the Origin-Realm
name from the Origin-Host, we can �nd the remaining part useful. In most cases it
contains information concerning network functions or corresponding company prod-
uct's name, so we can �lter by these values.
For instance, let us consider the message 'Insert-Subscriber-Data-Request`. A
possible host value is 'hss.tcu.ics.se` and the corresponding realm is 'tcu.ics.se`, so
the result of the subtraction is 'hss`, which matches its unique possible sender.
3.3 Targeted messages, interfaces, and nodes
Targeted diameter messages
Now let us take a look at the targeted messages. In Table 1 we already could see all
the possible command codes, but not all of them are important for us.
The excluded messages are
• Device-Watchdog-Request (DWR),
• Device-Watchdog-Answer (DWA),
• Capabilities-Exchange-Request (CER),
• Capabilities-Exchange-Answer (CEA),
• Disconnect-Peer-Request (DPR) and
• Disconnect-Peer-Answer (DPA).
DWR and DWA are irrelevant because they do not contain any relevant infor-
mation. Their only purpose is to keep the connection alive.
CER, CEA, DPR and DPA messages have signi�cance only when initiating and
aborting a connection.
20
Targeted diameter interfaces and nodes
The targeted messages use the interfaces, which are listed in the �rst column, be-
tween the network functions in the second column:
Rx: P-CSCF - PCRF
Gx/Gx+: PCRF - PGW
Cx: I-CSCF - HSS
Dx: I-CSCF - SLF
Dh: MMTelAS (or E-CSCF) - SLF
S6a: MME - HSS
Sh: MMTelAS (or E-CSCF) - HSS
(a) First priority
S6b: PGW - 3GPP AAA
Sx: MME - PCRF
SWx: 3GPP AAA - HSS
SLg/SLh: GMLC - MME
Zx: AP - HSS
Dzx: AP - SLF
(b) Second priority
Table 3: Diameter interfaces and network functions
Remark 1. The interfaces targeted in my thesis are listed in Table 3a. The ones
listed in Table 3b are for further investigation.
Remark 2. In the case of Sh and Dh, the sender can be E-CSCF and MMTelAS if
the command name is User-Data. This is the only relevant diameter message type
where Origin-Host is necessary to denominate the sender.
To �nd the list of message type with the corresponding functions and directions
see Table 4 and 5.
3.DIAMETERPROTOCOL
21
abbr Command name Code Interface Source Dest Interface2 Source2 Dest2 Interface Source DestAAR AA-Request 265 P-CSCF PCRF PGW 3GPP AAAAAA AA-Answer 265 PCRF P-CSCF 3GPP AAA PGWASR Abort-Session-Request 274 PCRF P-CSCF PCRF PGWASA Abort-Session-Answer 274 P-CSCF PCRF PGW PCRFCCR Credit-Control-Request 272 PGW PCRF MME PCRFCCA Credit-Control-Answer 272 PCRF PGW PCRF MMERAR Re-Auth-Request 258 PCRF P-CSCF PCRF PGWRAA Re-Auth-Answer 258 P-CSCF PCRF PGW PCRFSTR Session-Termination-Request 275 P-CSCF PCRF PGW 3GPP AAASTA Session-Termination-Answer 275 PCRF P-CSCF 3GPP AAA PGWUAR User-Authorization-Request 300 I-CSCF HSS I-CSCF SLFUAA User-Authorization-Answer 300 HSS I-CSCF SLF I-CSCFSAR Server-Assignment-Request 301 S-SCSF HSS S-SCSF SLF 3GPP AAA HSSSAA Server-Assignment-Answer 301 HSS S-SCSF SLF S-SCSF HSS 3GPP AAALIR Location-Info-Request 302 I-CSCF HSS I-CSCF SLFLIA Location-Info-Answer 302 HSS I-CSCF SLF I-CSCFMAR Multimedia-Auth-Request 303 S-SCSF HSS S-SCSF SLFMAA Multimedia-Auth-Answer 303 HSS S-SCSF SLF S-SCSFMAR Multimedia-Auth-Request 303 3GPP AAA HSS AP HSS AP SLFMAA Multimedia-Auth-Answer 303 HSS 3GPP AAA HSS AP SLF APRTR Registration-Termination-Request 304 HSS S-SCSF HSS 3GPP AAARTA Registration-Termination-Answer 304 S-SCSF HSS 3GPP AAA HSSPPR Push-Profile-Request 305 HSS S-SCSF HSS 3GPP AAAPPA Push-Profile-Answer 305 S-SCSF HSS 3GPP AAA HSSUDR User-Data-Request 306 MTAS/E-CSHSS MTAS/E-CSSLFUDA User-Data-Answer 306 HSS MTAS/E-CS SLF MTAS/E-CSCFPUR Profile-Update-Request 307 MTAS HSS MTAS SLFPUA Profile-Update-Answer 307 HSS MTAS SLF MTASSNR Subscribe-Notifications-Request 308 MTAS HSS MTAS SLFSNA Subscribe-Notifications-Answer 308 HSS MTAS SLF MTASPNR Push-Notification-Request 309 HSS MTASPNA Push-Notification-Answer 309 MTAS HSS
Rx S6b
Rx Gx
Gx/Gx+ Sx
Cx Dx
Rx Gx/Gx+
Rx S6b
Cx Dx
Cx Dx SWx
Cx Dx
SWx Zx Dzx
Cx SWx
Cx SWx
Sh Dh
Sh Dh
Sh Dh
Sh
Table 4: Diameter commands with the corresponding interfaces, network functions and directions 1/2
22
ULR Update-Location-Request 316 MME HSSULA Update-Location-Answer 316 HSS MMECLR Cancel-Location-Request 317 HSS MMECLA Cancel-Location-Response 317 MME HSSAIR Authentication-Information-Request 318 MME HSSAIA Authentication-Information-Answer 318 HSS MMEIDR Insert-Subscriber-Data-Request 319 HSS MMEIDA Insert-Subscriber-Data-Response 319 MME HSSDSR Delete-Subscriber-Data-Request 320 HSS MMEDSA Delete-Subscriber-Data-Response 320 MME HSSPUR Purge-UE-Request 321 MME HSSPUA Purge-UE-Response 321 HSS MMERSR Reset-Request 322 HSS MMERSA Reset-Answer 322 MME HSSNR Notify-Request 323 MME HSSNA Notify-Answer 323 HSS MMEPLR Provide-Location-Request 8388620 GMLC MMEPLA Provide-Location-Answer 8388620 MME GMLCRIR Routing-Info-Request 8388622 MME GMLCRIA Routing-Info-Answer 8388622 GMLC MME
Legend:
S6a
S6a
S6a
S6a
S6a
S6a
S6a
S6a
SLg
SLh
Everything is known just by looking at the command codeApplicationID is needed to know the interfaceUseful in the future, but now we do not need themCannot tell anything about it, maybe Origin host-Origin realm
Table 5: Diameter commands with the corresponding interfaces, network functions and directions 2/2
4. S1AP 23
4 S1AP
S1AP provides the signaling service between E-UTRAN and the evolved packet core
(EPC) that is required to ful�ll the S1AP functions
• E-RAB management function,
• Initial Context Transfer function,
• UE Capability Info Indication function,
• Mobility Functions,
• S1 interface management functions,
• NAS Signaling transport function,
• S1 UE context Release function,
• UE Context Modi�cation function,
• Status Transfer,
• Trace function,
• Location Reporting,
• S1 CDMA2000 Tunneling function,
• Warning message transmission function,
• RAN Information Management (RIM) function and
• Con�guration Transfer function.[12]
Basically, in this protocol, there is only one interface, S1-MME. Hence, it is not
hard to �nd the sender and the receiver NF, since the messages are transmitted
between eNodeB and MME. Most of the messages are one-directional, so the sender
is clear. The possible messages and the corresponding initiators are listed in Table 8
and in Table 9.
In each message the procedure name and message type is denoted by codes.
Table 6 and 7 show the logic how we can match them. The �rst two columns
list the procedure names and the corresponding codes. The third, fourth and �fth
columns show the message type: S1AP-PDU initiating Message has the number 0,
S1AP-PDU successful Outcome has 1 and S1AP-PDU Unsuccessful Outcome has 2.
Figure 5: Example for S1AP codes
24
For instance, if the procedure code is 23 and the S1AP-PDU number is 1 then
the message is UE CONTEXT RELEASE COMPLETE, as Figure 5 shows.
The problematic messages are
• RESET,
• RESET ACKNOWLEDGE and
• ERROR INDICATION.
By only taking these messages we cannot determine the direction, we need the
context. They appear only in case of error or misbehavior, therefore, in 90% of
the cases we can see other messages which can clearly determine the sender and
receiver. Apart from these three, the determination is straightforward for all the
other messages.
4. S1AP 25
S1AP-PDU initiaing Message
S1AP-PDU successful Outcome
S1AP-PDU Unsuccessful
OutcomeProcedure Procedure Code 0 1 2Handover Preparation 0 HANDOVER REQUIRED HANDOVER HANDOVER Handover Resource Allocation
1 HANDOVER REQUESTHANDOVER REQUEST ACKNOWLEDGE
HANDOVER FAILURE
Handover Notification 2
Path Switch Request 3 PATH SWITCH REQUESTPATH SWITCH REQUEST
PATH SWITCH REQUEST FAILURE
Handover Cancellation 4 HANDOVER CANCELHANDOVER CANCEL ACKNOWLEDGE
E-RAB Setup 5 E-RAB SETUP REQUEST E-RAB SETUP E-RAB Modify 6 E-RAB MODIFY REQUEST E-RAB MODIFY E-RAB Release 7 E-RAB RELEASE E-RAB RELEASE E-RAB Release Indication
8
Initial Context Setup 9INITIAL CONTEXT SETUP REQUEST
INITIAL CONTEXT SETUP RESPONSE
INITIAL CONTEXT SETUP FAILURE
Paging 10Downlink NAS Transport 11Initial UE Message 12Uplink NAS Transport 13Reset 14 RESET RESET ACKNOWLEDGEError Indication 15NAS non delivery indication 16S1 Setup 17 S1 SETUP REQUEST S1 SETUP RESPONSE S1 SETUP FAILUREUE Context Release Request 18DownlinkS1 CDMA2000 Tunnelling 19Uplink S1 CDMA2000 Tunnelling
20
UE Context Modification 21
UE CONTEXT MODIFICATION REQUEST
UE CONTEXT MODIFICATION
UE CONTEXT MODIFICATION
UE Capability Info Indication
22
UE Context Release 23UE CONTEXT RELEASE COMMAND
UE CONTEXT RELEASE COMPLETE
eNB Status Transfer 24MME Status Transfer 25Deactivate Trace 26Trace Start 27
Trace Failure Indication 28eNB Configuration Update
29ENB CONFIGURATION UPDATE
ENB CONFIGURATION UPDATE
ENB CONFIGURATION UPDATE FAILURE
Table 6: S1AP procedure codes 1/2
26
MME Configuration Update 30
MME CONFIGURATION UPDATE
MME CONFIGURAION UPDATE
MME CONFIGURATION
Location Reporting Control 31Location Reporting Failure Indication 32Location Report 33Overload Start 34Overload Stop 35
Write-Replace Warning 36WRITE-REPLACE WARNING REQUEST
WRITE-REPLACE WARNING RESPONSE
eNB Direct Information Transfer 37MME Direct Information Transfer
38
eNB Configuration Transfer 40MME Configuration Transfer 41Cell Traffic Trace 42Kill 43 KILL REQUEST KILL RESPONSEDownlink UE Associated LPPa Transport 44Uplink UE Associated LPPa Transport 45Downlink Non UE Associated LPPa Transport 46Uplink Non UE Associated LPPa Transport
47
PWS Failure Indication
PWS Restart Indication
Reroute NAS Request
UE Context Modification Indication
UE CONTEXT MODIFICATION INDICATION
UE CONTEXT MODIFICATION CONFIRM
UE Radio Capability Match
UE RADIO CAPABILITY MATCH REQUEST
UE RADIO CAPABILITY MATCH RESPONSE
PrivateMessage 39
E-RAB MODIFICATION INDICATION
E-RAB MODIFICATION INDICATION
E-RAB MODIFICATION CONFIRM
Table 7: S1AP procedure codes 2/2
4. S1AP 27
S1AP message groups message InitiatorE-RAB Setup Request MMEE-RAB Setup Response eNBE-RAB Modify Request MMEE-RAB Modify Response eNBE-RAB Release Command MMEE-RAB Release Response eNBE-RAB Release Indication eNBE-RAB Modification Indication eNBE-RAB Modification Confirm MMEInitial Context Setup Request MMEInitial Context Setup Response eNBInitial Context Setup Failure eNBUE Context Release Request eNBUE CONTEXT RELEASE COMMAND MMEUE Context Release Complete eNBUE Context Modification Request MMEUE Context Modification Response eNBUE Context Modification Failure eNBUE Radio Capability Match Request MMEUE Radio Capability Match Response eNBUE Context Modification Indication eNBUE Context Modification Confirm MMEHandover Required eNBHandover Command MMEHandover Preparation Failure MMEHANDOVER REQUEST MMEHandover Request Acknowledge eNBHANDOVER FAILURE eNBHandover Notify eNBPATH SWITCH REQUEST eNBPath Switch Request Acknowledge MMEPath Switch Request Failure MMEHandover Cancel eNBHndover Cancel Acknowledge MMEeNB Status Transfer eNBMME Status Transfer MME
Paging PAGING MMEINITIAL UE MESSAGE eNBDownlink NAS Transport MMEUplink NAS Transport eNBNAS Non Delivery Indication eNBReroute NAS Request MMERESET MME/eNBRESET ACKNOWLEDGE eNB/MMEError Indication MME/eNBS1 SETUP REQUEST eNBS1 SETUP RESPONSE MMES1 SETUP FAILURE MMEENB CONFIGURATION UPDATE eNB
NAS transport Messages
Handover Signalling Messages
Context Management Messages
E-RAB management Messages
Management Messages
Table 8: S1AP messages and initiators 1/2
28
S1AP message groups message InitiatorENB CONFIGURATION UPDATE ACKNOWLEDGE MMEENB CONFIGURATION UPDATE FAILURE MMEMME CONFIGURATION UPDATE MMEMME CONFIGURATION UPDATE ACKNOWLEDGE eNBMME CONFIGURATION UPDATE FAILURE eNBOVERLOAD START MMEOVERLOAD STOP MMEDownling S1 CDM2000 Tunneling MMEUplink S1 CDMA2000 Tunneling eNB
UE Capability Info Indication UE Capability Info Indication eNBTrace Start MMETrace Failure Indication eNBDeactivate Trace MMELocation Reporting Control MMELocation Report Failure Indication eNBLocation Report eNBWRITE-REPLACE WARNING REQUEST MMEWRITE-REPLACE WARNING RESPONSE eNBKILL REQUEST MMEKILL RESPONSE eNBPWS Restart Indication eNBPWS Failure Indication eNB
eNB Direct Information Transfer eNB DIRECT INFORMATION TRANSFER eNBMME direct Information Transfer MME DIRECT INFORMATION TRANSFER MME
eNB Configuration Transfer eNB CONFIGURATION TRANSFER eNBMME Configuration Transfer MME CONFIGURATION TRANSFER MME
Cell Traffic Trace Cell Traffic Trace eNBDownlink UE Associated LPPA Transport MMEUplink UE Associated LPPA Tranport eNBDOWNLINK NON UE ASSOCIATED LPPA TRANSPORT MMEUPLINK NON UE ASSOCIATED LPPA TRANSPORT eNB
S1 CDMA2000 Tunneling Messages
Trace Messages
Location Reporting Messages
Warning message transmission Messages
LPPa transport Messages
Management Messages
Table 9: S1AP messages and initiators 2/2
5. GTPV2 29
5 GTPv2
GPRS Tunneling Protocol (GTP) is present at all levels of LTE.
GTP is an important IP/UDP-based communications protocol used in GSM,
UMTS, and LTE core networks. It is used to encapsulate user data when pass-
ing through core network and also carries bearer speci�c signaling tra�c between
various core network entities.[15] GTP tunnels are used between two nodes commu-
nicating over a GTP based interface, to separate tra�c into di�erent communication
�ows.[14]
The advantages of GTP and one of the reasons why is used in LTE is the mobility.
In particular, when the User Equipment (UE) is mobile, the IP address remains the
same and packets are still forwarded since tunneling is provided between PGW and
eNB via SGW. Another bene�t is that multiple tunnels (bearers) can be used by the
same UE to obtain di�erent network QoS. Moreover, to provide security the main
IP address remains hidden.
Figure 6: GTP-U encapsulation of UE user plane tra�c[15]
For better understanding, it works as follows. Look at the case when an IP packet
generated by UE reaches to eNodeB and is then forwarded to SGW. Consider that
any application on UE creates an IP/TCP packet. This packet consists of actual
data by application, TCP or UDP header and the IP �eld information which has
source address of UE and destination address of application server.
As Figure 6 shows, when the eNodeB receives this packet it will put the IP packet
inside the GTP header. Then it is encapsulated inside the UDP and IP header and
forwarded as Ethernet frame toward the SGW. Here the IP header contains eNodeB
IP as a source address and SGW IP as a destination address.[15]
30
There are three GPRS Tunneling Protocol Types:
• GTP-C, the control part of GTP. Used for core network speci�c signaling in
GPRS, UMTS and LTE networks.
• GTP-U, used in user plane to carry user data tra�c in GPRS, UMTS and
LTE networks.
• GTP', it has the same message structure as GTP-C and GTP-U, but its pur-
pose is to carry charging data from the CDF of the GSM or UMTS to the
CGF.[15]
Today GTP has two versions. In LTE, GTPv2 is used for GTP-C on S5, S11,
S2a and S2b, and GTPv1 for GTP-U on S1-U, S5 and X2-U interfaces. Moreover,
S3, S4, S8, S10, S12 and S16 interfaces also utilize GTP protocols.
5.1 Targeted interfaces and nodes using GTPv2
In my thesis I focus on version 2, thus, I am investigating mainly interfaces between
nodes and control part of the signaling, for which GTP-C is used. These nodes and
interfaces are
• MME � MME (S10),
• MME � SGW (S11),
• SGW � PGW (S5/S8),
• ePDG � PGW (S2b) and
• TWAN � PGW (S2a).
However SGSN is not contained in the topology described in Section 2, it is still
likely to get a �le that contains messages sent by/to the SGSN on interfaces S3
(SGSN � MME), S4 (SGSN � SGW) and S16 (SGSN � SGSN). It is possible since
SGSN is not a part of VoLTE but has importance in 3G. To preclude the chance of
mistreating a message, two options are possible:
1. pre�ltering the list of messages before feeding the network discovery algorithm
in order to obtain messages sent only on the supported interfaces;
2. the network discovery method should be intelligent enough to recognize these
messages and handle them properly.
5. GTPV2 31
5.2 Methodology for GTPv2
The di�culty is that most of the messages do not contain any information about
the used interface, hence, each message requires di�erent logic to decide.
But before a deeper explanation, �rst a short introduction on TEID and F-TEID
is needed.
GTP Tunnel, TEID, F-TEID
To fully understand these abbreviations, a few de�nitions are necessary to be dis-
cussed.
De�nition 1 ([13]). A GTP tunnel is a communication tunnel between two GTP
nodes. It is used to separate tra�c into di�erent communication �ows.
De�nition 2 ([13]). A tunnel endpoint is identi�ed with a TEID, an IP address
and a UDP port number.
De�nition 3 ([13]). Tunnel Endpoint Identi�er (TEID) unambiguously iden-
ti�es a tunnel endpoint in scope of a path.
A GTP tunnel is identi�ed in each node by a TEID, an IP address, and a UDP
port number. The receiving end side of a GTP tunnel locally assigns the TEID value
that the transmitting side has to use. For the value exchange, GTP-C messages are
used.
The TEID-C shall be unique per PDN-Connection on GTP based S2a, S2b, S5
and S8 interfaces, and there shall be only one pair of TEID-Cs per UE on each of
the S11, S4, S3, S10 and S16 interfaces.
TEID is compulsory for most of the messages. In GTPv2 header, a �ag T
indicates its presence. The most common message among the exceptions, where T
should be set to 0, is Create Session Request. This is the one which includes the �S11
MME DL TEID� and the �S5 SGW DL TEID�, which are generated and included by
MME and SGW respectively. As an answer, the Create Session Response includes
the �S5 PGW UL TEID� and the �S11 SGW UL TEID�, which are generated and
included by PGW and SGW respectively.
The TEID value itself does not provide any information, we need the Fully-
quali�ed TEID (F-TEID) to match the TEID value to the corresponding IP address.
32
Luckily, F-TEID-type IEs are included in several messages, like
• Sender F-TEID for Control Plane,
• S1-U eNodeB F-TEID,
• S5/S8-U PGW FTEID,
• S2a-U PGW F-TEID,
• S2b-U PGW F-TEID,
• S4-U SGSN F-TEID,
• S12 RNC F-TEID.
Except for the �rst and third item, if one of the rest appears in the message, we
immediately can tell which interface was used. �Sender F-TEID for Control Plane�
carries useful information about the sender node, therefore, it can be used to decide
if the sender was MME or SGSN.
If �S1-U eNodeB F-TEID� is present, the interface is S11. With the same logic,
�S2a-U PGW F-TEID�, �S2b-U PGW F-TEID�, �S4-U SGSN F-TEID� and �S12
RNC F-TEID� indicate interface S2a, S2b, S4 and also S4, respectively.
�S5/S8-U PGW F-TEID� is slightly di�erent: in messages Create Session Re-
quest, Create Session Response, and Create Bearer Request if this Information Ele-
ment (IE) is not present, then the used interface had to be S2a or S2b. The expla-
nation is that on S2a/b the communication is carried out between TWAN/ePDG
and PGW, thus, there is no need to send any messages between SGW and PGW on
S5/S8.
But F-TEID type information elements are useful not just to draw conclusion
about the particular message but to obtain NF-IP pairs which can be used for further
identi�cations.
Additionally, there are other IEs, which if included, the used interface is known.
In particular in Bearer Resource Command �Tra�c Aggregate Description (TAD)� is
present only on S11, in Context Request �Routeing Area Identity (RAI)� and �GUTI�
indicates S3 and S10, respectively. The same is true for Identi�cation Request.
Another unusual utilization of TEID is the condition of T=0 or T=1. It is a
unique, not too e�ective but interesting solution. In Suspend Noti�cation message
if TEID is set to 0, the source is SGSN. The explanation lays in the condition that
5. GTPV2 33
if TEID is 0, the interface is S3 or S16, and if 1, the interface is S11/S4 or S3. With
the help of mathematical logic we can formalize this as follows:
S3 ∨ S4/S11 → SGSN ∨ (MME ∨ SGSN) = SGSN ∨MME
S3 ∨ S16 → SGSN ∨ SGSN = SGSN,
where the �rst line shows the sources in case of T=1 and the second in T=0.
Similar to the above case, with the same logic we can conclude that in case of
Suspend Acknowledge message the destination node is SGSN when T=0.
Table 10, 11 and 12 show the decision criteria of each message being sent on
interface GTPv2.
In these tables, if a network function is highlighted in light green, it signi�es that
we can clearly assign an IP address to it, without even looking at the content of the
message. If the message name itself is highlighted in light green it signi�es that the
information elements provided by this exact message are enough for the matching.
Fortunately, these messages are very common in any .pcap �le, therefore, other
messages are not required any more. There are also cases when the only problem is
the inability to di�erentiate between SGSN and MME. This to be resolved requires
other logic and technique which is for further future investigation. It also concerns
the decision problem between TWAN and ePDG.
For more coloring de�nitions see the legend in Table 12.
34
GTPv2 message Interface source dest Interfa source dest Interface source destECHO REQUESTECHO RESPONSEVersion Not Supported IndicationCreate Session Request S11/S4 MME/SGSN SGW S2a/b TWAN/ePDG PGW S5/S8 SGW PGWCreate Session Response S11/S4 SGW MME/SGSN S2a/b PGW TWAN/ePDG S5/S8 PGW SGWCreate Bearer Request S11/S4 SGW MME/SGSN S2a/b PGW TWAN/ePDG S5/S8 PGW SGWCreate Bearer Response S11/S4 MME/SGSN SGW S2a/b TWAN/ePDG PGW S5/S8 SGW PGWBearer Resource Command S11/S4 MME/SGSN SGW S2a/b TWAN/ePDG PGW S5/S8 SGW PGWBearer Resource Failure Indication S11/S4 SGW MME/SGSN S2b PGW TWAN/ePDG S5/S8 PGW SGWModify Bearer Request S11/S4 MME/SGSN SGW S5/S8 SGW PGWModify Bearer Response S11/S4 SGW MME/SGSN S5/S8 PGW SGWDelete Session Request S11/S4 MME/SGSN SGW S2a/b TWAN/ePDG PGW S5/S8 SGW PGWDelete Session Response S11/S4 SGW MME/SGSN S2a/b PGW TWAN/ePDG S5/S8 PGW SGWDelete Bearer Request S11/S4 SGW MME/SGSN S2a/b PGW TWAN/ePDG S5/S8 PGW SGWDelete Bearer Response S11/S4 MME/SGSN SGW S2a/b TWAN/ePDG PGW S5/S8 SGW PGWDownlink Data Notification S11/S4 SGW MME/SGSNDownlink Data Notification Acknowledge S11/S4 MME/SGSN SGWDownlink Data Notification Failure Indication S11/S4 MME/SGSN SGWDelete Indirect Data Forwarding Tunnel S11/S4 MME/SGSN SGWDelete Indirect Data Forwarding Tunnel Response S11/S4 SGW MME/SGSNModify Bearer Command S11/S4 MME/SGSN SGW S2a/b TWAN/ePDG PGW S5/S8 SGW PGWModify Bearer Failure Indication S11/S4 SGW MME/SGSN S2a/b PGW TWAN/ePDG S5/S8 PGW SGWUpdate Bearer Request S11/S4 SGW MME/SGSN S2a/b PGW TWAN/ePDG S5/S8 PGW SGWUpdate Bearer Response S11/S4 MME/SGSN SGW S2a/b TWAN/ePDG PGW S5/S8 SGW PGWDelete Bearer Command S11/S4 MME/SGSN SGW S5/S8 SGW PGWDelete Bearer Failure Indication S11/S4 SGW MME/SGSN S5/S8 PGW SGWCreate Indirect Data Forwarding Tunnel S11/S4 MME/SGSN SGWCreate Indirect Data Forwarding Tunnel Response S11/S4 SGW MME/SGSNRelease Access Bearers Request S11/S4 MME/SGSN SGWRelease Access Bearers Response S11/S4 SGW MME/SGSNStop Paging Indication S11/S4 SGW MME/SGSNModify Access Bearers Request S11 MME SGWModify Access Bearers Response S11 SGW MMERemote UE Report Notification S11 MME SGW S5/S8 SGW PGWRemote UE Report Acknowledge S11 SGW MME S5/S8 PGW SGWForward Relocation Request S10/S3/S16 MME SGSN (in S3 the direction is MME->SGSN)
Table 10: GTPv2 messages and corresponding interfaces 1/3
5.GTPV2
35
Forward Relocation Response S10/S3/S16 SGSN MME (in S3 the direction is SGSN->MME)Forward Relocation Complete Notification S10/S3/S16 SGSN MME (in S3 the direction is SGSN->MME)Forward Relocation Complete Acknowledge S10/S3/S16 MME SGSN (in S3 the direction is MME->SGSN)Context Request S10/S3/S16 MME/SGSN SGSN/MMEContext Response S10/S3/S16 MME/SGSN SGSN/MMEContext Acknowledge S10/S3/S16 SGSN/MME MME/SGSNIdentification Request S10/S3/S16 MME/SGSN SGSN/MMEIdentification Response S10/S3/S16 SGSN/MME MME/SGSNForward Access Context Notification S10/S16 MME/SGSN MME/SGSNForward Access Context Acknowledge S10/S16 MME/SGSN MME/SGSNDetach Notification S3 MME/SGSN SGSN/MMEDetach Acknowledge S3 SGSN/MME MME/SGSNChange Notification Request S11/S4 MME/SGSN SGW S5/S8 SGW PGWChange Notification Response S11/S4 SGW MME/SGSN S5/S8 PGW SGWRelocation Cancel Request S10/S3/S16 MME/SGSN SGSN/MMERelocation Cancel Response S10/S3/S16 SGSN/MME MME/SGSNConfiguration Transfer Tunnel S10 MME MMERAN Information Relay S3 MME/SGSN SGSN/MMEISR Status Indication S3 MME/SGSN SGSN/MMEUE Registration Query Request S3 SGSN MMEUE Registration Query Response S3 MME SGSNSuspend Notification S11/S4 MME/SGSN SGW S3/S16 SGSN MME S5/S8 SGW PGWSuspend Acknowledge S11/S4 SGW MME/SGSN S3 MME SGSN S5/S8 PGW SGWResume Notification S11/S4 MME/SGSN SGW S5/S8 SGW PGWResume Acknowledge S11/S4 SGW MME/SGSN S5/S8 PGW SGWCS Paging Indication S3 MME SGSNAlert MME Notification S3 MME SGSNAlert MME Acknowledge S3 SGSN MMEUE Activity Notification S3 SGSN MMEUE Activity Acknowledge S3 MME SGSNCreate Forwarding Tunnel Request S11 MME SGWCreate Forwarding Tunnel Response S11 SGW MMEDelete PDN Connection Set Request S11 MME/SGW SGW/MME S2a/b TWAN/ePDG/PGW PGW/TWAN/ePDG S5/S8 PGW/SGW SGW/PGWDelete PDN Connection Set Response S11 SGW/MME MME/SGW S2a/b PGW/TWAN/ePDG TWAN/ePDG/PGW S5/S8 SGW/PGW PGW/SGWUpdate PDN Connection Set Request S5/S8 SGW PGWUpdate PDN Connection Set Response S5/S8 PGW SGWPGW Restart Notification S11/S4 SGW MME/SGSNPGW Restart Notification Acknowledge S11/S4 MME/SGSN SGW
Table 11: GTPv2 messages and corresponding interfaces 1/2
36
PGW Downlink Triggering Notification S11/S4 SGW MME/SGSNPGW Downlink Triggering Acknowledge S11/S4 MME/SGSN SGWTrace Session Activation S11/S4 MME/SGSN SGW S2a/b TWAN/ePDG PGW S5/S8 SGW PGWTrace Session Deactivation S11/S4 MME/SGSN SGW S2a/b TWAN/ePDG PGW S5/S8 SGW PGWMBMS Session Start Request Sm/Sn MBMS GW MME/SGSNMBMS Session Start Response Sm/Sn MME/SGSN MBMS GWMBMS Session Update Request Sm/Sn MBMS GW MME/SGSNMBMS Session Update Response Sm/Sn MME/SGSN MBMS GWMBMS Session Stop Request Sm/Sn MBMS GW MME/SGSNMBMS Session Stop Response Sm/Sn MME/SGSN MBMS GW
Legend:We know all NEsOptional IEs + MME/SGSN decision problemMME/SGSN decision problem onlyWe know at least one NEOptional IEs but known MME/SGSNOptional IEs Cannot tell anything about itNot relevant
Table 12: GTPv2 messages and corresponding interfaces 3/3
6. CONCLUDING PASSIVE METHODS 37
6 Concluding passive methods on the investigated
interfaces
While the passive method works pretty well on Diameter and S1AP, the way how
to exploit Information Elements embedded in GTPv2 messages probably not really
e�ective.
For S1AP messages we only need to know the name of the message, and choose
the corresponding row from Table 8 and 9 to get the initiator node.
For Diameter messages, the �rst step is obtaining the command code, with a
help of the Request �ag deciding whether it is an answer or request type, then by
using the color representation from Table 5 deciding among the three cases:
1. Command Code is enough;
2. Application ID check is needed;
3. Cannot tell anything about the message.
In case 1 choose the corresponding row from Table 4 and 5. In case 2 �nd the
used interface in Application ID �eld, then choose the corresponding row from the
table and �nd the matching interface. In case 3 skip the message.
For GTPv2 it is di�erent. The useful information elements found in the packets
most of the times are not mandatory, and we cannot be sure that we can use them
for further investigation. Hence, if we receive a trace �le which does not start with
a Create Session Request, probably we will not be able to tell anything about the
source and destination node. Perhaps, in this case, the active method can help and
provide a much more comprehensive solution, which I will not detail in my thesis.
38
7. ANONYMIZATION AND DE-ANONYMIZATION 39
7 Anonymization and de-anonymization
7.1 Anonymization
As for many systems which gather messages containing user data, a network monitor-
ing tool (NMT) also needs to have a secure environment to handle private informa-
tion. Security does not only consist of anonymization, but it is one of its important
branches. Likewise, it is a recent topic in the world of security and privacy.
In a .pcap �le which is loaded in a network monitoring tool, the main private data
types are MSISDN (Mobile Station International Subscriber Directory Number) and
IMSI (International mobile subscriber identity), but there are other sensitive pieces
of information like IPv4 and IPv6, which needs to be handled carefully. The �rst
two are important numbers used for identifying a mobile subscriber, and are saved
in an encrypted database. There is also a uniquely assigned UserID for each of the
pairs. None of the private data listed in Section 2 should be revealed in the NMT
interface, therefore, they should be encrypted before being stored, hence, risks from
security leaks can be eliminated.
The storing mechanism works as follows:
1. reading .pcap �le,
2. collecting private data (MSISDN, IMSI, IPv4 & IPv6, etc.),
3. encrypting private data,
4. assigning a unique UserID,
5. storing encrypted MSISDN and IMSI in database with the corresponding
UserID,
6. exchanging private data values (except for MSISDN and IMSI) for their en-
crypted form in the loaded .pcap �le,
7. exchanging MSISDN and IMSI for UserID in the loaded .pcap �le.
Encryption schemes
Many good and robust encryption schemes are known and applied for securing
databases, which have to meet security requirements that normally include
• prevention of unauthorized disclosure of information,
• prevention of unauthorized modi�cation of information,
40
• prevent denial of service,
• prevent system penetration by unauthorized person and
• prevent the abuse of special privileges.[21]
Hybrid cryptography
A possible encryption method can be based on hybrid cryptography, a quite attrac-
tive database encryption technique with added security by use of two encryption
algorithms.
In 2010, Xing-hui and Xiu-jun[24] came up with an encryption system based
on International Data Encryption Algorithm (IDEA) combined with the Rivest-
Shamir-Adleman cryptosystem (RSA). This hybrid scheme in 2015 has still been
considered as safe and e�ective in a cryptographic manner.[23]
Hybrid cryptography is widely used nowadays because it combines the conve-
nience of a public-key cryptosystem with the e�ciency of a symmetric-key cryp-
tosystem in the following way: data encapsulation is done by symmetric-key, while
public-key cryptography is used as the key exchange mechanism.
Because of the huge amount of data we have to consider that the encryption
algorithm should be e�ective in the sense of preventing data reconstruction, and
fast at the same time. In 2010, Sharif and Mansoor[25] have done performance
analysis to compare stream and block cipher algorithms. Among block ciphers, they
tested IDEA, Serpent, CAST-5, RC2, RC5 and Blow�sh. Considering the speed
IDEA produced the worst result out of all the algorithms. Though IDEA is slower,
it is cryptographically more secure.
The proposition is, that instead of IDEA, use its successor IDEA NXT from 2003
(used to call FOX). It is also a symmetric block cipher that was developed to have
high-security level and large implementation possibilities. In [26] O'Kee� et.al tried
di�erent strategies for IDEA NXT implementation to test network performance pa-
rameters and found a way which resulted in increased speed and decreased memory
requirements while making no changes in power consumed.
Another possible choice for private key cryptography is AES. In [27], Nadeem
and Javed implemented four block cipher algorithms in order to compare their per-
formance. These four standards were DES, Triple DES, AES, and Blow�sh. What
they found is that the fastest was Blow�sh, then DES, AES and the slowest was
Triple DES. According to their results on the average execution times, AES is two
times slower than Blow�sh, which means that taking the values from [25] we can
7. ANONYMIZATION AND DE-ANONYMIZATION 41
conclude that AES is performing better than IDEA, which was four times slower
than Blow�sh.
The reason why DES or Blow�sh are not considered as a possibility is that
both are proved to be insecure. Against DES brute-force attack is e�ective. As for
Blow�sh it is known to be susceptible to attacks on re�ectively weak keys.[28][29]
IPv4 & IPv6 encryption can be done by using hybrid cryptography immediately
and substituting the encrypted values for the raw values in the .pcap �le right after.
If an NMT user wants to see the real data, by clicking on the encryption button,
the decryption is being performed and the raw data is revealed. This works only if
the current user has the access right to the corresponding data.
Attribute-based Encryption (ABE)
By going further, the question arises: is it possible to assign di�erent security level
to the di�erent types of data? The answer is yes, with the help of a cryptographic
encryption method, Attribute-based Encryption (ABE) schemes.
In a network monitoring tool, there are two di�erent types of data: classi�ed and
unclassi�ed. Unclassi�ed data can be stored in the clear without encryption, but
the sensitive data should be encrypted. Sensitive data is the above mentioned IMSI
and MSISDN, as well the monitoring tool users' personal data, such like settings,
results, and loaded �les, also shared �les when working in groups. To assign a
security level to each user of the tool, there are several schemes and methods which
can be chosen, including but not limited to RBAC, MAC, DAC, and TBAC. More
about them can be found in Section 9.1. Their implementation is based on attribute-
based encryption.
ABE is widely used for big data storage encryption, and makes it possible to
generate a public key for encrypting data and have been used as an access policy to
control users' access by exploiting attributes.[30]
In practice it is used as in hybrid cryptography: encrypt the database using
symmetric key cryptography, then encrypt the keys with ABE scheme. It is logical
since when encrypting a huge dataset like in a case of a network monitoring tool,
too many primes and therefore too much computation is needed.
For an example of a strong ABE algorithm, in 2012, Hwang and Yang[22] pro-
posed a multilevel database encryption system with subkeys. Their method allows
administrators to assign di�erent security level to the objects (e.g., �les, messages,
data, etc.) and distinct clearance to each subject (e.g., user, program, etc.). It
means that the decryption is permitted only in the security class higher than or
42
equal to that of the encrypted �eld-subkeys.
The used multilevel database system is a partially-ordered hierarchy (see Fig-
ure 7b), where an object with a particular security class can be accessed only by
subjects in the same or a higher security class. It also allows the encryption and de-
cryption of �elds within the same records. Not to reveal all the data corresponding
to the same user is smart.
The algorithm itself looks as follows.
(a) Totally-ordered hierarchy (b) Partially-ordered hierarchy
Figure 7: Secret key generation for each security classes[22]
Algorithm Key-Generation for Totally-Ordered Hierarchy [22]
Step 1 Get a node Sij from the hierarchy Hi by preorder traversal.
Step 2 Assigns sij a large prime pij randomly.
Step 3 Computes the secure key kij for sij using the formula
kij =∏
sil≥sij
pil.
Step 4 Repeat from Step 1 until all nodes of the hierarchy Hi are completely
examined.
Algorithm Key-Generation for Partially-Ordered Hierarchy [22]
Step 1 Get a node Sij from the hierarchy Hi by preorder traversal.
Step 2 Assigns sij two large primes pij and p′ij randomly.
Step 3 Computes the secure key kij for sij as follows:
7. ANONYMIZATION AND DE-ANONYMIZATION 43
Step 3.1 If sij is a root node, then kij = pij.
Step 3.2 If sij is not a root node, then
kij =∏
sil≥sij
pil∏
sil≥sij
p′il.
Step 4 Repeat from Step 1 until all nodes of the hierarchy Hi are completely
examined.
The system also provides fast update of records, in case of changing the sym-
metric key.
This method guarantees a high level of security thanks to the construction which
is mainly based on the Chinese remainder theorem. Hence, the security of the scheme
is equivalent to factoring a large composed prime.
7.2 De-anonymization
Other user data can be username, user location and time of call. During analyzation
most of the data got from the messages are dropped, but the last two are stored
and used for further, mainly statistical analysis. Though these datasets considered
as anonymous and safe, we still have to face the possibility of de-anonymization
attacks. According to the research papers from the last ten years, there are various
techniques and algorithms which can be used to build models of user behavior out
of these sets of information.
De�nition 4 (De-anonymization[16]). For the released data D, de-anonymization
of D is to connect its contained sensitive information to known user IDs.
By de�nition, there are basically two ways to commit de-anonymization, i.e. to
connect sensitive information to known IDs:
1. mapping users with known IDs to vertices in D, and
2. re-identifying the IDs of vertices in D.
Both ways can reveal sensitive information of users. However, in the former case,
mapping IDs to D does not always re-identi�es the mapped vertices.[16]
Nothing proves better its importance than the increasing number of publication
on de-anonymization, link prediction, and cross-reference among micro data, that
is, information about speci�c individuals.[17] It was possible due to the increasing
44
number of public datasets in response to �open government� laws and to support
data mining research.
In 2008 Narayanan and Shmatikov[17] came up with a de-anonymization method-
ology for sparse micro-data, and demonstrated its practical applicability on movie
viewing records. Their algorithm works under very general assumptions about the
distribution from which the data are drawn, and is robust to data perturbation.
Later, closely followed [17], in 2011 also Narayanan with Shi and Rubinstein[18]
published a paper about how they had won the Kaggle Social Network Challenge.
The goal of this machine learning competition was to promote research on link
prediction. The contest dataset was based on a large online social network (Flickr).
Then the obtained edge set was partitioning into a large training set and a smaller
test set, augmented with an equal number of fake edges. Using their own crawl of
Flickr, they were able to successfully de-anonymize 64.7% of the test edge-set.
In 2013, Gambs, Killijian, and Cortez[19] applied a de-anonymization attack
on geologicated datasets. They showed that the argument that, by itself location
data was anonymous and thus could be collected from users without violating their
privacy, was fallacious. They also showed that with high success rate the attack
could re-identify the individuals whose movements were contained in a provided
anonymous dataset. The adversary can use it as background information with some
mobility traces of the same individuals that he has been able to observe during the
training phase. From these traces, the adversary could build a Mobility Markov
Chain (MMC) that models in a compact and precise way the mobility behavior of
an individual. The de-anonymization attack was very accurate with a success rate
of up to 45% on large-scale real datasets.
A predecessor of the previous case was a closely related research by Mulder
et al.[20] on identi�cation via Location-Pro�ling in GSM networks. Their dataset
comes from a cellular network, i.e. a list of records of the movement of each device,
and probably its owner. This represents a serious privacy threat. In their work,
they showed techniques to build pro�les based on some user's locations, and then
techniques to match those pro�les with anonymized location data. For this identi�-
cation process, they used two methods: one based on simple �rst-order Markovian
chains, and another based on sequence of cell-IDs. The �rst one performed poorly:
slightly more than a third of the original mobile users could be correctly identi�ed,
while the latter performed well: around 80% of the original mobile users could be
properly identi�ed.
7. ANONYMIZATION AND DE-ANONYMIZATION 45
To obviate these kinds of attacks in 2011 Al Buona et.al[31] proposed de-
linkability, a privacy-preserving algorithm, that allows to sanitize multimedia doc-
uments' content and at the same time preserve their utility in order to achieve the
de-linkability.
These above examples of attacks show that revealing these datasets are very
dangerous and can easily fall into wrong hands. By anonymization, we only can
minimize the risk and possible harm of any data leakage.
46
8. SECURITY ISSUES WITH WEB APPLICATIONS 47
8 Security issues with web applications
Security mistakes are very easy to make and a simple one-line error can lead to catas-
trophic events included but not limited to dataset leakage, authentication problems,
cross-site-scripting (XSS) and cross-site-request-forgery (CSRF). Malicious actions
can be performed by leveraging weaknesses and vulnerabilities in a program code.
No programming language can protect from attacks, the code itself has to be able
to circumvent them.
Hereby I list and shortly introduce possible web client vulnerabilities which a
web application has to be aware of, as well remedies to avoid them. The Open Web
Application Security Project (OWASP) pages are excellent resources for gathering
information about this topic.
• Cross-Site Scripting (XSS) Attacks occur when user input is directly displayed
in an output web page, without any sanitization. With other words, anything
that is put into the input �eld is sent back to the page and rendered ver-
batim. Hence, the attacker can create a URL that submits malicious input
to the attacked website and tries to induce the victim to click on the link.
If he succeeds, the website response page includes malicious links or mali-
cious JavaScript code which are executed on the victim's browser. To prevent
these actions the programmer should make sure to 1. sanitize any user input
which might reach output statements (including statements that write to a
database or that save cookies), and 2. encode the output using HTML encod-
ing so that any malicious link or JavaScript code remains uninterpreted by the
browser.[39]
• Cross-Site Request Forgery (CSRF) occurs when a malicious website, email,
blog, instant message, or program causes a user's web browser to perform an
unwanted action on a trusted site for which the user is currently authenticated.
Owasp has two general recommendation for automated CSRF defense: 1. check
standard headers to verify the request is same origin and 2. Using Synchronizer
Token or Double Submit Cookie.
All requests should include Origin header and/or Referer header. If the Origin
header is present, its value should match the site's origin. If the Origin header
is not present, the hostname should be veri�ed in the Referer header if it
matches the site's origin. If both of these headers are missing, the more secure
way is to block the request.[40]
48
With the Synchronizer Token approach, the server embeds a dynamic hidden
variable in an input form. When the form is submitted, the server can check
if the hidden variable is present and is correct. This token can be reused, but
it is better to make it a one-time token by using nonces. They also protect
against replay attacks.[43]
The alternative defense is to use double submit cookie, which means that a
random value is sent in a cookie and also as a request parameter. Then the
server veri�es if the cookie value and request value match (see Figure 8).[40]
Figure 8: Double Submit Cookie[43]
• SQL injection occurs when the user provided data is used to form an SQL
query. The attacker provides malformed data to change the semantics of the
query. To mitigate this attack 1. always validate input that goes into an
SQL query, 2. use prepared or parametrized SQL queries instead of queries
formed by string concatenation or replacement and 3. grant access to tables
only through stored procedure.[39]
• Authentication issues
� Re�ection Attacks can be used for authentication, too. If the authentica-
tion is made by using hash function after a Di�e-Hellman key exchange
scheme, the two parties can authenticate themselves by sending to-be-
hashed messages, and if the received and the self-computed hash values
agree then the authentication worked. Therefore, as a malicious user, by
8. SECURITY ISSUES WITH WEB APPLICATIONS 49
sending random value r to the server, gets back its hashed value hash(r)
along with the message m to be hashed and sent back to the server.
At this point, the malicious user opens another session, sends m to the
server, and gets back hash(m). Then he can reuse it and send back to the
server to complete the �rst session. To mitigate this attack use direction
bits or di�erent keys in di�erent directions.[41]
� Password problems: A password has to ful�ll certain formal requirements.
Most applications do not allow users to set empty string as password, for
understandable reasons. The problem with weak passwords is that they
can be easily guessed (eg. pwd, password, secret, etc.. Short passwords
or ones with a limited variety of characters can su�er brute-force attacks.
On the other hand, using too di�cult and random passwords are safe but
hard to remember, hence the users can forget them.[39]
• Authorization issues
� File Access Race Condition or TOCTOU (time-of-check, time-of-use)
race conditions occur, when the program checks a property of a �le, ref-
erencing it by name. Then the program later performs a �lesystem oper-
ation using the same �lename and assumes that the previously-checked
property still holds. But in the meantime, if an attacker replaces the
�lename with a symbolic link to a di�erent �le, the program will use its
root privileges to operate on the �le, even though the attacker would be
unable to modify it.[36] To circumvent this, it is highly recommended to
use �lehandles instead of �lenames.[41]
� Least Privilege Violation Principle: When a program calls a privileged
function, it must �rst acquire root privilege. As soon as the privileged
operation has completed, the program should drop root privilege and
return to the privilege level of the invoking user.
Misused Privilege Management: Failure to adhere to the principle of least
privilege.[37][38]
50
9. ACCESS CONTROL: AUTHENTICATION AND AUTHORIZATION 51
9 Access control: Authentication and authorization
Accessing data is one of the key points in any system with stored sensitive informa-
tion. Con�dentiality, integrity and availability (abbreviated as �CIA�) are the three
types that information security risks can be categorized into. Access control is only
one aspect of a comprehensive computer security solution, but one of the most visi-
ble. It is critical to preserve the con�dentiality and integrity of information, so that
only authorized users can read information and can alter them in authorized ways.
There are two concepts which are fundamental to access control: authorization
and authentication. Although many people confuse them, they are not synonyms.
However, proper authorization is dependent on authentication.
In plain words, authentication is a process of determining who you are, autho-
rization determines what you are allowed to do.[33]
The following two de�nitions give a more sophisticated phrasing.
De�nition 5 ([35]). Authorization is a security mechanism used to determine
user/client privileges or access levels related to system resources, including computer
programs, �les, services, data and application features.
During authorization, a system veri�es an authenticated user's access rules and
either grants or refuses resource access.
De�nition 6 ([33]). Authentication is the process of determining that a user's
claimed identity is legitimate.
Remark 3 ([33],[35]). Authorization is normally preceded by authentication for user
identity veri�cation.
Authorization necessarily depends on proper authentication. If the system cannot
be certain of a user's identity, there is no valid way of determining if the user should
be granted access.
9.1 Authorization methods
There are several authorization management systems which exist and can be used
to allot di�erent access rights to users. There are early approaches like Manda-
tory Access Control (MAC) and Discretionary Access Control (DAC), which can be
enforced by Role-based access control (RBAC) without any complication, however,
RBAC is di�erent from them.
Restricting system access to authorized users and building a hierarchy is not
new and widely used in big companies with employees over 500. On average, these
52
organizations expended $241.01 per employee to implement RBAC.[32] RBAC is a
policy neutral access control mechanism which greatly simpli�es security adminis-
tration by using roles, hierarchies, and constraints to organize privileges. It attracts
a great deal of attention, particularly for commercial reasons, because it reduces the
complexity and cost of security administration in large networked applications. The
basic idea behind RBAC is that it takes into account that employees change much
more frequently than the duties within positions. If an employee moves within an
organization, only his or her role assignment is changed, revoking his or her existing
privileges and assigning a completely new set of privileges are unnecessary.[33]
RBAC has three primary rules:
1. Role assignment: A subject can execute a transaction only if the subject has
selected, or been assigned to, a role (i.e. has an active role).
2. Role authorization: A subject's active role must be an authorized role for that
subject.
3. Transaction authorization: A subject can execute a transaction only if the
transaction is authorized for one of the subject's active roles.
[49, Lecture 26][33]]
Remark 4 ([33]). Rule 1 and 2 ensure that users can take on a role only if they
are authorized for it. All the three rules together ensure that users can execute a
transaction only if they are authorized for it.
Figure 9: The basic RBAC model with sessions[34]
The basic idea of role-based access control is to cut the connection between the
user and the permission and connect them again with the insertion of another level
of indirection, namely the Roles. As Figure 9 illustrates, roles break this mapping
9. ACCESS CONTROL: AUTHENTICATION AND AUTHORIZATION 53
into two: users to roles and roles to privileges. Moreover, they introduced sessions
to extend the support for least privilege. Sessions are used on a particular occasion
when a user signs on the system to carry out some activity, hence, this means
another level of indirection between Roles and Users. So users activate roles within
the frame of a session.[34]
There are also other approaches like Task-based Access Control (TBAC) intro-
duced by Thomas and Sandhu[48] in 1997. TBAC is an active approach and a
family of models for authorization management. It is di�erent than the passive
subject-object model like RBAC. The di�erence is that permissions are turned on
only in a just-in-time fashion and synchronized with the processing of authorization
in progressing tasks. Basically, the granted access is based on a task, and the access
check compares it to the roles which contain that task, and then the users who are
part of at least one of those rules. TBAC can be considered as an extended form of
RBAC. However, it is not as widespread as RBAC and quite unknown.
Access control in practice
RBAC implementation can be done in two ways: implicitly and explicitly.
De�nition 7 ([50]).
Implicit access control: �Permissions granted or denied from users and groups�
Explicit access control: �Access Control applied directly to controllable objects�
In [51] they show the di�erence between these two types applied on RBAC.
Implicit access control is done by granting and revoking privileges to users. For
each transaction (resource) a set of roles is assigned directly in the program code.
For instance, the condition of the if statement contains the name of the roles which
have the access right.
The problem starts with the change of the security requirements. If the if
statement condition is changed, like granting access to another set of roles, the test
cases needs to be updated, the software to be rebuilt and a re-deployment to be
scheduled to production.
In the contrary, explicit access control applied in RBAC enables the security
policy change while the application is running. It can be done by not specifying in
the program code which role has the right privilege, but check if the current user
is permitted to commit to the current resource. Here the code is based on what is
being protected instead of who has the ability.
54
In the above mentioned article[51] they provided a list of the numerous bene�ts
of using explicit RBAC policy, including but not limited to the
• reduction of code refactoring by basing the code on the resources because they
change less frequently,
• increased �exibility of the security model and
• externalized security policy management: security policy changes can be done
by another person, bypassing the software developer.
9.2 Authentication in general
Authentication is based on one or more of the following factors:
• Something you know, such as the password, personal identi�cation number
(PIN), or lock combination;
• Something you have, such as a smart card, automatic teller machine (ATM)
card, or key;
• Something you are, or a physical characteristic, such as a �ngerprint or retinal
pattern, or a facial characteristic.[33]
The most popular and widely used authentication method is password based:
if for a given username the stored and the typed passwords match, the user is
authenticated.
Usually, username-password pairs stored in databases are not in plain but in
encrypted form. For this cryptographic hash functions are used. Its main properties,
namely pre-image resistance, second preimage resistance and collision resistance,
make it so widespread. In practice, it means that �nding another password which
has the same hash value is more than unlikely. Also, it is unfeasible to generate a
password from its hash value except by trying all possible messages. Hence, if the
table falls into wrong hands the passwords are not revealed.
In this case the authentication process works as follows (see Figure 10:
1. User requests content which needs permission
2. Server requests user name and password = p1
3. User provides credentials: user name = u1 and password = p1
9. ACCESS CONTROL: AUTHENTICATION AND AUTHORIZATION 55
4. Server compute the hash value of the given user name and password: hash(u1)
and hash(p1)
5. If the computed hash value pair is matching with a pair stored in the database:
(a) checks if the user owns the proper access rights
(b) if yes, the server provides the requested content.
6. If the computed hash value pair is not matching with any pair in the database:
(a) the server returns with a 401 error message.
Figure 10: Authentication with password
9.3 Authentication in a single page web application (SPA)
What is an SPA?
De�nition 8 ([42]). A single page web application (SPA) is an application delivered
to the browser that does not reload the page during use. Like all applications, it is
intended to help the user complete a task, such as �write a document� or �administer
a web server.� We can think of an SPA as a fat client that is loaded from a web
server.
Figure 11 illustrates how the business logic and generation of HTML migrate
between the server and the client.
The primary bene�t of an SPA over a traditional website is that it provides a
better user experience. An SPA can deliver the best of both worlds: the immediacy
of a desktop application and the portability and accessibility of a website. More
speci�cally, an SPA
• can render like a desktop application,
• can respond like a desktop application,
• can notify users of its state like a desktop application,
• is nearly universally accessible like a website,
• can be instantly updated and distributed like a website and
• is cross-platform like a website.[42]
56
Figure 11: Responsibilities of the database, server, and client[42]
Security concerns for SPAs
However a SPA has many bene�ts over the traditional approach, authentication is
still rising issues and presents new security challenges. These types of applications
are �untrusted clients� since the server-side code has no control over the environment
they run in. Through the developer console, one can alter or inject JavaScript code
on a page. Mobile applications are also can be decompiled and inspected, hence, a
developer has to avoid embedding sensitive information like secret keys or passwords
in these type of clients. [43]
The primary goal of web application security is to
• prevent malicious code from running (eg. XSS attacks),
• ensure that user credentials are sent to the server in a secure way,
• secure API endpoints (eg. CSRF attacks) and
• expose access control rules to the client (eg. session ID challenges).[43]
Section 8 addresses each of these concerns.
9. ACCESS CONTROL: AUTHENTICATION AND AUTHORIZATION 57
JSON Web Tokens (JWT)
An approach to secure user authentication in a single page web application is using
tokens for authentication instead of cookies. JSON Web Tokens (JWT) give a
structured way to declare a user's identity and its access privileges.
De�nition 9 ([46]). JSON Web Token (JWT, pronounced jot) is a relatively new
token format used in space-constrained environments such as HTTP Authorization
headers. JWT is architected as a method for transferring security claims between
parties.
JWT is a great authentication mechanism which provides a structured and state-
less way to declare users and their access rights in a cryptographically signed and
encrypted way.
A token consists of three separate sections. The �rst is a header that describes
the token: contains the metadata for the token and at a minimal contains the type
of the signature and/or the encryption algorithm. The second is called claims, a
payload which contains the valuable bits, i.e. the information which is to be signed.
The third and last is the JSON Web Signature, a signature hash that can be used
to verify the integrity of the token by using the secret key.[45][44]
A token is a Base64 encoded string, which after breaking it apart the three
sections can be separated from each other. After decoding the second section it
looks as follows:
{
"sub": "users/TzMUocMF4p",
"name": "Edward Example",
"scope": "self groups/admins",
"exp": "1300819380"
}
where sub stands for the URI to the user resource, name refers to the user, scope
indicates the person's access right and exp is the expiration date.
Tokens are given to the users after they present some hard credentials, typically a
username and password, but they can also provide API keys or tokens from another
service.
JWT's are great for SPAs mainly because of their portability. In an SPA access
control logic is built in the frontend as well the backend. Because tokens contain all
information that is needed for authorization, hence they are very portable and can
58
be used by both the frontend and the backend to make decisions. Also, they can be
shared with partner services.
To achieve high-level security, tokens must be protected against the event of
getting stolen: they should be endowed with signatures. Tokens must be signed
with a strong key that is available only to the authentication service. Signature
veri�cation must be checked each time a token is used to authenticate a user. Also,
tokens have to be in an encrypted form if they contain non-opaque information.
Least but not last they have to be transmitted over HTTPS connection and never
over a non-HTTPS one.[44]
Tokens have to be stored in order to keep them in case of refreshing the browser.
It can be a web Storage (localStorage/sessionStorage) or a client-side cookie.
When using browser storage (localStorage or sessionStorage) for a JWT to ex-
change username and password, the response body contains the JWT as an access
token. On the client side, the token is stored in HTML5 web storage. To pass the
access token back to the protected APIs, the HTTP Authorization Header and the
Bearer scheme are used.
Cookies can be used for the same reason. In this case the response use the
Set-Cookie HTTP header. To pass the access token back to the protected APIs on
the same domain, the browser automatically includes the cookie value.[47]
Among the possible storage types, storing tokens in HTTPS-only cookies is the
best way. The local storage area is very vulnerable to XSS attacks. Storing them
in secure cookies protects against being exposed to the JavaScript environment in
the browser, which is vulnerable to XSS attacks. Man-in-the-middle attacks can be
prevented by not transmitting tokens over non-HTTPS connections.
Because cookies are used only as a storage mechanism, not as an authentication
mechanism, they do not require state to be stored on the server if JWT is being
stored in the cookie. This is because the JWT encapsulates everything the server
needs in order to serve the request.[47]
However secure cookies are used for storing they are still vulnerable to CSRF
Attacks, hence it is important to implement a CSRF token strategy to combat this
issue.[44] More about these strategies can be found in Section 8.
9. ACCESS CONTROL: AUTHENTICATION AND AUTHORIZATION 59
9.4 User handling in a Network Monitoring Tool
Authorization in a network monitoring tool is an important issue which needs to be
resolved. On one hand, as is mentioned in Section 7, there are sensitive pieces of
information like IMSI and MSISDN which should not be available for each person
who uses the tool. But on the other hand, there are other aspects which have to be
considered.
The structure of the inner network. First of all, not all the users need to
get the permission to have an inside view into the network. The details should be
hidden for certain group of users, such like the information of what ports are used
for communication. As is also mentioned in Section 7, IPv4, and IPv6 should be
hidden.
Personalized user account. Each authorized user has to be able to create his
or her own account, save and retrieve the previously loaded data, and share them
with other authorized users. Anything which was created by that particular user
can be shared, but the default is that he or she is the only one who has access to it.
Working in groups. Having an individual account implies the possibility of
working in groups and sharing the latest updates manually or automatically between
the members.
The program itself. A network monitoring tool itself should not be a free
application, hence, it requires protection against unauthorized downloads and usage,
aiming to save this intellectual property.
Possible requirements and approaches to resolve them
In the aspect of security, since a network monitoring tool is an SPA, the requirements
are similar to the ones described in Section 8. Taking steps to mitigate penetra-
tion against attacks, including but not limited to CSRF attacks, XSS attacks, SQL
injection, re�ection attack and password issues is inevitable.
Using JSON Web Tokens (JWT), mentioned in this subsection earlier, is great
to easily implement protection against CSRF attacks. Moreover, using HTTPS-only
cookies for storing can mitigate XSS attacks.
Authentication method should be strong enough, but at the same time not too
di�cult, in order to make the system usable.
To mitigate unauthorized download, secure keys should be assign to each poten-
tial user with which they can download the application and register.
60
10. SECURITY PLAN 61
10 Security Plan
In the previous sections, problems and various techniques of remedies were intro-
duced and compared, providing a comprehensive view on security and privacy issues
which can occur in a web application. Hereby this section is devoted to summa-
rize what has being discussed and create a concept of a security plan for a network
monitoring tool.
In the �rst place, there should be emphasized that only privileged users have
access to the tool, and can operate only after they authenticated themselves.
Authentication
Authentication is a key point in a web application, mainly because of its complexity.
In a user point of view authentication in our network monitoring tool will be
password-based. It ful�lls the requirements of implementing a strong but not di�cult
authentication method.
Requirements for a strong password:
� longer than 8 character
� include symbols: (e.g. # $%)
� include numbers: (e.g. 123456)
� include lowercase characters: (e.g. abcdefgh)
� include uppercase characters: (e.g. ABCDEFGH)
� exclude similar characters: (e.g. i, l, 1, L, o, 0, O)
� exclude ambiguous characters: ({ } [ ] ( ) / \ ' " ` � , ; : . < >).
Each authorized user is provided a private 16 character long key, consists of
numbers and uppercase letters, with which they can authenticate themselves and
install the software.
In a developer point of view, the authentication system should ful�ll the require-
ments stated in the end of Subsection 9.3. To do so, JSON Web Tokens has to
be used, stored in HTTPS-only cookies. It guarantees a fundament of implement-
ing a secure authentication scheme. As is also discussed in the Section 9.3, taking
steps to mitigate penetration is inevitable and can be done by applying the remedies
discussed in Section 8.
62
Authorization
Assigning access rights will be based on Externalized RBAC. Hence, security policy
is not the duty of the developer, and the implementation is not hampered by dealing
with the di�erent roles and possible changes. Moreover, sessions can be used when
granting temporary access and working in groups as well. For more details see
Subsection 9.1.
Anonymization and data encryption
After a successful login, a network monitoring tool user (NMT-user) can start op-
erations like loading data from .pcap �les. These �les consist of messages which
possibly contain private information about telecom subscribers (s-user). For the list
of sensitive and to-be-encrypted data see Section 2. When the .pcap �le is loaded,
data is stored in the database with access only for the current NMT-user (or in case
of working in groups, with access for the group members). Right before storing, s-
user data listed in Section 2 will be encrypted using hybrid cryptography combining
AES or IDEA NXT with RSA.
Hence, s-user data will appear on the screen in encrypted form. If the NMT-
user is privileged, there is a decrypt and a decrypt all button appeared on the user
interface, make it possible for the original values to be seen.
10. SECURITY PLAN 63
Conclusion
In my Thesis, two main questions were investigated, namely how the sender and
receiver network functions can be identi�ed by analyzing messages transmitted on
interfaces using protocols diameter, S1AP and GTPv2; and providing an overall
picture of the security requirements in a network monitoring tool.
We concluded that the passive method works pretty well on diameter and S1AP
interfaces. S1AP messages can be transmitted between eNodeB and MME, hence
is enough to know the initiator node. Each diameter message contains information
about the used interface, hence by taking the Command Code and the Application-
ID we can clearly determine the sender and receiver node, except for one message
type. GTPv2 messages are di�erent in the aspect of clarity: the useful information
elements found in the packets in most cases are not mandatory, hence are not present.
Though there are several messages from which we can determine clearly at least one
end of the communication, and a .pcap �le is long, hence, with high probability,
there can be found a matching for each IP address and network function.
In the latter sections, an overall picture on security was given paying special
attention to the requirements regarding a network monitoring tool. With respect to
the authentication, the requirements for a single page application were followed. As
for a big company with employees over 500, using externalized RBAC is proposed.
For the protection of telecom subscriber data, encryption is needed. For this, hybrid
cryptography is suggested.
By using the security plan described in Section 10 a fundament of a secure
authentication scheme implementation can be guaranteed.
64
Bibliography
[1] Tim Wu., Apple's new iPhone augurs the inevitable return of the Bell telephone
monopoly, Access time: March 26, 2016, http://www.slate.com/articles/
technology/technology/2008/06/isurrender.html
[2] Anton A. Huurdeman, The worldwide history of telecommunications, Wiley,
2003
[3] Singtel, Samsung and Ericsson unveil world's �rst full-featured Voice over LTE
service, Access time: March 26, 2016, http://www1.singtel.com/about-
us/news-releases/singtel-samsung-and-ericsson-unveil-worlds-
first-full-featured-voice-over-lte.html
[4] Andrew S. Tanenbaum, David J. Wetherall, Computer networks, 5th ed., Pren-
tice Hall, 2011
[5] Miikka Poikselkä, Harri Holma, Jukka Hongisto, Juha Kallio andAntti Toskala,
Voice Over LTE: VoLTE, Wiley, 2012
[6] James Rankin, Alexandru Costaiche, and Joseph Zeto, Validating VoLTE � A
De�nitive Guide to Successful Deployments, Ixia, 2013
[7] Ed Elkin, The Secret Value of VoLTE, Access time: March 26, 2016,
http://blog.tmcnet.com/next-generation-communications/2014/04/
the-secret-value-of-volte.html
[8] Koi Tamás, Az operátorok sem tudják még, miért lesz jó a VoLTE, Access time:
March 26, 2016, http://www.hwsw.hu/hirek/50564/volte-voice-over-lte-
mobil-hang-2g-3g.html
[9] Lauri Seppänen, Kai Ojala, Anite Network Testing, VOICE CALL PERFOR-
MANCE MEASUREMENTS WITH 2G, 3G, AND VOLTE IN LTE NET-
WORKS, Anite 2014
65
66
[10] Fjardo, et al., RFC 6722 - Diameter Base Protocol, IETF 2012
[11] Introduction to Diameter, Access time: March 29, 2016, http://diameter-
protocol.blogspot.hu/2011/03/introduction-to-diameter.html
[12] LTE; Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1
Application Protocol (S1AP) 3GPP TS 36.413 version 13.1.0 Release 13 ETSI
2016
[13] Universal Mobile Telecommunications System (UMTS); LTE; 3GPP Evolved
Packet System (EPS); Evolved GPRS Tunnelling Protocol for Control plane
(GTPv2-C); Stage 3 (3GPP TS 29.274 version 13.4.0 Release 13) ETSI 2016
[14] Manjula M., G. Varaprasad. Implementation of Decoders for LTE Interface
Messages, 2011 Second International Conference on Networking and Distributed
Computing, 2011, Page 304 - 307
[15] Jean-Gabriel Remy, Charlotte Letamendia, LTE Standards, Wiley, 2014
[16] X. Ding, L. Zhang, Z. Wan and M. Gu, A Brief Survey on De-anonymization
Attacks in Online Social Networks, Computational Aspects of Social Networks
(CASoN), 2010 International Conference on, Taiyuan, 2010, pp. 611-615.
[17] A. Narayanan and V. Shmatikov, Robust De-anonymization of Large Sparse
Datasets, 2008 IEEE Symposium on Security and Privacy (sp 2008), Oakland,
CA, 2008, pp. 111-125.
[18] A. Narayanan, E. Shi and B. I. P. Rubinstein, Link prediction by de-
anonymization: How We Won the Kaggle Social Network Challenge, Neural
Networks (IJCNN), The 2011 International Joint Conference on, San Jose, CA,
2011, pp. 1825-1834.
[19] S. Gambs, M. O. Killijian and M. N. d. P. Cortez, De-anonymization Attack on
Geolocated Data, 2013 12th IEEE International Conference on Trust, Security
and Privacy in Computing and Communications, Melbourne, VIC, 2013, pp.
789-797.
[20] Mulder, Yoni De et al. Identi�cation via location-pro�ling in GSM networks.
WPES (2008).
BIBLIOGRAPHY 67
[21] S. Sesay, Zongkai Yang, Jingwen Chen and Du Xu, A secure database encryp-
tion scheme, Second IEEE Consumer Communications and Networking Confer-
ence, 2005. CCNC. 2005, 2005, pp. 49-53.
[22] Min-Shiang Hwang, Wei-Pang Yang, Multilevel secure database encryption
with subkeys, Data & Knowledge Engineering, Volume 22, Issue 2, April 1997,
Pages 117-131, ISSN 0169-023X
[23] S. Sesay, Zongkai Yang, Jingwen Chen and Du Xu, A secure database encryp-
tion scheme, Second IEEE Consumer Communications and Networking Confer-
ence, 2005. CCNC. 2005, 2005, pp. 49-53.
[24] X. h. Wu and X. j. Ming, Research of the Database Encryption Technique
Based on Hybrid Cryptography, Computational Intelligence and Design (ISCID),
2010 International Symposium on, Hangzhou, 2010, pp. 68-71. doi: 10.1109/IS-
CID.2010.105
[25] Suhaila Omer Sharif and S. P. Mansoor, Performance analysis of stream and
block cipher algorithms, 2010 3rd International Conference on Advanced Com-
puter Theory and Engineering(ICACTE), Chengdu, 2010, pp. V1-522-V1-525.
[26] O Kee�e, Colm, et al. Low power hardware and software implementation of
IDEA NXT algorithm. IEE conference publication. Vol. 511. London; Institution
of Electrical Engineers; 1999, 2005.
[27] Nadeem, Aamer, and M. Younus Javed. A performance comparison of data en-
cryption algorithms. Information and communication technologies, 2005. ICICT
2005. First international conference on. IEEE, 2005.
[28] Kara, Orhun, and Cevat Manap. A new class of weak keys for Blow�sh. Fast
Software Encryption. Springer Berlin Heidelberg, 2007.
[29] Gonzalez, Tom, and Tom Gonzalez. A Re�ection attack on blow�sh. J Latex
Files 6 (2007).
[30] Lee, Cheng-Chi, Pei-Shan Chung, and Min-Shiang Hwang, A Survey on
Attribute-based Encryption Schemes of Access Control in Cloud Environments.
IJ Network Security 15.4 (2013): 231-240.
[31] Al Bouna, Bechara, et al. De-linkability: A privacy-preserving constraint for
safely outsourcing multimedia documents. Proceedings of the Fifth International
Conference on Management of Emergent Digital EcoSystems. ACM, 2013.
68
[32] O'Connor, Alan C., and Ross J. Loomis. 2010 Economic Analysis of Role-Based
Access Control. RTI International report for NIST (2010).
[33] Ferraiolo, David, D. Richard Kuhn, and Ramaswamy Chandramouli. Role-based
access control. Artech House, 2003.
[34] Belokosztolszki, András. Role-based access control policy administration.
(2004).
[35] Techopedia, Authorization Access time: May 24, 2016, https://www.
techopedia.com/definition/10237/authorization
[36] OWASP File Access Race Condition: TOCTOU Access time: May 25, 2016,
https://www.owasp.org/index.php/File_Access_Race_Condition:_TOCTOU
[37] OWASP Least Privilege Violation Access time: May 26, 2016, https://www.
owasp.org/index.php/Least_Privilege_Violation
[38] OWASP Often Misused: Privilege Management Access time: May
26, 2016, https://www.owasp.org/index.php/Often_Misused:_Privilege_
Management
[39] Paolo Tonella, Security Testing course, https://sites.google.com/site/
sectestunitn/materials, University of Trento, 2015.
[40] Owasp, Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet, Ac-
cess time: May 26, 2016, https://www.owasp.org/index.php/Cross-Site_
Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet
[41] Levente Buttyán, Cryptographic Protocols course, http://www.hit.bme.hu/
~buttyan/courses/EIT-SEC/, Budapest University of Technology and Eco-
nomics, 2015
[42] Mikowski, Michael S., and Josh C. Powell, Single Page Web Applications, B
and W (2013)
[43] Micah Silverman, The Problem with Securing Single Page Applications, Access
time: May 26, 2016, https://stormpath.com/blog/secure-single-page-
app-problem
[44] Robert Damphousse, Token Based Authentication for Single Page Apps (SPAs),
Access time: May 26, 2016, https://stormpath.com/blog/token-auth-spa
BIBLIOGRAPHY 69
[45] Tom Abbott, Use JWT The Right Way! Access time: May 26, 2016, https:
//stormpath.com/blog/jwt-the-right-way
[46] Alberto Pose, Cookies vs Tokens. Getting auth right with Angular.JS, Ac-
cess time: May 28, 2016, https://auth0.com/blog/2014/01/07/angularjs-
authentication-with-cookies-vs-token/
[47] Tom Abbott Where to Store your JWTs � Cookies vs HTML5 Web
Storage Access time: May 28, 2016, https://stormpath.com/blog/
wheretostoreyourjwtscookiesvshtml5webstorage
[48] Thomas, Roshan K., and Ravi S. Sandhu. Task-based authorization controls
(TBAC): A family of models for active and enterprise-oriented authorization
management. Database Security XI. Springer US, 1998. 166-181.
[49] Dr. Bill Young, Introduction to Computer Security course, https://www.cs.
utexas.edu/~byoung/cs361/syllabus361.html, University of Texas, 2016
[50] Oracle R© Beehive Administrator's Guide, Release 2 (2.0.1.8), 13 Managing Or-
acle Beehive Access Control Access time: June 2, 2016, https://docs.oracle.
com/cd/E16671_01/bh.200/e16648/accesscontrol.htm
[51] Les Hazlewood, The New RBAC: Resource-Based Access Control, Ac-
cess time: June 2, 2016, https://stormpath.com/blog/new-rbac-resource-
based-access-control