Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 33.501  Word version:  16.3.0

Top   Top   Up   Prev   Next
1…   4…   5…   6…   6.2…   6.3…   6.5…   6.8…   6.9…   6.10…   6.12…   6.14   6.15   6.16   7…   7A…   7B…   8…   9…   10…   11…   13…   13.3…   13.4…   14…   15…   A…   B…   C…   D…   G…   K…   O…

 

9  Security procedures for non-service based interfaces

9.1  General

9.1.1  Use of NDS/IP

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.

9.1.2  Implementation requirements

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.
Up

9.1.3  QoS considerations

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.
Up

9.2  Security mechanisms for the N2 interface

N2 is the reference point between the AMF and the 5G-AN. It is used, among other things, to carry NAS signalling traffic between the UE and the AMF over 3GPP and non-3GPP accesses.
The transport of control plane data over N2 shall be integrity, confidentiality and replay-protected.
In order to protect the N2 reference point, it is required to implement IPsec ESP and IKEv2 certificates-based authentication as specified in subclause 9.1.2 of the present document. IPsec is mandatory to implement on the gNB and the ng-eNB. On the core network side, a SEG may be used to terminate the IPsec tunnel.
In addition to IPsec, DTLS shall be supported as specified in RFC 6083 to provide integrity protection, replay protection and confidentiality protection. Security profiles for DTLS implementation and usage shall follow the provisions given in clause 6.2 of TS 33.210.
Up

9.3  Security requirements and procedures on N3Word‑p. 135
N3 is the reference point between the 5G-AN and UPF. It is used to carry user plane data from the UE to the UPF.
The transport of user data over N3 shall be integrity, confidentiality and replay-protected.
In order to protect the traffic on the N3 reference point, it is required to implement IPsec ESP and IKEv2 certificate-based authentication 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 and the ng-eNB. On the core network side, a SEG may be used to terminate the IPsec tunnel.
QoS related aspects are further described in subclause 9.1.3 of the present document.
Up

9.4  Security mechanisms for the Xn interface

Xn is the interface connecting NG-RAN nodes. It consists of Xn-C and Xn-U. Xn-C is used to carry signalling and Xn-U user plane data.
The transport of control plane data and user data over Xn shall be integrity, confidentiality and replay-protected.
In order to protect the traffic on the Xn reference point, it is required to implement IPsec ESP and IKEv2 certificate- based authentication as specified in subclause 9.1.2 of the present document with confidentiality, integrity and replay protection. IPsec shall be supported on the gNB and ng-eNB.
In addition to IPsec, for the Xn-C interface, DTLS shall be supported as specified in RFC 6083 [58] to provide integrity protection, replay protection and confidentiality protection. Security profiles for DTLS implementation and usage shall follow the provisions given in clause 6.2 of TS 33.210.
QoS related aspects are further described in subclause 9.1.3 of the present document.
Up

9.5  Interfaces based on DIAMETER or GTPWord‑p. 136
This clause applies to all DIAMETER or GTP-based interfaces between the 5G Core and other network entities that are not part of the 5G System. These includes the Rx interface between the PCF and the IMS System and the N26 interface between the AMF and the MME.
The protection of these interfaces shall be supported according to NDS/IP as specified in TS 33.210, unless security is provided by other means, e.g. physical security. A SEG may be used to terminate the NDS/IP IPsec tunnels.
Up

9.6Void

9.7Void

9.8  Security mechanisms for protection of the gNB internal interfaces

9.8.1  General

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

9.8.2  Security mechanisms for the F1 interface

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 [58] to provide integrity protection, replay protection and confidentiality protection. Security profiles for DTLS implementation and usage shall follow the provisions given in clause 6.2 of TS 33.210.
Up

9.8.3  Security mechanisms for the E1 interface

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 integrity protection, replay protection and confidentiality protection. Security profiles for DTLS implementation and usage shall follow the provisions given in clause 6.2 of TS 33.210.
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.
Up

9.9  Security mechanisms for non-SBA interfaces internal to the 5GC and between PLMNsWord‑p. 137
Non-SBA interfaces internal to the 5G Core such as N4 and N9 can be used to transport signalling data as well as privacy sensitive material, such as user and subscription data, or other parameters, such as security keys. Therefore, these interfaces shall be confidentiality, integrity, and replay protected.
Roaming interfaces between PLMNs except for N32, shall be confidentiality, integrity, and replay protected. Protection for the N32 interface is specified in clauses 13.1 and 13.2..
For the protection of the above mentioned internal and roaming interfaces except N32, NDS/IP shall be used as specified in [3], unless security is provided by other means, e.g. physical security. A SEG may be used to terminate the NDS/IP IPsec tunnels.
Up

9.10  Security mechanisms for the interface between W-5GAN and 5GC |R16|

The W-AGF function in Wireline 5G Access network (W-5GAN) terminates the following interfaces:
  • N2 interface between the W-5GAN and the AMF.
  • N3 interface between the W-5GAN and the UPF.
The security of the N2 interface between the W-5GAN and the AMF is as defined in clause 9.2 of the present document.
The security of the N3 interface between the W-5GAN and the UPF is as defined in clause 9.3 of the present document.
On the W-AGF side a SEG may be used to terminate the IPsec tunnels.
Up

Up   Top   ToC