Patent Description:
Virtual RAN (vRAN), which may otherwise be known as Next Generation-RAN (NG-RAN) or cloud RAN, is being developed for <NUM>. Virtual RAN represents a virtual infrastructure that seeks to optimize RAN to one or more of: (<NUM>) deliver legacy RAN benefits and, additionally, alleviate the core network signalling (e.g., keep the mobility signalling in the RAN); and (<NUM>) deliver cloud benefits (e.g., resource pooling, improved reliability with geo-redundancy, etc.), together with reducing capital expenditure (CAPEX) and operational expenditure (OPEX), enabling multi-tenants, resiliency, deterministic computing performance, as well as, potentially providing a ground for new business models.

The vRAN system architecture considers a flexible scheme to place at least some of the entities of the random access network (RAN), which have been traditionally placed at the antenna site, in the cloud and to enable collaboration between such entities.

<FIG> illustrate an example vRAN system architecture and, in particular, at least some of the protocol stack layers and interfaces of the exemplary vRAN system architecture. Generally, <FIG> illustrates an example vRAN connected to a core network (CN) <NUM> over an S1 interface. The vRAN includes a radio <NUM> for the vRAN to communicate with a user equipment (UE) <NUM> over a Uu interface. The vRAN includes three layers, namely, Layer <NUM>, Layer <NUM>, and Layer <NUM>, which are known in the art and therefore will not be discussed in detail herein. The protocol stack functions may include Packet Data Convergence Protocol (PDCP), Radio Resource Control (RRC), Radio Link Control (RLC), and Medium Access Control (MAC), which are also known in the art and therefore will not be discussed in detail herein. <FIG> illustrates an example vRAN architecture showing an example implementation and interfaces between the layers. Specifically, the vRAN architecture shown in <FIG> illustrates the PDCP being handled by a packet processing function (PPF), the RRC being handled by a radio control function (RCF), and a baseband processing function (BPF) handling the RLC and MAC. The PPF-to-RCF interface is an E6 interface. The PPF to BPF interface is an F1-U interface and the RCF to BPF interface is an F1-C interface. The interfaces and functions depicted in <FIG> are meant to be exemplary and are not intended to be limiting. With vRAN, the access network entities requiring tight synchronization in the protocol stack and stringent latency may be placed closer to the radio environment (i.e., closer to the end-user UE <NUM>)), such as e.g., at the antenna site or hub-site. Such entities may be referred to herein as the BPF. The BPF may be, for example, a gNB-DU. On the other hand, the entities with radio asynchronous functions may be virtualized (e.g., in the Central Office (CO)). Such virtualized access network entities may include the PPF and/or the radio control function RCF. The RCF may be, for, example, gNB-Centralized Unit (CU) and/or gNB-CU-Control Plane (CP). PPF may be, for example, gNB-CU-User Plane (UP). It should be understood that these entities, e.g., BPF, PPF, and RCF, may be referred to by other names in the art. Depending on the implementation, the vRAN may further include other entity, such as another entity sometimes referred to as vUE that manages some UE identifiers, such as, for example, Cell Radio Network Temporary Identifiers (C-RNTI) and/or other UE identifiers (ID). Any networking solution used to separate and interconnect the BPFs with the vRAN entity(ies) should satisfy the latency requirements on any newly introduced interfaces in RAN.

<FIG> illustrates pools of vRAN resources in a cloud <NUM>. The vRAN resources may include a pool of BPFs that may connect to a pool of PPFs and a pool of RCFs. Resources for vRAN may be pooled and RAN functions or instances of RAN functions may be dynamically and/or automatically created when and where they are needed. For example, <FIG> illustrates a scenario where there may be a full mesh between the BPFs and vRAN entities in the cloud <NUM>. At least some of the functions of vRAN may be deployed in a virtual environment and managed to scale out e.g., the PPFs where the current instances are, for example, overloaded. In this manner, the radio heads and BPFs may connect, for example, to another site and/or another pool of PPFs. As shown in <FIG>, the vRAN entities in the cloud <NUM> may be connected to the core network <NUM> over e.g., the S1 interface and the BPFs and virtualized PPFs in the cloud <NUM> may be connected over e.g., the F1-U interface.

There are efforts to protect the vRAN interfaces (e.g., F1-C, F1-U, etc.) against various threats, such as, for example, unauthorized access, Distributed Denial of Service (DDoS) attacks, other threats associated with cloud environments, etc. Protection solutions can range from software (SW) firewalls (i.e., controlling the inter-process calls, message conformance, etc.) to controlling access to the various entities (e.g., BPF, PPF, RCF, etc.) and protecting such entities at the level of the underlying transport (which is Internet Protocol (IP)-based).

IP Security (IPsec) or Transport Layer Security (TLS) may be employed for confidentiality and integrity, especially if the vRAN and antenna/BPF sites are geographically distributed with internetworking under third-party responsibility and administration. Also, the end-user UE UP data is Packet Data Convergence Protocol (PDCP)-ciphered (up to the PPF) to provide over-the-air protection.

A recurrent problem that arises in RAN and Core networks (CNs) is signalling overload. In signalling overload, the various entities and corresponding interfaces may be legitimately, or maliciously overloaded with signalling traffic. This may happen frequently in Internet-of-Things (IoT) deployments where, for example, devices react altogether to the same stimuli, creating a signalling storm. Signalling storm scenarios can happen for both uplink (UL) and downlink (DL) traffic. Signalling storm is conventionally dealt with either (<NUM>) by absorbing it through scaling out the RAN (e.g., adding more vRCFs) and CN entities (e.g., adding more resources at the Mobile Management (MME)/Access and Mobility Management Function (AMF) level) and traffic redirections; or (<NUM>) by throttling. In throttling, the interface protocol data units (PDUs) are filtered at a certain rate with a rate limiting functionality implemented at the vRAN or CN entity level through a functionality, such as, for example, a software firewall (SW FW) or application level firewall.

The second option that includes controlling PDU rates (e.g., throttling, rate limiting, firewall, redirection) is typically performed when the interface is already overloaded. In other words, the entity itself is already experiencing an overhead when the rate limiting is applied.

Document <CIT> discloses a method of providing access of a mobile terminal (MS) to an IP network, which includes establishing a security association (SA) between the mobile terminal (MS) and a first security gateway (SGWHOME) of a first router (IARHOME) in said plurality of routers.

Document <CIT> discloses a method for translating filters and setting up additional tunnels or other procedures depending on the use case so that all end and intermediate nodes can perform required processing on modified packets. The methods and systems may take into consideration an overlap or intersection of two or more different types of packet filters.

According to the present disclosure, methods, a first network node and a system including a security node according to the independent claims are provided. Developments are set forth in the dependent claims.

Some embodiments advantageously provide methods and apparatuses that enable policy-based IP-level filtering in IPsec protected vRAN that can, for example, be used as a mitigation of signalling storms.

According to a first aspect, a first network node includes processing circuitry configured to receive a trigger to establish an Internet Protocol Security, IPsec, session with a second network node, the IPsec session being associated with a user equipment, UE; responsive to the trigger to establish the IPsec session associated with the UE, derive a unique identifier for the UE; generate a Security Parameter Index, SPI, value based at least in part on the unique identifier derived for the UE, the SPI value being unique to the IPsec session; and communicate an indication of the SPI value to the second network node.

According to this aspect, in some embodiments, the establishing the IPsec session with the second network node comprises an IPsec Security Association, SA, negotiation with the second network node. In some embodiments of this aspect, the trigger is associated with the IPsec SA negotiation with the second network node. In some embodiments of this aspect, the trigger is a request message, from the second network node, to establish the IPsec SA negotiation with the second network node. In some embodiments of this aspect, the trigger is one of a request message, a request message from the second network node, a control plane message, an indication of an establishment of a radio session for the UE, , and a radio bearer establishment message. In some embodiments of this aspect, the processing circuitry is further configured to receive, from the second network node, an IPsec packet, the IPsec packet associated with the UE and the IPsec packet including the indication of the SPI value; decrypt and authenticate the received IPsec packet using at least the indication of the SPI value; and communicate, to a third network node, the decrypted packet. In some embodiments of this aspect, the SPI value maps to IPsec traffic associated with the UE between the first network node and the second network node. In some embodiments of this aspect, the processing circuitry is further configured to derive the unique identifier for the UE based at least in part on data associated with the UE and, as a result of the derivation, the generation of the SPI value is based at least in part on the data associated with the UE. In some embodiments of this aspect, the data used to derive the unique identifier and generate the SPI value uniquely identifies IPsec traffic associated with the UE for IP-level filtering of traffic between the first network node and the second network node. In some embodiments of this aspect, wherein the data used to derive the unique identifier for the UE and generate the SPI value includes at least one of a Cell UE Identifier, a Baseband Processing Function, BPF, Identifier, and a Cell Identifier. In some embodiments of this aspect, the data used to derive the unique identifier for the UE and generate the SPI value includes an identification of a radio bearer, RB, for the UE. In some embodiments of this aspect, the data used to derive the unique identifier for the UE and generate the SPI value is signalling data associated with the UE. In some embodiments of this aspect, the data associated with the UE is data corresponding to one of an Uplink, UL, channel and a Downlink, DL, channel for the UE. In some embodiments of this aspect, the processing circuitry is further configured to derive the unique identifier for the UE by concatenating the data associated with the UE. In some embodiments of this aspect, the processing circuitry is further configured to generate the SPI value by inputting the unique identifier into an invertible function that returns a <NUM>-bit value representing the SPI. In some embodiments of this aspect, the indication of the SPI value is one of a clear text SPI value and an obfuscated SPI value. In some embodiments of this aspect, the processing circuitry is further configured to obfuscate the SPI value and the communication of the indication of the SPI value is a communication of the obfuscated SPI value to the second network node. In some embodiments of this aspect, the processing circuitry is configured to obfuscate the SPI value by being further configured to input at least the generated SPI value into a hash function. In some embodiments of this aspect, the processing circuitry is configured to obfuscate the SPI value by being further configured to input the generated SPI value and a key value into a hash function to generate the obfuscated SPI value. In some embodiments of this aspect, the processing circuitry is configured to receive, from the second network node, an IPsec packet, the IPsec packet including the indication of the SPI value; and decrypt and authenticate the received IPsec packet using at least the indication of the SPI value by being further configured to identify a Security Association, SA, of the IPsec packet via the obfuscated SPI value; decrypt the IPsec packet according to the identified SA to obtain payload data of the decrypted packet; determine the unique identifier for the UE and the SPI value from the decrypted payload data; input a key value and the determined SPI value into a hash function; determine whether the hash function returns an output value that is equal to the obfuscated SPI value; and one of communicate the decrypted packet and drop the decrypted packet based at least in part on whether the output value of the hash function is equal to the obfuscated SPI value. In some embodiments of this aspect, the processing circuitry is further configured to communicate, to a security node, at least the indication of the SPI value for Internet Protocol, IP, -level filtering of IPsec traffic between the first network node and the second network node. In some embodiments of this aspect, the processing circuitry is further configured to communicate, to the security node, a security action associated with the SPI value, the security action to be performed by the security node on IPsec traffic between the first network node and the second network node and the SPI value identifying the UE for the performance of the security action. In some embodiments of this aspect, the security action includes at least one of rate-limiting IPsec traffic associated with UE, accepting IPsec traffic associated with the UE, and rejecting IPsec traffic associated with the UE. In some embodiments of this aspect, the security node is a Layer <NUM> firewall for Internet Protocol, IP, traffic between the first network node and the second network node. In some embodiments of this aspect, one of the second network node and the first network node comprises at least one virtualized radio function in a cloud data center and the other one of the second network node and the first network node comprises a baseband function. In some embodiments of this aspect, the at least one virtualized radio function is a base station centralized unit, CU, in the cloud data center and the baseband function is a base station distributed unit, DU.

According to another aspect, a method is provided for a first network node. The method includes receiving a trigger to establish an Internet Protocol Security, IPsec, session with a second network node, the IPsec session being associated with a user equipment, UE; responsive to the trigger to establish the IPsec session associated with the UE, deriving a unique identifier for the UE; generating a Security Parameter Index, SPI, value based at least in part on the unique identifier for the UE, the SPI value being unique to the IPsec session; and communicating an indication of the SPI value to the second network node.

In some embodiments of this aspect, establishing the IPsec session with the second network node comprises an IPsec Security Association, SA, negotiation with the second network node. In some embodiments of this aspect, the trigger is a request message to establish an IPsec negotiation with the second network node. In some embodiments of this aspect, the trigger is a request message, from the second network node, to establish the IPsec SA negotiation with the second network node. In some embodiments of this aspect, the trigger is one of a request message, a request message from the second network node, a control plane message, an indication of an establishment of a radio session for the UE, and a radio bearer establishment message. In some embodiments of this aspect, the method further includes receiving, from the second network node, an IPsec packet, the IPsec packet associated with the UE and the IPsec packet including the indication of the SPI value; decrypting and authenticating the received IPsec packet using at least the indication of the SPI value; and communicating, to a third network node, the decrypted packet. In some embodiments of this aspect, the SPI value maps to IPsec traffic associated with the UE between the first network node and the second network node. In some embodiments of this aspect, deriving the unique identifier further comprises deriving the unique identifier for the UE based at least in part on data associated with the UE and, as a result of the derivation, the generation of the SPI value is based at least in part on the data associated with the UE. In some embodiments of this aspect, the data used to derive the unique identifier and generate the SPI value uniquely identifies IPsec traffic associated with the UE for IP-level filtering of traffic between the first network node and the second network node. In some embodiments of this aspect, the data used to derive the unique identifier for the UE and generate the SPI value includes at least one of a Cell UE Identifier, a Baseband Processing Function, BPF, Identifier, and a Cell Identifier. In some embodiments of this aspect, the data used to derive the unique identifier for the UE and generate the SPI value includes an identification of a radio bearer, RB, for the UE. In some embodiments of this aspect, the data used to derive the unique identifier for the UE and generate the SPI value is signalling data associated with the UE. In some embodiments of this aspect, the data associated with the UE is data corresponding to one of an Uplink, UL, channel and a Downlink, DL, channel for the UE. In some embodiments of this aspect, deriving the unique identifier further comprises deriving the unique identifier for the UE by concatenating the data associated with the UE. In some embodiments of this aspect, generating the SPI value further comprises generating the SPI value by inputting the unique identifier into an invertible function that returns a <NUM>-bit value representing the SPI. In some embodiments of this aspect, the indication of the SPI value is one of a clear text SPI value and an obfuscated SPI value. In some embodiments of this aspect, the method further includes obfuscating the SPI value and the communication of the indication of the SPI value comprises a communication of the obfuscated SPI value. In some embodiments of this aspect, the obfuscating the SPI value further comprises obfuscating the SPI value by inputting at least the generated SPI value into a hash function. In some embodiments of this aspect, the obfuscating the SPI value further comprises obfuscating the SPI value by inputting the generated SPI value and a key value into a hash function to generate the obfuscated SPI value. In some embodiments of this aspect, the method further includes receiving, from the second network node, an IPsec packet, the IPsec packet including the indication of the SPI value; and decrypting and authenticating the received IPsec packet using at least the indication of the SPI value by: identifying the Security Association, SA, of the IPsec packet via the obfuscated SPI value; decrypting the IPsec packet according to the identified SA to obtain payload data of the IP packet; determining the unique identifier for the UE and the SPI value from the decrypted payload data; inputting a key value and the determined SPI value into a hash function; determining whether the hash function returns an output value that is equal to the obfuscated SPI value; and one of communicating the IP packet and dropping the IP packet based at least in part on whether the output value of the hash function is equal to the obfuscated SPI value. In some embodiments of this aspect, the method further includes communicating, to a security node, at least the indication of the SPI value for Internet Protocol, IP, -level filtering of IPsec traffic between the first network node and the second network node. In some embodiments of this aspect, the method further includes communicating, to the security node, a security action associated with the SPI value, the security action to be performed by the security node on IPsec traffic between the first network node and the second network node and the SPI value identifying the UE for the performance of the security action. In some embodiments of this aspect, the security action includes at least one of rate-limiting IPsec traffic associated with UE, accepting IPsec traffic associated with the UE, and rejecting IPsec traffic associated with the UE. In some embodiments of this aspect, the security node is a Layer <NUM> firewall for IPsec traffic between the first network node and the second network node. In some embodiments of this aspect, one of the second network node and the first network node comprises at least one virtualized radio function in a cloud data center and the other one of the second network node and the first network node comprises a baseband function. In some embodiments of this aspect, the at least one virtualized radio function is a base station centralized unit, CU, in the cloud data center and the baseband function is a base station distributed unit, DU.

According to yet another aspect, a security node is provided. The security node includes processing circuitry configured to observe Internet Protocol Security, IPsec, traffic between a first network node and a second network node; and filter the observed IPsec traffic based at least in part on an indication of a Security Parameter Index, SPI, value, the SPI value based at least in part on a unique identifier for a user equipment, UE, and the SPI value being unique to an IPsec session associated with the UE.

In some embodiments of this aspect, the processing circuitry is further configured to receive the indication of the SPI value from one of the first network node and the second network node and filter the observed IP traffic based at least in part on the received indication of the SPI value. In some embodiments of this aspect, the processing circuitry is further configured to receive a security action associated with the SPI value; identify IP traffic associated with a user equipment, UE, based at least in part on the indication of the SPI value; and filter the identified IP traffic associated with the UE according to the received security action. In some embodiments of this aspect, the security action includes at least one of rate-limiting IPsec traffic associated with UE, accepting IPsec traffic associated with the UE, and rejecting IPsec traffic associated with the UE. In some embodiments of this aspect, the processing circuitry is configured to filter the observed IPsec traffic based at least in part on the indication of the SPI value by being further configured to match SPI fields of the observed IPsec packets to the SPI value; and filter at least one IPsec packet based on whether an SPI field of the IPsec packet matches the SPI value. In some embodiments of this aspect, the security node is a Layer <NUM> firewall between the first network node and the second network node.

According to another aspect, a method for a security node is provided. The method comprises observing Internet Protocol Security, IPsec, traffic between a first network node and a second network node; and filtering the observed IPsec traffic based at least in part on an indication of a Security Parameter Index, SPI, value, the SPI value based at least in part on a unique identifier for a user equipment, UE, and the SPI value being unique to an IPsec session associated with the UE.

In some embodiments of this aspect, the method further includes receiving the indication of the SPI value from one of the first network node and the second network node and filtering the observed IP traffic based at least in part on the received indication of the SPI value. In some embodiments of this aspect, the method further includes receiving a security action associated with the SPI value; identifying IPsec traffic associated with a user equipment, UE, based at least in part on the indication of the SPI value; and filtering the identified IPsec traffic associated with the UE according to the received security action. In some embodiments of this aspect, the security action includes at least one of rate-limiting IPsec traffic associated with UE, accepting IPsec traffic associated with the UE, and rejecting IPsec traffic associated with the UE. In some embodiments of this aspect, the filtering the observed IPsec traffic based at least in part on the indication of the SPI value comprises matching SPI fields of the observed IPsec packets to the SPI value; and filtering at least one IPsec packet based on whether an SPI field of the IPsec packet matches the SPI value. In some embodiments of this aspect, the security node is a Layer <NUM> firewall between the first network node and the second network node.

Enabling policy-based IP-level filtering to mitigate vRAN signalling storms, i.e., selectively rate limiting UE signalling sessions, can be challenging. At least some (incomplete) solutions that have been considered are discussed below. For example, if the radio-vRAN network leaves the underlying IP protocol unsecured (e.g., no IPsec or TLS), a deep inspection mechanism may be expected to infer UE IDs and basic signalling messages or signalling sessions directly from the IP packet payload. However, a deep packet inspection (DPI) may perform poorly compared to filtering the IP headers only. However, especially with PDCP encryption activated, distinguishing between the various signalling sessions can become complicated. Accordingly, management of the IP sessions may be implemented to carry the radio-to-vRAN traffic (e.g., the F1-C and F1-U data) between the vRAN entities (e.g., BPFs, RCFs, PPFs, etc.) by relying on a mechanism that maps radio bearers onto IP sessions. Currently, it is not clear the exact encapsulation of the vRAN entities (e.g., RCF and PPF PDUs) to implement a radio bearer to IP session mapping. In some embodiments, there may be a mapping for the PPF to associate the IP payload to a corresponding radio bearer.

For policy-based IP-level filtering, the solutions discussed above do not solve the case in which the radio - vRAN traffic is secured at the IP level with IPsec (unless the IPsec employs a null-cipher (i.e., no ciphering) to enable DPI). Implementing policy-based IP-level filtering or control (e.g., firewall throttling, rate limiting, redirection) on selected UE traffic directly on IPsec-encrypted IP traffic may have at least two primary advantages. Firstly, the control can be offloaded from the legacy vRAN functionalities and the core network CN (e.g., AMF, or MME). Secondly, reaction to signalling storms can be performed in a timelier manner, as compared to other solutions, and can be implemented through stateless firewalls.

Some of the problems with solutions that have been considered are discussed as follows. Signalling storm can be dealt with by throttling and rate limiting, implemented for example at the MME/AMF. However, such control is reactive - not proactive. Thus, vRAN or CN entities, as well as, their interfaces can be overloaded before the mitigation is even launched. Other proposals may include filtering on the interfaces, e.g., F1, or rate limiting over the newly introduced vRAN interfaces. However, filtering and/or rate limiting on the interfaces presents an insufficient solution. Specifically, if the encryption is activated over the inter-access sites (e.g., between the Hub-Site and Central office/vRAN), UE signalling sessions cannot be distinguished in the IPsec tunnel due to encryption. Thus, with such solutions, filtering could be applied only after decrypting the traffic. Some proposals rely on PDCP encryption for the IP sessions between the vRAN entities (e.g., BPFs, RCFs, and PPFs). For example, a vRAN interface, such as, F1-U with IPsec null cipher may accept IP rate limiting by an IP (L3) firewall with DPI. Other proposals provide radio bearer to IP session mapping and rely on the PDCP protection, which can be sufficient between the entities implementing a split-Long Term Evolution (LTE) stack (e.g., the so-called residential gateway and the small cells) in residential small cells where there is most probably a single administration domain. In such environments, IPsec may not be required; therefore, that type of mapping could help in implementing rate limiting and signalling storm mitigation.

Another solution where IPsec may be activated involves using IP version <NUM> (IPv6) flow labels to encode different UE data based on which rate limiting can be applied. In Encapsulating Security Payload (ESP) tunnel mode, such solution could include, for example, rewriting IPv6 labels (e.g., a classifier or router on-path between the LTE-split entities could modify the IPv6 labels to a unique value). If such routing is based on labels, there may be a vulnerability to DDoS attacks because instead of distributing the load between the different vRAN entities such as, for example, PPFs (e.g., in UL), one PPF or RCF could become overloaded with UEs. Additionally, if the access control is put in place based on IPv6 labels, many UEs could be filtered wrongly if the initial assigned labels are changed on-path. Thus, solutions in which the traffic is IPsec-encrypted, including ESP tunnel mode, and where control over the encapsulated sessions is performed directly on the encrypted traffic, are left as open problems.

Accordingly, the present disclosure provides for a solution to enable policy-based IP-level filtering (e.g., IP level control) in IPsec protected vRAN that can, for example, be used as a mitigation of signalling storms. The present disclosure considers that the various location sites for the access network (e.g., baseband (BB) sites and vRAN sites) may be geographically distributed with inter-network traffic and may cross domains under different security administration responsibilities. Thus, security protections, and, in particular, IPsec protection (e.g., ESP tunnel mode) may be required for each baseband-to-vRAN interface (e.g., each BPF - RCF (e.g., F1-C) interface, BPF - PPF (F1-U) interface, BPF - BPF (e.g., E5) interface, etc. may be IPsec ESP protected).

For the sake of simplicity and clarity, the examples discussed in the present disclosure are discussed primarily with respect to uplink (UL) transmissions from the UE to the RAN, e.g., the network node. However, it should be understood that the principles disclosed may also be beneficial for downlink (DL) transmissions from the RAN, e.g., network node, towards the UE. Control activated on, for example, the signalling data according to examples in the disclosure may impact both UL and DL.

Some embodiments of the disclosure provide that, at a UE connection, one unique identifier (ID) may be derived based on one or more UE ID(s) at a vRAN site. In some embodiments, for a dual-connected (DC) UE, two unique IDs may be derived. The derived ID may uniquely and globally identify a UE and/or traffic associated with the UE. The derived ID may serve to encode the Security Parameter Index (SPI) of the IPsec session (e.g., IPsec UL session) between, for example, a baseband function (e.g., BPF, gNB-DU, DU) and a vRAN site (e.g., RCF, gNB-CU-CP, CU), and/or between two secure gateways of these sites. Simple access control IP firewall rules (L3 FW) may thus be derived based on such SPIs to be used in mitigation policies of signalling storms in vRAN. For example, in some embodiments, an L3 firewall may filter based on L3 firewalling rules matching the SPI field in the IPsec header.

Advantageously, some embodiments of the present disclosure may provide for simple/efficient access to UE signalling sessions directly on IPsec ESP mode tunnels; mitigation outside the legacy baseband and vRAN <NUM> entities; and/or offloaded control.

Some embodiments of the present disclosure may provide a new security function for vRAN that is useful for other security controls and extensible to the user-plane. Some embodiments of the present disclosure enforce security policies over encrypted traffic between vRAN entities, such as, for example, a baseband function (e.g., gNB-DU) and a radio control function (e.g., gNB-CU-CP).

Some embodiments of the present disclosure are applied on protected traffic and do not introduce additional threats. In some embodiments, the present disclosure provides for IPsec level filtering, without exposing the packet information to a passive listener sniffing traffic between the entities (e.g., between BPF (e.g., gNB-DU) and the RCF (e.g., gNB-CU-CP)).

Some embodiments of the present disclosure enable a third-party entity to filter traffic while not revealing the content of the traffic or the security policies. In some embodiments, the solution in the present disclosure may be considered filtering based on filtering opaque values of the SPI. In some embodiments, the filtering entity may apply the security policies based on the inner packet information. In this case, the disclosure may be considered a type of shared secret shared between a RAN entity (e.g., RCF, BPF) and the filtering entity (e.g., a firewall).

Some embodiments of the disclosure advantageously present a mechanism to obfuscate the information from a passive listener, while such information is being shared between trusted parties. Additional mechanisms may be considered in the future depending on requirements for cryptographic performance and robustness.

Advantageously, some embodiments of the disclosure provide an efficient arrangement to enforce security policies by exposing the information that is useful for the filtering function into a standard field in the IP header. This may be sufficient to not require deep packet inspection (DPI) of the complete packet in order to identify and filter the packet.

Some embodiments of the disclosure provide an arrangement for the vRAN entities (e.g., BPF and PPF) to agree (e.g., according to pre-defined rules) on the fields to be used to encode the SPI value. Such fields used to encode the SPI value may be selected based on usefulness for enforcing the filtering security policies in an accurate and efficient manner. In addition to signalling storm mitigation in vRAN, other use cases may benefit from the principles in the present disclosure. For example, there may be other use cases identified where UE traffic may be discharged close to the radio site, which is the case, e.g., for blacklisted UEs. Furthermore, new <NUM> industrial use cases may require more control over IoT devices in various contexts (as compared to current control techniques for IoT devices), such as temporal contexts. For example, relying on the security services of an Access Provider, an IoT Service Provider might require from the Access Provider to enforce access control on the managed IoT devices during certain time intervals (i.e., temporal context) if the signalling load reaches certain thresholds (e.g., allow only N devices to connect during Delta units of time).

Before describing in detail exemplary embodiments, it is noted that the embodiments reside primarily in combinations of apparatus components and processing steps related to IPsec communications, such as, for example, secured vRAN and/or signalling storm mitigation in secured RAN. Note that although terminology from and/or relating to one particular type of network, such as, for example, vRAN networks may be used in this disclosure, this should not be seen as limiting the scope of the disclosure to only those types of networks and nodes. Other networks and/or nodes where IPsec communications are used may also benefit from exploiting the principles covered and features described in this disclosure. Also, components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.

In embodiments described herein, the joining term, "in communication with" and the like, may be used to indicate electrical or data communication, which may be accomplished by physical contact, induction, electromagnetic radiation, radio signalling, infrared signalling or optical signalling, for example.

In some embodiments a more general term "network node" is used and it can correspond to any type of radio network node or any node, which communicates with a wireless device and/or with another network node, directly or indirectly. In some embodiments, the network node may refer to a device or functionality implemented in a device that is associated with a base station, such as a gNB, and may be located in a cloud data center site, or at the antenna site. Examples of network nodes are BPF, RCF and/or PPF. The BPF may also be known as, or more generally referred to herein as the baseband function, distributed unit (DU), base station distributed unit, baseband distributed unit, etc. The BPF may be, for example, a gNB-DU. A network node may be a virtualized access network entity, such as, for example, the packet processing function (PPF) and/or the radio control function (RCF). The RCF may also be known as, or more generally referred to herein as the radio function, virtualized radio function, centralized unit (CU), and base station centralized unit. The RCF may be, for, example, gNB-CU and/or gNB-CU-Control Plane (CP). PPF may be, for example, gNB-CU-User Plane (UP). In some embodiments, the network node may refer to a device, and/or functionality implemented in a device, and/or an instance of a pooled vRAN function at a data center site/cloud that facilitates RAN services and connectivity (e.g., gNB-CU-CP, gNB-CU-UP, gNB-DU, etc.).

Other examples of network nodes are NodeB, master eNB (MeNB), secondary eNB (SeNB), gNode B (gNB), a network node belonging to master cell group (MCG) or a secondary cell group (SCG), base station (BS), multi-standard radio (MSR) radio node such as a (multi-standard radio) MSR BS, eNodeB, network controller, radio network controller (RNC), base station controller (BSC), relay, donor node controlling relay, base transceiver station (BTS), access point (AP), transmission points, transmission nodes, remote radio unit (RRU), remote radio head (RRH), nodes in distributed antenna system (DAS), core network node (e.g. mobile switching center (MSC), mobile management entity (MME), etc.), operation and maintenance (O&M), operations support system (OSS), self-organizing network (SON), positioning node (e.g., evolved serving mobile location center (E-SMLC)), minimization of drive test (MDT) node, etc..

In some embodiments the non-limiting terms user equipment (UE) and wireless device (WD) are used interchangeably. The UE (or WD) herein can be any type of wireless device capable of communicating with a network node or another UE over radio signals. The UE may also be a radio communication device, target device, device to device (D2D) UE, machine type UE or UE capable of machine to machine communication (M2M), low-cost and/or low-complexity UE, a sensor equipped with UE, Tablet, mobile terminals, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), USB dongles, Customer Premises Equipment (CPE), an Internet of Things (IoT) device, or a Narrowband IoT (NB-IOT) device etc..

Also, in some embodiments the generic term "radio network node" may be used. It can be any kind of a radio network node which may comprise any of base station, radio base station, base transceiver station, base station controller, network controller, radio network controller (RNC), evolved Node B (eNB), Node B, gNB, Multi-cell/multicast Coordination Entity (MCE), relay node, access point, radio access point, Remote Radio Unit (RRU), Remote Radio Head (RRH).

In some embodiments, the general term "virtualized radio function" may be used to indicate an RCF, gNB-CU-CP, a base station CU, or other virtualized radio control function that may be remotely implemented at a data center site.

In some embodiments, the general term "baseband function" may be used to indicate a BPF, gNB-DU, base station DU, or other baseband processing function that may be implemented at or near an antenna site, or at least closer to an antenna site than a virtualized RAN entity at a data center site.

Even though the descriptions herein may be explained in the context of one of a Downlink (DL) and an Uplink (UL) communication, it should be understood that the basic principles disclosed may also be applicable to the other of the one of the DL and the UL communication. Transmitting in downlink may pertain to transmission from the network or network node to the terminal. The terminal may be considered the WD or UE. Transmitting in uplink may pertain to transmission from the terminal to the network or network node. Uplink and downlink may be considered communication directions.

Although the description herein may be explained in the context of a particular channel, such as an UL channel, it should be understood that the principles may also be applicable to other channels.

An indication generally may explicitly and/or implicitly indicate the information it represents, corresponds to and/or indicates. Implicit indication may for example be based on, for example, a known association or correlation. Explicit indication may for example be based on a specific message and/or request, and/or one or more index or indices corresponding to a table, and/or one or more bit patterns representing the information.

Signaling may generally comprise one or more symbols and/or signals and/or messages. A signal may comprise or represent one or more bits. An indication may represent signaling, and/or be implemented as a signal, or as a plurality of signals. One or more signals may be included in and/or represented by a message. Signaling, in particular control signaling, may comprise a plurality of signals and/or messages, which may be communicated on different carriers and/or different interfaces and/or wired or wireless connections and/or be associated to different signaling processes, e.g., representing and/or pertaining to one or more such processes and/or corresponding information. An indication may comprise signaling, and/or a plurality of signals and/or messages, which may be communicated on different carriers and/or different interfaces and wired or wireless connections.

Any two or more embodiments described in this disclosure may be combined in any way with each other.

Returning to the drawing figures, in which like elements are referred to by like reference designators, there is shown in <FIG> a block diagram of a communication network <NUM> constructed according to at least some of the principles set forth in this disclosure. The communication network <NUM> includes the core network <NUM> and the cloud <NUM> which may include the Internet and/or the public switched telephone network (PSTN). The communication network <NUM> includes one or more network nodes such as a first network node 18a and a second network node18b, which may communicate via interface, such as, for example, an F1 interface. The communication network <NUM> includes a radio <NUM> in communication with the network node 18a. The network nodes 18a and 18b may be referred to collectively as network nodes <NUM>. It is contemplated that additional and/or different interfaces can be used for the communication between network nodes <NUM>. The network node <NUM> may include a generator <NUM>, which may be configured to perform one or more of the processes described herein for the network node <NUM>, such as generating an SPI value based at least in part on a unique UE identifier (ID). The communication network <NUM> may also include a security node <NUM>, which may be a firewall or filtering node, between the first network node 18a and the second network node 18b. The security node <NUM> may include an observer <NUM>, which may be configured to perform one or more of the processes described herein for the security node <NUM>, such as filtering IPsec traffic based at least in part on an SPI value that is unique to an IPsec session for a UE <NUM>. The network nodes <NUM> may serve user equipments (UEs) <NUM>, referred to collectively herein as UE <NUM>. Note that, although only one UE <NUM> and two network nodes <NUM> are shown for convenience, the communication network <NUM> may typically include many more UEs <NUM> and network nodes <NUM>. The communication network <NUM> may include other nodes, connections and interfaces that are not depicted in <FIG> for clarity and for ease of understanding.

Some embodiments of the present disclosure are described with respect to communications between the first network node 18a and the second network node 18b. It should be understood that although "first" and "second" are used to identify network nodes 18a and 18b, respectively, such terms are used solely to distinguish one entity or element from another entity or element, without necessarily requiring or implying any physical or logical relationship or order between such entities or elements. Further, a network node <NUM> configured to perform the processes described herein with respect to the first network node 18a in certain scenarios may also be configured to perform the processes described herein with respect to the second network node 18b in other scenarios. For example, the generator <NUM> may also be included in the network node 18a.

<FIG> is a block diagram of an embodiment of the network node <NUM> constructed in accordance with principles set forth herein. The network node <NUM> includes a communication interface <NUM> for setting up and maintaining a wired or wireless connection with an interface of a different communication device of the communication network <NUM>. The communication interface <NUM> may include a radio interface for setting up and maintaining at least a wireless connection with a UE <NUM> located in a coverage area served by the network node <NUM>. The radio interface may be formed as or may include, for example, one or more RF transmitters, one or more RF receivers, and/or one or more RF transceivers. The communication interface <NUM> may be configured to facilitate a wired and/or optical connection (e.g., F1) such as an IP connection or an IPsec connection with another node that may be at a data center site in the cloud <NUM>.

The network node <NUM> may also include processing circuitry <NUM>.

The network node <NUM> may further have software stored internally in, for example, memory <NUM>, or stored in external memory (e.g., database, storage array, network storage device, etc.) accessible by the network node <NUM> via an external connection. The software may be executable by the processing circuitry <NUM>. The processing circuitry <NUM> may be configured to control any of the methods and/or processes described herein and/or to cause such methods, and/or processes to be performed, e.g., by network node <NUM>. Processor <NUM> corresponds to one or more processors <NUM> for performing network node <NUM> functions described herein. The memory <NUM> is configured to store data, programmatic software code and/or other information described herein. In some embodiments, the software may include instructions that, when executed by the processor <NUM> and/or processing circuitry <NUM>, causes the processor <NUM> and/or processing circuitry <NUM> to perform the processes described herein with respect to network node <NUM>. For example, processing circuitry <NUM> of a first network node 18a may include the generator <NUM>, which may be configured to receive a trigger to establish an Internet Protocol Security, IPsec, session with a second network node 18b, the IPsec session being associated with a user equipment, UE <NUM>. The processing circuitry <NUM> may be configured to, responsive to the trigger to establish the IPsec session associated with the UE, derive a unique identifier for the UE <NUM>. The processing circuitry <NUM> may be configured to generate a Security Parameter Index, SPI, value based at least in part on the unique identifier derived for the UE <NUM>, the SPI value being unique to the IPsec session. The processing circuitry <NUM> may be configured to communicate (via e.g., communication interface <NUM>) an indication of the SPI value to the second network node 18b.

In some embodiments, establishing the IPsec session with the second network node18b comprises an IPsec Security Association, SA, negotiation with the second network node 18b. In some embodiments, the trigger is associated with the IPsec SA negotiation with the second network node 18b. In some embodiments, the trigger is a request message, from the second network node 18b, to establish the IPsec SA negotiation with the second network node 18b. In some embodiments, the trigger is one of a request message, a request message from the second network node 18b, a control plane message, an indication of an establishment of a radio session for the UE <NUM>, and a radio bearer establishment message. In some embodiments, the processing circuitry <NUM> is further configured to receive (via e.g., communication interface <NUM>), from the second network node 18b, an IPsec packet, the IPsec packet associated with the UE <NUM> and the IPsec packet including the indication of the SPI value; decrypt and authenticate the received IPsec packet using at least the indication of the SPI value; and communicate, to a third network node (e.g., PPF, gNB-CU-UP) and/or the core network <NUM>, the decrypted packet.

In some embodiments, the SPI value maps to IPsec traffic associated with the UE <NUM> between the first network node 18a and the second network node 18b. In some embodiments, the processing circuitry <NUM> is further configured to derive the unique identifier for the UE <NUM> based at least in part on data associated with the UE <NUM> and, as a result of the derivation, the generation of the SPI value is based at least in part on the data associated with the UE <NUM>. In some embodiments, the data used to derive the unique identifier and generate the SPI value uniquely identifies IPsec traffic associated with the UE <NUM> for IP-level filtering of traffic between the first network node 18a and the second network node 18b. In some embodiments, the data used to derive the unique identifier for the UE <NUM> and generate the SPI value includes at least one of a Cell UE Identifier, a Baseband Processing Function, BPF, Identifier, and a Cell Identifier. In some embodiments, the data used to derive the unique identifier for the UE <NUM> and generate the SPI value includes an identification of a radio bearer, RB, for the UE <NUM>. In some embodiments, the data used to derive the unique identifier for the UE <NUM> and generate the SPI value is signalling data associated with the UE <NUM>. In some embodiments, the data associated with the UE <NUM> is data corresponding to one of an Uplink, UL, channel and a Downlink, DL, channel for the UE. In some embodiments, the processing circuitry <NUM> is further configured to derive the unique identifier for the UE <NUM> by concatenating the data associated with the UE <NUM>. In some embodiments, the processing circuitry <NUM> is further configured to generate the SPI value by inputting the unique identifier into an invertible function that returns a <NUM>-bit value representing the SPI. In some embodiments, the indication of the SPI value is one of a clear text SPI value and an obfuscated SPI value. In some embodiments, the processing circuitry <NUM> is further configured to obfuscate the SPI value and the communication of the indication of the SPI value is a communication of the obfuscated SPI value to the second network node 18b. In some embodiments, the processing circuitry <NUM> is configured to obfuscate the SPI value by being further configured to input at least the generated SPI value into a hash function. In some embodiments, the processing circuitry <NUM> is configured to obfuscate the SPI value by being further configured to input the generated SPI value and a key value into a hash function to generate the obfuscated SPI value. In some embodiments, the processing circuitry <NUM> is configured to receive, from the second network node 18b, an IPsec packet, the IPsec packet including the indication of the SPI value. In some embodiments, the processing circuitry <NUM> is configured to decrypt and authenticate the received IPsec packet using at least the indication of the SPI value by being further configured to identify a Security Association, SA, of the IPsec packet via the obfuscated SPI value; decrypt the IPsec packet according to the identified SA to obtain payload data of the decrypted packet; determine the unique identifier for the UE <NUM> and the SPI value from the decrypted payload data; input a key value and the determined SPI value into a hash function; determine whether the hash function returns an output value that is equal to the obfuscated SPI value; and one of communicate the decrypted packet (via e.g., the communication interface <NUM>) and drop the decrypted packet based at least in part on whether the output value of the hash function is equal to the obfuscated SPI value. In some embodiments, the processing circuitry <NUM> is further configured to communicate, to a security node <NUM>, at least the indication of the SPI value for Internet Protocol, IP, -level filtering of IPsec traffic between the first network node 18a and the second network node 18b. In some embodiments, the processing circuitry <NUM> is further configured to communicate, to the security node <NUM>, a security action associated with the SPI value, the security action to be performed by the security node <NUM> on IPsec traffic between the first network node 18a and the second network node 18b and the SPI value identifying the UE <NUM> for the performance of the security action. In some embodiments, the security action includes at least one of rate-limiting IPsec traffic associated with UE, accepting IPsec traffic associated with the UE, and rejecting IPsec traffic associated with the UE <NUM>. In some embodiments, the security node <NUM> is a Layer <NUM> firewall for Internet Protocol, IP, traffic between the first network node 18a and the second network node 18b. In some embodiments, one of the second network node 18b and the first network node 18a comprises at least one virtualized radio function in a cloud <NUM> data center and the other one of the second network node 18b and the first network node 18a comprises a baseband function. In some embodiments, the at least one virtualized radio function is a base station centralized unit, CU, in the cloud <NUM> data center and the baseband function is a base station distributed unit, DU.

<FIG> is a block diagram of an embodiment of the security node <NUM> constructed in accordance with principles set forth herein. The security node <NUM> includes a communication interface <NUM> for communicating over a wired or wireless connection with an interface of a different communication device of the communication network <NUM>. The communication interface <NUM> may include a radio interface for setting up and maintaining at least a wireless connection with another communication device of the communication network <NUM>. The radio interface may be formed as or may include, for example, one or more RF transmitters, one or more RF receivers, and/or one or more RF transceivers. The communication interface <NUM> may be configured to facilitate a wired and/or optical connection such as an IP connection or an IPsec connection with another node, which may be at a data center site in the cloud <NUM>.

The security node <NUM> may also include processing circuitry <NUM>.

The security node <NUM> may further have software stored internally in, for example, memory <NUM>, or stored in external memory (e.g., database, storage array, network storage device, etc.) accessible by the security node <NUM> via an external connection. The software may be executable by the processing circuitry <NUM>. The processing circuitry <NUM> may be configured to control any of the methods and/or processes described herein and/or to cause such methods, and/or processes to be performed, e.g., by security node <NUM>. Processor <NUM> corresponds to one or more processors <NUM> for performing security node <NUM> functions described herein. The memory <NUM> is configured to store data, programmatic software code and/or other information described herein. In some embodiments, the software may include instructions that, when executed by the processor <NUM> and/or processing circuitry <NUM>, causes the processor <NUM> and/or processing circuitry <NUM> to perform the processes described herein with respect to security node <NUM>. For example, processing circuitry <NUM> may include the observer <NUM> configured to observe Internet Protocol Security, IPsec, traffic between a first network node 18a and a second network node 18b. The observer <NUM> may be configured to filter the observed IPsec traffic based at least in part on an indication of a Security Parameter Index, SPI, value, the SPI value based at least in part on a unique identifier for a user equipment, UE, <NUM> and the SPI value being unique to an IPsec session associated with the UE <NUM>.

In some embodiments, the processing circuitry <NUM> is further configured to receive the indication of the SPI value from one of the first network node 18a and the second network node 18b and filter the observed IP traffic based at least in part on the received indication of the SPI value. In some embodiments, the processing circuitry <NUM> is further configured to receive a security action associated with the SPI value; identify IP traffic associated with a user equipment, UE, <NUM> based at least in part on the indication of the SPI value; and filter the identified IP traffic associated with the UE <NUM> according to the received security action. In some embodiments, the security action includes at least one of rate-limiting IPsec traffic associated with UE <NUM>, accepting IPsec traffic associated with the UE <NUM>, and rejecting IPsec traffic associated with the UE <NUM>. In some embodiments, the processing circuitry <NUM> is configured to filter the observed IPsec traffic based at least in part on the indication of the SPI value by being further configured to match SPI fields of the observed IPsec packets to the SPI value; and filter at least one IPsec packet based on whether an SPI field of the IPsec packet matches the SPI value. In some embodiments, the security node <NUM> is a Layer <NUM> firewall between the first network node 18a and the second network node 18b.

<FIG> is a flowchart of an exemplary process in a network node <NUM>, such as, for example the first network node 18a. The process includes receiving a trigger to establish an Internet Protocol Security, IPsec, session with a second network node 18b, the IPsec session being associated with a user equipment, UE <NUM> (block S100). The process includes, responsive to the trigger to establish the IPsec session associated with the UE <NUM>, deriving a unique identifier for the UE <NUM> (block S102). The process includes generating a Security Parameter Index, SPI, value based at least in part on the unique identifier for the UE <NUM>, the SPI value being unique to the IPsec session (block S <NUM>). The process includes communicating an indication of the SPI value to the second network node 18b (block S106).

In some embodiments, the establishing the IPsec session with the second network node 18b comprises an IPsec Security Association, SA, negotiation with the second network node 18b. In some embodiments, the trigger is associated with the IPsec SA negotiation with the second network node 18b. In some embodiments, the trigger is a request message, from the second network node 18b, to establish the IPsec SA negotiation with the second network node 18b. In some embodiments, the trigger is one of a request message, a request message from the second network node 18b, a control plane message, an indication of an establishment of a radio session for the UE <NUM>, and a radio bearer establishment message. In some embodiments, the process further includes receiving, from the second network node 18b, an IPsec packet, the IPsec packet associated with the UE <NUM> and the IPsec packet including the indication of the SPI value; decrypting and authenticating the received IPsec packet using at least the indication of the SPI value; and communicating, to a third network node, the decrypted packet. In some embodiments, the SPI value maps to IPsec traffic associated with the UE <NUM> between the first network node 18a and the second network node 18b. In some embodiments, deriving the unique identifier further comprises deriving the unique identifier for the UE <NUM> based at least in part on data associated with the UE <NUM> and, as a result of the derivation, the generation of the SPI value is based at least in part on the data associated with the UE <NUM>. In some embodiments, the data used to derive the unique identifier and generate the SPI value uniquely identifies IPsec traffic associated with the UE <NUM> for IP-level filtering of traffic between the first network node 18a and the second network node 18b.

In some embodiments, the data used to derive the unique identifier for the UE <NUM> and generate the SPI value includes at least one of a Cell UE Identifier, a Baseband Processing Function, BPF, Identifier, and a Cell Identifier. In some embodiments, the data used to derive the unique identifier for the UE <NUM> and generate the SPI value includes an identification of a radio bearer, RB, for the UE <NUM>. In some embodiments, the data used to derive the unique identifier for the UE <NUM> and generate the SPI value is signalling data associated with the UE <NUM>. In some embodiments, the data associated with the UE <NUM> is data corresponding to one of an Uplink, UL, channel and a Downlink, DL, channel for the UE <NUM>. In some embodiments, deriving the unique identifier further comprises deriving the unique identifier for the UE <NUM> by concatenating the data associated with the UE <NUM>. In some embodiments, generating the SPI value further comprises generating the SPI value by inputting the unique identifier into an invertible function that returns a <NUM>-bit value representing the SPI. In some embodiments, the indication of the SPI value is one of a clear text SPI value and an obfuscated SPI value. In some embodiments, the process further includes obfuscating the SPI value and the communication of the indication of the SPI value comprises a communication of the obfuscated SPI value. In some embodiments, the obfuscating the SPI value further comprises obfuscating the SPI value by inputting at least the generated SPI value into a hash function.

In some embodiments, the obfuscating the SPI value further comprises obfuscating the SPI value by inputting the generated SPI value and a key value into a hash function to generate the obfuscated SPI value. In some embodiments, the process further includes receiving, from the second network node 18b, an IPsec packet, the IPsec packet including the indication of the SPI value; and decrypting and authenticating the received IPsec packet using at least the indication of the SPI value by: identifying the Security Association, SA, of the IPsec packet via the obfuscated SPI value; decrypting the IPsec packet according to the identified SA to obtain payload data of the IP packet; determining the unique identifier for the UE <NUM> and the SPI value from the decrypted payload data; inputting a key value and the determined SPI value into a hash function; determining whether the hash function returns an output value that is equal to the obfuscated SPI value; and one of communicating the IP packet and dropping the IP packet based at least in part on whether the output value of the hash function is equal to the obfuscated SPI value. In some embodiments, the process further includes communicating, to a security node <NUM>, at least the indication of the SPI value for Internet Protocol, IP, -level filtering of IPsec traffic between the first network node 18a and the second network node 18b.

In some embodiments, the process further includes communicating, to the security node <NUM>, a security action associated with the SPI value, the security action to be performed by the security node <NUM> on IPsec traffic between the first network node 18a and the second network node 18b and the SPI value identifying the UE <NUM> for the performance of the security action. In some embodiments, the security action includes at least one of rate-limiting IPsec traffic associated with UE <NUM>, accepting IPsec traffic associated with the UE <NUM>, and rejecting IPsec traffic associated with the UE <NUM>. In some embodiments, the security node <NUM> is a Layer <NUM> firewall for IPsec traffic between the first network node 18a and the second network node 18b. In some embodiments, one of the second network node 18b and the first network node 18a comprises at least one virtualized radio function in a cloud <NUM> data center and the other one of the second network node 18b and the first network node 18a comprises a baseband function. In some embodiments, the at least one virtualized radio function is a base station centralized unit, CU, (e.g., gNB-CU) in the cloud <NUM> data center and the baseband function is a base station distributed unit, DU (e.g., gNB-DU).

<FIG> is a flowchart of an exemplary process in a security node <NUM>. The process includes observing Internet Protocol Security, IPsec, traffic between a first network node 18a and a second network node 18b (block S108). The process includes filtering the observed IPsec traffic based at least in part on an indication of a Security Parameter Index, SPI, value, the SPI value based at least in part on a unique identifier for a user equipment, UE, <NUM> and the SPI value being unique to an IPsec session associated with the UE <NUM> (block S110). In some embodiments, the process further includes receiving the indication of the SPI value from one of the first network node 18a and the second network node 18b and filtering the observed IP traffic based at least in part on the received indication of the SPI value. In some embodiments, the process further includes receiving a security action associated with the SPI value; identifying IPsec traffic associated with a user equipment, UE, <NUM> based at least in part on the indication of the SPI value; and filtering the identified IPsec traffic associated with the UE <NUM> according to the received security action. In some embodiments, the security action includes at least one of rate-limiting IPsec traffic associated with UE <NUM>, accepting IPsec traffic associated with the UE <NUM>, and rejecting IPsec traffic associated with the UE <NUM>. In some embodiments, the filtering the observed IPsec traffic based at least in part on the indication of the SPI value comprises matching SPI fields of the observed IPsec packets to the SPI value; and filtering at least one IPsec packet based on whether an SPI field of the IPsec packet matches the SPI value. In some embodiments, the security node is a Layer <NUM> firewall between the first network node 18a and the second network node 18b.

Having generally described some embodiments of the present disclosure for facilitating signalling storm mitigation in IPsec-secured vRAN, a more detailed description of some of the embodiments are described below, with reference to <FIG> and <FIG>.

Some embodiments of the present disclosure provide for signalling storm mitigation through UE signalling control at the IP level in IPsec-secured vRAN deployments. <FIG> illustrates an example case where signalling data transmission is mobile originated (MO), i.e., UL data transfer. <FIG> shows a unique IPsec SPI value associated with signalling data for each UE <NUM>, between the first network node 18a (e.g., BPF, gNB-DU, etc.) and the second network node 18b (e.g., vRAN RCF, gNB-CU-CP, etc.) to which the respective UE <NUM> is attached. Thus, the present disclosure provides a method in which information, such as pre-defined information from the UE <NUM> signalling data (packet) may be reflected in or represented by a unique IPsec SPI value. This may be useful for increasing entropy for the SPI value. Bytes non-associated with the UE information may be random in some embodiments. The following description provides details of what may be performed in an example, with the output being an SPI value, based at least in part on a unique UE identifier (ID).

In some embodiments, the present disclosure provides a method to obfuscate the "packet information" in to an SPI- hash (e.g., secret key + clear text SPI). When no information is required, the method may output a random SPI. A method to filter the packet given the SPI value is also described. In some embodiments, security policies may be provided that allow a filtering node or security node <NUM> to process IPsec packets based on SPI values.

In some embodiments of the present disclosure, advantageously, changes to the current IPsec stack are not required. A potential issue with such implementation is that it can lead to the first network node 18a (e.g., BPF, gNB-DU, etc.) and the second network node 18b (e.g., RCF, gNB-CU-CP, etc.) managing multiple, different Security Associations (SAs). Some embodiments of the present disclosure may provide for the first network node 18a (e.g., BPF, gNB-DU, etc.) and the second network node 18b (e.g., RCF, gNB-CU-CP, etc.) to not require a clear separation between the IPsec sessions and the cryptographic material may be shared between the Security Associations (SAs), while the SPI value should remain distinct to distinguish the different UEs <NUM> from one another. An example implementation of the principles of the present disclosure is explained below with reference primarily to the flow diagram of <FIG>, which illustrates an example of a UE <NUM> initial access procedure according to at least some of the principles of the present invention.

At UE <NUM> connection and attach, at least a dedicated signalling radio bearer (SRB) and default data radio bearer (DRB) are established for the UE <NUM> between the UE <NUM> and the second network node 18b (e.g., RCF, gNB-CU-CP, etc.) and a packet processing function (PPF), respectively. An IPsec session in uplink may be setup between the first network node 18a (e.g., BPF, gNB-DU, etc.) and the second network node 18b (e.g., RCF, gNB-CU-CP, etc.) to secure signalling of the UE <NUM>. It should be noted that separate IPsec sessions per various signalling bearers of a particular UE <NUM> are also contemplated in some embodiments. <FIG> depicts a high-level overview of a sequence flow for the establishment of the uplink IPsec session between the first network node 18a (e.g., BPF, gNB-DU, etc.) and the second network node 18b (e.g., RCF, gNB-CU-CP, etc.) at UE <NUM> connection and attach according to the principles of the present disclosure.

In step S200, a Random Access Channel (RACH) procedure may be performed by the UE <NUM> towards the first network node 18a (e.g., gNB-DU, BPF). In step S202, the UE <NUM> may send a connection request message to the first network node 18a (e.g., gNB-DU, BPF). The connection request message may be an RRC connection request message and may include a cell UE ID for the UE <NUM>, a C-RNTI, and/or other UE information. In step S204, responsive to the connection request message from step S202, the first network node 18a may send a message to the second network node 18b over, for example, an F1-C interface. In some embodiments, the message may be a UE connection establishment request message, which may include the cell UE ID, C-RNI, BPF ID, and other UE information. In some embodiments, the message may be an F1 Application Protocol (AP) initial UL RRC message transfer message that includes the RRC connection request message and, if the UE <NUM> is admitted, corresponding lower layer configuration information for the UE <NUM>. In some embodiments, reception of the connection request message by the second network node 18b may be a trigger indicating an establishment of an IPsec session with the second network node 18b, for the UE <NUM>. Such trigger may result in the second network node 18b generating a globally unique ID for the UE <NUM> according to the principles in the present disclosure. There may also be other triggers.

In step S206, in response to the UE connection establishment request message from step S204, the second network node 18b may perform dedicated SRB establishment. In step S208, dedicated SRB and baseband (BB) resource allocation may be performed for the UE <NUM>. In step S210, the first network node 18a may allocate BB resources and dedicated SRB for the UE <NUM>. In step S212, the second network node 18b may send a message, e.g., over the F1-C interface, to the first network node 18a to indicate the UE <NUM> connection setup. In some embodiments, the message may be an F1 AP DL RRC message transfer message. In some embodiments, the second network node 18b may allocate a gNB-CU UE F1 AP ID for the UE <NUM> and may generate an RRC connection setup message towards the UE <NUM>. The RRC connection message may be encapsulated in the F1 AP DL RRC message transfer message. It should be noted that the initial UE <NUM> signalling messages on the F1-C interface (e.g., connection request and setup messages from steps <NUM> and <NUM>), which may be prior to establishment of the dedicated signalling bearer (SRB), may be exchanged on a separate IP session between the first and second network nodes 18a and 18b.

In step S214, the first network node 18a communicates a connection setup message to the UE <NUM>, which may include the dedicated SRB parameters for the UE <NUM>. In some embodiments, the connection setup message in step S214 may be an RRC connection setup message. In step S216, there may be an IPsec negotiation for an SA between the first network node 18a and the second network node 18b. The IPsec SA negotiation may be considered a part of establishing the IPsec session.

In this example described with reference to <FIG>, it is the second network node 18b (e.g., RCF, gNB-CU-CP, etc.) at the vRAN site that computes and/or generates the unique identifier for the UE <NUM> in step S218. The unique identifier may be considered a globally unique UE ID that is based at least in part on UE data in the connection request message in e.g., step S204. In one embodiment, a globally unique UE ID is derived for the UE <NUM> in a cell (in step S218) by concatenating at least some of the information (e.g., UE cell ID, BPF ID, cell ID, etc.) in the message from e.g., step S204 or <NUM> as follows:
globally_unique_UE_ID = cell_UE_ID | BPF_ID [ | cell_ID ],
where "|" is the concatenation operator. The different values for concatenation can be extracted from the initial connection request message from the UE <NUM>. For example, BPF_ID may be a value identifying the baseband function. If the first network node 18a (e.g., BPF, gNB-DU, etc.) serves several cells with the same cell_UE_ID potentially reused by several UEs <NUM> in the different cells, there may be an optional parameter ("[ ]") for the second network node 18b (e.g., RCF, gNB-CU-CP, etc.) site to rely upon, such as a cell_ID in order to ensure that the unique UE ID that is generated is unique to the IPsec session. In other embodiments, the globally unique UE ID may be derived/generated/encoded by combining UE data according to other techniques and operators.

In some embodiments, the cell_UE_ID may include the Channel Radio Network Temporary Identifier (C-RNTI10) and/or a temporary mobile subscriber identity (TMSI) type of identifier, etc. Also, if a unique identifier for the UE <NUM> similar to, for example, eNB UE S1AP ID in LTE (Technical Specification <NUM>) becomes available at the second network node 18b (e.g., RCF, gNB-CU-CP, etc.) before the establishment of the IPsec session, the second network node 18b (e.g., RCF, gNB-CU-CP, etc.) may use such unique identifier in addition to (or instead of another UE identifier) to generate the globally unique UE ID. This is because all packets on S1AP may be identified with such unique identifier and can be expected to help in mapping the IPsec packets to S1AP packets. In other embodiments, there may be other UE data used to derive the globally unique UE ID.

In step S220, based on this globally unique UE ID, a specific SPI value for the UE <NUM> (e.g., Clear_text_SPIUE) may be computed and/or derived during e.g., the IPsec session negotiation between the second network node 18b (e.g., RCF, gNB-CU-CP, etc.) and the first network node 18a (e.g., BPF, gNB-DU, etc.). In some embodiments, this IPsec session can secure all the subsequent dedicated signalling radio bearer for the UE <NUM>. The information encoded in one SPI value (e.g., Clear_text_SPIUE) can allow the network to uniquely map the derived SPI value to one active UE <NUM> in a particular cell, connected to the first network node 18a (e.g., BPF, gNB-DU, etc.). Furthermore, the IPsec SPI size is generally <NUM> bits; thus, the globally unique UE ID may be transformed through, for example, an invertible function such as: Clear_text_SPIUE = func(globally_unique_UE_ID), where func() is a function returning a <NUM> bit size value, with the property that:
globally_unique_UE_ID = func-<NUM> (Clear_text_SPIUE). For example, func() may apply selection of a predetermined number of bits, such as, the first <NUM> bits (e.g., if the unique UE ID is a C-RNTI that is <NUM> bits) concatenated with the last <NUM> bits in the globally unique UE ID, which may include at least part of the BPF_ID and/or cell_ID, for example. Thus, a network node <NUM> could obtain (e.g., via func-<NUM>()) the globally unique UE ID by observing, for example, the clear text SPI value and the source of the message (e.g., BPF_ID) carrying the clear text SPI value.

In step S222, the SPI value may optionally be transformed for obfuscation by the IPsec end point (in this example, the second network node 18b) into an obfuscated SPI value (e.g., Obfuscated_SPIUE). In step S224, the second network node 18b sends the obfuscated SPI value to the other IPsec end point, in this example the first network node 18a (e.g., BPF, gNB-DU, etc.). In some embodiments, the second network node 18b sends the obfuscated SPI value without any other indication, during the IPsec negotiation. In other embodiments, where step S222 of obfuscating the SPI value is not performed, the second network node 18b may send the clear text SPI value instead of the obfuscated SPI value. In some embodiments, the SPI obfuscation may be deactivated for those UEs <NUM> that are under Lawful Intercept.

Like the clear text SPI value, the obfuscated SPI value (e.g., Obfuscated_SPIUE) may also be uniquely mapped to one active UE <NUM> connected to one cell. Thus, control on the signalling (and/or data) between IPsec endpoints (e.g., first network node 18a and second network node 18b) may be enforced by a security node <NUM>, such as an L3 firewall, directly on the IPsec session, anywhere between the first network node 18a (e.g., BPF, gNB-DU, etc.) and the site corresponding to the second network node 18b (e.g., RCF, gNB-CU-CP, etc.), based on the obfuscated SPI value present in the IPsec header. In some embodiments, the security node <NUM> may be under the same administration domain with the vRAN entities, or may be managed by another party. It should be noted that, in this example, from the first network node 18a (e.g., BPF, gNB-DU, etc.) perspective, the IPsec session establishment may be a legacy one since it is the second network node 18b in this example that derives the unique UE ID and generates the SPI value based on the unique UE ID.

In one embodiment, the obfuscation may be performed by an irreversible transformation, such as a hash() function that may be applied on the clear text SPI value to obtain the obfuscated SPI (<NUM> bit) value. The objective of obfuscation of the SPI value is generally to conceal any of the meaningful information in the SPI field of the IPsec packets header. Thus, the uplink signalling traffic from the UE <NUM> can be sent by the first network node 18a (e.g., BPF, gNB-DU, etc.) over this IPsec session between the first network node 18a (e.g., BPF, gNB-DU, etc.) and the second network node 18b (e.g., RCF, gNB-CU-CP, etc.) sites, using the obfuscated SPI value in the IPsec header, as shown, for example, in steps S226 and S228. In step S226, the UE <NUM> sends the connection setup complete message to the first network node 18a. In step S228, the first network node 18a sends a message to the second network node 18b on e.g., the F1-C interface, in the IPsec tunnel with the obfuscated SPI value in the corresponding IPsec header. In one embodiment, the message includes the connection setup complete message from the UE <NUM>. In one embodiment, the first network node 18a encapsulates the message in an F1 AP UL RRC message transfer message and sends the encapsulated message to the second network node 18b. In step S230, the second network node 18b may send a message to another node or vRAN entity (e.g., PPF, gNB-CU-UP). The message may be a S1 AP PDU.

In one embodiment, the obfuscated SPI value may be derived from the clear text SPI value as follows: Obfuscated_SPIUE = hash_func(Key, Clear_text_SPIUE), where Key is a secret value stored at the second network node 18b (e.g., RCF, gNB-CU-CP, etc.) site. When an IPsec packet is received in UL by the second network node 18b (e.g., RCF, gNB-CU-CP, etc.) IPsec endpoint (for example, as in step S228), the obfuscated SPI value identifies the Security Association (SA) cryptographic material. In one embodiment, the operations may proceed as follow at second network node 18b (e.g., RCF, gNB-CU-CP, etc.) (ingress).

The IPsec Security Association (SA) is identified by the obfuscated SPI value in the IPsec header. The original clear data (e.g., a PDCP PDU) is obtained by decrypting the IPsec packet such as the IPsec packet received in step S228. If the second network node 18b receives an invalid (unknown) obfuscated SPI value, there are legacy IPsec procedures that may be used to notify the other IPsec endpoint (e.g., the first network node 18a). If the payload does not correspond to the traffic selector (TS), the packet may be dropped; otherwise the globally unique UE ID and the clear text SPI value may be locally computed for the decapsulated payload as described above, based on the various identifiers (IDs) and information found in the decapsulated payload. Next, using the Key secret value, if hash_func(Key, locally_computed_Clear_text_SPIUE) equals Obfuscated_SPIUE, then accept the original decrypted PDU; otherwise, drop the packet. In some embodiments, a similar scheme can be performed that takes the SRBs and DRBs identifiers (IDs) into account in addition to the various IDs used to compute the globally unique UE ID and the clear text SPI value for the UE <NUM>. Advantageously, using SRB and/or DRB IDs can allow the network to enforce a finer control in case of signalling storms and thus distinguish between the various types of signals originating from the UE <NUM>. It should be noted that if the UE <NUM> operates with dual connectivity, establishing <NUM> SRBs (e.g., one SRB from a master baseband processing function and one SRB with a secondary baseband processing function), the principles of the disclosure can still be applied by having the IDs discussed above duplicated (e.g., the UE <NUM> would have <NUM> different cell IDs).

In some embodiments, filtering (e.g., L3 filtering) of IPsec traffic may be performed by e.g., security node <NUM> based on an obfuscated IPsec SPI value. In IPsec protected vRAN, at least some of the principles of the present disclosure enable implementation of signalling storm mitigation by enforcing security policies with IP (L3) firewalling directly on the IPsec traffic by simply matching the SPI field of the IPsec packets in the observed first network node 18a - second network node 18b traffic. Accordingly, each IPsec packet between the first network node 18a (e.g., BPFs, gNB-DUs, etc.) and the second network node 18b (e.g., RCF, gNB-CU-CP, etc.) can be linked to signalling messages associated with a particular unique UE ID through an IPsec SPI value in the IPsec header. Therefore, filtering rules (e.g., L3 FW filtering rules) that include security policies to mitigate a signalling storm may follow a simple if condition decision template such as, for example, IPsec_hdr. SPI condition [RCF_SPI_value] sec_action, where:.

Regarding the information to be stored on the security node <NUM> as part of a mitigation policy, such as the SPI value(s) (e.g., RCF_SPL value(s)), when the security node <NUM> is not part of the same vRAN administration domain (e.g., the L3 FW is managed by a third party), the SPI value should be an obfuscated SPI value that has no meaningful information outside of the second network node 18b (e.g., RCF, gNB-CU-CP, etc.) context. These SPI values may be received by the security node <NUM> from the second network node 18b (e.g., RCF, gNB-CU-CP, etc.) site, together with the mitigation policy/security action (e.g., sec_actions).

On the other hand, if the security node <NUM> is part of the same vRAN administration domain, then the SPI value can be either an obfuscated SPI value, or a clear text SPI value. For the latter case, the Key used to compute the obfuscated SPI value may be communicated to the security node <NUM>, in addition to the hash() function and the clear text SPI values that are subject to be mitigated. In another embodiment, the Key used to compute the obfuscated SPI value may be communicated to the security node <NUM>, in addition to the hash() function and the one or more IDs used to derive the globally unique UE ID, as well as the func() used to compute the clear text SPI value. In other words, the security node <NUM> site could reconstitute the obfuscated SPI value from the Key, the different functions, and the inner packet information.

Even though the descriptions herein may be explained in the context of an Uplink (UL) communication from UE <NUM> to network node <NUM>, it should be understood that the basic principles disclosed may also be applicable to a Downlink (DL) communication from network node <NUM> towards the UE <NUM>. Similarly, even though the descriptions herein may be explained in the content of the second network node 18b deriving the globally unique UE identifier and the SPI value, it is contemplated that the first network node 18a may also be configured to derive the globally unique UE identifier and the SPI value in other contexts.

Some of the abbreviations that may be used herein are as follows:.

Claim 1:
A method carried out by a first network node (18a), the method comprising:
receiving (S100) a trigger to establish an Internet Protocol Security, IPsec, session with a second network node (18b), the IPsec session being associated with a user equipment, UE (<NUM>), wherein the IPsec session secures the signalling of the UE (<NUM>);
responsive to the trigger to establish the IPsec session associated with the UE (<NUM>), deriving (S102) a unique identifier for the UE (<NUM>);
generating (S104) a Security Parameter Index, SPI, value based at least in part on the unique identifier for the UE (<NUM>), the SPI value being unique to the IPsec session; and
communicating (S106) an indication of the SPI value to the second network node (18b),
wherein deriving the unique identifier further comprises deriving the unique identifier for the UE (<NUM>) based at least in part on data associated with the UE (<NUM>) and, as a result of the derivation, the generation of the SPI value is based at least in part on the data associated with the UE (<NUM>), wherein the data used to derive the unique identifier for the UE and generate the SPI value includes at least one of a Cell UE Identifier, a Baseband Processing Function, BPF, Identifier, and a Cell Identifier.