Towards Quantum-Safe O-RAN -- Experimental Evaluation of ML-KEM-Based IPsec on the E2 Interface

1. Problem Statement

As Open Radio Access Network (O-RAN) deployments expand, the disaggregation of network functions (CU, DU, RIC) significantly increases the attack surface. The E2 interface, which connects the 5G Node B (gNB) to the Near-Real-Time RAN Intelligent Controller (Near-RT RIC), is critical for near-real-time control loops (10ms–1s) and telemetry.

• Security Threat: The "store-now, decrypt-later" threat posed by future quantum computers renders current public-key cryptography (RSA, ECC, ECDH) vulnerable.
• The Gap: While Post-Quantum Cryptography (PQC) standards like NIST's ML-KEM (formerly CRYSTALS-Kyber) are being finalized, there is a lack of empirical data regarding the performance impact of integrating ML-KEM into the IPsec protocol specifically for the O-RAN E2 interface.
• Key Question: Can O-RAN operators migrate to quantum-safe IPsec on the E2 interface without violating the stringent latency and stability requirements of Near-RT RIC xApps?

2. Methodology

The authors designed and executed an experimental evaluation using a reproducible, open-source testbed that emulates a 5G O-RAN environment.

Testbed Architecture

• RAN Emulation: srsRAN (implementing O-DU and O-CU with 3GPP-compliant splits).
• Core Network: Open5GS (5G Core).
• Control Plane: FlexRIC (Near-RT RIC platform running representative xApps).
• Security Stack: strongSwan (IKEv2/IPsec daemon) patched with liboqs (Open Quantum Safe library) to support NIST-standardized ML-KEM.
• Hardware: A high-performance server (Dual Intel Xeon Gold 6248, 256GB RAM) running VirtualBox to host multiple VMs representing the gNB, RIC, Core, and Security Gateways.

Experimental Scenarios

The study compared three distinct configurations under realistic signaling workloads:

1. Baseline: No IPsec (unprotected E2).
2. Classical: IPsec with ECDH (Elliptic Curve Diffie-Hellman, Curve25519) key exchange.
3. Post-Quantum: IPsec with ML-KEM (Module-Lattice-based Key-Encapsulation Mechanism) key exchange, testing both ML-KEM-768 and ML-KEM-1024 parameter sets.

Metrics Evaluated

• Tunnel Setup Latency: Time from IKE_SA_INIT to IKE_AUTH completion and Child SA establishment.
• Data Plane Latency: Overhead introduced by IPsec encryption (AES-256-GCM) on steady-state traffic.
• xApp Stability: Impact on Near-RT RIC control loops and xApp startup times during tunnel establishment.

3. Key Contributions

1. First Empirical Evaluation on E2: This is the first known study to experimentally evaluate ML-KEM-based IPsec specifically on the O-RAN E2 interface using a standards-aligned, open-source testbed.
2. Reproducible Framework: The paper provides a fully documented, open-source framework (srsRAN, Open5GS, FlexRIC, strongSwan/liboqs) allowing other researchers to replicate PQC performance studies in O-RAN.
3. Quantitative Trade-off Analysis: It delivers concrete data on the latency overhead of PQC, distinguishing between handshake overhead and steady-state data transmission costs.

4. Results and Analysis

The experiments yielded the following key findings:

• Tunnel Setup Latency (Handshake Overhead):

  • Classical (ECDH): Average IKE Initiation time was ~1.36 ms.
  • ML-KEM-768: Added approximately 3 ms of overhead compared to ECDH (Total ~4.3 ms).
  • ML-KEM-1024: Added approximately 4.7 ms of overhead compared to ECDH (Total ~6.0 ms).
  • Observation: The overhead is primarily concentrated in the IKE Initiation phase due to the computational cost of lattice-based key encapsulation. The IKE Authorization and Child SA setup times remained relatively stable across configurations.

• Data Plane Latency:

  • Enabling IPsec (AES-256) added a consistent overhead of approximately 165 µs compared to the unencrypted baseline.
  • Crucially, no significant difference was observed in steady-state data latency between Classical IPsec and ML-KEM IPsec, as symmetric encryption (AES) remains unchanged; only the key exchange differs.

• xApp and Control Loop Stability:

  • The introduction of ML-KEM-based IPsec did not disrupt the runtime behavior of Near-RT RIC xApps.
  • Control loops remained stable, and xApp startup times were unaffected by the tunnel establishment phase. The additional ~3–5 ms delay in tunnel setup was deemed negligible for the 10ms–1s control loop constraints of the Near-RT RIC.

5. Significance and Conclusion

• Feasibility: The study concludes that integrating ML-KEM into IPsec for the O-RAN E2 interface is practically feasible on contemporary server-class hardware.
• Migration Strategy: The small overhead (3–5 ms) in tunnel establishment suggests that operators can begin staged migration to quantum-safe security without compromising the near-real-time responsiveness required for RAN optimization.
• Future Work: The authors propose extending this framework to TLS-based interfaces (A1, O1, O2) and exploring the use of Federated Learning (FL) to collaboratively optimize PQC parameters and detect anomalies across distributed O-RAN vendors without sharing sensitive data.

Summary Verdict: The paper successfully demonstrates that the transition to quantum-safe cryptography in O-RAN is not a "showstopper." While PQC introduces a measurable but minor latency penalty during the initial key exchange, it does not degrade the steady-state performance or stability of critical 5G control loops, validating the path toward "store-now, decrypt-later" resilient networks.