HackMD05/09/2022
What kind of threats are there in open fronthaul?
Is there any requirement of security in open fronthaul?
What are the requirements?
How do we test fronthaul security?
References
Itroduction
The open fronthaul interface is a standard protocol for a link between the radio units and the distributed unit in RAN, enabling different vendors interoperable. We study the security requirements of the open fronthaul interface for 5G networks. The O-RAN management plane (M-plane) mandates an end-to-end security using SSHv2, whereas the O-RAN control and user plane (CU-plane) do not support any security measure yet. We investigate MACsec for the CU-plane security, which is recommended as one of security options in the eCPRI specification. Furthermore, we implemented quantum-safe crypto solutions using a hybrid mode key exchange and signature schemes, which can be applied for the post-quantum SSH and MACsec protocols.
What kind of threats are there in open fronthaul?
- The O-DU sends UL C-plane messages and DL C-plane messages to O-RU to trigger transmission and reception of RF. The DL C-plane message describing multiple symbols must arrive at O-RU within a certain time window for the O-RU to successfully receive DL I/Q data in U-plane messages from O-DU. Likewise, the UL C-plane message
describing multiple symbols must arrive within a certain time window for the O-RU to successfully receive RF signal and send UL I/Q data in U-plane messages to O-DU. Any delay of these messages would cause the O-RU to drop/discard U-plane traffic from O-DU and the UE .An adversary can inject its own DL C-plane or UL C-plane messages by spoofing the associated O-DU. As a result, it would block the O-RU from processing the corresponding U-Plane packets received from the O-DU and O-RU respectively, leading to temporary DoS and, limited cell performance on cells served by the O-RU. - Open Fronthaul U-plane transports 5G System Control Plane and User Plane messages between O-CU-CP and UE, and O-CU-UP and UE. The Packet Data Convergence Protocol (PDCP) provides confidentiality and integrity protection of 5G System Control Plane and User Plane between O-CU-CP and UE, and O-CU-UP and UE.
Security Controls for S-plane
The Precision Time Protocol (PTP) is a protocol used to synchronize clocks within a PTP network. Within a PTP domain, the grandmaster clock is the source of time to which all other PTP clocks in the domain are synchronized. The IEEE 1588 standard specifies the Best Master Clock Algorithm (BMCA) for electing the best clock from PTP
Network and Local PTP Clock. The BMCA runs on PTP instances in the network continuously and is adjusting to changes in that network. PTP ANNOUNCE messages are used to build a timing distribution hierarchy with grandmaster at the top. There can be many grandmasters in PTP Network, but PTP Domain can have only one. The chosen grandmaster clock is responsible for providing timing to the PTP slave nodes.
Following the selection of the new grandmaster, the grandmaster begins transmitting the current time within the SYNC message and FOLLOW_UP messages if applicable. This allows the other clocks to synchronize their time to the grandmaster.
S-Plane attacks include an attacker masquerading as a grandmaster or manipulating PTP to degrade synchronization.
Is there any requirement of security in open fronthaul? What are the requirements?
C-plane
Requirements
[REQ-SEC-OFCP-1] The C-Plane shall support authentication and authorization of O-DUs that exchange C-plane messages with O-RUs.
Security Controls
Authentication and Authorization of network elements supporting the C-Plane
This clause addresses requirements REQ-SEC-OFCP-1 based on the use of IEEE 802.1X-2020 Port-based Network
Access Control for authentication and subsequent authorization of PTP nodes.
Clause of this document provides requirements and security controls for the authentication and authorization of
an O-DU and other network elements supporting the C-Plane within Open Fronthaul point-to-point LAN segments.
S-plane
Requirements
[REQ-SEC-OFSP-1] The S-Plane shall support authentication and authorization of PTP nodes that communicate with other PTP nodes within Configuration LLS-C1, Configuration LLS-C2, or Configuration LLS-C3.
NOTE: This ensures least privilege access to the S-Plane where authenticated and authorized PTP nodes communicate over the Open Fronthaul network.
NOTE: There is no specific requirement for authentication and authorization mechanism of S-plane PTP messages.
[REQ-SEC-OFSP-2] The S-Plane should provide a means to prevent spoofing of master clocks.
[REQ-SEC-OFSP-3] For the O-DU at the Data Centre deployment model the S-Plane should protect against MITM attacks that degrade the clock accuracy due to packet delay attacks or selective interception and removal attacks .
Security Controls
Synchronization Architecture Redundancy
This clause addresses requirement REQ-SEC-OFSP-3 by providing an architectural recommendation to S-plane security based on redundancy in the Open Fronthaul Synchronization architecture.
O-RAN.SFG.Security-Requirements-Specifications-v03.00
The following architectural recommendations for security controls build S-Plane redundancy into to the Open Fronthaul for increased robustness against security breaches.
SEC-CTL-OFSP-1: The Open Fronthaul Synchronization architecture should support simultaneous Grandmasters.
SEC-CTL-OFSP-2: The Open Fronthaul Synchronization architecture should support the assignment of GMs to physically separated PTP ports. Multiple masters could be connected to offer topology resilience. O-RAN Synchronization Architecture and Solution Specification Clause 8.2.3 Timing/Synchronization. Redundancy & Resiliency provides additional details on redundancy for the Open Fronthaul Synchronization architecture.
uthentication and Authorization of PTP nodes
This clause addresses requirements REQ-SEC-OFSP-1 and REQ-SEC-OFSP-2 based on the use of IEEE 802.1X-2020
Port-based Network Access Control for authentication and subsequent authorization of PTP nodes.
Clause 3.2.5.5 of this document provides requirements and security controls for the authentication and authorization of
S-Plane PTP nodes within Open Fronthaul point-to-point LAN segments.
M-plane
Requirements
Security Controls
Open Fronthaul Point-to-Point LAN Segment
The Open Fronthaul Ethernet L1 physical interface comprises one or more coaxial cables, twisted pairs, or optical fibers.
These are also known as point-to-point LAN segments. Each end of the Open Fronthaul point-to-point LAN segment comprises a physical connection (colloquially known as an Ethernet Port) to physical O-RAN network elements, e.g., DU, O-RU, etc., as described.
An Open Fronthaul network element is an entity in a point-to-point LAN segment. Xhaul Transport Network Elements that share a point-to-point LAN segment with Open Fronthaul network elements are also Open Fronthaul network elements. Examples of O-RAN Alliance defined Open Fronthaul network elements include, but are not limited to, O-DU, O-RU, switches, FHM, FHGW, TNE and PRTC-T/GM .
Requirements
REQ-SEC-OFHPLS-1: The Open Fronthaul shall provide a means to authenticate and authorize point-to-point LAN
segments between Open Fronthaul network elements.
REQ-SEC-OFHPLS-2: The Open Fronthaul shall provide a means to detect and report when an authorized point to point LAN segment is made or broken.
REQ-SEC-OFHPLS-3: The Open Fronthaul shall provide a means to block access to unused Ethernet ports in an Open
Fronthaul network element.
Open Fronthaul implementations may support IEEE 802.1X-2020 to satisfy the requirements listed above.
Implementations that support optional 802.1X shall provide the security controls as specified in sections and
Solution 1: Authentication and Authorization based on 802.1x Port based Network
Access Control
EEE 802.1X-2020 is optional to support.
NOTE: Further security requirements for IEEE 802.1X-2020 will continue to be studied. It is intended to evolve IEEE
802.1X-2020 to a mandatory requirement for the Open Fronthaul interface after completion of the study.
How do we test fronthaul security?
Port-based Network Access Control provides the means to control network access in point to LAN segments within the Open Fronthaul network. Port-based network access control in the O-RAN Alliance
Open Fronthaul comprises supplicant, authenticator, and authentication server entities described in IEEE 802.1X-2020.
The security test cases in this section covers the validation of the authenticator and supplicant functionalities of the
11 802.1X support by O-RAN components of O-DU and O-RU.
Authenticator Validation
Requirement Name: Authenticator function of O-RAN component
Requirement Reference: Section O-RAN Security
Requirement Description: Requirements of Authenticators in the open fronthaul network and its interface to an
Authentication Server
Threat References: T-FRHAUL
O-RAN Component References: O-DU, O-RU
Test description and applicability
Open fronthaul network component (such as O-RU and O-DU) could serve the authenticator role of the 802.1X for
port-based network access control. This test validates the authenticator requirements of the network component to serve the request from supplicant(s) using EAP TLS authentication per 802.1X-2020 .
Test setup and configuration
First set up an authentication RADIUS2 24 server (e.g. free radius on Linux) with certificates (root, server and client) created, proper configuration of .cnf files and eap configuration (eap.conf), then start the authentication RADIUS server.
DUT is an O-RAN component with IP enabled network interface reachable to the authentication server and 802.1X enabled for its open fronthaul interface.
Test procedure
First set up the 802.1X test tool host/device with EAP authentication for 802.1X protocol.
Because Radius support is required over interface between an authenticator and
authentication server in the security requirement specification, only Radius authentication server
is called for in this security test environment setup. Diameter based authentication server could
be used as an alternative.
