When an IAB-node accesses to the current IAB-topology, the IAB-donor need to learn the parent of the new IAB-node and discover the topology. There are two potential options as specified in TR 38.874. The integration of an IAB-node to the topology may trigger the topology adaptation. The IAB-topology can be changed to provide coverage and ensure service continuity. Based on the information such as backhaul link quality, link- and node-load, neighbour-node signal strength, the new topology is determined.

In case the identifier of collocated IAB-UE or DU for topology discovery lack confidentiality, integrity and replay protection, it will be possible for an attacker to eavesdrop, modify, and replay packets, which may lead to IAB-donor's discovering false topology information. The incorrect topology information may influence backhaul link quality even lead to link failure.

An IAB-node connects to an IAB donor at startup in a 3GPP network supporting the IAB architecture. At startup the IAB-node acts as an MT. The MT part of the IAB-node acts as a UE towards the IAB donor. The network provides configuration to the IAB-nodes, for L2 transport and resource management like:

• the setup and release of IAB-nodes; configuration of adaptation layer at the IAB-nodes and IAB-donor DU; configuration of BH RLC channels, QoS information, routing tables, bearer-mappings; configuration of means for network synchronization; and configuration for sharing of time-domain resources among backhaul and access links (see physical layer specification).
• IP address allocation for the IAB-nodes.
• QoS flow configuration across multiple hops.

The IAB-node acting as MT needs to be authenticated by the 3GPP network and the IAB-node needs to authenticate the 3GPP network. Further, the network needs to authorize the IAB node to provide service.

If the IAB-node acting as a MT is not authenticated by the 3GPP network, then a false IAB-node is able to connect to the 3GPP network via an IAB-donor. If the IAB-node acting as a MT does not authenticate the 3GPP network, then the IAB-node may connect to a false IAB-donor or a false 5G core network. The unauthorized IAB Node with valid subscription credentials, may get access to obtain/provide IAB service.

Mutual authentication of the IAB node acting as a MT and the 3GPP core network supporting IAB architecture shall be supported. The 5GC/EPC shall authorize the IAB Node to provide IAB functionalities.

An IAB-node acting as a MT connects to an IAB-donor at startup in the IAB architecture. The MT part of the IAB node acts as a UE towards the IAB-donor. The network provides configuration to the IAB nodes, for L2 transport and resource management like:

• the setup and release of IAB-nodes; configuration of adaptation layer at the IAB-nodes and IAB-donor DU; configuration of BH RLC channels, QoS information, routing tables, bearer-mappings; configuration of means for network synchronization; and configuration for sharing of time-domain resources among backhaul and access links (see physical layer specification).
• IP address allocation for the IAB-nodes.
• QoS flow configuration across multiple hops.

If the network need to be able to securely provide the configurations. IAB node security also needs to be studied for the cases where single or multiple hops failed due to RLF failure. During the RLF, the network needs to perform topology change hierarchically to minimize disruption in service continuity which results in a backhaul link change from one IAB-Node to another. In this scenario, the PDCP endpoints are not changed, but the F1-AP link needs to be rebuilt, such behaviour is transparent to UE. F1-AP link establishment needs study from a security perspective for secure link establishment, Key derivations and transfer of keys from one IAB Node to another IAB node to maintain service continuity. Security keys for communication needs to be established between the IAB-node and the 5G core network; and between the IAB-node and the IAB-donor.

If an IAB-node acting as MT and a 5G core network does not integrity protects and cipher the communication sent between them, then an attacker can modify, replay or eavesdrop the communication. If an IAB-node acting as MT and an IAB donor does not integrity protect and cipher the communication sent between them then, then an attacker can modify, replay or eavesdrop the communication. Potential disruption of the network's service. If the IAB node is not securely configured, then any illegitimate node may be part of the multi-hop backhauling and leads to risk of theft of service and Denial of Service against the system.

The control plane communication between the IAB node acting as MT and the 5G core network shall support encryption, integrity protection and replay protection. The control plane communication between the IAB node acting as MT and the IAB-donor shall support encryption, integrity protection and replay protection. Secure control plane configuration of the IAB nodes shall be supported. The system shall support secure service continuity.

Regarding the work split in clause 4.2, this key issue belongs to the group #(B) illustrated in Figure 4.2-1, i.e., security of backhaul-link between child-node and parent-node. TR 38.874 discusses recovery from backhaul-RLF in clauses 9.7.12 to 9.7.15. One possible option described in clause 9.7.14 is: A simplified illustration of backhaul-RLF recovery is shown in Figure 5.2.3.1-1. The RLF occurs between the IAB-donor and the IAB-node#1. This causes backhaul connectivity loss for the parent-node IAB-node#1. This also causes upstream backhaul connectivity loss for child-nodes IAB-node#2 and IAB-node#n. For the sake of example, the parent IAB-node#1 cannot recover the backhaul-link via the IAB-node#3 because of a big mountain between them. Therefore, the parent IAB-node#1 informs the child IAB-node#2 about the upstream backhaul connectivity loss so that the child IAB-node#2 can itself seek means to recover. The child IAB-node#2 identifies that the Path1 is lost. Therefore, it recovers using Path2 via the IAB-node#3.

This backhaul-RLF recovery is likely achieved by some form of control message between the parent-node and the child-node via a new adaptation layer called the BAP (Backhaul Adaptation Protocol), or via lower layer mechanism like MAC control element. Even though this backhaul-RLF recovery is a rare event, it is very crucial to protect any form of control messages between the parent-node and the child-node. This is explained further in the threats below.

A parent-node is responsible for multiple child-nodes and ultimately to multiple UEs being served via the IAB system. If the control message from the parent-node to the child-node is not protected, then over-the-air attacker could potentially trigger backhaul-RLF recovery on the child-node. It could mean abrupt loss of connection for large number of UEs, short- or long-term degradation in throughput or speed, and loss of operator's reputation, among other things.

TS 38.340, details the function supported by the BAP sublayer. Specifically, the flow control feedback and polling signalling and BH RLF indication are exchanged without protection between the BAP sublayers of IAB-nodes or between the IAB-node and IAB-donor. Clause 5.2.3, Key Issue #2.3: Protection of recovery from backhaul-RLF, illustrates the backhaul-RLF recovery scenario.

If the fake BAP Control PDU is transmitted by a fake node to the parent IAB-node or to the IAB-donor, then acting on the received fake BAP Control PDU could lead to QoE degradation (degradation of the system throughput) of the UE served by the victim IAB-node and may lead to unnecessary link release and re-establishment.

The integrated Access and Backhaul (IAB) is specified in TS 38.300 and TS 38.401 to realize the NR CU-DU split over NR wireless links. The overall architecture is shown in the Figure 5.3.1.1-1. The IAB is realized either in SA mode (a) or EN-DC (b). An IAB donor node has gNB-CU functionality and an IAB node has gNB-DU functionality. Each IAB node is connected to the IAB-donor node either directly (i.e., a single hop) or via another IAB node (i.e., multiples hops).

The protocol stacks for control plane and user plane between IAB-donor node and IAB node and between IAB nodes described in [3] are shown in Figure 5.3.1.1-2 and Figure 5.3.1.1-3. It is noted that an IAB-node that has the gNB-DU part communicates with an IAB-donor node that has the gNB-CU part using F1 protocols as in the wireline CU-DU interface.

Without having security protection on the protocol layers, the IAB is vulnerable to adversary attacks on both control plane and user plane of F1 interface, e.g., packet injection, packet modification, replay, eavesdropping. Furthermore, if the security protection is not applied end-to-end, then an attacker that breaks into any on the intermediate node will similarly be able to perform the above attacks. This key issue is to study potential solutions for F1 interface security for IAB.

An attacker may inject malicious control plane signalling or replay control plane signalling in IAB (F1-C) over the wireless link between an IAB donor and an IAB node or between IAB nodes. An attacker may modify control plane signalling in IAB (F1-C) over the wireless link between an IAB donor and an IAB node or between IAB nodes. An attacker may inject bogus user plane packets or replay user plane packets in IAB (F1-U) over the wireless link between an IAB donor and an IAB node or between IAB nodes. An attacker may modify user plane packets in IAB (F1-U) over the wireless link between an IAB donor and an IAB node or between IAB nodes. An attacker may eavesdrop control plane signalling in IAB (F1-C) over the wireless links between an IAB donor and an IAB node or between IAB nodes. An attacker may eavesdrop user plane packets in IAB (F1-U) over the wireless links between an IAB donor and an IAB node or between IAB nodes. An attacker that compromises an intermediate node will be able to inert bogus packet, modify packets of eavesdrop on packets.

The system shall support end-to-end confidentiality protection of F1-C control plane signalling between the terminating nodes of the F1-C interface, i.e. the IAB node and the IAB-donor. The system shall support end-to-end integrity and replay protection of F1-C control plane signalling between the terminating nodes of the F1-C interface, i.e. the IAB node and the IAB-donor. The system shall support end-to-end confidentiality protection of F1-U user plane packets between the terminating nodes of the F1-U interface, i.e. the IAB node and the IAB-donor. The system shall support end-to-end integrity and replay protection of F1-U user plane packets between the terminating nodes of the F1-U interface, i.e. the IAB node and the IAB-donor.

This solution addresses the security requirement for the Authentication and Authorization of IAB Node in key issue #2.1 and key issue #2.2.

In the CU/DU architecture, the IAB Node host the DU and UE functionalities and would effectively look like a DU connected through the wireless interface to the controlling CU. Therefore for secure connection setup purposes, the IAB-UE functionalities of the IAB Node, performs the primary authentication and key agreement procedure with the 5GC as specified in TS 33.501, as shown in Figure 6.1.1.2-1 or with the EPC as specified in TS 33.401, as shown in Figure 6.1.1.2-2. Further the IAB-UE functionality in the IAB Node performs the NAS and AS security setup procedures as specified in the TS 33.501 or TS 33.401, to obtain IAB configuration data securely from the network. This solution assumes that, IAB node (IAB-UE) acts as a UE for performing the primary authentication and key agreement procedure, subscription credential(s) storage requirements, NAS security setup and AS security setup procedures as specified in TS 33.501 and TS 33.401.

The authorization for connectivity of the IAB Node to the 5GC/EPS is evaluated by the network once the IAB Node is successfully identified and authenticated. This authorization is executed during IAB Node Registration procedure. The core network authorizes the IAB Node through the subscription profile.

This solution reuses the existing authentication, authorization and security context establishment procedure as specified in TS 33.501 and TS 33.401, which fulfils the potential security requirements of key issue #2.1(Authentication and Authorization of IAB Node) and key issue #2.2 (Activating control plane communication security in IAB node).

This solution addresses the security credentials establishment for the security requirements in key issue #3.1.

For establishment of the secure RRC connection with the network (IAB MT setup), the MT functionality in the IAB node performs authentication with the network and establish the AS security context for the secure exchange of the RRC messages (Solution #1.1). Further, for establishment of secure F1 interface (IAB DU setup), it is required to perform an authentication mechanism over IKEv2 to establish IPSec tunnels (Solution #3.1). As the IAB Node's MT functionality and DU functionality establish the security context independently, multiple authentication procedures are performed between the IAB Node and to the same network (for the same RAN technology). Instead of performing the mutual authentication again between the IAB Node and the IAB Donor, the Access Stratum (AS) security context key KgNB (in possession of the MT functionality in the IAB node and in the IAB Donor) is used to derive a Shared Key, which will be used to compute the AUTH value directly and the authentication run is skipped (skipping full authentication run, for example, EAP-TLS or EAP-AKA procedure). During the UE Registration procedure, the network performs verification of IAB subscription information for IAB-node authorization (see TS 23.501). Therefore, only after successful verification of IAB-node authorization, the 5GC completes the Registration procedure and provides AS security context key KgNB to the IAB-donor. By using the AS security context key KgNB, the IAB Donor ensures that the IAB Node is authorized already by the core network.

• Phase 1: IAB-MT setup. In this phase, the MT functionality of the new IAB-node (e.g. the IAB-node 2 in Figure 6.2.1.1-1) connects to the network as a normal UE, by performing RRC connection setup procedure with IAB-donor-CU, authentication with the core network, IAB-node 2-related context management, IAB-node 2's access traffic-related radio bearer configuration at the RAN side, and, optionally, OAM connectivity establishment. As part of AS security establishment, the MT functionality of the new IAB-node and the IAB donor, derives the key KgNB. In case of NSA, the MT functionality of the new IAB-node and the IAB donor are in possession of the KgNB which is the S-KgNB provided by the MeNB.
• Phase 2-1: Backhaul RLC channel establishment. In this phase, at least the backhaul RLC channels for CP traffic e.g. carrying F1-C messages to and from the IAB-node, are established.
• Phase 2-2: Routing update. In this phase, the BAP layer is updated to support routing between the new IAB-node 2 and the IAB-donor-DU. This includes configuration of a BAP routing identifier for routing in downstream direction on the IAB-donor-DU and a BAP route identifier in upstream direction on MT functionality of IAB-node 2. The routing tables are updated for all ancestor IAB-nodes (e.g. IAB-node 1) and the IAB-donor-DU with routing entries for the new BAP routing identifier. The DU functionality of the new IAB-node configures an IP address to establish IP connectivity to the operator's network.
• Phase 3: IAB-DU part setup. In this phase, the DU functionality of the IAB-node 2 is configured. The DU functionality of the IAB-node 2 initiates the set up F1-C connection with the IAB-donor-CU and establish security context. For the establishment of security context for the F1 interface (F1-C and/or F1-U), the IAB-node 2 initiates IKEv2 procedure (as detailed in Solution #3.1) with the IAB-donor-CU to establish the IPsec SAs. The Access Stratum (AS) security context key KgNB (in possession of the MT functionality in the IAB node and in the IAB Donor) is used to derive a pre shared key (KIAB), which will be used to compute the AUTH value directly and the authentication run is skipped (skipping full authentication run, for example, EAP-TLS or EAP-AKA procedure). The IAB node and the IAB Donor uses the KIAB derivation function detailed in Figure 6.2.1.1-2 for the deriving the KIAB.
  After the F1 is setup, the IAB node can now start serving the UEs.

During the topology adaptation (as detailed in TS 38.401), it may be possible to allocate different TNL address(es) that is (are) routable via the target IAB-donor-DU. Therefore it is required to (re)establish the IPsec associations between the IAB-node and the IAB-donor.

This solution details the mechanism for establishment of secure F1 interface, performing an authentication mechanism over IKEv2 to establish IPsec tunnels, which is required for Solution #3.1 (concluded for normative work, see clause 7.4.1). This solution does not require any additional pre-provisioned security credentials for performing an authentication mechanism over IKEv2 to establish IPsec tunnels. The security credential required to perform IKEv2 procedure is derived using the AS security context (which is established as part of IAB-UE setup procedure). Further using the PSK authentication method for establishment of secure F1 due to IAB-node migration skips the full authentication run, therefore the solution is more efficient than performing an additional authentication procedure over IKEv2.