Network Address Translators (NATs) are not designed to be part of the network domain control plane of NDS/IP-networks. Since network domain security employs a chained-tunnel approach it may be possible to use NATs provided that the network is carefully configured. NDS/IP provides no explicit support for Transition Gateways (TrGWs) to be used in the network domain control plane of NDS/IP-networks, but the NDS/IP architecture will not itself prohibit the use of TrGWs. However, the inclusion of TrGWs needs to be carefully executed in order not to create interoperability problems.

In order to strengthen the security for IP based networks, border gateways and access routers would normally use packet filtering strategies to prevent certain types of traffic to pass in or out of the network. Similarly, firewalls are used as an additional measure to prevent certain types of accesses towards the network. The rationale behind the application of packet filters and firewalls could be found in the security policy of the network operator. Preferably, the security policy would be an integral part of the network management strategy as a whole. While network operators are strongly encouraged to use filtering routers and firewalls, the usage, implementation and security policies associated with these are considered outside the scope of this document. Simple filtering may be needed before the Security Gateway (SEG) functionality. The filtering policy allosw key protocols such as DNS and NTP to pass. This will include traffic over the Za interface from IKEv2 and IPsec ESP in tunnel mode. Unsolicited traffic is rejected.

It is observed that GPRS Border Gateways (BG) and NDS/IP Security Gateways (SEGs) will both reside at the border of an operator network.

This section details how NDS/IP shall be used when GTP is to be security protected.

The GPRS Tunnelling Protocol (GTP) is defined in TS 29.060. The GTP protocol includes both the GTP control plane signalling (GTP-C) and user plane data transfer (GTP-U) procedures. GTP is defined for Gn interface, i.e. the interface between GSNs within a PLMN, and for the Gp interface between GSNs in different PLMNs. GTP-C is used for traffic that that is sensitive in various ways including traffic that is:

• critical with respect to both the internal integrity and consistency of the network;
• essential in order to provide the user with the required services;
• crucial in order to protect the user data in the access network and that might compromise the security of the user data should it be revealed.

Amongst the data that clearly can be considered sensitive are the mobility management messages, the authentication data and MM context data. Therefore, it is necessary to apply security protection to GTP signalling messages (GTP-C). Network domain security is not intended to cover protection of user plane data and hence GTP-U is not protected by NDS/IP mechanisms. Table 1 presents a list of GTP interfaces that shall be considered by NDS/IP.

It shall be possible to discriminate between GTP-C messages, which shall receive protection, and other messages, including GTP-U, that shall not be protected. Since GTP-C is assigned a unique UDP port-number in (TS29.060 [6]) IPsec can easily distinguish GTP-C datagrams from other datagrams that may not need IPsec protection. Security policies shall be checked for all traffic (both incoming and outgoing) so datagrams can be processed in the following ways:

• discard the datagram;
• bypass the datagram (do not apply IPsec);
• apply IPsec.

Under this regime GTP-U will simply bypass IPsec while GTP-C will be further processed by IPsec in order to provide the required level of protection. The SPD has a pointer to an entry in the Security Association Database (SAD) which details the actual protection to be applied to the datagram.

IPsec ESP shall be used with both encryption and integrity protection for all GTP-C messages traversing inter-security domain boundaries. Gn and Gp control plane traffic shall be routed via a SEG when it takes place between different security domains. In order to do so, operators shall operate NDS/IP Za-interface between SEGs. If a network node has implemented SEG functionality within the same physical entity, transport mode IPsec is optional for implementation and use on the Gn and Gp interfaces. It will be for the operator to decide whether and where to deploy Zb-interfaces in order to protect the GTP-C messages over the Gn and Gp interfaces within the same security domain.

This section details how NDS/IP shall be used to protect IMS protocols and interfaces. The network domain security for IMS in 3GPP2 networks shall be as specified in in Annex S.5 of TS 33.203.

The security architecture of the IP multimedia Core Network Subsystem (IMS) is specified in TS 33.203. TS 33.203 defines that the confidentiality and integrity protection for SIP-signalling are provided in a hop-by-hop fashion. The first hop i.e. between the UE and the P-CSCF through the IMS access network (i.e. Gm reference point) is protected by security mechanisms specified in TS 33.203. The other hops, within the IMS core network including interfaces within the same security domain or between different security domains are protected by NDS/IP security mechanisms as specified by this Technical Specification. 3GPP TS 23.002 specifies the different reference points defined for IMS.

IMS control plane traffic within the IMS core network shall be routed via a SEG when it takes place between different security domains (in particular over those interfaces that may exist between different IMS operator domains). In order to do so, IMS operators shall operate NDS/IP Za-interface between SEGs as described in clause 5.6.2. When SEGs are deployed to secure a Za reference point potentially carrying IMS session keys (i.e. in IMS roaming scenarios, when SEGs are deployed between a P-CSCF and I-CSCF located in different security domains), IPsec ESP shall be used with both encryption and integrity protection for all SIP signalling traversing inter-security domain boundaries. It will be for the IMS operator to decide whether and where to deploy Zb-interfaces in order to protect the IMS control plane traffic over those IMS interfaces within the same security domain.

This annex details how NDS/IP shall be used to protect UTRAN/GERAN IP transport protocols and interfaces.

The control plane in question is used to transfer signalling messages in UTRAN/GERAN IP transport network. The UTRAN IP transport option is specified in Rel-5 UTRAN Technical Specifications. UTRAN Iu interface signalling transport is specified in TS 25.412 and Iur interface signalling transport in TS 25.422. The architecture for the UTRAN Iuh/Iurh interfaces is specified in TS 25.467, stage 3 specification is contained in TS 25.468 and TS 25.471. Based on the known security threats in IP networking, the traffic shall be protected properly. This is in order not to restrict the application of IP in UTRAN and GERAN only to closed network environments. The security solution for IP based UTRAN/GERAN transport shall follow the principles introduced in the NDS/IP since the IPsec provides application independent security solution for all IP traffic. Iu/Iuh and Iur/Iurh interfaces are carrying information that is classified as sensitive. Iu/Iuh and Iur/Iurh are used for conveying e.g. subscriber specific security keys. These keys are vital for the end-user security. Hence Iu/Iuh and Iur/Iurh shall be encrypted along with the integrity check.

IPsec ESP shall be used with both encryption and integrity protection for all RANAP and RNSAP messages traversing inter-security domain boundaries. Iu/Iuh and Iur/Iurh control plane traffic shall be routed via a SEG when it takes place between different security domains (in particular over those interfaces that may exist between different operator domains). In order to do so, operators shall operate NDS/IP Za-interface between SEGs. If a UTRAN node has implemented SEG functionality within the same physical entity, transport mode IPsec is optional for implementation and use on the Iur/Iurh interface. It will be for the operator to decide whether and where to deploy Zb-interfaces in order to protect the RANAP and RNSAP messages over the Iu/Iuh and Iur/Iurh interfaces within the same security domain.