One of the biggest drivers that has impacted the design of 5G systems is the goal of providing extremely low latency and high-speed data rates throughout the entire network. The increase in data delivery speeds with 5G environments promises staggering benefits- we are talking about moving from the 1 Gbps world of 4G into a promised 10 Gbps future- or more simply put, an evolution akin to shifting from the horse and buggy to internal combustion engines. Such an enormous jump in the speed at which the world’s most valuable resource (data) can be exchanged helps explain the amount of energy and excitement around 5G that we are all collectively experiencing.

But how does this translate into architecture principles?

Leaving carrier aggregation (CA) and massive MIMO aside for another conversation, we will focus on the network itself. For starters, the 3GPP determined early on that the control plane (CP) and user plane (UP) must be split (across both the RAN and the core) so that each plane can be independently scaled and flexibly deployed. In addition to this split, the decision to take a NFV/SDN, or “cloud-native” approach to the underlying resources is critical in achieving the promised speeds of 5G. Cloud-native allows for centralization of compute resources, and optimization of all physical resources that are serving network functions (NF), regardless of location in the network.

NF communications within the SBA

To better illustrate the changes occurring when moving into cloud-native environments, and the implications for 5G network visibility, let’s take a closer look at one of the most important aspects of a successful 5G network deployment- the Service Based Architecture (SBA) that drives the 5G core control plane.

5G-core-control-plane-imageAs defined by the 3GPP, the SBA is

“a system architecture in which the system functionality is achieved by a set of NFs (network functions) providing services to other authorized NFs to access their services”.

As illustrated in the graphic above, there are multiple network functions that co-exist within the SBA, all of which communicate through a common interface- the Service Based Interface (SBI). These functions are used for session management, access authorization, network slicing, subscription management, policy control, and for allowing outside applications to interface with the 5G environment. This is not an exhaustive list of everything these functions accomplish, but it is safe to say that these NFs are essential to the implementation of a 5G network.

Now to pivot back to the topic of cloud-native: these functions are completely software driven and are not bound to proprietary hardware and protocols. The SBA embraces a microservices architecture- NFs are deployed using container technology, where a node (i.e. machine, or “kernel”) can be servicing either a singular function, multiple functions, or perhaps even combining multiple nodes to service a single function.

5G-control-plane-SBI

Regardless of how the nodes are distributed, the main takeaway is that all NFs within the SBA communicate at the “container-to-container” level- allowing for the full benefit of cloud-native flexibility, scale, and performance.

 

Impacts on 5G network visibility

Given that these critical NFs are now communicating at the “container-to-container” level, it is important to note that visibility into communications is a challenge to overcome. If a network operator would like to monitor what is occurring within the SBA, be it for performance delivery or security concerns, they can not utilize traditional network visibility solutions. From network taps, to network packet brokers, all the way to VM-based “cloud” solutions- these approaches simply do not have visibility into container-to-container level communication. This is the visibility gap that many network professionals are facing today. In order to successfully monitor container-level data exchanges within cloud-native environments, you need to leverage a visibility solution that is also cloud-native.

MantisNet’s Containerized Visibility Fabric (CVF) is a cloud-native solution that provides visibility into container level communication. This is possible because the solution leverages visibility agents sitting on the physical machines, or nodes, that are running the virtual NFs- an approach that focuses on “kernel-level” visibility. In doing so, this solution has complete understanding of each node that is spun up, to include all containers (and subsequently, all NFs) running within that node.

All container-to-container traffic is now visible, and available to pipe into analytic solutions or custom analytic pipelines.

5G-control-plane-SBI-MantisNet-visibility

 

5G SBI and encryption

So, if a cloud-native solution is indeed being used to gain visibility, how can it handle encryption? It is widely known, and published in standards, that the SBI utilizes a protocol stack that includes TLS encryption (up to and including TLS 1.3).

5G-SBI-StackIf all the traffic is encrypted, does visibility matter much? The answer to this is twofold:

  1. yes, even if you are monitoring encrypted traffic, there is still a lot to be gained from observation.
    CVF agents extract and publish a wealth of encrypted session parameters, specifically the details of the TLS client - server exchanges, that providers need to meet most of their cryptographic visibility, management, and security demands. Regardless if it is to identify, monitor or quantify encrypted exchanges or to ensure the reliability and stability of systems, or to differentiate legitimate cryptographic exchanges from potentially malicious unknown, unreliable or questionable traffic. The CVF architecture publishes all the metadata and traffic of interest needed to support analytics, decryption, storage and forensic analysis services
  2. yes, if you are leveraging MantisNet’s CVF, you have access to unencrypted information another benefit of using the agent based CVF is that in can also capture the plaintext associated with the encrypted communication (for OpenSSL and GNU encryption libraries, up to and including TLS 1.3). Due to the “kernel-level” visibility that the agents have, they have visibility into the data exchanges made between NFs before they are encrypted. This plaintext is egressed out to a message queue, for consumption by analytic systems, fueling streaming analysis and real-time observability. With plaintext now readily available, operators no longer need to rely simply on “in the clear” metadata regarding the exchanges, or the prospect of capturing all encrypted traffic, as well as the keys, and then decrypting the traffic off-line. Learn more about both of these encrypted session visibility options.

MantisNet’s CVF helps solve tough visibility challenges that are present within 5G environments- or any cloud-native environment for that matter. As more organizations find themselves tasked with the responsibility for monitoring container environments, it is important to consider how this can best be accomplished. 

Discover more

 

Topics: mantis, containers, cloud native network function, 5G

Mike Fecher

Written by Mike Fecher

Mike's a leader in developing client solutions for data center infrastructure, cybersecurity, and network visibility. He has worked with commercial telecom providers, the US Intelligence Community, and various other government agencies to help implement data-centric solutions.