On the Impact of Flooding Attacks on 5G Slicing with Different VNF Sharing Configurations

Virtualized Network Function (VNF) sharing among multiple Fifth Generation (5G) slices allows network operators to increase the efficiency and utilization of the network. However, this sharing of VNFs can result in a degradation of the performance of the slices in the presence of an attack. In this paper, we evaluate the impact of flooding attacks on the performance of 5G slices with different VNF sharing configu-rations. We consider two VNF sharing configurations, in the first configuration, the Session Management Function (SMF) and User Plane Function (UPF) are shared among the deployed slices, while the SMF and UPF of the slices are isolated in the second configuration. The performance of these configurations is evaluated using different traffic types under two flooding attack scenarios; a ping flood attack targeting the data plane of 5G network, and a registration request flood attack directed at the control plane of 5G network. Our results showed different responses in the control and data planes. In the data plane, isolating VNFs of the slices provides better performance and mitigates the adverse effects of the attacks studied.


I. INTRODUCTION
Utilizing 5G resources efficiently and simplifying system implementation can be achieved by adopting the strategy of sharing VNFs across various slices in 5G networks.Sharing of VNFs allows network operators to efficiently utilize the underlying resources and serve multiple slices.On the other hand, sharing VNFs between deployed slices may expose users of one slice to the threats and attacks originating from other slices [1], [2].For example, studies [3] have shown that Distributed Denial-of-Service (DDoS) attacks on one slice can affect the services of other slices if they share the underlying physical resources.
Enhancing network security is an essential requirement of 5G with the emergence of network slicing, VNFs, and VNF sharing between slices [4].One strategy to improve network security is to introduce slice isolation in which each slice is assigned to a set of dedicated VNFs without sharing them with other slices.However, complete isolation of all VNFs reduces resource utilization and increases overhead and cost for the network operator.In our previous work [5], we formulated a security-aware VNF sharing model that optimizes resource utilization while ensuring the security requirements of the slices.
In this paper, we deploy a 5G testbed using open-source tools and evaluate multiple VNF sharing configurations under § The corresponding author, Email: abdulazizabdulghaff@cmail.carleton.cavarious attack scenarios.This work aims to examine the impact of attacks on VNF sharing strategies, ensure the availability of a slice, and evaluate the network performance using various User Equipment (UE) applications and traffic types under different attacks.
To the best of our knowledge, this is the first work to examine the impact of attacks on slice performance under different VNF sharing configurations in a virtualized 5G testbed.Our contribution in this paper has multiple parts explained as follows: (1) evaluating and comparing the performance of the proposed VNF sharing network configurations during flood attacks on each of the data and control planes in a 5G testbed environment.(2) considering two VNF sharing configurations and comparing the performance of both network configurations with multiple UE applications, including iPerf downlink data transfer, ping RTT, and UE procedures delay, under flood attack traffic.and (3) considering two flood attack scenarios, one to flood the data plane network using a ping flood attack, and the second to exhaust the resources of the control plane VNFs in the core network with a registration request flood attack.It is worth noting that setting up a virtualized (and emulated) 5G network from open-source tools for the work in this paper has been a substantial exercise but it is unavoidable in the absence of expensive real infrastructures for testing.
The remainder of this paper is organized as follows.Section II presents the related studies that implemented 5G slicing and the studies that analyzed the impact of the attack on the 5G slicing.Section III describes the testbed setup and the network configurations we consider in this work.Section IV explains the threat model, while Section V describes the evaluation methodology used in this work.Next, we present and discuss the results of the experiments in Section VI.Finally, Section VII concludes the paper.

II. RELATED WORK A. Implementation of 5G Slicing
The study carried out by Chai et al. [6] implements a 5G testbed using open-source tools such as OpenStack [7], Tacker [8], and Free5GC [9].The authors further evaluate the performance of three different deployment scenarios with multiple dedicated slices.The performance metrics used to compare the configurations include registration time, network throughput, utilization, and response time.However, the authors' findings suggest that no single configuration outperformed others across all performance metrics.Instead, the choice of deployment strategy depends primarily on the specific requirements of the slice being deployed.A similar study done by Lee et al. [10] also uses OpenStack [7], Tacker [8], Free5GC [9], and UERANSIM [11] to deploy the 5G network.Their work aims to enable users to automatically deploy 5G slices based on their requirements.
Saha et al. [12] demonstrate a solution to monitor and analyze network slicing Key Performance Indicators (KPIs) using open-source tools.The 5G testbed is set up using Free5GC [9] and UERANSIM [11].To monitor the slice KPIs, the authors implement a Steam game server [13] that enables the streaming of a game to a UE through the 5G network.The average downlink throughput per network slice is selected as monitored KPI during the experiments.Two experiments are performed that compare the performance of the network while streaming a game through a dedicated slice and a besteffort slice with background traffic.The authors claim from the results that background traffic impacts the quality of the stream and degrades the quality of experience for the UE.Similarly, Pepito et al. [14] also perform video streaming experiments utilizing an Nginx web server [15] and Open Broadcaster Software (OBS) [16] in a 5G network consisting of Free5GC [9] and UERANSIM [11].Their work aims to develop an opensource deployment of Multi-access Edge Computing (MEC) in the 5G network.Garcia-Aviles et al. [17] also develops a multi-slice 5G network prototype and considers two use cases of video streaming and augmented reality applications.The access network of the prototype is implemented using srsLTE [18] whereas the core network functionality is provided by custom-built network functions implemented by the authors.The work provides comprehensive details on the proposed solution, however, it lacks an extensive performance evaluation of the deployed prototype.
In summary, previous studies focused mainly on the deployment and performance evaluation of 5G slicing, but they have not examined the impact of attacks on 5G slicing.On the contrary, our paper investigates the impact of attacks on the data plane and control plane of UE applications under different VNF sharing configurations.

B. Impact of Attacks on 5G Slicing
The work by Danish et al. [2] proposes a slice isolation technique to mitigate the impact of DDoS attacks on 5G core network.The authors propose an optimization model to reduce end-to-end delay while ensuring slice isolation to protect against such attacks.The performance is evaluated in a combination of simulation and testbed experiments.From the results, the benefit of isolation is evident, as it reduces the impact of the DDoS attacks and ensures the availability of the slices.However, their work is limited to the isolation of physical resources for slice isolation.In contrast, our study extends beyond this by also addressing isolation at the VNF level.
Chen et al. [19] present the feasibility of implementing 5G network slicing using open-source tools such as OpenAirInterface (OAI), nextEPC, and OpenStack.Three different slices are deployed to serve enhanced Mobile Broadband (eMBB), Ultra-Reliable Low Latency Communications (URLLC), and massive Machine Type Communications (mMTC) applications.The performance of the architecture is evaluated using various metrics including bandwidth, latency, throughput, and packet loss rate.Also, the impact of User Datagram Protocol (UDP) DDoS attack on slice throughput is analyzed.The major limitation of their work is the utilization of nextEPC, which is software designed to deploy the 4G core network, to handle the functions of the 5G core network.Furthermore, their work does not prioritize the analysis of attack impacts.However, our work uses Free5GC for core network deployment and emphasizes identifying the impact of attacks on 5G slicing.
The impact of the DDoS attack in 5G network slicing was also studied by Khan et al. [3].The authors deploy a 5G testbed using Free5GC [9] and UERANSIM [11].The authors demonstrate the impact of the DDoS attack on the bandwidth and latency experienced by the UE.Furthermore, the authors collect a new DDoS attack dataset from the deployed 5G testbed which, according to the authors, is the first dataset for the DDoS attack in 5G network slices.The major contribution of their work is the proposed deep learning-based model to detect DDoS attacks.From the results, the authors conclude that their proposed model can successfully detect 99.99% of the DDoS attacks.The authors only consider the DDoS attacks on the data plane in their work, whereas in our work we analyze the impact of the data plane attack as well as the control plane attack.
Amponis et al. [20] carry out various attacks against the Packet Forwarding Control Protocol (PFCP) in a 5G testbed setup.The 5G testbed is implemented using Open5GS [21] and UERANSIM [11].The authors executed five attacks on the PFCP protocol, leading to service disruptions for legitimate UEs.However, their study focuses mainly on assessing the security of the PFCP protocol and the impact of PFCP attacks on the UE.

III. SYSTEM ARCHITECTURE AND TESTBED SETUP
In this section, we provide an overview of our implemented testbed setup and system configurations.This setup is essential to evaluate the network performance under various VNF sharing configurations while subject to different attack scenarios.

A. Testbed Setup
We utilize open-source tools to deploy our testbed.The testbed is running on a single physical machine with 32 cores of Intel Xeon Processor and 24 GB of RAM.To run a complete 5G network, we deployed up to 7 Virtual Machines (VMs) using Oracle VM VirtualBox [22].Free5GC [9] is an opensource project to deploy 5G core networks and is installed on a dedicated VM to provide 5G core network functionality.Furthermore, Free5GC also provides UPF functionality, and in our setup, we use dedicated VMs to run UPF functions only.For Radio Access Network (RAN), we install UERANSIM [11] in three VMs to emulate 5G UEs and gNodeBs (gNBs).Finally, a dedicated VM acts as a Data Network (DN) in our testbed setup instead of the public Internet.Although Free5GC

B. Network Configurations
In these experiments, we consider two network configurations with different VNF sharing options between different network slices, as shown in Figures 1 and 2. In the deployed network, we implement two network slices.The UE 1 and UE 3 belong to slice 1 while UE 2 belongs to slice 2. Figure 1 shows the first network configuration (C1) where the SMF and UPF Network Functions (NFs) are shared between the two slices.For the second network configuration (C2), each slice has dedicated SMFs and UPFs as shown in Figure 2. In the figures, the network entities that belong to slice 1 are shown in green, while the network entities that are part of slice 2 are shown in purple.All other core VNFs are shared between the two slices in both network configurations.
Note that we run a single UE and gNB in a single VM.In our initial experiments, where we deployed multiple UEs with one gNB on a single VM, we observed that the gNB became the limiting factor when handling a large volume of traffic from the UEs.To address this bottleneck in RAN, we deployed each UE with its own gNBs in a separate VM.

IV. THREAT MODEL
In this section, we outline the threat model and the different attacks that we consider in this study.
1) Assumptions: The following are the assumptions in our threat model: • The operator's 5G network supports multiple network slices.
• The UEs, including the attacking UEs, are legitimate users of the 5G network.• It is not possible for the attacker to modify the hardware configurations of the bare-metal systems • The attackers can generate a high volume of traffic that can exhaust the resources of the operator's 5G VNFs.2) Adversaries: In this study, we consider the attacker as a legitimate user of the network slice.The attackers will generate large traffic to impact the performance of the legitimate UEs in other slices that share the same VNFs as the attacker's slice.
3) Attack Scenarios: In this study, we consider the following attack scenarios targeting the data plane and the control plane of the 5G network: • Data plane flood attack: The first attack scenario is the ping flood attack initiated by the attacking UEs to flood the links of the slice and to exhaust the resources of the data plane VNFs [23].When the UEs send ping requests, the DN responds with ping replies, further flooding the network links.Figure 3 shows the ping flood attack (red arrows) originating from UE 1 and UE 3, towards the DN and the ping replies from the DN to the UEs.We use data plane flood attack and ping flood attack interchangeably to refer to this attack throughout the paper.• Control plane flood attack: Request flood attacks are common in different types of networks [23], [24].The second attack that we consider is the registration request flood attack targeting the control plane VNFs [25].With this attack, the attacker sends many registration requests to the core network and tries to maliciously register with a slice that the attacker is not authorized to join.While the registration request does not succeed in our testbed as the authentication of the attacking UE fails and the 5G core rejects malicious UE request, the attacking UEs persistently sending registration requests at a high rate causes a flooding situation.The attacker's aim is to overload and consume the resources of the core VNFs such as reaching 100% CPU utilization, ultimately degrading  In the first set of experiments, we analyze the impact of the ping flood attack launched by UE 1 and UE 3 on the average downlink data transfer rate for UE 2 within slice 2. The iPerf 3 tool [26] is used to measure the available bandwidth between UE 2 and the DN, where the server part is running on the DN and the client part is running on UE 2. This is shown in Figure 3, where the red arrows from UE 1 and UE 3 indicate the ping flood attack, while the 1 ⃝ green arrow from the DN towards UE 2 shows the direction of the traffic sent by the iPerf.This experiment is performed to mimic the behaviour of a file download application running on a UE and compare the performance of multiple configurations in the presence of an attack.

B. Round-trip time (RTT) during data plane flood attack
The second set of experiments evaluates the effect of the flooding attack on the round trip time (RTT) of the ping between the legitimate user (UE 2) and the DN.Similar to the previous experiments, the ping flood attack originates from UE 1 and UE 3, while UE 2 sends ping requests to the DN while measuring the RTT.This is shown in Figure 3, where the attack traffic is shown with red arrows, and the ping requests ⃝.This experiment mimics the functionality of a low-latency application (e.g., online gaming) and analyzes the impact on its performance during an attack or flooding traffic.

C. Procedures delay during control plane flood attack
The third experiment measures the delay in successfully completing a procedure by a legitimate UE during the control plane flood attack.For this purpose, the attacking UEs (UE 1 and UE 3) send registration requests to join slice 2. To perform the experiments, we set the sending rate of each UE at 15 requests per second, so the total combined rate of both UEs is 30 requests per second.This experiment is depicted in figure 4, where the attacking UEs 1 and 3 try to maliciously send registration requests to join slice 2 which they are not authorized to join.Meanwhile, UE 2 initiates the registration and Protocol Data Unit (PDU) session establishment procedures and measures the delay to perform these procedures successfully.

VI. RESULTS AND DISCUSSION
In this section, we present the results of the three experiments and compare the performance of the C1 and C2 configurations.The reported results are the average of 5 experiment runs for each configuration.

A. Downlink data transfer rate during data plane flood attack
The first experiment measures the iPerf downlink data rate under the ping flood attack.Figure 5 compares the data transfer rate results of configurations C1 and C2, with blue and green colors, respectively.The x-axis represents the experiment timeline in seconds, while the y-axis shows the data transfer rate in megabits per second (Mbps).When the experiment starts, the data rate in both configurations is more than 100 Mbps.However, after a few seconds, it drops to approximately around 100 Mbps.The attacking UEs, 1 and 3, start the ping flood attack traffic at 10 seconds, as represented  Furthermore, we calculate the total data transferred from the DN to UE 2 and compare the results of the C1 and C2 configurations as shown in Figure 6.The average data downloaded by UE 2 in the C1 configuration is 242.4Megabytes (MB), while the data downloaded in the C2 configuration is 532.8MB.The graph also includes a 95% confidence interval for each configuration.As the confidence interval does not overlap, there is a statistically significant difference between the performance of the C1 and C2 configurations.To analyze the impact of the flooding attack on the latency of data traffic sent by the UE, we measure the ping roundtrip time (RTT) between UE 2 and the DN under the attack.Figure 7 shows the results of this experiment, where the numbers of ping requests are represented on the x-axis and the RTT is on the y-axis.At the beginning, the RTT for both configurations (C1 and C2) is approximately around 15 ms.However, once the attack traffic starts at ping request number 9, the RTT for configuration C1 increases significantly and remains consistently above 50 ms throughout the duration of the attack.On the other hand, the benefit of having isolated VNFs is prominent, as the flooding attack does not affect the RTT in the case of configuration C2.

C. Procedures delay during control plane flood attack
The experiments discussed in this subsection are performed to measure the delay to complete the UE registration procedure and the PDU session establishment procedure under the control plane flood attack.The attack traffic is present throughout the entire experiment.Figure 8 (a) shows the average registration delay for UE 2. The delay in performing the registration procedure for configurations C1 and C2 is 240 ms and 229 ms, respectively, which is approximately in the same range.The figure also displays the 95% confidence interval of the results.Notably, the intervals for both configurations overlap, indicating that the difference between C1 and C2 is statistically insignificant.
Finally, the delay in performing the PDU session establishment procedure is depicted in Figure 8 (b).The average delay for C1 is 380 ms, while the average delay for C2 is 414 ms.Again, the overlap in the 95% confidence interval for these two averages suggests that there is no significant difference between the performance of the C1 and C2 configurations.This can be attributed to the fact that the registration and the PDU session establishment procedures mainly involve the core network functions at the control plane level.It should be noted that UPF serves as a data plane NF.In the two configurations we implemented, only the SMF and UPF are either shared or isolated.The remaining VNFs are shared between slices in both configurations.Consequently, the impact of a control plane flood attack on the results remains relatively indistinguishable.
The results obtained in this paper are only applicable to the configurations and parameters used in this work, and the results may change using other configurations and parameters.

VII. CONCLUSION
The results clearly demonstrate the advantages of isolating VNFs among different slices, as the impact of attacks on the UE downlink data rate and the RTT is significantly diminished compared to configurations with shared VNFs.Specifically, our findings reveal that the UE downlink data rate experiences a remarkable increase of 1677% in the isolated SMF and UPF configuration (C2) compared to the shared SMF and UPF configuration (C1).Similarly, the RTT in the isolated VNF configuration is substantially reduced by 447% compared to the shared VNF configuration.At the control plane level, our analysis of the UE procedures delay indicates an insignificant difference between C1 and C2.This could be due to the fact that most of the control plane VNFs are shared between both configurations, with the exception of SMF.Further experiments with configurations involving the of more control plane VNFs are required to verify whether isolating more control plane VNFs mitigates the impact of attacks."All the results presented are based on the configurations and parameters used in this work, and these results might change with different configurations and parameters.However, it is essential to recognize that there is a trade-off involved: while increasing the isolation of VNFs between slices may improve security, it also increases the overhead.

Fig. 1 .
Fig. 1.Network configuration C1 with shared SMF and UPF.The yellow rectangles represent dedicated VMs.The network entities belonging to slice 1 are shown in green color, while the purple color is used for slice 2. The shared SMF and UPF are shown as a gradient of both colors.The rest of the core VNFs are shown in white blocks, whereas the gNBs are blue in color.The rest of the figures follow similar color coding.

Fig. 2 .
Fig. 2. Network configuration C2 with isolated SMF and UPF.The yellow rectangles represent dedicated VMs.The network entities belonging to slice 1 are shown in green color, while the purple color is used for slice 2. The rest of the core VNFs are shown in white blocks, whereas the gNBs are blue in color.The rest of the figures follow similar color coding.

Fig. 3 . 1 ⃝
Fig. 3. 1 ⃝ Downlink data transfer experiment (Section V-A) and 2 ⃝ Ping RTT experiment (Section V-B) during data plane (ping) flood attack (figure only shows C1 configuration but the same experiment is also performed on C2 configuration) Figure 4 shows the control plane flood attack, where UE 1 and UE 3 send malicious registration requests (shown in red arrows) to the Access and Mobility Function (AMF) to join slice 2. Throughout the paper, we interchangeably use control plane flood attack and registration request flood attack to refer to this attack V. EVALUATION METHODOLOGY To evaluate and compare the performance of the VNF sharing configurations, C1 and C2, we conducted three experiments to assess the following three performance indicators: A. Downlink data transfer rate during data plane flood attack

Fig. 4 .
Fig. 4. UE 2 procedure delay experiment (Section V-C) during control plane flood attack (figure only shows C1 configuration but the same experiment is also performed on C2 configuration)

Fig. 8 .
Fig. 8. Average (a) Registration, (b) PDU Establishment Delay for UE 2 during control plane flood attack (Section VI-C) Once the attack is launched, the data transfer rate of UE 2 in C1 drops significantly from 100 Mbps to around 2 Mbps.On the other hand, configuration C2 with isolated SMF and UPF is less affected by the presence of an attack, since the data transfer rate of UE 2 only decreases from 100 Mbps to 80 Mbps.The attack lasts for a duration of 30 seconds, between 10 and 40 seconds.Once the attack stops (second red line at 40 seconds), the data rate in both configurations starts to increase and stabilizes around 100 Mbps again.With this result, we can see the adverse impact of an attack launched by UEs in slice 1 on UE belonging to slice 2 when the SMF and UPF are shared among the slices.