The protection of IP based interfaces for 5GC and 5G-AN according to NDS/IP is specified in TS 33.210. Traffic on interfaces carrying control plane signalling can be both integrity and confidentiality protected according to NDS/IP.

IPsec ESP implementation shall be done according to RFC 4303 as profiled by TS 33.210. For IPsec implementation, tunnel mode is mandatory to support while transport mode is optional. IKEv2 certificate-based authentication implementation shall be done according to TS 33.310. The certificates shall be supported according to the profile described by TS 33.310. IKEv2 shall be supported conforming to the IKEv2 profile described in TS 33.310.

If the sender of IPsec traffic uses DiffServ Code Points (DSCPs) to distinguish different QoS classes, either by copying DSCP from the inner IP header or directly setting the encapsulating IP header's DSCP, the resulting traffic may be reordered to the point where the receiving node's anti-replay check discards the packet. If different DSCPs are used on the encapsulating IP header, then to avoid packet discard under one IKE SA and with the same set of traffic selectors, distinct Child-SAs should be established for each of the traffic classes (using the DSCPs as classifiers) as specified in RFC 4301.

The following clause applies to the gNB supporting the split architecture.

The F1 interface connects the gNB-CU to the gNB-DU. It consists of the F1-C for control plane and the F1-U for the user plane. The security mechanisms for the F1 interface connecting the IAB-node to the IAB-donor-CU are detailed in clause M.3.3 of this document. In order to protect the traffic on the F1-U interface, IPsec ESP and IKEv2 certificates-based authentication shall be supported as specified in subclause 9.1.2 of the present document with confidentiality, integrity and replay protection. In order to protect the traffic on the F1-C interface, IPsec ESP and IKEv2 certificates-based authentication shall be supported as specified in subclause 9.1.2 of the present document with confidentiality, integrity and replay protection. IPsec is mandatory to implement on the gNB-DU and on the gNB-CU. On the gNB-CU side, a SEG may be used to terminate the IPsec tunnel. In addition to IPsec, for the F1-C interface, DTLS shall be supported as specified in RFC 6083 to provide mutual authentication, integrity protection, replay protection and confidentiality protection. Security profiles for DTLS implementation and usage shall follow the TLS profile given in clause 6.2 of TS 33.210 and the certificate profile given in clause 6.1.3a of TS 33.310. The identities in the end entity certificates shall be used for authentication and policy checks.. Mutual authentication shall be supported over the F1-C interface between the gNB-CU and the gNB-DU using DTLS and/or IKEv2.

The E1 interface connects the gNB-CU-CP to the gNB-CU-UP. It is only used for the transport of signalling data. In order to protect the traffic on the E1 interface, IPsec ESP and IKEv2 certificates-based authentication shall be supported as specified in subclause 9.1.2 of the present document with confidentiality, integrity and replay protection. In addition to IPsec, DTLS shall be supported as specified in RFC 6083 to provide mutual authentication, integrity protection, replay protection and confidentiality protection. Security profiles for DTLS implementation and usage shall follow the TLS profile given in clause 6.2 of TS 33.210 and the certificate profile given in clause 6.1.3a of TS 33.310. The identities in the end entity certificates shall be used for authentication and policy checks. Mutual authentication shall be supported over the E1interface between the gNB-CU-CP and the gNB-CU-UP using DTLS and/or IKEv2. IPsec is mandatory to support on the gNB-CU-UP and the gNB-CU-CP. Observe that on both the gNB-CU-CP and the gNB-CU-UP sides, a SEG may be used to terminate the IPsec tunnel.