Sec5G: Securing 5G for Mission Critical Services


OneSource, Consultoria Informáica Lda. https://www.onesource.pt

Experiment description

The 5G standards provided by 3GPP already bring support for mission critical communications, with support for low latency flows, dynamic allocation of resources, resource isolation and push-to-video. However, despite such features, diverse applications, known as Application Functions (AFs) in the 3GPP Service Based Architecture (SBA), need to communicate their specialized requirements to the 5G Core (5GC) when employed in mission critical services.

With Sec5G, OneSource aims at validating the concept of employing NEF as the entry point for Public Protection and Disaster Recovery (PPDR) services in the 5GC, enabling the adjustment of 5G networks to the requirements of such services. While NEF can enable the wider adoption of 5G by providing a set of functionalities allowing a dynamic configuration of the network, performance, security and reliability are of utmost importance for PPDR missions. In this context, Sec5G had two major goals: to assess the performance of OneSource’s implementation of NEF, and to validate an enhanced security framework for 5G Network Functions (NFs), in particular, to provide protection against malicious behaviors (e.g., DDoS attacks, signaling storms, etc.). This security framework includes an Applicational Intrusion Detection and Prevention System (App IDPS) that performs security analysis of NFs, or in this particular case of NEF.

General architecture of the Sec5G platform

NEF is deployed in the 5G core to expose standardized APIs for other services, commonly referred as AFs in the 5G terminology. Platform servers, which support management of PPDR resources in mission critical services, act as an AF and request to NEF the appropriate QoS configurations for the different flows that are associated with the PPDR terminals (e.g. mobile phones), and this request is relayed to the Policy Control Function (PCF) via NEF. The PCF will then assess this request and perform the necessary steps in the Session Management Function (SMF) to re-configure the network. For instance, specific settings are requested for critical types of data, e.g. panic buttons and biosensors that must be prioritized for safety of PPDR personnel, or audio and video flows that must ensure low latency for a real-time full situational awareness picture.

Architecture of the Sec5G App IDPS

While the aforementioned 5GC architecture is defined by 3GPP standards and effectively works in most scenarios, it does not consider the possibility of malicious users and misconfigurations that can lead to problems. Sec5G addresses the security requirements in mission critical services with App IDPS, which performs security analysis and takes measures to block attacks.

A two-phase approach for the experiment was followed. The first phase aimed solely at validating NEF as an entry point for critical communications (represented as AFs), its integration with other NFs and its raw performance with limited resources. The second phase included an additional security layer, enabling a secure NEF through App IDPS and actively blocking API attacks from malicious AFs. It also demonstrated the impact of attacks in terms of performance, both having and not having the additional security layer of App IDPS.

The setup and steps for both phases of the experiment are described below.

  • For the validation of NEF, tests were carried out using 3 AF VNFs, 1 NEF VNF and 1 VNF for dummy 5GC components (e.g. PCF, NRF, BSF, etc.).
    • Functional tests were performed to assess functionality and standard compliance.
    • Performance tests were done to evaluate how NEF performs under heavy load and limited resources. Load was added gradually to ensure that the highest number of processed requests/second is achieved.
    • There was a mapping of 1:1 for VNFs and virtual machines, and each machine had 1 vCPU (@ 2.40 GHz) and 1024MB of RAM.
  • To evaluate the security layer provided by App IDPS, the setup consisted of 2 AF VNFs, 1 NEF VNF, 1 VNF for dummy 5GC components and 1 VNF for App IDPS.
    • Several functional tests were performed using different types of attacks, allowing the system to detect and prevent the malicious usage of NEF resources.
    • Multiple attack types were considered: Denial of Service (DoS), Parameter Attacks (where requests are correctly formed but repeatedly contain invalid values), Malformed Requests and Lack of Rate Limiting (similar to DoS, but at a lower scale and considering multiple simultaneous requests to the same API routes).
    • Performance tests intended to evaluate how attacks affect the performance of NEF, both with and without the addition of App IDPS. Moreover, the footprint of App IDPS in the VNF of NEF was measured.
    • There was a mapping of 1:1 for VNFs and virtual machines, and each machine had 1 vCPU (@ 2.40 GHz) and 1024MB of RAM.


With the gradual addition of load (3 stages, one for each AF VNF running up to 100 instances of the service), the results show NEF processing up to 150 requests/second. However, one needs to take into account that NEF was using a single vCPU, and performance can greatly be improved with multiple vCPUs in parallel. Moreover, NEF is a highly scalable component with a pretty much stateless interface. This means that multiple instances of NEF can be deployed, and load balancing strategies can be used to share the load among them.

CPU Usage for NEF Performance Tests

The second perspective, depicted in the results below, aimed at evaluating how NEF performance is impacted by security. A first set of tests took the malicious AF, as well as another AF with legitimate requests, and had the malicious AF randomly attacking NEF with multiple parallel processes while the legitimate AF aimed at sending 1 request/second without impact in its perceived latency. In this case, the App IDPS security was not enabled. A second set of tests was a replica of the first set, but this time with App IDPS security fully enabled.

CPU Usage for NEF Security Tests (Security Disabled)

CPU Usage for NEF Security Tests (Security Enabled)

From the results depicted above, and thus considering the CPU Usage for NEF with/without App IDPS security enabled, we see that without security there are very high CPU usage fluctuations caused by the constant and undeterred attacks against NEF. Although these were not enough to affect the performance perceived by the legitimate AF (results not depicted for the sake of simplicity), in a best-case scenario illegitimate traffic would be using resources and incurring additional costs without revenue. Also, one may also postulate that with higher number of attacks the CPU resources would be scarce and would lead to a very noticeable impact in the legitimate AFs. Unfortunately, the resources available for our experiment did not allow this to be proven or disproven. On the other hand, if we consider the results obtained with the App IDPS security fully enabled, we see that attacks are quickly mitigated, and performance is barely affected by them. This allows for a simple conclusion: adding App IDPS security adds a slight increase on CPU usage baseline, but it also prevents that large chunks of resources are used by illegitimate traffic. It is thus beneficial to add App IDPS from both the performance and security perspectives.


During the experiment, many valuable lessons were learnt, and further validation and enhancements were achieved for both NEF and App IDPS. Moreover, the results depicted in the previous section allow us to draw important conclusions regarding the goals of the experiment. The first conclusion is that OneSource has developed a scalable, reliable and 3GPP-compliant NEF. This NEF has the potential to be used in Mission Critical Services, and it is already being integrated in PPDR networks for the first 5G deployment trials. The second conclusion is that securing NEF is not only important for the obvious reasons, but also to maintain performance and avoid disruption of service to the users. Finally, we also concluded that security is an essential part of NEF and should be further enhanced to cope with the demanding challenges that any exposed service is deemed to face nowadays.

Contact Us

We're not around right now. But you can send us an email and we'll get back to you, asap.

Not readable? Change text. captcha txt

Start typing and press Enter to search

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.