Security for F1 interface

In the vRAN architecture, where the CU and DU are split, the logical interface that connects the entities is known as the F1. This is comprised of F1-C for control plane and F1-U for user plane. Importantly, 3GPP have defined that this interface and the connectivity between the two should be secured with IPsec.

The F1-C carries F1-AP messages specific to the control plane. Importantly these messages are transported using SCTP, which is much the same as with the N2 interface and NG-AP. PDCP is used to secure most of the control plane communications; however, some of these F1-AP messages carry no inherent security, and are sent in cleartext, which poses a security risk.

The F1-U carries user plane data, and provides a native security function through the use of PDCP. This provides confidentiality as well as integrity protection.

IPsec is specified by 3GPP to secure the connectivity of the F1 interface, and importantly provides the same key functions that we experience with a monolithic gNB:

• Authentication and authorization

• Integrity protection

• Confidentiality

Utilizing a SecGW for enforcing these IPsec functions at the CU-side is beneficial as it can reduce the overall security and cryptographic processing required on the CU. Furthermore, a SecGW can be used to enforce additional granular controls and security, such as SCTP firewall inspection.

While IPsec applies authentication and authorization to both F1-C and F1-U, F1-C should also be considered for IPsec to provide integrity protection and confidentiality because not all F1-AP communications are protected by PDCP. For F1-U, providing anything more than authentication and authorization would be a less efficient solution. (Integrity protection and confidentiality on the user plane would be performed twice: PDCP and IPsec.) Therefore, IPsec with ESP is applied to F1-C, but IPsec with ESP NULL encryption (for example) can be used for the F1-U connections.