Our 5G Standalone Blog Series Continues
This blog is the second part of our 5G Standalone (SA) series. In the first part of our series, we outlined the nature of the new 5G cloud-native core and innovative network architecture attributes. In this second post, we’ll discuss how this new core architecture is built as a secure network from the ground up and why this poses a challenge for operators when aiming to gain visibility into the customer experience.
Introduction: 5G SA as A Trusted Innovation Platform
5G Standalone will redefine mobile network boundaries by facilitating digitization, automation, and connectivity to machines, robots, and mission-critical use cases such as transport, medical services, and others.
Hence, 5G SA expectations are high, with operators promising a significantly enhanced customer experience through blisteringly fast data speeds, higher capacity, and lower latency. This network evolution is cloud-native and is dependent on the Service-Based Architecture (SBA) as its new underlying technology.
With the future network supporting mission-critical use cases, this raises the bar for greater availability while assuring secured communication services. Thus, in terms of security, 5G marks the beginning of a new era with privacy and security built-in its foundations with advanced controls and measurements, such as new mutual authentication mechanisms, improved subscriber identity protection, and advanced security protocols.
While these advanced security controls were designed to limit the impact of known threats, they also create new challenges. For one, the 5G SA cloud-native environment is altering the core aspects of data access with its topology (physical and virtual), interfaces, and flows (packets, octets, and protocols) all being encrypted. Operators need to search for new ways to monitor and optimize their networks from the RAN to the core to ensure a successful 5G Standalone deployment.
5G SA Core: Opened Yet Secured
As 5G core moves away from traditional telecom-style protocol interfaces, it allows network functions to communicate and expose data using a distributed web services model – a standard API. An API enables the exposure of an organization’s digital services and assets in a controlled way and is a universal concept used by modern software design, especially for web services, and encompasses a wide range of use cases.
As an operator, by using the already widely adopted RESTful paradigms, you can break down traditional network silos and empower vertical markets. This will build upon your network’s infrastructure modular services that will seamlessly slot into place, turning the telco cloud into a service platform for other vendors. Each network function in the 5G core can expose its functionality and communicate through Service-Based Interfaces (SBI’s) using RESTful-based APIs via HTTP/2.
The novelty of the 5G core is that while it allows for its network functions to expose their functionality, it still maintains its communication security by using Transport Layer Security (TLS) protocols.
TLS is a cryptographic protocol that provides end-to-end communications security over networks by encrypting data and authenticating connections when moving data over the internet. In the 5G SA core, TLS offers the highest levels of encryption and privacy.
Encryption of 5G SA core control plane interfaces using TLS represents a major security enhancement over LTE’s Enhanced Packet Core (EPC), in which key control plane interfaces that used protocols such as GTP-C and Diameter were unencrypted. Many operators are using TLS 1.2 with their initial 5G SA core deployment while planning the next step that would provide even better network security – TLS 1.3.
RSA (Rivest–Shamir–Adleman) is the typical key exchange method in TLS 1.2. With RSA key exchange, per-session keys can be derived by passive probes from the Server Private Keys that are relatively static.
To take this process to the next level and provide enhanced network security, operators are planning to use TLS 1.3, which offers a faster TLS handshake and simpler, more secure cipher suites. With TLS 1.3, the direct communication between network functions (NFs) is secured based on mutual authentication keys and transport security and Perfect Forward Secrecy (PFS). PFS refers to an encryption system that changes the keys used to encrypt and decrypt information frequently and automatically, per session.
Unlike TLS 1.2, session keys are generated and exchanged in a way that prevents a passive monitoring system from deriving the per-session key from a static key. This leads to more secure connectivity between NFs, where only authorized parties can access the information.
The Inherent Monitoring Challenge
While implementing previous network security protocols, operators were able to passively decrypt the network traffic, with the introduction of TLS 1.3, this mode of decryption is put to challenge.
As an operator, if you choose to adopt TLS 1.3 for your network core, this will affect passive probing and your ability to understand the customers’ QoE and QoS. This is because it uses a different key generation and exchange method, replacing the static RSA (Rivest–Shamir–Adleman) with Diffie-Hellman Ephemeral (DHE) key exchange. As a result, decrypting the traffic is more challenging.
Within this secured yet encrypted environment, how can you gain real-time subscriber analytics and advanced insights into your traffic? And how can you continuously assure your customers’ quality of experience?
How to Gain Visibility into TLS 1.3 Encryption?
How can you overcome the TLS 1.3 encryption challenge? Here are three main ways which will be further described below.
- Get access to network locations where an unencrypted message is being transmitted, in packet format.
- Collect the data directly from the NFs using event feeds that provide data in unencrypted event format, instead of using a copy of the encrypted packets being transmitted on the NF-to-NF interfaces.
- Obtain the per-session TLS 1.3 keys in real time and use those keys to decrypt the encrypted packets being transmitted on the NF-to-NF interfaces.
Deploy a Pod-Based Monitoring Solution
The first option to successfully monitor SBA data communications within a cloud-native environment, is to implement an E2E service assurance solution that is also cloud native and controlled by Kubernetes. Such a solution inserts a cloud-native component into each network function pod it monitors, which is able to duplicate the packets flowing inside the NF pod and forward a copy directly to the assurance system.
This virtualized component is injected into the same Pods comprising the NF, sharing the same network namespace as the other containers in the pod. In many cases, an unencrypted message is transmitted within the pod from the application containers to a Service Proxy container which encrypts the message and sends it out on the network to the destination NF. Thus, the monitoring component can access the unencrypted traffic. Such a containerized component is lightweight and provides optimal load balancing, with data integrity being agnostic to any network changes, as it is an “organic” part of your network.
Upon capturing the data traffic from the hosting network function, the component sends the traffic to be processed by the solution’s cloud-native virtual probes. This enables you to perform real-time monitoring of encrypted or unencrypted traffic, delivering unique levels of visibility into advanced security protocols and achieving top-level service quality.
Collect and Correlate Multiple Data Sources
The second option is to deploy an independent auditor of the network that collects and correlates unencrypted event data feeds from the NFs themselves, instead of using a copy of the encrypted packets being transmitted on the NF-to-NF interfaces. Thus, the auditor can provide operators with an understanding of the customer experience and enable end-to-end network troubleshooting. This auditor is able to combine standardized and/or proprietary event feeds for E2E 5GC monitoring:
Obtain Keys in Real-Time
The third option is to harvest the TLS keys from the TLS Server and/or Client during sessions, using a software agent. The software agent is authorized to scan system memory and can read keys from TLS processes and libraries and is able to extract the session keys as soon as the TLS handshake is complete. Thus, you can gain high performance with a small footprint since the TLS Key is extracted by the agent and sent to virtual probes before the 1st encrypted packet is transmitted. This enables TLS 1.3 (and 1.2) deciphering on the virtual probe.
Summary
In conclusion, as 5G Standalone continues to be deployed globally, it aims to become a trusted innovative platform that serves critical use cases, making security an imperative ingredient to its success. With the introduction of advanced security protocols and mechanisms, operators encounter critical monitoring challenges that call for an advanced assurance solution to come and mediate within this new reality.
This blog was the second part to our 5G Standalone series. Look out for the next part to learn more about 5G SA. Read why now, more than before, integrating an advanced assurance solution that can address the unique security challenges of 5G SA is imperative to success.
To learn how to assure the lifecycle of your 5G network download our infographic.
This article is subject to Radcom’s disclaimers regarding Forward-looking statements and general information under the links below:
