For NDS/IP-networks the key management and distribution between SEGs is handled by the protocol Internet Key Exchange Internet Key Exchange (IKEv2) (RFC 7296). The main purpose of IKEv2 is to negotiate, establish and maintain Security Associations between parties that are to establish secure connections. The concept of a Security Association is central to IPsec and IKEv2. To secure a typical, bi-directional communication between two nodes using IKEv2 an IKE SA is established through which the Child Security associations i.e. IPsec security associations are established. IPsec Security associations are uniquely defined by the following parameters:

• A Security Parameter Index (SPI);
• An IP Destination Address (this is the address of the ESP SA endpoint);
• A security protocol identifier (this will always be the ESP protocol in NDS/IP).

With regard to the use of IPsec security associations in the network domain control plane of NDS/IP-networks the following is noted:

• NDS/IP only requires support for ESP SAs;

The specification of IPsec SAs can be found in RFC 4301.

The Security Policy Database (SPD) is a policy instrument to decide which security services are to be offered and in what fashion. The SPD shall be consulted during processing of both inbound and outbound traffic. This also includes traffic that shall not/need not be protected by IPsec. In order to achieve this, the SPD shall have unique entries for both inbound and outbound traffic such that the SPD can discriminate among traffic that shall be protected by IPsec, that shall bypass IPsec or that shall be discarded by IPsec. The SPD plays a central role when defining security policies, both within the internal security domain and towards external security domains. The security policy towards external security domains will be subject to roaming agreements.

The Security Association Database (SAD) contains parameters that are associated with the active security associations. Every SA has an entry in the SAD. For outbound processing, a lookup in the SPD will point to an entry in the SAD. If an SPD entry does not point to an SA that is appropriate for the packet, an SA shall be automatically created.

This section gives an overview of the features of IPsec that are used by NDS/IP. The overview given here defines a minimum set of features that shall be supported. In particular, this minimum set of features is required for interworking purposes and constitutes a well-defined set of simplifications. The accumulated effect of the simplifications is quite significant in terms of reduced complexity. This is achieved without sacrificing security in any way. It shall be noted explicitly that the simplifications are specified for NDS/IP and that they may not necessarily be valid for other network constellations and usages. Within their own network, operators are free to use IPsec features not described in this section although there should be no security or functional reason to do so. Clause 5.3 contains the general 3GPP IPsec ESP profile. Other 3GPP specifications (e.g. TS 33.203, etc.) may point to clause 5.3. Thus parts of clause 5.3 may also apply to devices and network nodes as specified in other specifications. New specifications using ESP should refer to this profile with as few exceptions as possible. Unless explicitly stated otherwise, the 3GPP ESP profile apply for all uses of ESP to protect 3GPP interfaces.

When NDS/IP is applied, the ESP security protocol shall be used. IPsec ESP shall be supported according to RFC 4303. Extended sequence number may be supported. Usage guidance for the Implementation of Cryptographic Algorithm for ESP shall follow RFC 8221.

Since security gateways are an integral part of the NDS/IP architecture, tunnel mode shall be supported. For NDS/IP inter-domain communication, security gateways shall be used and consequently only tunnel mode (RFC 4301) is applicable for this case.

The implementation conformance requirements for ESP encryption transforms (including authenticated encryption transforms) in RFC 8221 shall be followed. Only the ESP encryption algorithms (including authenticated encryption algorithms) mentioned in RFC 8221 shall be used. Algorithms marked with "MUST" shall be supported.

The implementation conformance requirements for ESP authentication transforms in RFC 8221 shall be followed. Only the ESP authentication algorithms mentioned in RFC 8221 shall be used. Algorithms marked with "MUST" shall be supported. AES-GMAC with AES-128 shall be supported. ESP shall always be used to provide integrity, data origin authentication, and anti-replay services, thus the NULL authentication algorithm is explicitly not allowed for use, unless an authenticated encryption algorithm is used.

The following strengthening of the requirements on how to construct the IV shall take precedence over the description given in Section 3 of RFC 2451 and all other descriptions that allow for predictable IVs.

• For CBC mode: the IV field shall be the same size as the block size of the cipher algorithm being used. The IV shall be chosen at random, and shall be unpredictable to any party other than the originator.
• For CTR, GCM, CCM, and GMAC mode: the IV field shall be 8 octets. The IV shall be generated in a manner that ensures uniqueness. The same IV and key combination shall not be used more than once.
• It is explicitly not allowed to construct the IV from the encrypted data of the preceding encryption process.

The common practice of constructing the IV from the encrypted data of the preceding encryption process means that the IV is disclosed before it is used. A predictable IV exposes IPsec to certain attacks irrespective of the strength of the underlying cipher algorithm. The second bullet point forbids this practice in the context of NDS/IP. These requirements imply that the network elements shall have a capability to generate random data. RFC 4086 gives guidelines for hardware and software pseudorandom number generators.

Clause 5.4 contains the general 3GPP IKEv2 profile. Other 3GPP specifications point to clause 5.4. Thus parts of clause 5.4 may also apply to devices and network nodes as specified in other specifications. New specifications using IKE should refer to this profile with as few exceptions as possible. Unless explicitly stated otherwise, the 3GPP IKEv2 profile apply for all uses of IKEv2 to protect 3GPP interfaces.

The Internet Key Exchange protocol IKEv2 shall be supported for negotiation of IPsec SAs. The following additional requirements apply.

The NDS/IP key management and distribution architecture is based on the IKEv2 (RFC 7296) protocol. As described in the previous section a number of options available in the full IETF IPsec protocol suite have been considered to be unnecessary for NDS/IP. Furthermore, some features that are optional in IETF IPsec have been mandated for NDS/IP and lastly a few required features in IETF IPsec have been deprecated for use within NDS/IP scope. Sections 5.3 and 5.4 give an overview over the profiling of IPsec and IKEv2 in NDS/IP. The compound effect of the design choices in how IPsec is utilized within the NDS/IP scope is that the NDS/IP key management and distribution architecture is quite simple and straightforward. The basic idea to the NDS/IP architecture is to provide hop-by-hop security. This is in accordance with the chained-tunnels or hub-and-spoke models of operation. The use of hop-by-hop security also makes it easy to operate separate security policies internally and towards other external security domains. In NDS/IP only the Security Gateways (SEGs) shall engage in direct communication with entities in other security domains for NDS/IP traffic. The SEGs will then establish and maintain IPsec secured ESP Security Association in tunnel mode between security domains. SEGs will normally maintain at least one IPsec tunnel available at all times to a particular peer SEG. The SEG will maintain logically separate SAD and SPD databases for each interface. The NEs may be able to establish and maintain ESP Security Associations as needed towards a SEG or other NEs within the same security domain. All NDS/IP traffic from a NE in one security domain towards a NE in a different security domain will be routed via a SEG and will be afforded hop-by-hop security protection towards the final destination. Operators may decide to establish only one ESP Security Association between two communicating security domains. This would make for coarse-grained security granularity. The benefits to this is that it gives a certain amount of protection against traffic flow analysis while the drawback is that one will not be able to differentiate the security protection given between the communicating entities. This does not preclude negotiation of finer grained security granularity at the discretion of the communicating entities.

Additional guidelines on how to apply IPsec in SCTP are specified in RFC 3554. This RFC is optional for implementation unless otherwise explicitly indicated per reference point.

The following interfaces are defined for protection of native IP based protocols:

• Za-interface (SEG-SEG)
  The Za-interface covers all NDS/IP traffic between security domains. On the Za-interface, authentication/integrity protection is mandatory and encryption is recommended. ESP shall be used for providing authentication/integrity protection and encryption. The SEGs use IKEv2 to negotiate, establish and maintain a secure ESP tunnel between them. The tunnel is subsequently used for forwarding NDS/IP traffic between security domain A and security domain B. Inter-SEG tunnels can be available at all times, but they can also be established as needed.
  One SEG of security domain A can be dedicated to only serve a certain subset of security domains that security domain A needs to communicate with. This will limit the number of SAs and tunnels that need to be maintained.
  All security domains compliant with the present document shall operate the Za-interface.
• Zb-interface (NE-SEG / NE-NE)
  The Zb-interface is located between SEGs and NEs and between NEs within the same security domain. The Zb-interface is optional for implementation. If implemented, it shall implement ESP in tunnel mode and IKE as described in clause 5.4. The support of ESP in Transport mode is optional.
  On the Zb-interface, ESP shall always be used with authentication/integrity protection. The use of encryption is optional. The ESP Security Association shall be used for all control plane traffic that needs security protection.
  Whether the Security Association is established when needed or a priori is for the security domain operator to decide. The Security Association is subsequently used for exchange of NDS/IP traffic between the nodes.