System and method for securing network traffic using internet protocol security tunnels in a communications network

Abstract

A base station for securing network traffic using Internet Protocol Security (IPSec) tunnels in a communications network is disclosed. The base station includes a transport manager container that handles network traffic termination at a network interface. The base station further includes an Internet Protocol (IP) security tunnel management container that exchanges one or more IKE parameters between a source IKE daemon unit deployed in at least one POD and a target IKE daemon unit deployed in a peer node. The IP security tunnel management container further (a) authenticates the peer node based on the extracted IKE parameters, (b) configures the source IKE daemon unit based on the extracted one or more IKE parameters in response to successful authentication of the peer node, and (c) creates at least one IP security tunnel between the at least one POD and the peer node based on a security data table updated in a network kernel.

Description

[Technical Field]

[0001] The present disclosure relates to communication network systems, and more particularly to systems and methods for securing network traffic using Internet Protocol Security (IPSec) tunnels in communication networks. [Background technology]

[0002] Fifth-generation (5G) networks typically introduce the concept of a split or disaggregated radio access network (RAN). Here, the RAN is divided into a distribution unit (DU) and a aggregation unit (CU). Typically, the DU does not have access to customer communications and is therefore suitable for deployment in unsupervised sites. Meanwhile, the CU performs security functions, terminates access stratum (AS) security, and is typically deployed in sites with limited access for maintenance personnel. The DU and CU together constitute a gNodeB (gNB). Communication between the DU and CU is established using an F1 interface. Furthermore, the CUs communicate with each other via an E1 interface. Traffic sent through these interfaces may carry sensitive data, making them a target for attackers. For this reason, 3GPP specifications require confidentiality, integrity, and replay protection for control plane data exchanged over these interfaces.

[0003] The 3GPP Security Specification (TS 33.501) sets requirements for the protection of base station (e.g., gNB) internal interfaces supporting split architectures and further details security mechanisms for both the F1 and E1 interfaces. In both cases, support for Internet Protocol Security (IPsec) tunnels is required. The specific implementation specifies the use of the IPsec ESP protocol according to IETF RFC 4303 as profiled by TS 33.21089 and IKEv2 certificate-based authentication (following the profile described by TS 33.31090). Given the potential selectivity / flexibility defined in this specification, there is a distinction between control and user plane data. Section 5.3.9 sets requirements for confidentiality, integrity, and replay protection as mandatory for the control plane interface (F1-C). However, the situation is different for the user plane (F1-U) interface. While some requirements specify that gNBs support confidentiality, integrity, and replay protection on the gNB DU-CU F1-U interface for the user plane, other notes specify that the above requirements allow the F1-U to be protected differently from all other traffic on the CU-DU (e.g., traffic on the F1-C) (including turning integrity and / or encryption off or on for the F1-U). With regard to E1 interface protection used for signaling data transfer, the requirements specify that the E1 interface between the CU-CP and CU-UP is confidentiality, integrity, and replay protected, without explicitly listing any further remarks or exceptions. In light of this, it is clear that the specification requires mandatory confidentiality, integrity, and replay protection for the F1 signaling plane and E1 interface, while making it optional for the F1 user plane interface. Summary of the Invention [Problem to be solved by the invention]

[0004] Data transmitted over the RAN interface may contain sensitive data in both the user and control data planes, the protection of which is important to prevent information disclosure, data tampering, or denial of service attacks. Furthermore, while the DU-CU split allows flexibility in deployment options, it relies on proper protection of the interface between the DU and CU (otherwise sensitive data will be vulnerable to attacks).

[0005] Therefore, to address the aforementioned shortcomings, a need exists for a method and / or apparatus for securing network traffic using Internet Protocol Security (IPSec) tunnels in a communications network. Specifically, a need exists for creating and managing IPSec channels for 3GPP F1 / E1 / X2 / N2 / N3 / S1 interfaces in a cloud-native radio access network (RAN). [Means for solving the problem]

[0006] According to one embodiment of the present disclosure, a base station for securing network traffic using Internet Protocol Security (IPSec) tunnels in a communications network is disclosed. The base station includes one or more hardware processors and a memory. The memory is coupled to the one or more hardware processors. The memory includes a plurality of Programmable / Open / Disaggregated Solution (POD) subsystems in the form of microservices-based containers executable by the one or more hardware processors. Each of the plurality of POD subsystems includes a transport manager container and an Internet Protocol (IP) security tunnel management container.

[0007] The transport manager container is configured to handle network traffic termination for one or more network interfaces, the one or more network interfaces including at least one of a control path interface and a data path interface.

[0008] The IP security tunnel management container is configured to receive an Internet Key Exchange (IKE) day-1 local configuration for each transport manager container in each of the plurality of POD subsystems, and further configured to negotiate IP security (IPsec) policy with a peer node over an ISAKMP protocol according to the received IKE day-1 local configuration.

[0009] The IP security tunnel management container is configured to receive one or more network packets via one or more network interfaces from a peer node, the peer node being communicatively coupled to at least one POD subsystem of the base station's plurality of POD subsystems.

[0010] The IP security tunnel management container is configured to extract one or more IKE parameters from one or more received network packets for a predetermined configured time interval. The one or more IKE parameters are exchanged between a source IKE daemon unit deployed on at least one POD and a target IKE daemon unit deployed on a peer node. The one or more IKE parameters include an IP address of the peer node, one or more encryption algorithms, security policy details, and a peer node certificate identifier.

[0011] The IP Security tunnel management container is configured to authenticate the peer node based on the extracted one or more IKE parameters.

[0012] The IP Security tunnel management container is further configured to configure the source IKE daemon unit based on the extracted one or more IKE parameters in response to successful authentication of the peer node.

[0013] The IP security tunnel management container is further configured to update one or more security data tables in the network kernel with the set of information according to the configuration of the source IKE daemon unit. The set of information includes at least one of information related to an encryption algorithm, one or more secret keys, information related to one or more security policies, and a security parameter index (SPI). The IP security tunnel management container is further configured to generate at least one IP security tunnel between the at least one POD and a peer node based on the one or more security data tables updated in the network kernel. The IP security tunnel management container is further configured to perform one or more secure operations through the generated at least one IP security tunnel. The one or more secure operations include at least one of encryption and decryption of one or more received network packets.

[0014] In one aspect of the embodiment, the IP security tunnel management container is further configured to monitor the at least one created IP security tunnel to determine one or more states of the at least one created IP security tunnel, and the IP security tunnel management container is further configured to automatically repair the at least one created IP security tunnel based on the determined one or more states.

[0015] In another aspect of the embodiment, the IP security tunnel management container is further configured to generate one or more alarm events corresponding to one or more northbound entities based on the determined one or more conditions.

[0016] In another aspect of the embodiment, a transport manager container and an IP security tunnel management container are deployed in the user plane of the base station.

[0017] In yet another aspect of the embodiment, the base station further comprises a first-pass terminating unit configured to register information about a security association database (SAD) and a security policy database (SPD) from a network kernel using a network link socket, wherein the information about the SAD and the SPD is updated by a source IKE daemon unit based on one or more Internet Key Exchange (IKE) messages exchanged with a target IKE daemon unit when at least one IP security tunnel is created.

[0018] In yet another aspect of the embodiment, the IP security tunnel management container is further configured to at least one of enable and disable the created at least one IP security tunnel based on a type of the network interface.

[0019] In one aspect of the embodiment, when authenticating the peer node based on the extracted one or more IKE parameters, the IP security tunnel management container is configured to obtain device certificate information for the peer node from the extracted IKE parameters, and the IP security tunnel management container is further configured to authenticate the peer node based on the obtained device certificate information.

[0020] In yet another aspect of the embodiment, an IP security tunnel management container is configured to interact with one or more peer subsystems deployed across multiple peer nodes to secure network traffic within a communications network.

[0021] In a further aspect of the embodiment, the base station further comprises an aggregation unit control plane (CU-CP), an aggregation unit user plane (CU-UP) communicatively coupled to the CU-CP, and a distribution unit (DU) communicatively coupled to the CU-CP and the CU-UP, each of which comprises a plurality of POD subsystems.

[0022] In one aspect of the embodiment, a method for securing network traffic using Internet Protocol Security (IPSec) tunnels in a communications network is disclosed. The method includes receiving an Internet Key Exchange (IKE) day-1 local configuration for a transport manager container in each of a plurality of Programmable / Open / Disaggregated Solutions (POD) subsystems of a base station. The method further includes negotiating an Internet Security (IPSec) policy between at least one POD of the plurality of POD subsystems and a peer node over an ISAKMP protocol in accordance with the received IKE day-1 local configuration. The method further includes receiving one or more network packets from the peer node via one or more network interfaces. The method further includes extracting one or more Internet Key Exchange (IKE) parameters from the received one or more network packets for a predetermined configured time interval. The one or more IKE parameters include an Internet Protocol (IP) address of the peer node, one or more encryption algorithms, security policy details, and a peer node certificate identifier.

[0023] The method further includes exchanging one or more IKE parameters between a source IKE daemon unit deployed at the base station and a target IKE daemon unit deployed at the peer node. The method also includes authenticating the peer node based on the extracted one or more IKE parameters. The method also includes configuring the source IKE daemon unit based on the extracted one or more IKE parameters in response to successful authentication of the peer node. The method also includes (h) updating one or more security data tables in a network kernel with the set of information in response to the configuration of the source IKE daemon unit. The method also includes generating at least one IP security tunnel between the at least one POD subsystem and the peer node based on the one or more security data tables updated in the network kernel. In addition, the method also includes performing one or more secure operations through the generated at least one IP security tunnel.

[0024] In one aspect of the embodiment, the method further comprises monitoring the at least one created IP security tunnel to determine one or more states of the at least one created IP security tunnel, and automatically restoring the at least one created IP security tunnel based on the determined one or more states.

[0025] In another aspect of the embodiment, the method further comprises generating one or more alarm events corresponding to the one or more northbound entities based on the determined one or more conditions.

[0026] In another aspect of the embodiment, the method further comprises registering information about a security association database (SAD) and a security policy database (SPD) from a network kernel using a network link socket, wherein the information about the SAD and the SPD is updated by the source IKE daemon unit based on one or more Internet Key Exchange (IKE) messages exchanged with the target IKE daemon unit when at least one IP security tunnel is created.

[0027] In another aspect of the embodiment, the method further comprises at least one of enabling and disabling the created at least one IP security tunnel based on a type of the network interface.

[0028] In another aspect of the embodiment, when authenticating the peer node based on the extracted one or more IKE parameters, the method comprises obtaining device certificate information for the peer node from the extracted IKE parameters; and authenticating the peer node based on the obtained device certificate information.

[0029] In another aspect of the embodiment, the method further comprises interacting with one or more peer subsystems deployed across the plurality of peer nodes to secure network traffic within the communication network.

[0030] In another aspect, when executed by a hardware processor, the method includes: (a) receiving an Internet Key Exchange (IKE) day-1 local configuration for a transport manager container in each of a plurality of Programmable / Open / Disaggregated Solutions (POD) subsystems of a base station; (b) negotiating an Internet Security (IPsec) policy between at least one POD of the plurality of POD subsystems and a peer node over an ISAKMP protocol according to the received IKE day-1 local configuration; (c) receiving one or more network packets from the peer node via one or more network interfaces; (d) extracting one or more Internet Key Exchange (IKE) parameters from the received one or more network packets for a predetermined configured time interval; (e) exchanging one or more IKE parameters between a source IKE daemon unit deployed at the base station and a target IKE daemon unit deployed at the peer node; (f) authenticating the peer node based on the extracted one or more IKE parameters; and (g). A non-transitory computer-readable storage medium is disclosed that stores instructions that cause a processor to perform the following operations: (i) configure a source IKE daemon unit based on the extracted one or more IKE parameters in response to successful authentication of the peer node; (ii) update one or more security data tables in a network kernel with a set of information in response to the configuration of the source IKE daemon unit; (iii) generate at least one IP security tunnel between at least one POD subsystem and the peer node based on the updated one or more security data tables in the network kernel; and (iv) perform one or more secure operations through the generated at least one IP security tunnel.

[0031] To further clarify the advantages and features of the present disclosure, a more particular description of the present disclosure will follow by reference to specific embodiments thereof, which are illustrated in the accompanying drawings. It will be understood that these drawings depict only typical embodiments of the present disclosure and are not to be construed as limiting the scope. The present disclosure will be described and explained with additional specificity and detail accompanied by the accompanying drawings. [Brief explanation of the drawings]

[0032] The disclosure will be described and explained with additional specificity and detail in the following accompanying figures.

[0033] FIG. 1 is a schematic representation of a third-generation partnership project (3GPP) interface with plain traffic to a peer node according to the prior art.

[0034] FIG. 2 is a schematic representation of a cloud-native network architecture showing fifth generation (5G) New Radio (NR) with multiple interfaces, according to one embodiment of the present disclosure.

[0035] FIG. 3 is a block diagram illustrating an example base station for securing network traffic using Internet Protocol (IP) security tunnels in a communication network, in accordance with one embodiment of the present disclosure.

[0036] FIG. 4 is a schematic representation of a 3GPP interface with network traffic secured using IP security tunnels between multiple POD subsystems and peer nodes, according to one embodiment of the present disclosure.

[0037] FIG. 5 is a block diagram illustrating a peer-to-peer communication network for creating IP security tunnels and cryptographic operations on application data according to one embodiment of the present disclosure.

[0038] FIG. 6 is a block diagram illustrating the creation of an IP security tunnel for a fastpath application according to one embodiment of the present disclosure.

[0039] FIG. 7 is a flowchart illustrating a computer-implemented method for securing network traffic using IP security tunnels in a communications network, according to one embodiment of the present disclosure.

[0040] Further, those skilled in the art will understand that elements in the figures are illustrated for simplicity and have not necessarily been drawn to scale. Further, for device configurations, one or more components of the device may be represented in the figures by conventional symbols, and the figures may show only specific details that are helpful in understanding embodiments of the present disclosure, so as not to obscure the figures with details that will be apparent to those skilled in the art having the benefit of the description herein. DETAILED DESCRIPTION OF THE INVENTION

[0041] To promote an understanding of the principles of the present disclosure, reference will be made to illustrated embodiments in the figures, and specific language will be used to describe them. Nonetheless, it will be understood that no limitation of the scope of the present disclosure is intended. Such modifications and further variations in the illustrated online platform, and such further applications of the principles of the present disclosure as would normally occur to one skilled in the art, are intended to be within the scope of the present disclosure.

[0042] The terms "comprise," "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process or method comprising a list of steps may include not only those steps but also other steps not expressly listed or inherent in such process or method. Similarly, the term "comprises... a" precedes one or more devices or subsystems or elements or structures or components, and does not exclude the presence of other devices, subsystems, elements, structures, components, additional devices, additional subsystems, additional elements, additional structures, or additional components, unless specifically stated otherwise. The appearance of the phrases "in one embodiment," "in another embodiment," and similar language throughout this specification may, but does not necessarily, refer to the same embodiment.

[0043] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. The systems, methods, and examples provided herein are illustrative only and not intended to be limiting.

[0044] In the description that follows, reference will be made to a number of terms that shall be defined to have the following meanings: The singular forms "a," "an," and "the" include plural references unless the context clearly dictates otherwise.

[0045] A computer system (standalone, client, or server computer system) configured by an application may comprise "modules" (or "subsystems") that are configured and run to perform specific operations. In one embodiment, a "module" or "subsystem" may be implemented mechanically or electronically, such that the module includes dedicated circuitry or logic (such as within a dedicated processor) that is permanently configured to perform specific operations. In other embodiments, a "module" or "subsystem" may comprise programmable logic or circuitry (such as contained within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform specific operations.

[0046] Thus, the term "module" or "subsystem" should be understood to encompass a tangible entity (whether physically / permanently constructed / configured (hardwired) or temporarily configured (programmed) to operate in a particular manner and / or to perform particular operations described herein).

[0047] Wireless node: The term "wireless node" is used to refer to a wireless access node or a wireless device.

[0048] Radio Access Node: The term "radio access node" or "radio network node" refers to any node in a radio access network that operates to transmit and / or receive signals wirelessly. Some examples of radio access nodes include, but are not limited to, base stations (e.g., New Radio (NR) base stations (gNBs) in a 3GPP (Third Generation Partnership Project) fifth-generation (5G) NR network or enhanced or evolved Node Bs (eNBs) in a 3GPP (Long Term Evolution) (LTE) network), high-power or macro base stations, low-power base stations (e.g., micro base stations, pico base stations, Home eNBs, etc.), etc.

[0049] Core network node: The term "core network node" refers to any type of node in a core network.

[0050] Wireless Device: The term "wireless device" refers to any type of device that has access to (i.e., is served by) a cellular communications network by wirelessly transmitting and / or receiving signals to and / or from a wireless access node. Some examples of wireless devices include, but are not limited to, user equipment devices (UEs) and machine-type communications (MTC) devices in 3GPP networks, etc.

[0051] Network Node: The term "network node" refers to any node that is part of the radio access network or core network of a cellular communication network / system.

[0052] The embodiments described herein may be utilized in any wireless communication network, including, but not limited to, wireless fidelity (Wi-Fi), global system for mobile communications (GSM), universal mobile telecommunications system (UMTS), worldwide interoperability for microwave access (WiMAX), enhanced general packet radio service (enhanced GPRS), third generation partnership project (3GPP) long term evolution (LTE), third generation partnership project 2 (3GPP2) ultra-mobile broadband (UMB), high speed packet access (HSPA), Z-Wave, Zigbee, and other 802.XX wireless technologies and / or legacy communication technologies.

[0053] C-RAN (Cloud Radio Access Network) is an architecture for a centralized, cloud-computing-based radio access network (RAN) that enables large-scale deployment, collaborative radio technology support, and real-time virtualization capabilities. C-RAN is an evolution of current wireless communication systems, using the latest Common Public Radio Interface (CPRI) standard, coarse or dense wavelength division multiplexing (CWDM / DWDM) technology, and millimeter wave (MM wave) transmission for long-distance signals. The "C" in C-RAN may alternatively stand for centralized or collaborative. The radio access network (RAN) serves as a bridge connecting cellular devices to public or private clouds. Mobile devices send information over radio waves to the RAN baseband unit, which then forwards the data to a core network for access to the global Internet.

[0054] C-RAN improves wireless networks through improvements in real-time virtualization and cloud computing to provide higher spectral efficiency and faster RAN speeds and support a larger number of mobile devices.

[0055] A cloud-native 5G core network represents a microservices-oriented core network based on containers. Cloud-native 5G core networks decompose software into smaller, more manageable pieces. Service providers are defining and deploying cloud-native infrastructure throughout the network, from the core to the remote edge. As defined by the 3rd Generation Partnership Project (3GPP), a service-based architecture (SBA) is a set of interconnected network functions (NFs) that deliver the control plane functions and common data repository for a cloud-native 5G core network. In other words, a service-based architecture (SBA) provides modular building blocks (both control plane and user plane) modeled as network functions (NFs) that invoke and use each other's services. Supporting SBA brings new requirements for the control, coordination, and orchestration of disaggregated network functions distributed throughout the core network. Network functions are containerized microservices that can support the 5G core, virtualized radio access network (vRAN), and N6-LAN network functions.

[0056] In one embodiment, the EUTRAN network includes multiple eNodeBs, also commonly known as cell sites. The eNodeBs provide radio functionality and perform key control functions, including air link resource scheduling or radio resource management, active mode mobility or handover, and admission control for services. The eNodeBs are responsible for selecting which mobility management entity serves a user equipment (UE) for protocol features such as compression and encryption. The eNodeBs that make up the EUTRAN coordinate with each other for radio resource management and handover.

[0057] Communication between user equipment and eNodeB occurs over an air interface (also known as the "LTE-Uu" interface).

[0058] In one embodiment, the terms "eNodeB" and "eNB" are used interchangeably throughout this specification. Further, the terms "gNodeB" and "gNB" are used interchangeably throughout this specification. Further, the terms "IPSec" and "IP security tunnel" or "IPsec tunnel" are used interchangeably throughout this specification.

[0059] Multiple eNodeBs may be interconnected with each other using an X2 interface. The X2 interface may be established between two eNodeBs to provide for the exchange of signals that may include load- or interference-related information and handover-related information. The eNodeBs communicate with the evolved packet core via an S1 interface. The S1 interface may be split into two interfaces: one for the control plane and the other for the user plane.

[0060] In one embodiment, in accordance with 3GPP specifications, the air interface for LTE and 5G New Radio (NR) is referred to as the "UU interface." The NR air interface is denoted as NR-Uu or NR only. The LTE air interface is correspondingly named LTE-Uu. The UE establishes a connection to an eNodeB, which functions as the master node, and a gNodeB, which functions as the secondary node. The eNodeB is connected to the ePC via an S1 interface and to the en-gNodeB via an X2 interface. The S1 interface is configured by the S1-MME for the control plane, and S1AP is an application layer signaling protocol. The S1-MME, also known as S1-C, is the reference point for control plane protocols between the E-UTRAN and the Mobility Management Entity (MME). The S1-MME uses the SCTP protocol stack for S1AP control plane transport. The SCTP signaling association is automatically set up at eNodeB startup. For each MME, the eNodeB initializes an SCTP association using the OAM configuration initial remote IP endpoint as the starting point until an SCTP connection is established, as described in IETF RFC4960. An eNodeB may be connected to several MMEs over the S1-flex protocol. In an S1-flex configuration, the NAS node selection algorithm selects the appropriate MME based on various possible inputs. In 5G NR, any connection between two eNodeBs, en-gNodeB and eNodeB, is still referred to as the X2 interface. According to TS38.420, the Xn interface describes the interface between two gNodeBs in a standalone (SA) architecture. For this reason, it is not applicable in E-UTRA-NR dual connectivity (EN-DC). Some operators enable the X2 interface to support intra-LTE active mode mobility.For security reasons, the X2 interface needs to be encrypted, which means that an IPsec tunnel is used. Generally, two possible IPsec configurations for the X2 interface are possible. The first is a direct X2 connection from the eNodeB directly to the neighbor eNodeB. In this configuration, the eNodeB needs to support an IPsec tunnel for each neighbor eNodeB. In an indirect X2 connection over an IPsec gateway, the X2 interface traffic is included in the existing IPsec tunnel between the eNodeB and the IPsec gateway. The longer forwarding delay over the X2 interface in this configuration does not have a significant impact.

[0061] Figure 1 illustrates a schematic representation of a third-generation partnership project (3GPP) interface with plane traffic to a peer node according to the prior art. Figure 1 shows a cloud-native random access network (RAN) or gNB microservices architecture 100 terminating in different programmable / open / disaggregated solutions (PODs) 104 of network functions for different 3GPP interfaces (including an F1 interface, an E1 interface, an X2 interface, an N2 interface, an N3 interface, and an S1 interface). In one embodiment, a base station may include an aggregation unit control plane (CU-CP) 106, an aggregation unit user plane (CU-UP) 108 communicatively coupled to the CU-CP 106, and a distributed unit (DU) 110 communicatively coupled to the CU-CP 106 and the CU-UP 108. Each of the CU-CP 106, the CU-UP 108, and the DU 110 includes multiple POD subsystems 104.

[0062] A respective transport manager container 102A-G handles the terminating operations in each of these PODs 104. Although the transport manager containers 102A-G control traffic termination, there is no common service to protect traffic termination for each of the aforementioned gNB 3GPP interfaces.

[0063] With reference to the drawings (more particularly, FIGS. 2-7), in which like reference characters denote corresponding features consistently throughout the drawings, examples are shown and described in the context of the following exemplary systems and / or methods.

[0064] 2 is a schematic representation of a cloud-native network architecture 200 illustrating a fifth-generation (5G) New Radio (NR) with multiple interfaces according to one embodiment of the present disclosure. In a preferred embodiment, the fifth-generation mobile communication system is also referred to herein as a 5G system or a Next Generation (NextGen) system (NG system). The new radio access technology (RAT) for the 5G system is referred to as New Radio (NR), 5G RAT, or NG RAT. The new radio access network (RAN) for the 5G system is referred to as a 5G-RAN or NextGen RAN (NG RAN). The new base station in the 5G-RAN is referred to as an NR NodeB (NR NB) or gNodeB (gNB).

[0065] The new core network for the 5G system is called a 5G core network 208 (5G-CN or 5GC) or NextGen Core (NG Core). A wireless terminal (User Equipment (UE)) that connects to the 5G system is called a 5G UE, NextGen UE (NG UE), or simply UE.

[0066] 5G systems are expected to operate in two modes, including non-standalone and standalone operation modes. For the non-standalone operation mode, 3GPP specifications define extensions to the S1 and X2 interfaces, and for standalone operation, new interfaces are defined. The new interfaces for standalone operation may be at least one of an interface between RAN nodes as X2 / Xn, an interface between RAN and core network as S1 / NG, an interface for function split and open interface as F1 / E1 within a RAN node, an interface between physical (PHY) and radio as eCPRI (enhanced common public radio interface), etc.

[0067] A network node (or radio network node) is used herein to refer to any type of network node that serves a UE and / or is connected to other network nodes, network elements, or other network nodes from which a UE can receive radio signals. A network node may also have multiple antennas for performing various transmission operations (e.g., MIMO operations). A network node may have cabinets and protected enclosures, antenna masts, and actual antennas. Depending on the configuration and type of antennas, a network node may serve several cells, also called sectors.

[0068] Examples of network nodes include, but are not limited to, NodeB devices, base station (BS) devices, access point (AP) devices, radio access network (RAN) devices, etc. The network nodes may comprise multi-standard radio (MSR) radio node devices, including, but not limited to, MSR BS, eNode B, network controller, radio network controller (RNC), base station controller (BSC), relay, donor node controlling relay, base transceiver station (BTS), transmission point, transmitting node, RRU, RRH, node in a distributed antenna system (DAS), etc. In 5G terminology, the network nodes may be referred to as gNodeB devices.

[0069] Interface between RAN nodes as X2 / Xn: The X2 interface used between eNBs in LTE is reused between RAN nodes in non-standalone operation (between eNB and en-gNB), and a new Xn interface is defined between RAN nodes in standalone operation (between ng-eNB and ng-eNB / gNB and gNB / ng-eNB and gNB). The X2 interface extension includes functionality to adopt EN-DC and flow control for split bearers for non-standalone operation. The flow control function defined for LTE-DC split bearers is used for appropriately split downlink data when using the radio resources of multiple RAN nodes. While the basic flow control functions and interface are defined for LTE-DC, the information exchanged between RAN nodes is further improved to optimize flow control for non-standalone operation. The Xn interface is based on the functionality of the X2 interface, but the UE context management function is mainly improved to adopt the new QoS flow framework and network slicing.

[0070] Interface between RAN and core network as S1 / NG: Similar to the interface between RAN nodes, the interface between the RAN node and the 5G core network 208 is also different for non-standalone and standalone operation modes. In non-standalone operation, the S1 interface is reused between the RAN node and the EPC, while a new interface with the name of NG is defined between the RAN node (ng-eNB / gNB) and the 5G core network in standalone operation.

[0071] An extension to the S1 interface includes the ability to report data volumes for a specific RAT in non-standalone operation. This functionality was introduced to calculate the amount of data volume via NR. In non-standalone operation, since the S1-C interface is established only between the master node and the 5G core network 208, data volumes through bearers terminated at the master node are counted by the master node itself and reported directly to the 5G core network 208 via the S1 interface, while data volumes from bearers terminated at secondary nodes are counted by the secondary node and reported to the master node via the X2 interface and by the master node to the core node via the S1 interface.

[0072] Interface for Functional Split and Open Interface as F1 / E1 in RAN Node: To solve the problem of explosive increase in bandwidth required for transport between the aggregation unit (CU) 202 and the distributed unit (DU) 204 due to the introduction of massive MIMO (multi-input multi-output) and the expansion of frequency bandwidth using Cloud RAN (C-RAN) deployment, a new functional split between the CU (gNB-CU) 202 and DU (gNB-DU) 204 in the gNB and a corresponding open interface between these nodes are defined. Specifically, the functional split is adopted where the PDCP layer and above may be located in the gNB-CU 202, and the RLC layer and below may be located in the gNB-DU 204. The standard interface between them is defined as the F1 interface.

[0073] In addition to the functional split between gNB-CU202 and gNB-DU204, a functional split of the control plane (C-plane) and user plane (U-plane) in gNB-CU202 has been introduced.

[0074] In addition, 3GPP standardization defines an open interface between the C-plane termination unit and U-plane termination unit of the gNB-CU202 so that this type of functional division can be realized even between different vendors. The network node that terminates the C-plane 210A of the gNB-CU202 is called the gNB-CU-CP210A, and the network node that terminates the U-plane 212B of the gNB-CU202 is called the gNB-CU-UP212B. The standard interface between these network nodes may be defined as an E1 interface.

[0075] In one embodiment, typically, the gNB network functions (gNB-CUCP, gNB-CUUP, gNB-DU) are implemented as a microservices architecture. In this disclosure, each of the 3GPP interfaces (F1 / E1 / X2 / N2 / N3 / S1) of gNB traffic terminates at a different POD of the network function. There is no common solution or model today for creating and managing IPsec tunnels for these PODs to secure traffic for the aforementioned interfaces.

[0076] A gNB (also referred to throughout this specification as a "base station") for securing network traffic using Internet Protocol Security (IPSec) tunnels is disclosed. The gNB includes multiple POD subsystems 214 capable of securing network traffic using Internet Protocol Security (IPSec) tunnels. The multiple POD subsystems 214 are deployed in a gNB network function, such as a gNB-CUCP 210A-B, a gNB-CUUP 212A-B, or a gNB-DU 204. In one embodiment, each of the 3GPP interfaces (F1 / E1 / X2 / N2 / N3 / S1) of the gNB traffic is terminated at the multiple POD subsystems 214 in the network function.

[0077] The gNB includes one or more hardware processors and memory coupled to the one or more hardware processors. The memory includes multiple Programmable / Open / Disaggregated Solution (POD) subsystems 214 in the form of microservice-based containers executable by the one or more hardware processors. The multiple POD subsystems 214 include a transport manager container configured to handle network traffic termination for one or more network interfaces. The one or more network interfaces include at least one of a control path interface and a data path interface. The multiple POD subsystems 214 further include an Internet Protocol (IP) security tunnel management container communicatively coupled to the transport manager container. The IP security tunnel management container is configured to receive an Internet Key Exchange (IKE) day-1 local configuration for each transport manager container in each of the multiple POD subsystems 214. The IP security tunnel management container is further configured to negotiate IPsec policy with peer nodes over the ISAKMP protocol according to the received IKE day-1 local configuration. The IP security tunnel management container is further configured to receive one or more network packets from peer nodes via the one or more network interfaces. The peer node includes a peer POD subsystem communicatively coupled to at least one POD subsystem 214 of the base station's plurality of POD subsystems 214. The IP security tunnel management container is also configured to extract one or more IKE parameters from one or more received network packets for a predetermined configured time interval. The one or more IKE parameters are exchanged between a source IKE daemon unit deployed in the at least one POD and a target IKE daemon unit deployed in the peer node.The IP security tunnel management container is further configured to authenticate the peer node based on the extracted one or more IKE parameters. The IP security tunnel management container is also configured to configure a source IKE daemon unit based on the extracted one or more IKE parameters in response to successful authentication of the peer node. The IP security tunnel management container is further configured to update one or more security data tables in the network kernel with a set of information in response to the configuration of the source IKE daemon unit. The set of information includes at least one of an encryption algorithm, one or more secret keys, information related to one or more security policies, and information related to a security parameter index (SPI). Additionally, the IP security tunnel management container is configured to generate at least one IP security tunnel between the at least one POD and the peer node based on the one or more security data tables updated in the network kernel. The IP security tunnel management container is further configured to perform one or more secure operations through the generated at least one IP security tunnel. The one or more secure operations include at least one of encrypting and decrypting one or more received network packets. Details of the gNB are shown in FIG. 3.

[0078] The cloud-native network architecture 200 as shown in FIG. 2 may further include cloud interfaces, servers including hardware assets and operating systems (OSs), network interfaces, and application program interfaces (APIs). The cloud interfaces enable communication between the gNBs and UEs. The cloud interfaces also enable communication between other components, such as the gNodeBs and other POD systems, such as the 5G core 208 and peer network nodes. As used herein, "cloud-native network architecture 200" refers to a processing environment with configurable computing physical and logical assets (e.g., networks, servers, storage, applications, services, etc.) and data distributed across a cloud platform. The cloud-native network architecture 200 provides on-demand network access to a shared pool of configurable computing physical and logical assets.

[0079] Those skilled in the art will appreciate that the hardware depicted in Figure 2 may vary depending on the particular implementation. For example, other peripheral devices such as optical disk drives, local area networks (LANs), wide area networks (WANs), wireless (e.g., Wi-Fi) adapters, graphics adapters, disk controllers, and input / output (I / O) adapters may be used in addition to or in place of the hardware depicted. The depicted example is provided for purposes of explanation only and is not intended to imply architectural limitations with respect to the present disclosure.

[0080] Those skilled in the art will recognize that for simplicity and clarity, the complete structure and operation of a base station suitable for use with the present disclosure will not be shown or described herein. Instead, only cloud-native network architecture 200 that is specific to the present disclosure or that is necessary for an understanding of the present disclosure is shown and described. The remainder of the configuration and operation of cloud-native network architecture 200 may conform to any of a variety of current implementations and practices known in the industry.

[0081] 2 depicts a gNodeB and its respective network functions, those skilled in the art will understand that cloud-native network architecture 200 may be applicable to other radio access nodes, including, but not limited to, base stations (e.g., New Radio (NR) base stations (gNB) in a Third Generation Partnership Project (3GPP) fifth-generation (5G) NR network or enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), high-power or macro base stations, low-power base stations (e.g., micro base stations, pico base stations, Home eNB, etc.), 6G, Internet of Things (IoT) narrowband (NB IoT), Open RAN, etc., and combinations thereof. Furthermore, cloud-native network architecture 200 may be applicable to cloud-based non-RAN technology PODs.

[0082] 3 is a block diagram illustrating an exemplary base station 300 for securing network traffic using Internet Protocol (IP) security tunnels in a communication network, according to one embodiment of the present disclosure. The base station 300 (also referred to herein as a gNodeB (gNB)) is configured to secure network traffic (e.g., egress / ingress) over a 3GPP interface using Internet Protocol (IP) security tunnels. In a preferred embodiment, IPsec tunnel creation and management functionality is integrated as a sidecar service with each of multiple POD subsystems.

[0083] The base station 300 includes a hardware processor 314. The base station 300 further includes a memory 302 coupled to the hardware processor 314. The memory 302 includes a plurality of Programmable / Open / Disaggregated Solution (POD) subsystems 214 in the form of microservices-based containers executable by the hardware processor 314. The plurality of POD subsystems 214 include one or more containers deployed on a single network node. The microservices-based containers comprise one or more containerized applications that may be used to facilitate a serverless cloud-native computing deployment and management model for software applications. In support of a serverless cloud-native computing deployment and management model for software applications, such microservices-based containers may be used as part of an event handling mechanism such that various events spin up containerized applications to run as event handlers. The above-described system may be deployed in various manners, including in a manner that supports fifth-generation ("5G") networks.

[0084] Multiple POD subsystems 214 can be useful for managing a group of closely related microservice containers that may depend on each other and need to collaborate on the same host to accomplish their tasks. Multiple POD subsystems 214 can be scheduled together and run on the same physical server or virtual machine. The microservice containers in each of the multiple POD subsystems 214 can have the same IP address and port space and can communicate via localhost or standard interprocess communication.

[0085] As used herein, hardware processor 314 refers to any type of arithmetic circuitry, including, but not limited to, a microprocessor unit, a microcontroller, a complex instruction set computing microprocessor unit, a reduced instruction set computing microprocessor unit, a very long instruction word microprocessor unit, an explicitly parallel instruction computing microprocessor unit, a graphics processing unit, a digital signal processing unit, or any other type of processing circuitry. Processor 314 may also include embedded controllers such as generic or programmable logic devices or arrays, application specific integrated circuits, single chip computers, etc.

[0086] Memory 302 may be non-transitory volatile memory and non-volatile memory. Memory 302, such as a computer-readable storage medium, may be coupled for communication with processor 314. Processor 314 may execute machine-readable instructions and / or source code stored in memory 302. Various machine-readable instructions may be stored in and accessed from memory 302. Memory 302 may include any suitable element for storing data and machine-readable instructions, such as read-only memory, random-access memory, erasable programmable read-only memory, electrically erasable programmable read-only memory, a hard drive, a removable media drive for handling compact discs, digital video discs, diskettes, magnetic tape cartridges, memory cards, etc. In this embodiment, memory 302 includes multiple subsystems stored in the form of machine-readable instructions on any of the aforementioned storage media and may be executed by processor 314 with which it can communicate.

[0087] The memory 302 includes a plurality of POD subsystems 214 stored in the form of executable programs that instruct a hardware processor 314 to perform the method steps described above via a system bus 310. The plurality of POD subsystems 214 include the following microservice-based containers: a transport manager container 304, an internet protocol (IP) security tunnel management container 306, and a fast path terminating unit 308. Each of the transport manager container 304, the internet protocol (IP) security tunnel management container 306, and the fast path terminating unit is a microservice-based container.

[0088] Containerization may include operating system features where a network kernel allows the existence of multiple isolated user-space instances. These instances, called containers, partitions, virtual environments, etc., may operate like real computers from the perspective of programs running in them. A computer program running on a typical operating system can see the computer's resources (connected devices, files and folders, network shares, processing power, quantifiable hardware capabilities, etc.). However, a program running within a container can only see the contents of the container and the devices assigned to the container.

[0089] Containers may represent a form of virtualization at the operating system level. Containers may represent a new VNF option that allows networks to run more VNFs on a single physical host server. Containers may not include their own operating system but may rely more heavily on the host OS. Containers may encapsulate application dependencies, required libraries, and configurations in one package and are isolated from other containers in the same operating system. Furthermore, VNF microservices may be deployed in containers, enabling continuous delivery and deployment of larger, more complex applications.

[0090] Containers may be used alongside virtual machines in an NFV environment. VNF deployments may be solely virtual machines, solely containers, or hybrid. In hybrid mode, containers may run in VMs, providing security and isolation features. Containers may also run in heterogeneous mode, where some VNFs run in VMs, some in containers, or a mix of both. Deploying containers to host microservices may enable active scheduling and management to optimize resource utilization. A container orchestration engine may enable the provisioning of host resources to containers, the assignment of containers to hosts, and the instantiation and rescheduling of containers.

[0091] Containerized microservices may have the ability to orchestrate containers such that a separate lifecycle management process may be applied to each service. This allows each service to be versioned and upgraded independently, rather than upgrading the entire VNF in a VM. For example, during an upgrade of an entire application or VNF, the container scheduler may determine which individual services have changed and deploy only those specific services. The VM may instantiate containers by maintaining state information about the containers and pods, associated IP and MAC information, and node information.

[0092] Computer memory elements may include any suitable memory devices for storing data and executable programs, such as read-only memory, random-access memory, erasable programmable read-only memory, electronically erasable programmable read-only memory, hard drives, removable media drives for handling memory cards, etc. Embodiments of the present subject matter may be implemented in conjunction with program modules, including functions, procedures, data structures, application programs, to perform tasks or define abstract data types or low-level hardware contexts. Executable programs stored on any of the aforementioned storage media may be executable by the hardware processor 314.

[0093] The transport manager container 304 is communicatively coupled to the hardware processor 314. The transport manager container 304 is configured to handle network traffic termination for one or more network interfaces. In one embodiment, the one or more network interfaces include at least one of a control path interface and a data path interface. The control path interface between the 5G core network 208 and the gNB 300 (i.e., the RAN) is referred to as the N2 interface, NG2 interface, or NG-C interface and is used for the transfer of non-access stratum (NAS) information and control information (e.g., N2 AP information elements) between the 5G core network 208 and the gNB 300 (i.e., the RAN). The user / data path interface between the 5G core network 208 and the gNB 300 (i.e., the RAN) is referred to as the N3 interface, NG3 interface, or NG-U interface and includes packets of one or more PDU flows within a UE PDU session. Furthermore, the N3 interface is a user path interface between the 5G core network 208 and the gNB 300 (i.e., the NG-RAN).

[0094] The IP security tunnel management container 306 is communicatively coupled to the hardware processor 314. The IP security tunnel management container 306 is configured to receive an Internet Key Exchange (IKE) day-1 local configuration for each transport manager container 304 in each of the plurality of POD subsystems 214. The IP security tunnel management container 306 is further configured to negotiate IP security (IPsec) policy with a peer node over the Internet Security Association and Key Management Protocol (ISAKMP) in accordance with the received IKE day-1 local configuration. The IP security tunnel management container 306 is further configured to receive one or more network packets from a peer node via one or more network interfaces. In one embodiment, a peer node is communicatively coupled to at least one POD subsystem of the plurality of POD subsystems 214 of the base station 300. In an exemplary embodiment, the peer node may be another random access network. In other exemplary embodiments, the peer node may be another POD subsystem itself.

[0095] The IP security tunnel management container 306 is further configured to extract one or more Internet Key Exchange (IKE) parameters from the received network packet(s) for a predetermined configuration time interval. The predetermined configuration time interval may be a day-1 configuration. In one embodiment, the one or more IKE parameters are exchanged between a source IKE daemon unit deployed on at least one POD and a target IKE daemon unit deployed on a peer node. In one embodiment, the one or more IKE parameters include at least one of an IP address of the peer node, one or more encryption algorithms, security policy details, a peer node certificate identifier, etc. Upon extracting the one or more IKE parameters, the IP security tunnel management container 306 is further configured to download or update an X.509 device certificate required for end-entity authentication as part of the IPsec tunnel creation procedure. In one embodiment, an X.509 certificate is a widely used digital certificate format based on asymmetric cryptography. Each certificate uses a pair of encryption keys known as a public and private key. The private key on the certificate may generate encryption that can only be decrypted by its public key partner.

[0096] The IP security tunnel management container 306 is further configured to authenticate the peer node based on the extracted one or more IKE parameters. The IP security tunnel management container 306 is also configured to authenticate the peer node based on the extracted one or more IKE parameters by (a) obtaining the peer node's device certificate information from the extracted IKE parameters, and (b) authenticating the peer node based on the obtained device certificate information. In one embodiment, to authenticate the peer node, the IP security tunnel management container 306 is further configured to update a security association database (SAD) and a security policy database (SPD) tables in the network kernel with corresponding encryption / authentication algorithms, secret keys, policies, SPI details, etc. The SAD / SPD information is required to encrypt / decrypt application data.

[0097] Additionally, the IP security tunnel management container 306 is configured to configure the source IKE daemon unit based on the extracted one or more IKE parameters in response to successful authentication of the peer node.

[0098] The IP security tunnel management container 306 is also configured to update one or more security data tables in the network kernel with the set of information according to the configuration of the source IKE daemon unit. In one embodiment, the set of information includes at least one of an encryption algorithm, one or more secret keys, information related to one or more security policies, information related to a security parameter index (SPI), etc. The IP security tunnel management container 306 is further configured to generate at least one IP security tunnel between the at least one POD and a peer node based on the one or more security data tables updated in the network kernel. In one embodiment, the at least one IP security tunnel is generated in accordance with RFC 7296 (i.e., Internet Key Exchange Protocol Version 2 (IKEv2)). In one embodiment, the purpose of Internet Key Exchange (IKE) is to independently generate the same symmetric key for network nodes. This key encrypts and decrypts standard IP packets passing through the IPSec tunnel. A security association (SA) is the result of the IKE negotiation.

[0099] IKE and IPsec tunnels work together. IKE helps establish security associations (SAs) for the Encapsulated Security Protocol (ESP) or Authentication Header (AH), which are part of the IPsec protocol. IKE is a network security protocol designed to dynamically exchange cryptographic keys and create security associations (SAs) between a UE and an evolved packet data gateway (ePDG). These security associations or SAs may be established dynamically and may be removed at negotiated intervals.

[0100] Conceptually, non-3GPP access can be divided into wireless versus wired (also known as "fixed"), or into "trusted" versus "untrusted." For untrusted non-3GPP access 300, Internet Key Exchange (IKE) and Internet Protocol Security (IPsec) are used between the UE and the ePDG non-3GPP Interworking Function (N3IWF) to establish a secure connection. For 5G untrusted non-3GPP access, Non-Access Stratum (NAS) signaling is introduced to support 5G registration and protocol data unit (PDU) session setup. Between the UE and the N3IWF, NAS signaling messages are transported through IKE message exchanges during IKE security association (SA) establishment and through an IPsec tunnel after the initial IPsec SA establishment. IKE itself does not interpret 5G NAS signaling, but is responsible for the user plane setup (IPsec tunnel establishment) between the UE and the N3IWF for the PDU session.

[0101] The IP security tunnel management container 306 is further configured to perform one or more secure operations over the created at least one IP security tunnel. The one or more secure operations include at least one of encrypting and decrypting one or more received network packets. The IP security tunnel management container 306 is further configured to interact with one or more peer subsystems deployed across multiple peer nodes to secure network traffic within the communication network.

[0102] The IP security tunnel management container 306 is further configured to monitor the at least one generated IP security tunnel to determine one or more states of the at least one generated IP security tunnel, and to self-heal the at least one generated IP security tunnel based on the determined one or more states. In one embodiment, the IP security tunnel management container 306 monitors and self-heals the IPsec tunnel state by determining whether the IPsec tunnel state goes down / up due to a network problem or a peer node problem.

[0103] The IP security tunnel management container 306 is further configured to generate one or more alarm events (e.g., EMS) corresponding to the one or more northbound entities based on the determined one or more conditions. In one embodiment, the IP security tunnel management container 306 is further configured to at least one of enable and disable the created at least one IP security tunnel based on the type of the network interface.

[0104] In one embodiment, a transport manager container 304 and an IP security tunnel management container 306 are deployed in the user plane of base station 300 .

[0105] The first path terminating unit 308 is configured to register information about a security association database (SAD) and a security policy database (SPD) from a network kernel using a network link socket. Information about the SAD and SPD is updated by the source IKE daemon unit based on one or more Internet Key Exchange (IKE) messages exchanged with the target IKE daemon unit when at least one IP security tunnel is created. In one embodiment, the first path terminating unit 308 reads the SAD / SPD database information from the network kernel through a network link socket, such as a NETLINK socket. The SAD / SPD database information in the network kernel is updated by the IKE daemon unit based on IKE messages exchanged with the target IKE daemon unit when an IPsec tunnel is created. The target IKE daemon unit may reside in a peer node.

[0106] In one embodiment, the base station 300 may include an aggregation unit control plane (CU-CP) 202A, an aggregation unit user plane (CU-UP) 202B communicatively coupled to the CU-CP 202A, and a distributed unit (DU) 204 communicatively coupled to the CU-CP 202A and the CU-UP 202B. Each of the CU-CP 202A, CU-UP 202B, and DU 204 includes multiple POD subsystems 214.

[0107] The database 312 stores information about the base station 300, user equipment, the POD subsystems 214, etc. The database 312 is, for example, a structured query language (SQL) data store. The database 312 is configured as a cloud-based database implemented in the base station 300, where computing assets are delivered as services on a cloud platform. According to another embodiment of the present disclosure, the database 312 is a file system location directly accessible by the POD subsystems 214. The database 312 is configured to store packet information, IKE parameters, IPSec tunnel state, IPSec local configuration information, encryption algorithms, one or more private keys, information related to one or more security policies, information about security parameter indexes (SPIs), security data tables, etc. The database 312 may be a cloud database, an edge database, etc.

[0108] Those skilled in the art will appreciate that the hardware depicted in Figure 3 may vary depending on the particular implementation. For example, other peripheral devices such as optical disk drives, local area networks (LANs), wide area networks (WANs), wireless (e.g., Wi-Fi) adapters, graphics adapters, disk controllers, and input / output (I / O) adapters may be used in addition to or in place of the hardware depicted. The depicted example is provided for purposes of explanation only and is not intended to imply architectural limitations with respect to the present disclosure.

[0109] Those skilled in the art will recognize that, for simplicity and clarity, the complete structure and operation of a base station system suitable for use with the present disclosure will not be shown or described herein. Instead, only the base station 300 specific to the present disclosure or that is necessary for an understanding of the present disclosure is shown and described. The remainder of the configuration and operation of the base station 300 may conform to any of various current implementations and practices known in the art.

[0110] FIG. 4 is a schematic representation of a 3GPP interface with network traffic secured using IP security tunnels (IPsec tunnels) 404 between multiple POD subsystems 214 and a peer node 402, according to one embodiment of the present disclosure. IP security tunnel creation and management functionality is integrated with each of the multiple POD subsystems 214 as a sidecar service (i.e., IP security tunnel management container 306) for securing egress and ingress traffic for the 3GPP interface with IP security, as shown in FIG. 4. The IP security tunnel management container 306 is an integrated sidecar service designed to create and manage IPsec tunnels across all NFs for the gNB 3GPP interface (F1, E1, X2, N2, N3, S1). The creation of at least one IPsec tunnel 404 between at least one POD subsystem of the multiple POD subsystems 214 and a peer node 402 was described in FIG. 3. The IP security tunnel management container 306 may be deployed for control plane interfaces (F1c, E1, X2c, XNc, N2) that terminate in the kernel and / or data plane interfaces (F1u, X2u, XNu, N3, S1u) that terminate in first-path applications in user space (e.g., VPP). The IP security tunnel management container 306 may be extended for eNB 3GPP interfaces such as S1c, S1u, X2c, X2u, and Mid Haul (MH). Furthermore, the IP security tunnel management container 306 may control the IPsec enable / disable feature for specific interfaces within multiple POD subsystems 214. The IP security tunnel management container 306 may be extended for dynamic scaling out or in of PODs that require traffic to be protected by IPsec.Furthermore, the IP security tunnel management container 306 provides a unified method for retrieving IKE parameters to create and manage tunnels across all POD subsystems 214. Furthermore, the IP security tunnel management container 306 provides a unified method for monitoring and automatically repairing IPsec tunnels when they go down due to network issues or peer node restarts. The IP security tunnel management container 306 also provides a unified method for raising alarms / notifications to northbound entities (such as EMS) when tunnels go down or up. Furthermore, the IP security tunnel management container 306 may be extended for other / newer PODs in the RAN that require traffic to be secured with IPsec. In addition, the IP security tunnel management container 306 may be used for cloud-based non-RAN technology PODs whose traffic needs to be secured.

[0111] In FIG. 4, the gNB-CU-CP 210, the gNB-CU-UP 212, and the gNB-DU 204 each include multiple POD subsystems 214 as microservice containers. Each of the multiple POD subsystems 214 includes a transport manager container 304 and an IP security tunnel management container 306. Each of the multiple POD subsystems 214 is further connected to the peer node 402 via an IPsec tunnel 404. The IP security tunnel management container 306 in each of the POD subsystems 214 can protect network traffic. The gNB-CU-UP 212 additionally includes a container user plane app (userplaneapp) 112 (F1 / x2 / xn / s1 / n3). The gNB-DU 204 further includes a container L2 user plane app (F1u) 114.

[0112] FIG. 5 is a block diagram 500 illustrating a peer-to-peer communication network for creating an IPsec tunnel 404 and performing cryptographic operations on application data, according to one embodiment of the present disclosure. In FIG. 5, each POD subsystem 214 includes a transport manager container 304 and an IP security tunnel management container 306, as previously described. In addition, the POD subsystem 214 includes an IP stack 508 and an Ethernet developer unit 510. Each POD subsystem 214 includes a user space and a kernel space. The transport manager container 304 and the IP security tunnel management container 306 are deployed in the user plane. The IP security tunnel management container 306 includes a source IKE daemon unit 504. One or more IKE parameters are exchanged between the source IKE daemon unit 504 deployed at the base station 300 and the target IKE daemon unit 506 deployed at the peer node 402. The source IKE daemon unit 504 is configured based on the extracted one or more IKE parameters in response to successful authentication of the peer node 402.

[0113] The IP stack 508 acts as a database for storing SAD or SPD details such as encryption / authentication algorithms, keys and policies, SPIs, etc. The transport manager container 304 retrieves application plane data from the IP stack 508. Furthermore, the IP security tunnel management container 306 updates the SAD / SPD details in the IP stack 508 via NETLINK. Furthermore, the IP stack 508 is responsible for sending application encryption data to the peer node 402.

[0114] Peer node 402 comprises a target IKE daemon unit 506 configured to exchange IKE messages with source IKE daemon unit 504. Peer node 402 also comprises an Ethernet developer unit 510B. In one embodiment, peer node 402 may be another gNB or other POD subsystem or any other device.

[0115] FIG. 6 is a block diagram 600 illustrating the creation of an IP security tunnel 404 for a fast-path application, according to one embodiment of the present disclosure. FIG. 6 illustrates the use of the IP security tunnel management container 306 with data / fast-path terminating applications, including virtual pocket processing (VPP) / open data plane (ODP), to secure user plane traffic for interfaces including at least one of an F1U interface, an N3 interface, an X2U interface, an XNU interface, an S1U interface, etc. A fast-path application represents a process in which network packets are processed at very high rates or near the line rate of an Ethernet interface. The transport manager container 304 and the IP security tunnel management container 306 are deployed in the user plane of the base station 300.

[0116] 6 illustrates an IP security tunnel management container 306 exchanging one or more IKE parameters between a source IKE daemon unit 504 deployed on at least one POD 214 and a target IKE daemon unit 506 deployed on a peer node 402. The IP security tunnel management container 306 updates one or more security data tables (i.e., Security Association Database (SAD) / Security Policy Database (SPD) tables) in the network kernel with a set of information depending on the configuration of the source IKE daemon unit 504. The set of information includes at least one of an encryption algorithm, one or more secret keys, information related to one or more security policies, information about a security parameter index (SPI), etc.

[0117] The first path terminating unit 308 is configured to register information about the security association database (SAD) and security policy database (SPD) from the network kernel using a network link socket. The information about the SAD and SPD is updated by the source IKE daemon unit 504 based on one or more Internet Key Exchange (IKE) messages exchanged with the target IKE daemon unit 506 when at least one IP security tunnel 404 is created. In one embodiment, the first path terminating unit 308 reads the SAD / SPD database information from the network kernel through a network link socket, such as a NETLINK socket. The SAD / SPD database information in the network kernel is updated by the IKE daemon unit based on IKE messages exchanged with the target IKE daemon unit 506 when the IPsec tunnel 404 is created. The target IKE daemon unit 506 may reside in the peer node 402.

[0118] In one embodiment, in the above Fast Path application, the functionality of the IP security tunnel management container 306 is not modified to support the cryptographic operations to be performed by the Fast Path terminating unit 308. The only change required is to modify the Fast Path terminating unit 308 to register and retrieve SAD and SPD information from the network kernel.

[0119] In one embodiment, the IP security tunnel management container 306 may be used in conjunction with a data / fast-path terminating application (such as VPP / ODP) to secure user plane traffic on the F1U, N3, X2U, XNU, and S1U interfaces. The fast-path application is expected to process network packets at very high rates, or even at rates close to the line rate of the Ethernet interface. As shown in FIG. 6, when IKE messages are exchanged by the IKE daemon unit to create the IPsec tunnel 404, the following information, primarily in the network kernel SAD / SPD table, is updated by the source IKE daemon unit 504 through the NETLINK socket (step 2): the encryption algorithm, the authentication algorithm, the secret key for encrypting / decrypting network packets, the SPI (Security Parameter Index), etc. The same SAD and SPD information as above needs to be read by the fast-path terminating application (such as VPP / ODP) through the NETLINK socket. This information is then used to encrypt and decrypt network packets to and from the application (such as the NR user plane).

[0120] 7 is a flowchart illustrating a computer-implemented method 700 for securing network traffic in a communications network using IP security tunnels 404, according to one embodiment of the present disclosure. In step 702, an Internet Key Exchange (IKE) day-1 local configuration for a transport manager container 304 is received at each of a plurality of Programmable / Open / Disaggregated Solutions (POD) subsystems 214 of a base station 300.

[0121] In step 704, an IP security (IPsec) policy is negotiated between at least one POD of the plurality of POD subsystems 214 and the peer node 402 over the ISAKMP protocol according to the received IKE day-1 local configuration.

[0122] In step 706, one or more network packets are received via one or more network interfaces from a peer node 402. In one embodiment, the peer node 402 is communicatively coupled to at least one POD subsystem of the plurality of POD subsystems 214 of the base station 300.

[0123] In step 708, one or more Internet Key Exchange (IKE) parameters are extracted from one or more received network packets for a predetermined configured time interval. One or more IKE parameters are exchanged between a source IKE daemon unit 504 deployed at the base station 300 and a target IKE daemon unit 506 deployed at the peer node 402.

[0124] In step 710, the peer node is authenticated based on the extracted one or more IKE parameters.

[0125] In step 712, in response to successfully authenticating the peer node 402, the source IKE daemon unit 504 is configured based on the extracted IKE parameter(s).

[0126] In step 714, one or more security data tables in the network kernel are updated with a set of information depending on the configuration of the source IKE daemon unit 504. The set of information includes at least one of an encryption algorithm, one or more secret keys, information related to one or more security policies, information about a security parameter index (SPI), etc.

[0127] In step 716, at least one IP security tunnel 404 is created between at least one POD subsystem 214 and the peer node 402 based on one or more security data tables updated in the network kernel.

[0128] In step 718, one or more secure operations are performed through the created at least one IP security tunnel 404. The one or more secure operations include at least one of encrypting and decrypting the received network packet or packets.

[0129] In one embodiment, the at least one IP security tunnel 404 is monitored to determine one or more conditions of the created at least one IP security tunnel 404. The created at least one IP security tunnel 404 is automatically repaired based on the determined one or more conditions. Further, one or more alarm events corresponding to one or more northbound entities are generated based on the determined one or more conditions. In one embodiment, the peer node 402 is authenticated based on the extracted one or more IKE parameters by obtaining device certificate information for the peer node 402 from the extracted IKE parameters and authenticating the peer node 402 based on the obtained device certificate information.

[0130] The present disclosure provides an IP security tunnel management container 306 that is used as a common service to secure traffic for each of the gNB 3GPP interfaces (i.e., the F1, E1, X2, N2, N3, and S1 interfaces). The IP security tunnel management container 306 functions as a plug-and-play module that allows for easy solution integration and short development time. Furthermore, the present disclosure allows for easy extension of the solution to IP secure traffic for additional POD subsystems 214 in different RANs than the above interfaces, such as F1, E1, X2, N2, N3, and S1. The present disclosure allows for easy maintenance of the POD subsystem 214 without requiring redundant code.

[0131] The present disclosure utilizes the same IP security tunnel management container 306 for control path and data / fast path interfaces in the same / different POD subsystems 214, where the control path interface is typically terminated in the kernel and the data / fast path interface is typically terminated in user space by a fast path application such as VPP. The present disclosure is a generic solution that may be used for cloud-based, non-RAN technology PODs to secure their traffic. Furthermore, the present disclosure reduces overall development time. The present disclosure utilizes the IP security tunnel management container 306 to monitor and automatically repair the created IPsec tunnels 404 when they go up and down due to network issues and peer node 402 reboots.

[0132] The written description describes the subject matter herein so that one skilled in the art can make and use the embodiments. The scope of the subject matter embodiments is defined by the claims, and may include other modifications that occur to those skilled in the art. Such other modifications are intended to be within the scope of the claims whether they have similar elements that do not differ from the claim language or whether they include equivalent elements that have insubstantial differences from the claim language.

[0133] Embodiments herein may comprise both hardware and software elements. Embodiments implemented in software include, but are not limited to, firmware, resident software, microcode, etc. The functions performed by various modules described herein may also be implemented in other modules or combinations of modules. For purposes of this description, a computer-usable or computer-readable medium may be any apparatus that contains, stores, communicates, transmits, or transfers a program for use by or in connection with an instruction execution system, apparatus, or device.

[0134] The medium may be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device), or a transmission medium. Examples of a computer-readable medium include a semiconductor or solid-state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk, and an optical disk. Current examples of optical disks include compact disk, read-only memory (CD-ROM), compact disk, read / write (CD-R / W), and DVD.

[0135] Input / output (I / O) devices (including but not limited to keyboards, displays, pointing devices, etc.) may be coupled to the system either directly or through intervening I / O controllers. Network adapters may be coupled to the system to enable the data processing system to be coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modems, and Ethernet cards are just a few examples of currently available types of network adapters.

[0136] A typical hardware environment for implementing embodiments may include a hardware configuration of an information handling / computer system according to embodiments herein. The system herein comprises at least one processor or central processing unit (CPU). The CPU is interconnected to various devices, such as random access memory (RAM), read-only memory (ROM), and input / output (I / O) adapters via a system bus 310. The I / O adapters may also connect to peripheral devices, such as disk units and tape drives, or other program storage devices readable by the system. The system may read inventive instructions on the program storage devices and follow these instructions to perform methods according to embodiments herein.

[0137] The system further includes a user interface adapter that connects other user interface devices, such as a keyboard, mouse, speaker, microphone, and / or touch screen device (not shown), to the bus for gathering user input. Additionally, a communications adapter connects the bus to a data processing network, and a display adapter connects the bus to a display device, which may be embodied as an output device, such as a monitor, printer, transmitter, etc.

[0138] The description of an embodiment having several components capable of communicating with each other does not imply that all such components are required. To the contrary, various optional components are described to illustrate the broad range of possible embodiments of the present invention. When a single device or article is described herein, it is apparent that multiple devices / articles (whether cooperating or not) may be used in place of the single device / article. Similarly, when multiple devices or articles (whether cooperating or not) are described herein, it is apparent that the single device / article may be used in place of the multiple devices or articles, or that a different number of devices / articles may be used in place of the number of devices or programs shown. The functionality and / or features of a device may instead be embodied by one or more other devices not explicitly described as having such functionality / features. Thus, other embodiments of the present invention may not include a device per se.

[0139] The illustrated steps are presented to explain the exemplary embodiments shown, and ongoing technological developments are expected to change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration and not limitation. Moreover, the boundaries of functional building blocks are arbitrarily defined herein for simplicity of description. Alternative boundaries may be defined so long as the defined functions and relationships are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to those skilled in the art based on the teachings contained herein. Such alternatives are encompassed within the scope and spirit of the disclosed embodiments. Furthermore, the terms "comprising," "having," "containing," "including," and other similar forms are intended to have equivalent meanings and are open-ended in that the use of items following any one of these terms does not imply an exhaustive listing of such items or that items are limited to only the listed items. It should be noted that as used herein and in the appended claims, the singular forms "a," "an," and "the" include plural references unless the context clearly dictates otherwise.

[0140] Finally, the language used herein has been chosen primarily for readability and instructional purposes, and not to delineate the contours or boundaries of the inventive subject matter. Accordingly, the scope of the invention is intended not to be limited by this detailed description, but rather by the claims issued based on this application. Accordingly, the embodiments of the invention are intended to be illustrative, and not limiting, of the scope of the invention, which is set forth in the following claims.

Claims

1. 1. A base station for securing network traffic using an Internet Protocol Security (IPSec) tunnel in a communications network, comprising: one or more hardware processors; a memory coupled to the one or more hardware processors and comprising a plurality of Programmable / Open / Disaggregated Solution (POD) subsystems in the form of microservices-based containers executable by the one or more hardware processors; Equipped with Each of the plurality of POD subsystems comprises: a transport manager container configured to handle network traffic termination for one or more network interfaces comprising at least one of a control path interface and a data path interface; an Internet Protocol (IP) security tunnel management container communicatively coupled to the transport manager container, receiving an Internet Key Exchange (IKE) day-1 local configuration for each transport manager container in each of the plurality of POD subsystems; negotiating IPsec policy with the peer node over ISAKMP protocol according to the received IKE day-1 local configuration; receiving one or more network packets from the peer node communicatively coupled to at least one POD subsystem of the plurality of POD subsystems of the base station via the one or more network interfaces; extracting from the one or more received network packets one or more IKE parameters exchanged between a source IKE daemon unit deployed on the at least one POD and a target IKE daemon unit deployed on the peer node for a predetermined configured time interval; authenticating the peer node based on the extracted one or more IKE parameters; configuring the source IKE daemon unit based on the extracted one or more IKE parameters in response to successful authentication of the peer node; updating one or more security data tables in a network kernel with a set of information comprising at least one of an encryption algorithm, one or more secret keys, information relating to one or more security policies, and information about a security parameter index (SPI) in response to a configuration of the source IKE daemon unit; generating at least one IP security tunnel between the at least one POD and the peer node based on the one or more security data tables updated in the network kernel; performing one or more secure operations comprising at least one of encrypting and decrypting the one or more network packets received through the at least one created IP security tunnel; an IP Security tunnel management container configured to execute A base station comprising:

2. The IP security tunnel management container comprises: monitoring the at least one created IP security tunnel to determine one or more states of the at least one created IP security tunnel; automatically restoring the at least one created IP security tunnel based on the determined one or more conditions; The base station of claim 1 further configured to perform:

3. 3. The base station of claim 2, wherein the IP security tunnel management container is further configured to generate one or more alarm events corresponding to one or more northbound entities based on the determined one or more conditions.

4. The base station of claim 1 , wherein the transport manager container and the IP security tunnel management container are deployed in a user plane of the base station.

5. The base station of claim 1 , wherein the one or more IKE parameters comprise an IP address of the peer node, one or more encryption algorithms, security policy details, and a peer node certificate identifier.

6. a first-pass terminating unit configured to register information about a security association database (SAD) and a security policy database (SPD) from the network kernel using a network link socket; the information about the SAD and SPD is updated by the source IKE daemon unit based on one or more Internet Key Exchange (IKE) messages exchanged with the target IKE daemon unit when the at least one IP security tunnel is created; The base station according to claim 4.

7. The base station of claim 1 , wherein the IP security tunnel management container is further configured to perform at least one of enabling and disabling the created at least one IP security tunnel based on a type of network interface.

8. When authenticating the peer node based on the extracted one or more IKE parameters, the IP Security tunnel management container: obtaining device certificate information of the peer node from the extracted IKE parameters; authenticating the peer node based on the obtained device certificate information; The base station of claim 1 configured to perform the following:

9. 10. The base station of claim 1, wherein the IP security tunnel management container is configured to interact with one or more peer subsystems deployed across multiple peer nodes to secure the network traffic within the communication network.

10. an aggregation unit control plane (CU-CP); an aggregation unit user plane (CU-UP) communicatively coupled to the CU-CP; a distributed unit (DU) communicatively coupled to the CU-CP and the CU-UP; Further provided with Each of the CU-CP, the CU-UP, and the DU comprises the plurality of POD subsystems. The base station of claim 1 .

11. 1. A method for securing network traffic using an Internet Protocol Security (IPSec) tunnel in a communications network, comprising: receiving, by a processor, an Internet Key Exchange (IKE) day-1 local configuration for a transport manager container in each of a plurality of Programmable / Open / Disaggregated Solutions (POD) subsystems of the base station; Negotiating, by the processor, an Internet Security Association Key Management Protocol (ISAKMP) policy between at least one POD and a peer node of the plurality of POD subsystems according to the received IKE day-1 local configuration; receiving, by the processor, one or more network packets from the peer node communicatively coupled to at least one POD subsystem of the plurality of POD subsystems of the base station via one or more network interfaces; extracting, by the processor, from the one or more received network packets, one or more Internet Key Exchange (IKE) parameters exchanged between a source IKE daemon unit deployed at the base station and a target IKE daemon unit deployed at the peer node for a predetermined configuration time interval; authenticating, by the processor, the peer node based on the extracted one or more IKE parameters; configuring, by the processor, the source IKE daemon unit based on the extracted one or more IKE parameters in response to successful authentication of the peer node; updating, by the processor, one or more security data tables in a network kernel with a set of information comprising at least one of a cryptographic algorithm, one or more secret keys, information relating to one or more security policies, and a security parameter index (SPI) in response to a configuration of the source IKE daemon unit; generating, by the processor, at least one IP security tunnel between the at least one POD subsystem and the peer node based on the one or more security data tables updated in the network kernel; performing, by the processor, one or more secure operations comprising at least one of encrypting and decrypting the one or more network packets received through the at least one created IP security tunnel; A method for providing the above.

12. monitoring the at least one created IP security tunnel to determine one or more states of the at least one created IP security tunnel; automatically restoring the at least one created IP security tunnel based on the determined one or more conditions; The method of claim 11 further comprising:

13. The method of claim 12 , further comprising generating one or more alarm events corresponding to one or more northbound entities based on the determined one or more conditions.

14. The method of claim 11 , wherein the one or more IKE parameters comprise an Internet Protocol (IP) address of the peer node, one or more encryption algorithms, security policy details, and a peer node certificate identifier.

15. registering information about a security association database (SAD) and a security policy database (SPD) from the network kernel using a network link socket; the information about the SAD and SPD is updated by the source IKE daemon unit based on one or more Internet Key Exchange (IKE) messages exchanged with the target IKE daemon unit when the at least one IP security tunnel is created; The method of claim 11.

16. The method of claim 11 , further comprising at least one of enabling and disabling the created at least one IP security tunnel based on a type of network interface.

17. authenticating the peer node based on the extracted one or more IKE parameters; obtaining device certificate information of the peer node from the extracted IKE parameters; authenticating the peer node based on the obtained device certificate information; The method of claim 11 , comprising:

18. 12. The method of claim 11, further comprising interacting with one or more peer subsystems deployed across a plurality of peer nodes to secure the network traffic within the communications network.

19. When executed by a hardware processor, receiving an Internet Key Exchange (IKE) day-1 local configuration for a transport manager container in each of a plurality of Programmable / Open / Disaggregated Solutions (POD) subsystems of the base station; Negotiating an Internet Security (IPsec) policy between at least one POD and a peer node of the plurality of POD subsystems over an ISAKMP protocol according to the received IKE day-1 local configuration; receiving one or more network packets from the peer node communicatively coupled to at least one POD subsystem of the plurality of POD subsystems of the base station via one or more network interfaces; extracting from the one or more received network packets one or more Internet Key Exchange (IKE) parameters exchanged between a source IKE daemon unit deployed at the base station and a target IKE daemon unit deployed at the peer node for a predetermined configured time interval; authenticating the peer node based on the extracted one or more IKE parameters; configuring the source IKE daemon unit based on the extracted one or more IKE parameters in response to successful authentication of the peer node; updating one or more security data tables in a network kernel with a set of information comprising at least one of an encryption algorithm, one or more secret keys, information relating to one or more security policies, and information about a security parameter index (SPI) in response to a configuration of the source IKE daemon unit; generating at least one IP security tunnel between the at least one POD subsystem and the peer node based on the one or more security data tables updated in the network kernel; performing one or more secure operations comprising at least one of encrypting and decrypting the one or more network packets received through the at least one created IP security tunnel; A non-transitory computer-readable storage medium storing instructions that cause the processor to perform the operations of

20. monitoring the at least one created IP security tunnel to determine one or more states of the at least one created IP security tunnel; automatically restoring the at least one created IP security tunnel based on the determined one or more conditions; 20. The non-transitory computer-readable storage medium of claim 19, further comprising instructions for causing the processor to execute:

Images