Taking a step back

When discussing the specific benefits and approaches of leveraging eBPF programs, it is very easy to head directly into a technical rabbit hole. The technology is very detailed and can be used for a wide variety of use cases. Consequently, conversations can quickly get wrapped around specifics while glossing over the fundamental elements of the technology. As is true with any newer technology, it is often helpful to level-set and take a step back to discuss the basics. This post will serve to do just that- provide a high level view into the fundamentals of an eBPF program, and more specifically, into an eBPF program being used for 5G SA visibility.

What is eBPF, and why is it so important?

The Extended Berkeley Packet Filter (eBPF) functions constitute a relatively new and powerful set of capabilities embedded in the Linux kernel. First released in 2014 (w/ Linux 3.18) we are seeing accelerating adoption of eBPF for very good reason.

The access that eBPF provides enables a variety of important use-cases in modern cloud-native environments. Use-cases span across application and network performance monitoring, service mesh, load balancing, continuous discovery, dynamic topology and anomaly detection for a variety of development, systems engineering, operations, cloud infrastructure, 5G / IoT, and cybersecurity applications. We discuss these in more detail further below.

As 5G stand alone (SA) environments are beginning to roll out in more earnest, there is an ongoing conversation about how to best support visibility of these container-centric platforms. Network function vendors, carriers, MNOs, and MVNOs all have skin in the game and are taking part in this conversation. At the core of the discussion is a very simple question- what is the best way to instrument and observe these complex and heavily containerized systems?

Traditional tools are no longer viable- this is common knowledge across the ecosystem. The days of deploying taps are long gone, and the days of relying on virtual taps for “cloud resources” have also faded away. We are now firmly in the era of “cloud-native”- the first major evolution of the cloud. Cloud-native has ushered in a new focus on how to best leverage virtual resources and distributed computing, with the core tenet being a shift from VMs and VNFs to containers and CNFs. The challenge now is determining how to best introspect these containerized environments.

How a cloud native packet capture platform can meet the DoD SCCA Requirement

Traditionally full packet capture systems exist to obtain the network communications between various hardware devices – servers, switches, routers – in a physical network environment. With the advent of Kubernetes and cloud native environments that type of traditional approach is no longer effective (or relevant) to provide information into ephemeral resources. Information from microservices and containers such as pod-to-pod, namespaces, and intra-pod communications, etc. are critical for continuous observability and forensic inspection for performance, security, and reliability engineering applications. The evolution of infrastructure and network communications has evolved into virtualized and cloud native architectures such that new technologies are needed to operate and monitor those systems.

Recently, we were approached to partner with a global cloud service provider (CSP) to meet the Department of Defense Secure Cloud Computing Architecture Functional Requirements PDF (DoD SCCA) for Full Packet Capture (FPC) by providing a cloud native FPC solution for their new environments.

How to Get Visibility into 5G SA Ephemeral and Cloud-native Network Resources 

Cloud native and containerized architectures are becoming the de facto design standard for 5G networks and applications. In the telecommunications industry, the players are focused on building out 5G Stand Alone (SA) deployments to deliver the promise of faster connection speeds to enable IoT, medical, autonomous use cases - not to mention improved communications, support the streaming of real-time content and the promise of a myriad of new applications and services. As we work with Tier 1 operators, MVNOs and analytics providers we are encountering a staggering issue: they can no longer adequately monitor, correlate, and measure critical network and application communications events at the container level and across the infrastructure.

The recently announced NSA "instructions for National Security System (NSS), Department of Defense (DoD) and Defense Industrial Base (DIB) system administrators on how to detect, prioritize and replace unauthorized or deprecated TLS protocols with ones that meet current standards.”

Encrypting communications is one of the most critical tools for protecting data. However, if older and out-of-date encryption protocols are in use, that presents a vulnerability that could be exploited to gain access to systems or networks. Updating to the latest TLS 1.3 and the heavily supported TLS 1.2 along with compliant cipher suites and strong authentication is recommended.  

As another year is completed, now is the time to spend reflecting on the state of technology, cybersecurity and innovations. The year 2020 (and previous years) has revealed some uncomfortable truths, despite our best efforts towards improving the future prospects for clients and our industry. We are confronted with some key issues to take to heart, to improve on what has been brought to light through recent cyber events – including the Marriott, TikTok, & Solarwinds incidents - among the growing list of breaches.

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

The 5G era is here. Soon carriers will begin offering 5G services to enable many new and exciting applications for this technology. The consumer applications for 5G are numerous; gaming, autonomous vehicles, video, commerce, tech-enabled medicine, retail, finance coupled with AI, ML, and AR/VR: all of these will provide a new level of user/customer experiences. This will be achieved by an ecosystem of telecommunications infrastructure, software and service providers in support of both existing and new forms of carriers and operators. The White House published the National Strategy to Secure 5G earlier this year and it is worth the time to read it in its entirety.

The ecosystem of players are working hard to define and build a resilient 5G infrastructure that meets the new speed and scale requirements, while also adopting new and open technologies that disaggregate hardware and software functions. 

In our last post “Introducing the MantisNet CVF: Solving Cloud Native, Serverless, Observability Challenges“ we provided an overview of the Containerized Visibility Fabric (CVF) capabilities and made some assertions about how revolutionary and disruptive cloud-native technologies are, the resulting opacity problems, as well the art of the possible insofar as enabling next-generation observability.

In this installment we’ll go into more detail as to what exactly we mean by cloud-native observability as well as the significance, deeper implications of it, interoperability and investment protection. So, let’s revisit containerization, and by extension, why cloud-native observability is so revolutionary.