Section: 9.4 Security mechanisms for the Xn interface
Content: 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 sub-clause 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 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[ Network Domain Security (NDS); IP network layer security ]  [3] and the certificate profile given in clause 6.1.3a of TS 33.310[ Network Domain Security (NDS); Authentication Framework (AF) ]  [5]. The identities in the end entity certificates shall be used for authentication and policy checks. Mutual authentication shall be supported over the Xn interface between the NG-RAN nodes using DTLS and/or IKEv2. NOTE 1: The use of transport layer security, via DTLS, does not rule out the use of network layer protection according to NDS/IP as specified in TS 33.210[ Network Domain Security (NDS); IP network layer security ]  [3]. In fact, IPsec has the advantage of providing topology hiding.. NOTE 2: The use of cryptographic solutions to protect Xn is an operator's decision. In case the NG-RAN node (gNB or ng-eNB) has been placed in a physically secured environment then the 'secure environment' includes other nodes and links beside the NG-RAN node. QoS related aspects are further described in sub-clause 9.1.3 of the present document.