Section: I.3 Security mechanisms for interfaces with RNCs in exposed locations
Content: In order to protect the Iu and Iur interfaces as required by Annexes X.2.3 and X.2.4, it is required to implement IPsec ESP as specified and profiled by TS 33.210[ Network Domain Security (NDS); IP network layer security ]  [39], with confidentiality, integrity and replay protection. NOTE 1: In certain deployments IPsec security mechanisms may not be usable on the interfaces of the RNC in exposed locations. In such cases it is an operator decision to either ensure the interface security by other means, or to change the interface transport mechanisms to allow the application of IPsec security mechanisms. IKEv2 with certificates based authentication shall be implemented. The certificates shall be implemented according to the profile described by TS 33.310[ Network Domain Security (NDS); Authentication Framework (AF) ]  [40]. IKEv2 shall be implemented conforming to the IKEv2 profile described in TS 33.310[ Network Domain Security (NDS); Authentication Framework (AF) ]  [40]. For Iu and Iur, tunnel mode IPsec is mandatory to implement. On the core network side a SEG may be used to terminate the IPsec tunnel. Transport mode IPsec is optional for implementation on Iu and Iur. NOTE 2: Transport mode can be used for reducing the protocol overhead added by IPsec. NOTE 3: The IPsec security associations may also apply to IP packets carrying management information. 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 is specified in RFC 4301 [41].