Logo
ScienceStack
Table of Contents
Fetching ...
Sign In

Securing O-RAN Open Interfaces

Joshua Groen, Salvatore D'Oro, Utku Demir, Leonardo Bonati, Davide Villa, Michele Polese, Tommaso Melodia, Kaushik Chowdhury

TL;DR

The paper addresses the security-cost challenge of encrypting Open RAN interfaces, focusing on the E2 near-Real-Time Controller path and the Open Fronthaul. It uses two large-scale platforms—the Colosseum wireless emulator with ColO-RAN and a private 5G/Open Fronthaul testbed—to empirically quantify latency and throughput penalties introduced by encryption (e.g., AES-GCM vs AES-CBC, IPsec vs MACsec) and to model end-to-end delays. The study derives four security-by-design principles: provision sufficient compute resources, choose encryption algorithms carefully, address I/O bottlenecks, and optimize network path sizes, plus demonstrates that E2 incurs modest costs while Open Fronthaul can experience substantial latency and throughput overhead depending on configurations. These insights guide practical secure deployments, informing hardware provisioning, protocol choices, and end-to-end path planning in multi-vendor Open RAN ecosystems.

Abstract

The next generation of cellular networks will be characterized by openness, intelligence, virtualization, and distributed computing. The Open Radio Access Network (Open RAN) framework represents a significant leap toward realizing these ideals, with prototype deployments taking place in both academic and industrial domains. While it holds the potential to disrupt the established vendor lock-ins, Open RAN's disaggregated nature raises critical security concerns. Safeguarding data and securing interfaces must be integral to Open RAN's design, demanding meticulous analysis of cost/benefit tradeoffs. In this paper, we embark on the first comprehensive investigation into the impact of encryption on two pivotal Open RAN interfaces: the E2 interface, connecting the base station with a near-real-time RAN Intelligent Controller, and the Open Fronthaul, connecting the Radio Unit to the Distributed Unit. Our study leverages a full-stack O-RAN ALLIANCE compliant implementation within the Colosseum network emulator and a production-ready Open RAN and 5G-compliant private cellular network. This research contributes quantitative insights into the latency introduced and throughput reduction stemming from using various encryption protocols. Furthermore, we present four fundamental principles for constructing security by design within Open RAN systems, offering a roadmap for navigating the intricate landscape of Open RAN security.

Securing O-RAN Open Interfaces

TL;DR

The paper addresses the security-cost challenge of encrypting Open RAN interfaces, focusing on the E2 near-Real-Time Controller path and the Open Fronthaul. It uses two large-scale platforms—the Colosseum wireless emulator with ColO-RAN and a private 5G/Open Fronthaul testbed—to empirically quantify latency and throughput penalties introduced by encryption (e.g., AES-GCM vs AES-CBC, IPsec vs MACsec) and to model end-to-end delays. The study derives four security-by-design principles: provision sufficient compute resources, choose encryption algorithms carefully, address I/O bottlenecks, and optimize network path sizes, plus demonstrates that E2 incurs modest costs while Open Fronthaul can experience substantial latency and throughput overhead depending on configurations. These insights guide practical secure deployments, informing hardware provisioning, protocol choices, and end-to-end path planning in multi-vendor Open RAN ecosystems.

Abstract

The next generation of cellular networks will be characterized by openness, intelligence, virtualization, and distributed computing. The Open Radio Access Network (Open RAN) framework represents a significant leap toward realizing these ideals, with prototype deployments taking place in both academic and industrial domains. While it holds the potential to disrupt the established vendor lock-ins, Open RAN's disaggregated nature raises critical security concerns. Safeguarding data and securing interfaces must be integral to Open RAN's design, demanding meticulous analysis of cost/benefit tradeoffs. In this paper, we embark on the first comprehensive investigation into the impact of encryption on two pivotal Open RAN interfaces: the E2 interface, connecting the base station with a near-real-time RAN Intelligent Controller, and the Open Fronthaul, connecting the Radio Unit to the Distributed Unit. Our study leverages a full-stack O-RAN ALLIANCE compliant implementation within the Colosseum network emulator and a production-ready Open RAN and 5G-compliant private cellular network. This research contributes quantitative insights into the latency introduced and throughput reduction stemming from using various encryption protocols. Furthermore, we present four fundamental principles for constructing security by design within Open RAN systems, offering a roadmap for navigating the intricate landscape of Open RAN security.
Paper Structure (24 sections, 2 equations, 15 figures, 4 tables)

This paper contains 24 sections, 2 equations, 15 figures, 4 tables.

Table of Contents

  1. Introduction
  2. Background
  3. O-RAN Principles and Architecture
  4. Network Security Protocols
  5. The Latency Cost of Security
  6. O-RAN Security Evaluation Platforms
  7. E2 Interface
  8. E2 Experimental Setup
  9. Open Fronthaul
  10. Open Fronthaul Experimental Setup
  11. E2 Experimental Results
  12. Analysis
  13. Packet Size Analysis
  14. Throughput Analysis
  15. Open Fronthaul Experimental Results
  16. ...and 9 more sections

Figures (15)

  • Figure 1: Overview of the study, focusing on securing the O-RAN architecture's open interfaces.
  • Figure 2: Overall O-RAN architecture showing the 7.2x split with disaggregated , , and . The Near-RT and Non-RT house models to provide closed-loop RAN control under different time scales.
  • Figure 3: O-RAN testbed used to study security in the E2 interface, consisting of three , a , and the near-RT . Each component is implemented in an on top of an within Colosseum.
  • Figure 4: E2 traffic displays a common pattern of one small E2AP packet then one large E2AP packet followed by a as seen in this flow graph.
  • Figure 5: CDF of packet length for both and traffic.
  • ...and 10 more figures