5G ONAP Anomaly Detection Projects

5G Slicing Cybersecurity: Demonstration and Mitigation of a Distributed Slice Mobility Threat

Summary:

Open

For code, please see, 5G Slice Mobility Security

Yatis K. Dodia, Maxwell Yarter, Jeff Pitcher, Soradhmuny Lanh, Sebastiano DePani 
Georgia Tech Research Institute

Introduction

This report details our investigation into 5G Slice Security using a simulated economic threat which leverages 3GPP-compliant UE-initiated slice movement. The threat aims to leverage legitimate initiation of and movement between allowed slices in an attempt to trigger and exploit dynamic scaling of underlying infrastructure resources, e.g., autoscaling of Kubernetes containers/pods, which has the potential to cause the Mobility Network Operator (MNO) to incur undue operational costs. Notably, this type of threat was selected due to its decreased reliance on user data volume and simulation, instead seeking to exploit dynamic scaling of underlying virtualized resources through inter-slice movement. We also aimed to demonstrate a proof-of-concept discriminator for anomalous UE movement in an attempt to correlate to increased and unexpected resource utilization to determine threat responsibility. 
The investigation consisted of four (4) primary thrusts:

1. Dynamic Slice Mobility (DSM) threat implementation and simulation.

2. 5G-specific feature and metric identification and collection.

3. Machine Learning (ML) modeling for threat detection and mitigation (proof of concept).

4. Utilization of and integration into open-source frameworks for all of the above; specifically, SD-Core and Open5GS were used for the 5G Core and ONAP was used for the orchestration platform, data collection, ML modeling, and network control for threat mitigation.

Our contributions parallel these thrusts. First, we identified a viable threat formulation which was approachable given GTRI's feature-rich testbed and representative of real-world slicing mechanics without the need for large-scale user data generation. Second, modeling of threats would require data collection and exactly which data to collect and how to process for particular security concerns still remains a challenge in networking, especially for 5G. We identify and collect available 3GPP-guided metrics from 5G functions as features used for modeling. We also guide which features were desirable but unavailable due to a lack of implementation in respective open-source Core frameworks. Third, our work provides a notional neural network-based (NN) anomaly detection model to identify threat UEs performing exploitative inter-slice movements. The NN models are benchmarked with statistical methods such as principal component analysis (PCA). Fourth, we integrate all of the above into ONAP (a collection of network automation), which include collection of the aforementioned data, packaging into the Virtual Event Streaming (VES) messages to successfully ingest and process for both threat detection and potential mitigation. Lastly, we guide available API endpoints as part of the mitigation action set which, at a first pass, are suitable actions targeting indicated threats. Combined, these represent foundational capabilities for an end-to-end cybersecurity analysis.

The 5G Architecture and Slicing

The Fifth Generation of wireless networks (5G) introduces several new features and improvements over past generations. For instance, previous generations were primarily designed for cell phones, often called User Equipment (UE). Many increments of 3G and 4G introduced increasing support for devices such as laptops, gaming, or IP telephony, generalizing the scope of a UE to be any supported device capable of connecting. 3GPP provides a generalized overview of the connectivity, with essentially the same high-level elements when compared to prior generations: 

Open

Figure 1. Overview of the 5G System (5GS) [1]

The UE depicted in Figure 1 is a user cell phone and the radio tower is typically called a "g Node B", where 'g' stands for 5G. The UE connects to the Radio Access Network (RAN) over the air using a standardized radio access technology (RAT). A distinction here is that 5G uses the "New Radio" (NR) RAT with frequencies in two broad ranges dubbed Frequency Range 1 (410 – 7,125 MHz) and 2 (24,250 – 71,000 MHz), or FR1 and FR2, respectively. In contrast, 4G operates in a frequency range of 600 – 2,500 MHz. As a UE begins to connect and attach to a 5G network, the Core contains several functions which control and manage the UE. The Access and Mobility Management Function (AMF) and User Plane Function (UPF) are show in the System Architecture in Figure 2. The AMF manages UE registration, providing authentication and authorization for use of network resources and is a component of the signaling or _Control Plane{_}. The UPF provides a session and connection to a data network (DN), i.e., user data connectivity and is part of the _Data Plane{_}. Other relevant network functions (NF) of the 5GS are shown in the System Architecture view below:

Open

Figure 2. System Architecture of the 5G Core [1] 

A particular _new_ feature of 5G is Network Slicing. Slicing provides a way to have simultaneous virtual network services on top of a common physical underlay network. That is, each network slice is served as an independent, logically separate network with resources specific to the needs of the user or application. Many such slices could exist and are multiplexed on the network at any given time with compute, network, and other resources dynamically scaled or allocated using network function virtualization (NFV). We detail further in this report, focusing relevance and implementation for cyber threats to slicing.

The 5G networking architecture leverages emerging technologies to create flexible communication networks that outperform 4G networks in many areas. The primary change between 4G and 5G networks is a transition toward software defined networks (SDN). By implementing 5G networks through software defined components, network operators are able to reduce cost through dynamic resource allocation and provide services for next generation applications. Applications such as enhanced mobile broadband (eMBB), ultra-reliable low latency communications (URLLC), and massive internet of things (mIoT) are made possible due to 5G SDNs. The dedicated technologies that 5G protocols implement include network function virtualization, network slicing, and edge computing. Each slice allows for fine-grained control and isolation of network resources to meet a customer's service level agreement (SLA). 

Virtual Network Functions 

Virtual network functions (VNF) replace the dedicated proprietary hardware that made up the backbone of previous generation mobile telephony infrastructure. Prior to SDNs Each 4G network function was its own hardware component that was manufactured and installed on-site to increase the capacity of a 4G core network. As more user devices are added to a 4G network the maximum load on that network goes up and more resources must be invested in maintaining user quality of service (QoS). The model of permanently expanding physical infrastructure is an impractical solution for the rapidly increasing number of internet-connected devices or internet of things (IoT). VNFs overcome this problem by containerizing network functions as software applications and hosting them on virtual infrastructure. Hosting 5G core network functions on virtual infrastructure makes the 5G core a software defined network (SDN). VNFs enable dynamic expansion and contraction of the 5G core to meet user demand without investment in hardware components that may only be utilized during peak hours. This makes 5G networks more efficient in terms of resource usage as well as resilient to surges in user demand. Additionally, these VNFs make it easy to logically separate portions of a network in a process known as slicing.

Network Slicing 

Network slicing is an organizational concept used to segment portions of shared physical resources into separate virtual networks. A network slice is a functional end-to-end network that provides all of the network functions required to service user equipment (UE). Multiple slices can be defined on a single set of shared physical resources to service different applications and user QoS/SLA requirements. Figure 3 shows a diagram of logical slices across 5G infrastructure. The concept of slicing also allows network operators to deploy new slices, or allocate additional resources to an existing slice to meet surges in demand. There are many benefits to network slicing including: dynamic and efficient resource allocation, application specific network definition, user prioritization, and logical separation of applications. Network slicing is challenging to orchestrate due to its dynamic nature and introduces new cyber-attack surfaces that will be discussed in a following section.

Open

 Figure 3: Slicing across the access, core, and data Network. Multiple slices can share resources such as the gNB and network functions.

5G Architecture 

There are 3 separate networks to consider for 5G communication:

1. Radio Access Network (RAN)

2. Core Network

3. Data Network

RAN

The 5G RAN is the access point that UEs communicate with to gain access to 5G services. The RAN is very similar to previous generation of RAN technology with the primary distinction being a focus on smaller cell technology. 5G small-cells are used to provide small areas with network access and more broadly support the 5G goal of servicing more devices with greater bandwidth. 5G networks can be accessed by previous generation RANs through handover procedures that must be configured by the network provider.

5G Core 

The 5G core is responsible for both control and management of users on the network, performing nearly all the operations required to connect and maintain UEs. Figure 4 shows a 5G core network diagram with relevant VNFs. The 5G core handles UE connection, authentication, authorization, management, and data services. The 5G core is composed of containerized VNFs including:

• Access management function (AMF)

• Session management function (SMF)

• Authentication server function (AUSF)

• Policy control function (PCF)

• Network slice selection function (NSSF)

• Service communication proxy (SCP)

• Unified data management (UDM)

• Unified data repository (UDR)

• User plane function (UPF)

• Network repository function (NRF)

Open

Figure 4: 5G core network showing network functions

For the purposes of our threat and security analysis the relevant network functions are the AMF, SMF, UDM, AUSF, PCF, and UPF.

AMF

The access and mobility management function (AMF) is the VNF that handles connection requests from UEs requesting 5G services. The AMF receives PDU session requests from the RAN and communicates with various network functions to determine if the UE is authorized, what slices it has permission on, and what QoS it is afforded on the network.

SMF

The session management function (SFM) manages PDU sessions between UEs and UPFs. After a UE is authorized by the AMF the SMF establishes a connection between the UE and UPF specified by the AMF.

AUSF

The authentication server function (AUSF) handles the authentication of UEs that are requesting a 5G network connection. The AUSF coordinates with the AMF to determine if A UE will be provided service.

UDM

The unified data management (UDM) stores user/subscriber data that other VNFs need to reference. The AMF, AUSF, and SMF all require the UDM to determine if a subscriber is authorized and what services they are being provided.

PCF

The policy control function (PCF) regulates the QoS provided to a UE by communicating with the AMF and SMF. The PCF ensures that a UE is provided the correct QoS and dynamically adjusts its connection under changing conditions.

UPF

The user plane function (UPF) connects a user to the data network name (DNN) that they request. This could be a private network or, more generally, a WAN like the internet. The UPFs two primary functions are communication with the 5G control plane, and regulating the path between the DNN and UEs.

Data Network 

The data network is the data path for use by the user, often out to the internet or some WAN or LAN to which UEs desire a connection. The data network is not necessarily managed by the 5G network operators. This report doesn't detail anything further regarding these networks.

Open-Source Cores

The transition towards SDNs has lowered the barrier for entry to creating a 5G network. Legacy networks required specialized hardware, the budget to purchase it, and the knowledge to install it. These factors made it impractical for anyone besides telecommunication providers or researchers with a test bed to create and maintain a private 3GPP guided communication network. 5G protocols are software defined and the standards documentation is freely available from 3GPP. The software defined VNFs have enabled the development of open-source cores that can be downloaded and hosted on virtual resources. The two cores investigated for the purpose of this threat and security analysis were SD-Core and Open5GS.

SD-Core

SD-Core, developed by the Open Networking Foundation (ONF), is the 5G core network component of the broader Aether project. The Aether project is an open-source 5G platform that contains both SD-Core and a software defined RAN implementation for creating end-to-end 5G networks. The Aether project provides Helm charts for deploying software defined components through Kubernetes. Kubernetes is an open-source containerized application deployment and management system commonly used for applications that require dynamic resource allocation. Helm charts are a standard packaging format used to define Kubernetes resources (in this case 5G VNFs).
SD-Core offers all of the primary 5G core VNFs as Helm charts and can be deployed in a preset configuration with minimal user modifications. VNF deployment is managed through Ansible (an infrastructure as code platform) "playbooks" that can be modified to deploy different network configurations. In this work, the SD-Core network was deployed with a multiple UPFs and a single AMF and SMF. The SD-core VNFs are standards guided but deviate from 3GPP documentation in some notable ways. Firstly, SD-Core implements a non-standard metric function for AMF and SMF data collection. Secondly, SD-Core implements a runtime operational control function (ROC) for slice definition and UE orchestration. Thirdly, SD-Core does not allow UEs to access multiple slices simultaneously.
The non-standard aspects of SD-core highlight the fact that open-source cores take liberties with standards documentation to create functional implementations of 5G protocols. The metrics function is a supervisory system that provides data to an open-source monitoring system called Prometheus. Prometheus can be used to monitor events in time-series AMF, SMF, and UPF data. In the SD-Core implementation, AMF and SMF metrics are concentrated in the metric function while UPF data is pulled directly from each UPF. Optionally, these metrics can be visualized using an open-source visualization application called Grafana. These systems are all implementation decisions to make network monitoring convenient for the network operator. The ROC function provides a REST API that enables the network orchestrator to define SIM cards, devices, device groups, ip pools, UPFs and slices. Device groups are an implementation specific construct that are not defined in 3GPP standards documentation. Device groups are introduced as an organizational tool for grouping devices that have different QoS guarantees.
A major limitation of SD-Core is that UEs are restricted to a single device group and each device group is assigned to a single slice. This results in UEs being limited to participation in a single slice regardless of how the RAN is configured. In the standards documentation, each UE should have a list of network slice selection assistance information (NSSAI) that indicate a set of slices that a UE has access to. The decision to create device groups and limit UEs to participation in a single device group has the adverse consequence of omitting a standard guided feature of 5G networks.

Open5GS

Open5GS is an open-source project that provides VNFs for 5G NR and LTE core networks. The project enables users to build individual VNFs from source code or deploy them using Kubernetes and helm charts as a management tool. Open5GS offers a robust 5G core but is more compartmentalized than SD-Core. This is illustrated by the fact that, unlike SD-Core, Open5GS does not provide a software defined RAN implementation and depends on user configuration of a separate open-source or commercial RAN. Two compatible RANs investigated in this work are the open-source software defined RAN UERANSIM and the commercial Amarisoft RAN. The narrower focus of Open5GS makes a single all-encompassing deployment more difficult to set up, but provides benefits in flexibility.
Open5GS supports Kubernetes based horizontal pod autoscaling (HPA). HPA is used to deploy additional resources to VNFs based on user-specified tolerances on virtual resource usage such as CPU and memory. This allows Open5GS deployments to contract and expand relative to resource utilization as guided by 3GPP standards. Additionally, Open5GS manages slices and authorized UEs through an implementation specific database control interface. This database manages the SIM cards, slices, and QoS similar to the ROC in SD-Core. Open5GS has no limitation on the slice participation of UEs meaning that UEs can request and hold PDU sessions on multiple slices simultaneously as per standards.
Open5GS manages metric collection and event reporting through Prometheus and Grafana. Metric collection is not enabled by default and the metrics scraped by Prometheus are not 1:1 implementations of performance metrics defined in standards documentation.

ONAP

ONAP is a suite of open-source applications that were developed initially by AT&T and China Mobile to facilitate automation of early stages of network function virtualization (NFV). It was initially developed to automate the functions of OpenStack for orchestration, lifecycle management, and metrics collection for network functions deployed in virtual machines. AT&T and China mobile decided to open source these applications and ONAP was born and has since achieved the status of a Linux Foundation sponsored open-source project. ONAP is preparing for its 15th release and considerable work has been done adding new features and integrating open-source standards.

Open

Figure 5. ONAP Architecture for planned OSLO Release

As the architecture shows in Figure 5, ONAP is a large, multi-function, and complex platform consisting of several components that can be operated independently or as part of the larger platform. Most commercial entities utilizing ONAP have teams of developers dedicated to maintaining their ONAP setup and contribute back code enhancements to the ONAP project. However, it can also be scaled to support research and experimentation by focusing on the subset of its functionality tailored more towards deployment, lifecycle management, and monitoring. The major applications that perform these functions are Service Design and Creation (SDC), Policy, Software Defined Network Controller (SDNC), and Data Collection Analytics and Events (DCAE). Once deployed, Active and Available Inventory (A&AI) can be used to monitor the deployment of Virtual Functions (VF's).

Simplified ONAP Overview

Open

Figure 6. Simplified view of major ONAP components and Responsibilities

ONAP can be understood as a collection of applications to facilitate the design, orchestration, operations, and analytics of network service functions, as seen in Figure 6. In the case of a 5G or other cellular network service, components are bundled into a package by the Service Design and Creation (SDC) and Controller Design Studio (CDS) applications, distributed to the ONAP runtime components including Service Orchestrator (SO) which then deploy those services on cloud infrastructure. This could be Kubernetes clusters, OpenStack, or other cloud services.
Once deployed ONAP has applications to track these services in inventory, (Active and Available Inventory (A&AI), and microservices that can interface with data collectors or analytics microservices provided by Data Collection, Analytics, and Events (DCAE). This process is illustrated in Figure 7.

Open

Figure 7. ONAP Design, Orchestration and Analytics Simplified

The essential takeaway is that ONAP can deploy Open5GS into a Kubernetes cluster provided it receives valid onboarding artifacts to build a model that will successfully deploy.

Data Collection, Analytics and Events (DCAE)

The DCAE system is used to gather performance, usage, and configuration data from the managed environment which is then fed into different analytic applications. These applications can earmark anomalous events and trigger actions in the managed environment. The DCAE system has several components which can be distributed for large scale deployments or centralized to support greater processing capacity and better connectivity. The main components are as follows: collection framework, data movement, storage lakes, analytic framework, and analytic applications.

DCAE VES Collector

The VNF Event Stream Collector is designed to receive event message streams from virtual network functions. ONAP has worked to define the VES standard with 3GPP and other SDOs. Each connected client can directly send messages to a VES collector microservice, running under the DCAE umbrella within an ONAP deployment. Messages are classified by topic and once received are published on a message bus (Data Movement as a Platform (DMaaP)) that are then accessible by DCAE consumers. Note that DMaaP has been replaced by Strimzi/Kafka as the event streaming provider in later ONAP releases, however it performs the same functions.

DCAE Analytics Microservices

DCAE provides a mechanism for analytics microservices to operate on events received from the message bus. These analytics take the form of a microservice and subscribe to a specific event topic on Strimzi/Kafka. The microservice usually contains logic to process the received event data and generate an output message that is pushed back out to Strimzi/Kafka on a different topic to be made available to other consumers. In some cases, the analytic microservices contain hooks to other ONAP components such as Policy or CPS.
The current New Delhi release of ONAP contains several example microservices as part of the standard DCAE release including a KPI computation microservice, a slice analysis microservice, and a Self-Organizing Network (SON) handler microservice among others to provide implementations of various use cases related to cellular network management.

Cybersecurity Threats

The 5G network transfers voice and data at unprecedented rates and scale. User Equipment (UE) now encompasses any connected device which will include vehicles in V2X communications in the near future. While the network is often broken up into the Control and User Planes, threats can affect one or more planes. For instance, over-the-air radio threats could include traditional DoS or RF jamming or more sophisticated threats to privacy and user tracking and detection \[2\]. Internal or external threats are also of concern. Insider concerns could be present with trusted entities leveraging access to the network management config. The Core presents another critical and complex layering of functionality vulnerable to attack. By design, the network leverages several cloud-based technologies and virtualization and each aspect has its own respective security concerns. For example, a recent HTTP/2 "Rapid Reset" DDoS attack was exposed and mitigated by Google \[3\]. Since the 5G service-based architecture (SBA) uses HTTP/2, it's unclear to what degree such attacks are possible in telecom networks using common internet protocols.

In our investigation we demonstrate a proof-of-concept vulnerability for inefficient infrastructure resource utilization and its potential to incur undue costs to the MNO. Using similar tools, an adversary could theoretically target adjacent, co-located user traffic or slices, through exploitation of virtualization and overutilization of the underlying hardware to induce service degradation. Additionally, hardware and supply chain concerns arise due to the heterogeneity and the "open and interoperable" nature of the design. Below, we brief a few areas of cybersecurity concern for the Access Network (AN) and Slicing.

Access Network

As access technologies and network access points evolve, cyber risks are expected to increase. 3GPP standards provide access through the RAN which represents the predominant mode of establishing a 5G connection. Another option is through the Non-3GPP Interworking Function (N3IWF) which facilitates protocol conversion and mediation, providing a secure gateway and access from non-5G access points, e.g., 3G, LTE, or WiFi networks.
Further, the industry is shifting to an Open RAN standard, allowing for the open and interoperable interfaces and sub-components from multiple vendors. The overall security challenges remain similar to other telecommunication technologies such as the need to prevent denial of service (DoS) threats as systems grow in size and complexity. One new and emerging consideration centers on supply-chain threats. As multiple vendors and increased heterogeneity is introduced into the RAN, it will be critical to assure software and hardware is obtained from trusted vendors. It may be possible to leverage tools in formal verification for independent validation of components.
Other concerns also deal with emerging technologies, namely the exponentially-growing use of AI/ML and deployment of IoT devices. Additionally, complexity is introduced by using AI/ML models, which are increasing deployed as neural networks (NN). These models often provide little to no assurances on their performance or resiliency to attack. In a similar manner, the explosion of IoT devices connecting to the network presents a potential a new threat surface, at a large scale, and is at risk for adversarial hijacking. For example, the 3GPP guides that trust in Stand-alone (SA) 5G degrades as one moves away from the Core. Accordingly, as the model evolves, practitioners will need to account for how these additional layers of complexity affect network operations at scale. For instance, our investigation laid the groundwork for a proof-of-concept slice threat emulation, data collection, and processing to detect inter-slice mobility threat actors. A sophisticated threat actor or nation state could use similar, standards-based, mechanisms to orchestrate a large-scale attack using hijacked IoT devices.

Slicing

The 5G threat surface contains several threats, such as DoS attacks on signaling, misconfiguration, man-in-the-middle (MitM). Our investigation into an economic attack has potential to scale up to network degradation or DoS through a large-scale deployment. Examples of misconfigurations could be where the MNO or operators configure incorrect slice access resulting in exploitative movement. While we don't explore MitM methods in this report, these are of concern as they could unknowingly modify communications between parties. As mentioned above, leveraging a wide variety of web technologies and heterogenous hardware has potential to open up threats previously not considered in telecommunications systems.

Other Threats

Vulnerabilities are likely to be introduced into the 5G system through the leveraging of modern technologies, e.g., cloud and web infrastructure and protocols, IoT devices, small and large scale 5G and non-5G access points, and especially AI/ML. Fortunately, there is considerable ongoing research which comes along with the increased considerations in using the respective technologies. As mentioned, the cloud brings distributed and virtualized functionality, both of which have active research so the security professional need not start from scratch. The largest capability, however, remains the use of AI/ML and its impact is expected to be disproportionate and rapidly increase in the near term. It's clear that threat actors will leverage AI/ML, especially generative AI like large language models (LLM), for a variety of attacks. Operators and security researchers are also expected to leverage AI/ML for network and cyber defense. However, AI/ML systems, especially neural network-based models, present additional security considerations and an entire field of Trustworthy AI (TAI) is rapidly evolving to address model robustness and resiliency. With the additional of such high-tech, enabling technologies, operators are advised to consider component security and its potential to impact or expose vulnerabilities of the broader network.
The remainder of this report details the background, implementation, and cyber-testing results of a particular 5G slice security threat: The Distributed Slice Mobility threat. The investigation touches on a few aspects from above, namely, leveraging an open-source orchestration framework, two open-source Cores with varying degrees of functionality, and the scaling of virtualized resources. Each facet represents security considerations related to software frameworks and their implementation, and data identification, collection, and processing. Many of these are outside of our direct control, although the option to contribute to and code in additional functionality is available (given additional resources). As operators consider how to architect their 5G system and weigh available frameworks and tools, either open-source or proprietary, inherent security considerations should be part of the design process.

The Distributed Slice Mobility (DSM) Threat

The distributed slice mobility attack (DSM) is an attack that leverages knowledge of the 5G architecture and slicing to cause performance and economic damages to a 5G network \[4\]. The attack is outlined in the following steps: 

1. A malicious actor identifies a network they wish to target and gathers resources in the form of UEs that can connect to the network. These UEs can be owned by the malicious actor or, more likely, distributed UEs such as a botnet.

2. After acquiring resources, the attacker begins an attack loop:

   1. Malicious UEs surge to a targeted slice and simultaneously request PDU sessions on that slice.

   2. The malicious UEs remain on the target slice for some time (t_up) until the network deploys additional resources to the slice to handle the load.

   3. The malicious UEs vacate the target slice and request PDU sessions on different random slices.

   4. The malicious UEs remain on alternate random slices for some time (t_down) until the network removes the previously deployed resources due to lack of demand.

   5. The attack loop repeats starting from a).

This attack seeks to cause performance and economic damages by taking advantage of the dynamic nature of VNFs and slicing. The DSM attack has additional cost over a standard DDoS attack because it causes harm to both control plane function and user plane functions. The AMF and SMF are harmed by a surge of PDU session requests in step 2a). This surge of requests causes performance damages by preventing legitimate users from connecting to the network and economic damages by forcing the deployment of additional AMF and SMF resources. The same damages are true for the UPF which sees a surge in uplink and downlink data transfer which can slow the data rate of legitimate users while forcing the UPF resources to expand to accommodate the junk data being requested by malicious UEs. The malicious UEs vacate the target slice in step 2c) to allow network contraction. The malicious actor wants the network to contract because both hosting and deploying VNFs is an expensive process. The damage is maximized by allowing the network to contract and immediately forcing another expansion of resources. The malicious UEs scatter to random slices on the network to make identification harder.

Attack Implementation Requirements 

Several key considerations went into selecting an open-source 5G core for the DSM attack implementation. The following points were identified as components for the threat.

1. Automated VNF scaling

2. Core resource utilization monitoring

3. Multiple slices with unique SNSSAI and QoS rules

4. UE slice mobility

The VNF scaling is required as an implementation proxy for resource scaling. In our lab environment, our VNFs were instantiated in Kubernetes pods and the threat triggered auto-scaling. Next, Core resource utilization monitoring would allow for (near) real-time monitoring of underlying infrastructure usage, e.g., CPU and memory. Multiple slices were also instantiated and managed to better emulate a real-world scenario. Finally, UE slice mobility was emulated through scripts. The following sections detail the design decisions for Core selection and threat implementation.

5G Core Selection 

Of the two open-source cores investigated, SD-Core and Open5GS, both support Kubernetes based deployment and can therefore utilize HPA for automated VNF scaling. Open5GS actively deploys HPA objects with unconfigured scaling rules while HPA is an experimental feature on SD-Core. This means both cores can be configured to automatically deploy additional control plane VNFs when a certain amount of processing resources are used. Both cores also support the use of Prometheus for metric scraping. Neither core adheres directly to 3GPP guided performance metrics, but each have analogous metrics that provide a well-rounded perspective on the state of the core network. Additionally, both cores support the creation of slices at different QoS levels with unique SNSSAI. Ultimately, the deciding factor for 5G core selection was UE orchestration capability. The DSM attack is impossible to implement without slice mobility and SD-Core does not allow UEs to participate in multiple slices despite 3GPP standards enabling UEs to have multiple SNSSAI. Open5GS allows UEs to hold PDU sessions on multiple slices concurrently making it the optimal platform for threat implementation and analysis.

Threat Implementation 

Open

Figure 8. DSM attack highlighting the impacted components. The malicious actor takes control of a set of UEs that cause resource/performance damage to control and user plane functions.

The DSM threat was implemented using Open5GS, the Open5GS UE database control, Kubernetes based HPA, and the Amarisoft UE simulator. The Open5GS core network control plane was deployed using Kubernetes on a virtual machine. The control plane had a single VNF of each type by default. Six UPFs were deployed on separate virtual machines in the same network and routed to the core SMF. Each UPF was used to create a single slice with the NSSAI and traffic type defined in Table 1. Different kinds of traffic were specified to emulate the purpose of slices as logical separation between UE applications and QoS levels. Each slice shared a single RAN and all core AMF/SMF resources. Figure 8 shows the experimental setup for the DSM attack and highlights the affected VNFs.  

Table 1. Slice NSSAI and protocol used

The Open5GS database control was used to assign UE SIMs and corresponding slice permission / QoS level for each device. Using the database control, 180 UEs were evenly distributed across the 3 categories of SST. Each UE was assigned the SNSSAI corresponding to both SDs for a given SST. For example, 60 UEs were assigned to SST 1 and each UE in that group was given permission on SD 111111 and 222222. From the 180 UEs, a subset of ~50 random UEs were selected to be under malicious control. This number was selected after experimentally determining that approximately 50 UEs were required to force network resource expansion. Each UE under malicious control was given permission on all 6 network slices to enable attacks on any slice.
Kubernetes based HPA was used to define control plane expansion rules for the AMF and SMF based on CPU utilization. The AMF and SMF are the primary functions impacted by the surge of PDU session requests made in the DSM attack. The HPA scaling rules used for both the AMF and SMF are defined in Table 2. These HPA rules enable the core network to expand and contract relative to the amount of traffic at a given time. It is assumed that the threat actor has knowledge of the policies for scaling the network up and down so that they can design their attack around those parameters.

Table 2. HPA Scaling Policies

The Amarisoft UE simulator is used to simulate UEs and to manage both benign and malicious network traffic scenarios. The general traffic patterns will be discussed here and the details of the Amarisoft simulator will be discussed in a subsequent section. Firstly, a benign scenario was defined for each slice. A benign scenario consisted of rules defining the maximal number of UEs that would be active, the power on and power off duration a UE, and the characteristics of traffic that the UE requests from the network. Traffic characteristics were things like the protocol, data rate, and duration of traffic. These benign scenarios were then augmented to implement the DSM attack for the ~50 malicious UEs on the network. These malicious UEs followed the steps outlined in the DSM threat section while the benign UEs performed the same operations as the benign scenario.

Data and Metrics: Identification and Collection

Core-Specific Metrics (from SD-Core and Open5GS)

3GPP defines key performance indicators (KPIs) for monitoring the status of 5G networks. The relevant categories of KPIs for detecting the DSM attack are \[5\]:

1. Accessibility

2. Integrity

3. Utilization

The open-source 5G implementations investigated in this work do not provide direct standards-guided KPIs. Appendix A shows a comparison of standards guided KPIs and available metrics in each core. Table 3 and Table 4 show the list of considered metrics for SD-Core and Open5GS respectively. Figure 9 provides an overview of the data collection procedure and the following sections provide further details for collection at various network components.

Table 3. SD-Core Metrics

While the metrics are not identical to 3GPP guidance they can be used to calculate or approximate standards guided KPIs. Each open-source core has a reasonable representation of the relevant KPI categories needed to detect the DSM attack. Open5GS has a major advantage in that metrics are collected per slice rather than aggregated across all slices and delivered as a single value. SD-Core only separates UPF traffic metrics by slice and makes no distinction of the number of UEs connected to each slice.

Table 4. Open5GS Metrics

VES Collection

The ONAP virtual event streaming (VES) collector is used to collect metric data from an ONAP managed core network. The VES collector is connected to the ONAP event streaming platform Strimzi/Kafka which allows various ONAP microservices to ingest the data for further process or orchestration activities. ONAP uses a framework of "producers", "consumers", and topics to deliver data between the core network and orchestration services. The VES-collector is a producer, that publishes data to a VES event topic. The VES event topic can be queried by consumers such as the proposed attack detection and mitigation model. Topics work on a first in first out basis and deliver the maximum amount of data possible when queried.
The VES-collector is not configured to work directly with Prometheus which was the only provided data collection utility for each of the open-source cores. To connect the VES-collector with Open5GS a 3^rd party VES-Prometheus adapter (VESPA) was used. VESPA uses custom object definitions to identify and pull Prometheus metrics for delivery to the VES-collector. VESPA uses a configuration file to define targets for VESPA to query from Prometheus and deliver to the VES-collector. This adds the benefit that the Prometheus query language (PromQL) can be used to define expressions that can be applied to targeted Prometheus endpoints. For example, the successful PDU session creation metric is a raw counter that provides the total number of PDU sessions over all time. Instead, an expression can be defined to return the number of PDU sessions created in a certain time frame by taking the difference in time.

Amarisoft UE Simulator

In addition to 5G core KPIs, metrics for each induvial UE are necessary to determine not only if there is an attack in progress but which UEs are contributing to the attack. This information is not accessible through the core network but rather the RAN. The Amarisoft callbox was used as the RAN for this work and the UE metrics specified in Table 5 were collected from the callbox.

Table 5. UE Metrics

Open

Figure 9. Data collection from the Open5GS core and Amarisoft callbox. Data is funneled to ONAP for orchestration and threat detection.

Threat Analysis: Detection and Mitigation

In this work, an anomaly detection model is utilized to identify and mitigate the DSM attack.
Figure 10 shows the organization of the previously discussed components necessary to monitor

Open

Figure 10. Full implementation, the Open5GS core is orchestrated by ONAP where the anomaly detection and threat mitigation control modules sit. Metrics are collected from Open5GS and the Amarisoft callbox. The DSM attack is launched through the Amarisoft UE SIM.

NN Model Architecture: Autoencoder

Autoencoder neural networks are a type of unsupervised AI model that use encoding and decoding modules to learn the latent representation of data. When a sample is fed into the autoencoder it first passes through the encoder module. The encoder performs a non-linear compression on the input data to produce a reduced dimension feature set. This reduced-dimension feature set is then passed to the decoder module which attempts to reconstruct the original data from the encoded feature space. The reconstructed output is then compared to the original input to calculate a loss score based on their similarity. Through an iterative training process, an Autoencoder learns what normal data looks like and becomes more successful at reproducing it from the compressed feature space. When the autoencoder is given an out-of-distribution sample it will struggle to recreate it because it was not trained on similar examples. This principle allows a trained autoencoder to quantify how anomalous a sample is by comparing the reconstruction loss of each sample to the average loss of training samples. These properties make autoencoder neural networks powerful anomaly detectors. Figure 11 shows the reconstruction loss of benign and malicious samples from the autoencoders trained in this work.
Autoencoders can be adapted to different data modalities by selecting the type of ML layers used for the encoder and decoder. In this work, 1D-convolutional layers were used to incorporate temporal information. A convolutional autoencoder learns to reconstruct a sequence of samples rather than a single point in time making it learn patterns of behavior in a given timeframe. Temporal information is an important characteristic for DSM attack detection because the attack follows a set pattern in time. Individual time steps do not distinguish the attack from natural surges in traffic that a network might experience. The attack behavior becomes apparent when a set of UEs repeatedly surge and back-off of a single slice. Incorporating the temporal context of the system through a sequence of samples in time reveals this abnormal pattern. The primary drawback of a temporal autoencoder is that it is reactive rather than proactive. The autoencoder must process a sequence of samples that have already demonstrated a malicious characteristic before identifying the problem and acting.
In this work, two 1D-convolutional autoencoder were used as anomaly detectors for DSM attack detection and UE attribution respectively. Each anomaly detector processed sequences of 24 samples gathered from Open5GS core network and Amarisoft callbox respectively. The sequence length was selected based on the HPA scaling rules, properties of the DSM attack, and sample rate of core/UE metrics. The 24-sample sequence corresponds to 2 minutes of data taken at a sample rate of 5 seconds. The DSM attack pattern is repeated based on the total scale up and scale down time of core network VNFs defined by the HPA parameters in Table 2. Some additional overhead time was given in addition to the HPA rules to account for variability in the spin up and tear down time required for Kubernetes pods.

Open

Open

Figure 11. Distribution of reconstruction loss for benign and malicious samples in slice data (top) and UE data (bottom).

A hierarchical approach was implemented in which samples from the core network were processed first to identify if any of the slices were under attack. Figure 12 illustrates the components utilized in the final anomaly detection model.

Open

Figure 12. The anomaly detection model. Two autoencoders are trained on slice and UE metrics respectively. When an anomaly is detected on a slice the UEs corresponding to that slice are checked. The most anomalous UEs are sent to the threat mitigation controller.

Open5GS metrics in Table 4 are split into separate samples for each slice and passed to the anomaly detection model. When the slice anomaly detection model identifies an ongoing attack, it signals which slice is being targeted to the UE anomaly detection model and filters all of the samples of UEs that were not active on that slice during the attack time frame. The UE anomaly detection model then processes the samples for each candidate UE to identify which UEs may be participating in the attack. This approach is far more efficient than processing the samples for every single UE on the network at each timestamp and reduces the possibility of false positives by first checking to see the overall health of each slice. The UE anomaly detection step uses a high reconstruction loss threshold so that only the most anomalous UEs are flagged for countermeasures. This threshold was selected empirically by taking the mean and standard deviation of benign reconstruction loss. The threshold was then set as the mean plus three standard deviations to ensure that almost all benign samples would be correctly classified. Choosing a high threshold results in higher false negative but fewer false positives. The consequence of missing individual malicious UEs is relatively low and if a sufficient subset of is detected the attack can be thwarted. The IMSI of each anomalous UE is then sent as an alert to a separate module that takes appropriate action to mitigate the threat. See Appendix B for plots of the confusion matrices generated at different detection thresholds using our autoencoder.

Mitigation

The Open5GS core provided a UE database control API that interfaces with the UDM. The UDM is responsible for managing UE SIM information and the QoS afforded to each UE allowed on the network. The API provides three possible approaches to threat mitigation each with their own pros and cons:

1. Ban malicious UEs from the network preventing access to the core

   1. Pros:

      1. Prevents access attempts to the core network

      2. Mitigates damage on both the control and user plane

   2. Con: If a legitimate UE is falsely identified as malicious, it will be removed from the network entirely

2. Remove the PDU session permission of malicious UEs on DSM targeted slices

   1. Pros:

      1. Mitigates damage to the user plane and SMF

      2. If legitimate UEs are removed they can still access alternate slices

   2. Cons:

      1. Malicious UEs can still make PDU session requests to the AMF

      2. The AMF still experience performance and economic damages

3. Throttle malicious UEs bitrate between the user plane and data network

   1. Pros:

      1. Reduces the impact on the user plane by reducing data rates

      2. If a legitimate UE is throttled the UE still has service (although reduced)

   2. Cons:

      1. The threat to control plane resources may not be fully mitigated

      2. The attacker could deploy additional UEs to cause the same effect on the UPF

Figure 13 illustrates the mitigation techniques and their placement within the threat assessment framework.

Open

Figure 13. DSM attack mitigation with walls representing possible mitigation strategies. UE BAN is between the UE and AMF. PDU session revoking in between the SMF and UPF. Bitrate throttling is between the UPF and DNN.

Banning malicious UEs means the AMF will reject inbound 5G session establishment requests coming from the gNB. This protects all core network and user plane function. Removing PDU session privileges allows malicious UEs into the core but prevents them from gaining access to the user plane. Throttling traffic allows malicious UEs to have access to both the control and user planes but lowers the resources allocated to them. Of the available mitigation techniques, the strategy of banning malicious UEs from the network was adopted. While heavy handed, this approach is the only available method for preventing malicious access to both the control and user plane functions. Harm to legitimate UEs can be mitigated by setting a high threshold for malicious UE detection. This means only the "most malicious" UEs would be removed from the network. If only a subset of the malicious UEs can be identified and removed the threat can be mitigated by starving the attacker of their resources. Additionally, a form of exponential backoff timer could be employed to remove malicious users for increasing periods of time. This would allow legitimate UEs back onto the network while progressively increasing the ban times for UEs that continue to exhibit malicious behavior.
Mitigation can be implemented in the testbed network by updating the UDR in the core network. Open5GS uses a "database control" API to manage SIM identities and their associated data such as NSSAI, and QoS. Sending request to the Open5GS database control API updates the information stored in the UDR. The information stored in the UDR is used by other VNFs to make decisions on incoming UE requests. When a malicious UEs IMSI is removed from the UDR the AMF rejects all incoming 5G session establishment requests from that UE. Removing the PDU session privileges for a UE on a specific slice is a less effective mitigation technique because the AMF still has to process PDU session requests with the SMF before rejecting them.

Discussion and Future Work

Several efforts have begun work to leverage AI/ML capabilities to address cybersecurity in telecommunications. One example of an over-the-air attack (OTA) targeted the Signal Synchronization Block (SSB) to inject a signal at a record low of 3.4 dB _below_ the legitimate signal to overshadow and perform a DoS attack \[6\]. Other research focused on the Core, using usual network metrics such as packet loss rate, delay budget to predict the slice type. A long short-term memory (LSTM) based neural network, dubbed DeepSecure, was used to detect DDoS attacks \[7\]. Another effort used packet captures at various points on a 4G/5G network, leveraging usual protocol features such as Layer 4 protocol, sequence, or offset for attack detection \[8\]. While there are countless research questions to pursue, our work and literature review focused on service degradation and threat detection focused on the Core and aimed to leverage inherent 5G (3GPP-based) metrics and KPIs. Accordingly, the aforementioned and all publicly-available research literature, to the best of our knowledge, largely attempts to leverage "smart algorithms", such as ML or neural networks, using standard network measurements and common intrusion detection system (IDS) datasets, e.g., 5G-NIDD \[8\]. A variety of models are tried using standard best practice metrics such as precision, recall, area under the curve (AUC), and/or mean squared error (MSE) against known ground truths. However, this is limiting in our view as it's unclear how to transfer these methods to operational, real-world networks, especially at scale. Further, there is likely a rich, untapped set of metrics, KPIs, and data specific to the 5G, and any future 3GPP, architecture which seems underutilized.

Our work has taken the first steps to identify and leverage 3GPP-guided metrics through two open-source Cores. Additionally, the initial effort represents a foundation on which future cyber research can occur. For example, the DeepSecure work uses the CICDDoS 2019 dataset to train a slice prediction model as part of its DDoS detection \[7\], \[9\]. Our foundation can readily accommodate both inherent 5G data generation _and_ native ML development and testing using metrics sourced from the Core. This presents a "closed-loop" and approachable research thrust. Similarly, RAN threats are now also approachable. Using the SigUnder example above, data can be readily gathered from the Core and additional data could be identified if needed. Assuming one could implement the SigUnder attack OTA, our research foundation could leverage the existing data collection and ML processing to generate data and train a model for RAN threat detection.

Conclusion

This 5G slicing cybersecurity effort implemented a novel the slicing threat, identified and packaged metrics and KPIs for analysis, and demonstrated a proof-of-concept neural network-based ML model for threat detection. Further, our work guides network mitigation actions directly to Core or RAN components, allowing future work to extend and incorporate into an orchestration framework for network control. Our work focused on the Core and we explore two (2) open-source Cores: SD-Core and Open5GS \[10\], \[11\]. Most of the developed capability and code resided within ONAP, which was leveraged for data collection, pipelining, ingestion, and AI/ML model processing. Combined, these modules formed a complete, end-to-end workflow for assessment and detection of the DSM threat. Notably, this foundational framework readily allows future cyber investigations. For example, other slice security research efforts could leverage the existing data pipeline and processing, extending or swapping out particular modular components as needed for the specific case. As more complex cybersecurity research is undertaken, we expect further evolution in data/metric identification and collection and additional model architectures. A small effort was made to investigate the open-source code base of the two Cores and feature additions for un-implemented metrics were not pursued; as there are several dependencies, it's possible future work could add custom code for desired features and/or metrics.

Leveraging the Amarisoft Callbox and UE Simulator, we were able to generate the necessary data for sufficient scaling up of the DSM attack. A notional autoencoder (AE) model was trained and tested with appreciable performance in discriminating between _normal_ and _malicious_ UEs. Finally, a set of mitigation actions was identified and guided for _how_ and _where_ to potentially deal with the threat. This list presents a notional set of actions for initial exploration and pros and cons are also provided; it is expected that as such capabilities evolve, these actions will be incorporated into the orchestration layer, likely ONAP, and a more comprehensive set of actions can be catalogued to provide fine-grained control. The AE models have a false positive and false negative rate of approximately 11 and 14%, respectively, in the UE identification case. See Appendix B for more details and performance under different threshold choices. Further efforts to "scale up and out" for increased number of users and user data and additional metrics, respectively, would likely boost AI/ML-enabled capabilities. In summary, this effort demonstrates the utility of leveraging comprehensive 3GPP-inherent metrics and AI/ML methods for cybersecurity research, greatly extending traditional techniques using packet captures.

References

[1]"5G System Overview." Accessed: Nov. 07, 2024. [Online]. Available: https://www.3gpp.org/technologies/5g-system-overview
[2]N. Ludant, P. Robyns, and G. Noubir, "From 5G Sniffing to Harvesting Leakages of Privacy-Preserving Messengers," in 2023 IEEE Symposium on Security and Privacy (SP), May 2023, pp. 3146–3161. doi: 10.1109/SP46215.2023.10179353.
[3]"How it works: The novel HTTP/2 'Rapid Reset' DDoS attack," Google Cloud Blog. Accessed: Nov. 13, 2024. [Online]. Available: https://cloud.google.com/blog/products/identity-security/how-it-works-the-novel-http2-rapid-reset-ddos-attack
[4]V. N. Sathi and C. S. R. Murthy, "Distributed Slice Mobility Attack: A Novel Targeted Attack Against Network Slices of 5G Networks," IEEE Networking Letters, vol. 3, no. 1, pp. 5–9, Mar. 2021, doi: 10.1109/LNET.2020.3044642.
[5]J. M. Meredith, M. C. Soveri, and M. Pope, "3rd Generation Partnership Project;Technical Specification Group Services and System Aspects; Management and orchestration;5G end to end Key Performance Indicators (KPI) (Release 19)." 3GPP. [Online]. Available: https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3415
[6]N. Ludant and G. Noubir, "SigUnder: a stealthy 5G low power attack and defenses," in Proceedings of the 14th ACM Conference on Security and Privacy in Wireless and Mobile Networks, in WiSec '21. New York, NY, USA: Association for Computing Machinery, Jun. 2021, pp. 250–260. doi: 10.1145/3448300.3467817.
[7]N. A. E. Kuadey, G. T. Maale, T. Kwantwi, G. Sun, and G. Liu, "DeepSecure: Detection of Distributed Denial of Service Attacks on 5G Network Slicing—Deep Learning Approach," IEEE Wireless Communications Letters, vol. 11, no. 3, pp. 488–492, Mar. 2022, doi: 10.1109/LWC.2021.3133479.
[8]S. Samarakoon et al., "5G-NIDD: A Comprehensive Network Intrusion Detection Dataset Generated over 5G Wireless Network," Dec. 02, 2022, arXiv: arXiv:2212.01298. doi: 10.48550/arXiv.2212.01298.
[9]I. Sharafaldin, A. H. Lashkari, S. Hakak, and A. A. Ghorbani, "Developing Realistic Distributed Denial of Service (DDoS) Attack Dataset and Taxonomy," in 2019 International Carnahan Conference on Security Technology (ICCST), Oct. 2019, pp. 1–8. doi: 10.1109/CCST.2019.8888419.
[10]"SD-Core," Open Networking Foundation. Accessed: Apr. 07, 2023. [Online]. Available: https://opennetworking.org/sd-core/
[11]"Open5GS," GitHub. Accessed: Apr. 07, 2023. [Online]. Available: https://github.com/open5gs

Appendix A

A comparison on standards guided KPIs and open-source core metrics. Empty cells indicate no available metric, N/A indicates the KPI is not relevant due to the core configuration (for example using a single VN and not VN groups), and phrases such as "mean" or "difference" indicate the KPI must be calculated using other metrics.