Abnormal traffic processing method, device and equipment, micro-isolation system and readable storage medium

Abstract

The embodiment of the invention provides an abnormal traffic processing method, device and equipment, a micro-isolation system and a readable storage medium, and the method comprises the steps that first equipment obtains traffic information extracted by an XDP mounting point, and determines abnormal traffic information according to the traffic information, and executing at least one of the following items according to the abnormal traffic information: generating a first security policy for abnormal traffic detection, updating the first security policy, generating a security event, generating a security threat view, and updating the security threat view.

Description

Technical Field

[0001] This application relates to the field of communication technology, specifically to an abnormal traffic processing method, apparatus, device, micro-isolation system, and readable storage medium. Background Technology

[0002] Existing micro-segmentation mechanisms are primarily based on the extended Berkeley Packet Filter (eBPF). This mechanism, by mounting an eBPF program on the operating system of a network element virtual machine or container, enables the collection, reporting, and enforcement of network element traffic information and security policies. However, current micro-segmentation based on network element eBPF can only monitor network element management plane traffic, resulting in the inability to effectively monitor all east-west traffic within the resource pool. This limitation makes potential threats in the network easily overlooked, reducing overall security protection capabilities. Summary of the Invention

[0003] This application provides an abnormal traffic processing method, apparatus, device, micro-isolation system, and readable storage medium to solve the problem of how to securely monitor all east-west traffic within a resource pool.

[0004] In a first aspect, an abnormal traffic handling method is provided, applied to a first device, comprising:

[0005] Obtain traffic information extracted from the XDP mount point, and determine abnormal traffic information based on the traffic information;

[0006] Based on the abnormal traffic information, perform at least one of the following: generate a first security policy for abnormal traffic detection, update the first security policy, generate a security event, generate a security threat view, and update the security threat view.

[0007] Optionally, after performing at least one of the following based on the abnormal traffic information: generating a first security policy for abnormal traffic detection, updating the first security policy (i.e., after generating the first security policy or updating the first security policy), the method further includes:

[0008] The first security policy is sent to the controller, so that the controller converts the first security policy into a first flow table. The first flow table is used by the open-source virtual switch OVS forwarding plane to mirror traffic outside the whitelist to the XDP mount point while forwarding it normally.

[0009] Optionally, before obtaining the traffic information extracted from the XDP mount point and determining abnormal traffic information based on the traffic information, the method further includes:

[0010] A second security policy for detecting abnormal traffic is generated based on traffic access relationships. The second security policy is used to instruct the OVS forwarding plane to mirror all traffic to the XDP mount point.

[0011] The second security policy is sent to the controller, which then converts the second security policy into a second flow table. The second flow table is used by the open-source virtual switch OVS forwarding plane to mirror traffic to the XDP mount point while processing traffic normally.

[0012] Optionally, the traffic access relationship is determined based on a traffic information learning process or is pre-configured.

[0013] Optionally, the first security policy includes at least one of the following: a whitelist, and a policy of mirroring traffic outside the whitelist to the XDP mount point.

[0014] Secondly, a micro-isolation system is provided, comprising: a first device, an XDP, a second device, an OVS, and a controller; wherein...

[0015] The first device generates a second security policy for abnormal traffic detection based on traffic access relationships. The second security policy is used to instruct the OVS forwarding plane to mirror all traffic to the XDP mount point.

[0016] The first device sends the second security policy to the controller;

[0017] The controller converts the second security policy into a second flow table, and sends the second flow table to the OVS forwarding plane through the OVS control plane;

[0018] The OVS forwarding plane performs traffic forwarding processing according to the second flow table, and mirrors all traffic to the XDP mount point according to the second flow table;

[0019] The XDP mount point extracts the traffic information of the received traffic;

[0020] The first device acquires traffic information extracted from the XDP mount point, determines abnormal traffic information based on the traffic information, and performs at least one of the following based on the abnormal traffic information: generating a first security policy for abnormal traffic detection, updating the first security policy, generating a security event, generating a security threat view, and updating the security threat view.

[0021] Optionally, the first device sends the first security policy to the controller, the controller converts the first security policy into a first flow table, and sends the first flow table to the OVS forwarding plane through the OVS control plane. The OVS forwarding plane mirrors the traffic outside the whitelist to the XDP mount point while forwarding the traffic normally according to the first flow table.

[0022] Optionally, the first device sends the first security policy or the second security policy to the controller via VIM or NFVO and VIM.

[0023] Optionally, the micro-segmentation system further includes an agent deployed in a third device, the agent being used for at least one of the following: loading the XDP program onto the network port of the second device or the network device driver of the third device, creating a map, storing the traffic filtering policy to be executed by the XDP mount point into the map, and reading traffic information from the XDP mount point from the map.

[0024] Optionally, the VIM forwards traffic information from the agent to the first device;

[0025] Alternatively, the VIM forwards traffic information from the agent to the NFVO, which then forwards it to the first device.

[0026] Optionally, if the second device supports XDP, the XDP mount point is the network port of the second device, or if the second device supports XDP, the XDP mount point is the network device driver of the third device.

[0027] Optionally, the first security policy includes at least one of the following: a whitelist, and a policy of mirroring traffic outside the whitelist to the XDP mount point.

[0028] Thirdly, an abnormal traffic processing device is provided, comprising: a first transceiver unit and a first processing unit;

[0029] The first processing unit is used to acquire traffic information extracted from the XDP mount point, determine abnormal traffic information based on the traffic information, and perform at least one of the following based on the abnormal traffic information: generate a first security policy for abnormal traffic detection, update the first security policy, generate a security event, generate a security threat view, and update the security threat view.

[0030] Fourthly, a communication device is provided, including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0031] Fifthly, a readable storage medium is provided, on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect.

[0032] A sixth aspect provides a computer program product including computer instructions that, when executed by a processor, implement the steps of the method described in the first aspect.

[0033] In this application, the first device acquires the traffic information extracted by the XDP mount point, determines abnormal traffic information based on the traffic information, and performs at least one of the following based on the abnormal traffic information: generating a first security policy for abnormal traffic detection, updating the first security policy, generating a security event, generating a security threat view, and updating the security threat view, so as to respond to and handle potential security issues in a timely manner. The XDP mount point serves as the entry point for packet processing and traffic monitoring. XDP can efficiently capture east-west traffic flowing through the network. Thus, the method of this application breaks through the limitations of existing micro-segmentation schemes and improves security protection capabilities through comprehensive monitoring of east-west traffic within the resource pool, effectively improving the overall security of the network environment. Attached Figure Description

[0034] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0035] Figure 1 This is a flowchart of an abnormal traffic handling method provided in an embodiment of this application;

[0036] Figure 2 This is a schematic diagram of a micro-isolation system based on a second device provided in an embodiment of this application;

[0037] Figure 3 This is a flowchart of micro-segmentation security policy learning and generation based on a second device, provided in an embodiment of this application;

[0038] Figure 4 This is a flowchart illustrating the generation and distribution of micro-segmentation security policies based on a second device, provided in an embodiment of this application.

[0039] Figure 5 This is a flowchart of abnormal traffic detection and traffic information reporting based on a second device provided in an embodiment of this application;

[0040] Figure 6 This is a schematic diagram of an abnormal traffic processing device provided in an embodiment of this application;

[0041] Figure 7 This is a schematic diagram of a communication device provided in an embodiment of this application. Detailed Implementation

[0042] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0043] The term "comprising," and any variations thereof, used in the specification and claims of this application, is intended to cover a non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those explicitly listed, but may include other steps or units not explicitly listed or inherent to such process, method, product, or apparatus. Furthermore, the use of "and / or" in the specification and claims indicates at least one of the connected objects, such as A and / or B, indicating the inclusion of A alone, B alone, or both A and B.

[0044] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0045] With the development of cloud computing, Network Functions Virtualization (NFV), and Software Defined Networking (SDN), traditional telecommunications networks are gradually adopting NFV, SDN, and virtualization technologies for network reconstruction. Currently, some operators have deployed 5G core network control plane elements and 4G evolved core (EPC) cores on virtual infrastructure under NFV or SDN architectures. In traditional telecommunications networks, point-to-point communication between network elements allows traffic to be collected at the communication interface, and abnormal traffic can be detected. However, in virtualized 5G core network (5GC), traffic between network elements, and between virtual machines or Pods within a network element, may interact through virtual switches on the host, without leaving the physical network interface card (NIC). Traditional methods of collecting physical NIC traffic from hardware switches for abnormal traffic detection cannot cover all east-west traffic within the resource pool (i.e., traffic between network elements and between virtual machines or Pods within a network element). Using technologies such as SDN to extract traffic from virtual switches for collection has a significant impact on the performance of virtual switches and network bandwidth.

[0046] From a security attack perspective, cloud resource pools utilize general-purpose servers, incorporate various open-source software, and exhibit homogeneous operating systems, making it easier for attackers to discover and exploit vulnerabilities. Once a vulnerability is exploited, attackers can further leverage this homogeneity to extend their attacks within the resource pool via east-west traffic—a lateral movement attack—and potentially even compromise the entire resource pool. Currently, micro-segmentation technology is commonly used in public clouds. Micro-segmentation, a typical technology for fine-grained control of east-west traffic, was first proposed by Gartner in its Software-Defined Data Center (SDDC) technology framework. It provides secure access control between hosts (virtual machines, containers) (distinct from past security domain access control) and provides visualized management of east-west traffic. Currently, micro-segmentation technology, along with Software-Defined Perimeter (SDP) and Identity and Access Management (IAM), is considered one of the three key technologies for zero trust. The most typical micro-segmentation solution proposed in the industry involves installing agent software on each virtual machine to inspect traffic entering and leaving the virtual machine, as well as the applications and content within the virtual machine. This approach is dependent on the virtual machine's operating system. Another approach is to use the security groups of the virtual switch (vswitch) in the virtual layer to identify and drop abnormal traffic. This approach has a significant impact on the performance of the virtual switch.

[0047] In telecommunications network scenarios, the virtualized network elements and their guest operating systems provided by vendors possess a degree of proprietary nature. Installing third-party micro-segmentation agents onto the guest operating system of virtualized network elements can lead to incompatibility issues, resulting in decreased network element performance and even service interruptions. Furthermore, the performance overhead of micro-segmentation mechanisms based on virtual switch security groups makes them unsuitable for cloud-based telecommunications networks. Moreover, current micro-segmentation mechanisms in cloud-based telecommunications networks only require micro-segmentation security detection to be enabled for service reliability assurance; security actions require manual confirmation before issuing security policies, and security groups often discard abnormal traffic, potentially leading to service interruptions due to misjudgments. Therefore, the virtual machine security group-based approach is unsuitable for application in telecommunications networks.

[0048] See Figure 1 The embodiments of this application provide an abnormal traffic processing method, applied to a first device, and the specific steps include: step 11 and step 12.

[0049] Step 11: Obtain traffic information extracted from the XDP mount point, and determine abnormal traffic information based on the traffic information;

[0050] An XDP mount point refers to a specific entry point or node in the network data processing path, on which XDP programs can be attached and executed. Optionally, the XDP mount point can be the network device driver of a second device's network port or a third device. The second device includes, but is not limited to, a smart network interface card (NIC), and the third device includes, but is not limited to, the host machine where virtual machines are deployed.

[0051] Step 12: Based on the abnormal traffic information, perform at least one of the following: generate a first security policy (or security detection policy) for abnormal traffic detection, update the first security policy, generate a security event, generate a security threat view, and update the security threat view.

[0052] In some implementations, the first device generates a first security policy for abnormal traffic detection based on abnormal traffic information.

[0053] In some implementations, the first device updates the existing first security policy based on abnormal traffic information to obtain a new first security policy.

[0054] In some implementations, the first device generates a security event based on abnormal traffic information.

[0055] In some implementations, the first device generates a security threat view based on abnormal traffic information.

[0056] In some implementations, the first device updates the existing security threat view based on abnormal traffic information to obtain a new security threat view.

[0057] In some implementations, the first device generates a first security policy for abnormal traffic detection based on abnormal traffic information, and generates security events and a security threat view based on the abnormal traffic information.

[0058] In some implementations, the first device generates a first security policy for abnormal traffic detection based on abnormal traffic information, generates a security event based on abnormal traffic information, and updates the existing security threat view based on abnormal traffic information to obtain a new security threat view.

[0059] In some implementations, the first device updates the existing first security policy based on the abnormal traffic information to obtain a new first security policy, and generates security events and a security threat view based on the abnormal traffic information.

[0060] In some implementations, the first device updates the existing first security policy based on the abnormal traffic information to obtain a new first security policy, generates a security event based on the abnormal traffic information, and updates the existing security threat view based on the abnormal traffic information to obtain a new security threat view.

[0061] A security incident refers to a security-related activity or situation that occurs in an information system or network environment. These incidents may indicate potential security vulnerabilities, intrusion attempts, or other abnormal behavior. Optionally, security incidents may include attack attempts, abnormal logins, and malware detection.

[0062] A security threat view is a visualization tool used to present an overview of the security threats currently present in a system or network and their impact. It displays various security threats, attack paths, affected resources, attacker locations, and more through a graphical interface.

[0063] In one implementation, the first device includes a micro-segmentation management module.

[0064] Optionally, the first device can be deployed independently. Alternatively, the first device can be deployed on NFVO or VIM.

[0065] In one embodiment of this application, after step 12 (i.e., after generating or updating the first security policy), the method further includes:

[0066] The first security policy is sent to the controller, so that the controller converts the first security policy into a first flow table. The first flow table is used by the open-source virtual switch OVS forwarding plane to mirror traffic outside the whitelist to the XDP mount point while forwarding it normally.

[0067] In one embodiment of this application, before step 11, the method further includes:

[0068] Step 13: Generate a second security policy for abnormal traffic detection based on traffic access relationships. The second security policy is used to instruct the OVS forwarding plane to mirror all traffic to the XDP mount point.

[0069] Optionally, the second security policy (or stream learning security policy) includes, but is not limited to, at least one of the following: 1) Access control, specifying which devices or users can access which resources, including authentication mechanisms, role-based access control, etc.; 2) Traffic filtering, defining allowed and denied traffic types, and using matching conditions such as IP address, port number, and protocol type to set whitelists and blacklists; 3) Intrusion detection and response, monitoring network traffic to identify abnormal activity, and specifying response measures when an intrusion is detected, such as alarms and blocking the attack source IP; 4) Logging and auditing, specifying how to record traffic data, access records, and security events; 5) Data encryption and privacy protection, encrypting the transmission of sensitive data and specifying the security standards for storage.

[0070] Step 14: Send the second security policy to the controller so that the controller converts the second security policy into a second flow table. The second flow table is used by the OVS forwarding plane to mirror traffic to the XDP mount point while processing traffic normally.

[0071] Optionally, the first or second flow table may include, but is not limited to, at least one of the following: 1) a matching field, a standard used to identify packets; a flow table entry is only effective if the matching field matches the information in the packet header; 2) an operation, specifying what operation should be performed for a matching packet; and 3) a priority, where each flow table entry has a priority value to determine which entry should be processed first when multiple entries match. Entries with higher priority are applied first.

[0072] In one embodiment of this application, the traffic access relationship is determined based on a traffic information learning process or is pre-configured.

[0073] In one embodiment of this application, the first security policy includes at least one of the following: a whitelist, and a policy of mirroring traffic outside the whitelist to the XDP mount point.

[0074] In this application, the first device generates a second security policy for abnormal traffic detection based on traffic access relationships. This process ensures that the second security policy reflects the actual data access and traffic patterns, thereby covering east-west traffic throughout the entire resource pool. The first device sends the second security policy to the controller, which converts the second security policy into second flow tables. These second flow tables not only allow normal traffic processing but also mirror traffic to XDP mount points for deeper traffic monitoring. The first device obtains the traffic information extracted from the XDP mount points, determines abnormal traffic information based on the traffic information, and performs at least one of the following actions based on the abnormal traffic information: generating a first security policy for abnormal traffic detection, updating the first security policy, generating a security event, generating a security threat view, and updating the security threat view, in order to respond to and handle potential security issues in a timely manner. The method of this application breaks through the limitations of existing micro-segmentation schemes and improves security protection capabilities through comprehensive monitoring of east-west traffic within the resource pool, effectively improving the overall security of the network environment.

[0075] See Figure 2 Embodiments of this application provide a micro-segmentation system, including: a first device, an XDP, a second device, an OVS (including an OVS forwarding plane and an OVS control plane), and a controller (e.g., the controller includes, but is not limited to, an SDN controller); wherein,

[0076] The first device generates a second security policy for abnormal traffic detection based on traffic access relationships. The second security policy is used to instruct the OVS forwarding plane to mirror all traffic to the XDP mount point.

[0077] The first device sends the second security policy to the controller;

[0078] The controller converts the second security policy into a second flow table, and sends the second flow table to the OVS forwarding plane through the OVS control plane;

[0079] The OVS forwarding plane performs traffic forwarding processing according to the second flow table, and mirrors the traffic to the XDP mount point according to the second flow table;

[0080] The XDP mount point extracts the traffic information of the received traffic;

[0081] The first device acquires traffic information extracted from the XDP mount point, determines abnormal traffic information based on the traffic information, and performs at least one of the following based on the abnormal traffic information: generating a first security policy for abnormal traffic detection, updating the first security policy, generating a security event, generating a security threat view, and updating the security threat view.

[0082] In one embodiment of this application, the first device sends the first security policy or the second security policy to the controller via VIM or NFVO and VIM.

[0083] In one embodiment of this application, the micro-segmentation system further includes an agent deployed in a third device, the agent being used for at least one of the following: loading the XDP program to the network port of the second device or the network device driver of the third device, creating a map, storing the traffic filtering policy to be executed by the XDP mount point in the map, and reading traffic information from the XDP mount point from the map.

[0084] Optionally, the XDP mount point and map can be configured together, for example, the XDP mount point and map can be deployed on a fourth device, or the XDP mount point and map can be configured independently. In one embodiment of this application, the VIM forwards traffic information from the agent to the first device;

[0085] Alternatively, the VIM forwards traffic information from the agent to the NFVO, which then forwards it to the first device.

[0086] In one embodiment of this application, the second flow table includes a graylist, the graylist actions including normal forwarding and mirroring traffic to an XDP mount point.

[0087] In one embodiment of this application, the XDP mount point may be the network port of a second device or the network device driver of a third device.

[0088] In one embodiment of this application, the first security policy includes at least one of the following: a whitelist, and a policy of mirroring traffic outside the whitelist to the XDP mount point.

[0089] In this embodiment, the micro-segmentation system enables real-time monitoring of all east-west traffic in the resource pool. The first device generates dynamic security policies using traffic access relationships, ensuring effective oversight of both internal and external traffic. These policies are sent to the controller, converted into flow tables, and then the OVS forwarding plane performs traffic forwarding tasks while simultaneously mirroring traffic to the XDP mount point for in-depth analysis. This method not only ensures efficient packet processing but also reduces network latency and improves overall performance. Secondly, by extracting traffic information from the XDP mount point, the first device can instantly identify abnormal traffic and take corresponding measures. This approach enhances the system's automated response capabilities, enabling rapid generation and updating of first security policies for abnormal traffic detection, generation of security event reports, and visualization of security threats, significantly improving the speed of detection and response to potential attacks. In summary, the micro-segmentation system, with its flexible architecture, real-time monitoring, and adaptive security policies, effectively reduces security risks and enhances network security, providing enterprises with a comprehensive and efficient network security solution to address the increasingly complex network threat environment.

[0090] The implementation methods of this application are described below with reference to Examples 1 to 4.

[0091] With the development of smart NICs and their application in cloud-based telecommunications networks, the forwarding plane of vswitch can be offloaded to smart NICs (i.e., the second device), improving forwarding efficiency. To enable broader security detection of east-west traffic, especially for detecting abnormal traffic at the virtual layer (attacks on the virtual layer could affect all services), this invention proposes a micro-segmentation scheme based on smart NICs. By combining vswitch with XDP (eXpress Data Path) capabilities, security policies are transformed into whitelist + graylist flow tables. vswitch mirrors graylist traffic to XDP, and XDP and the agent report traffic information. This allows the first device to update security policies based on traffic information, generate a security threat view, and thus achieve rapid detection of abnormal traffic across all network planes with zero impact on network elements.

[0092] Example 1:

[0093] Figure 2 The micro-segmentation system requires adding a first device based on a smart NIC deployed in the management domain, an agent deployed in the host operating system's user space, a map deployed on the smart NIC, and an eXpress Data Path (XDP) deployed on the smart NIC, to the existing open-source virtual switch (OVS) forwarding plane offloading framework. The specific functional descriptions are as follows:

[0094] 1) The first device based on smart network interface cards: used to obtain monitored asset information from the Network Functions Virtualization Orchestrator (NFVO) and generate network topology.

[0095] Optionally, asset information includes, but is not limited to, at least one of the following: Virtual Network Function (VNF) type, Virtual Network Function instance ID, Virtual Machine (VM) ID contained in the Virtual Network Function, physical host name where the VM resides, host name, VM ID contained on the host, etc.

[0096] For example, to detect 5G core network (5GC) management plane traffic, you would obtain the 5GC's VNF type, VNF instance ID, included VM ID, and the physical host name (i.e., third-party device name) from the NFVO. If you are detecting virtual layer management plane traffic, you should obtain the host name (i.e., third-party device name), the VM ID contained on the host (i.e., third-party device), the VNF type corresponding to the VM, and the VNF instance ID from the NFVO.

[0097] Optionally, the first device is also used to generate a second security policy or a first security policy based on traffic learning or a pre-configured whitelist, and to send the first security policy or the second security policy to the Software-Defined Network (SDN) controller. The SDN controller then sends the first security policy or the second security policy to the OVS control plane in the form of a first flow table or a second flow table, and the OVS control plane then sends it to the OVS forwarding plane.

[0098] Optionally, the first or second security policy may include, but is not limited to, at least one of the following: 1) Access control, specifying which devices or users can access which resources, including authentication mechanisms, role-based access control, etc.; 2) Traffic filtering, defining allowed and denied traffic types, and using matching conditions such as IP address, port number, and protocol type to set whitelists and blacklists; 3) Intrusion detection and response, monitoring network traffic to identify abnormal activity, and specifying response measures when an intrusion is detected, such as alarms and blocking the attack source IP; 4) Logging and auditing, specifying how to record traffic data, access records, and security events; 5) Data encryption and privacy protection, encrypting the transmission of sensitive data and specifying the security standards for storage.

[0099] Optionally, the first or second flow table includes at least one of the following: 1) a matching field, a criterion used to identify packets; a flow table entry is only effective if the matching field matches the information in the packet header; 2) an operation, specifying what operation should be performed for a matching packet; and 3) a priority, where each flow table entry has a priority value to determine which entry should be processed first when multiple entries match. Entries with higher priority are applied first.

[0100] Optionally, the first device is also used to update the first security policy, generate security events, security threat views, and / or update security threat views based on the received abnormal traffic information.

[0101] A security incident refers to a security-related activity or situation that occurs in an information system or network environment. These incidents may indicate potential security vulnerabilities, intrusion attempts, or other abnormal behavior. Optionally, security incidents may include attack attempts, unusual logins, and malware detection.

[0102] A security threat view is a visualization tool used to present an overview of the security threats currently present in a system or network and their impact. It displays various security threats, attack paths, affected resources, attacker locations, and more through a graphical interface.

[0103] In one implementation, the first device can be deployed independently; in another implementation, the first device can also be deployed on NFVO or Virtualized Infrastructure Manager (VIM).

[0104] 2) Agent: Used to load the XDP program onto the second device, create a map, store the traffic filtering strategy (extracting traffic quintuple information) to be executed by the XDP program into the map, and read traffic information from the XDP program from the map.

[0105] Optionally, XDP and map can be configured together, i.e., deployed on the fourth device, or XDP and map can be configured independently. The first, second, and fourth devices in this application can be virtual devices or physical devices.

[0106] Optionally, a traffic filtering policy refers to a set of rules and conditions used to determine how to process network traffic. A traffic filtering policy includes at least one of the following: matching conditions, allow or deny actions, priorities, etc.

[0107] 3) XDP program: XDP stands for eXpress Data Path, a high-performance network packet processing technology in the Linux kernel. It processes packets before they enter the protocol stack, resulting in high performance. XDP is also based on the extended Berkeley Packet Filter (eBPF) technology, but eBPF can execute in multiple locations within the kernel, making it more widely applicable. XDP, on the other hand, is specifically designed for early processing of network packets and is typically mounted at the network device driver, offering higher performance than eBPF.

[0108] In this application, the XDP program reads the traffic filtering policy from the map, performs flow filtering according to the traffic filtering policy after receiving traffic, and stores the processing results in the map.

[0109] Optionally, the processing result usually refers to the decisions and operations made on the received network traffic according to the traffic filtering policy. For example, the processing result may include the following types: allow, drop, redirect, modify, etc.

[0110] 4) Map: Created by the agent, the map's attributes can be specified, including size and type. The map stores the traffic filtering policies that XDP needs to execute, as well as the traffic information reported by XDP.

[0111] 5) OVS forwarding plane: Used to forward received packets according to the second flow table, mirror traffic that hits the gray list, and send it to the XDP mount point offloaded on the second device.

[0112] The OVS forwarding plane matches received packets against predefined flow table rules to identify which traffic needs to be mirrored. Traffic in the graylist may be marked based on specific conditions (such as IP address, port, protocol, etc.). A new mirrored flow is created in the OVS forwarding plane, specifying the source flow to be monitored (i.e., the traffic that hits the graylist) and the destination, i.e., the XDP mount point to which the mirrored data is sent. When matching traffic is detected, the OVS forwarding plane copies each matching packet, creating a replica. These replicas are used for subsequent analysis or processing, while the original packets continue to flow and be forwarded normally. The mirrored packet replicas are then sent to the XDP mount point offloaded on the second device. Once the packets arrive at the XDP mount point, the XDP mount point can further process these mirrored traffic according to the configured logic, such as filtering, monitoring, statistical analysis, or logging.

[0113] Optionally, the OVS forwarding plane can also update the second flow table based on the first flow table issued by the OVS control plane.

[0114] The micro-segmentation system comprises a learning phase and a security monitoring phase. In the learning phase, the first device learns from traffic information or pre-configures traffic access relationships to generate micro-segmentation security policies. The security monitoring phase utilizes OVS+XDP to perform security monitoring of abnormal traffic. The flow learning phase is executed during the deployment and trial operation phase of the operator's network.

[0115] Micro-segmentation is a network security strategy designed to restrict and protect communication across different parts of a network through granular access control. It partitions network traffic to isolate small areas of each application or service, thereby reducing the risk of potential attack surfaces and making it difficult for attackers to move laterally even if they gain access to the network.

[0116] Example 2:

[0117] See Figure 3 The specific learning process is described below:

[0118] Step 1: The first device based on the smart network card generates a flow learning security policy (i.e., the second security policy). This flow learning security policy requires OVS to mirror all traffic to the XDP mount point (which can be a network port of the smart network card or the network device driver of the host).

[0119] Stream learning security strategy is a dynamic network security management strategy designed to deeply analyze and optimize network traffic in order to achieve the goal of micro-segmentation.

[0120] This flow-learning security strategy first utilizes smart network interface cards (NICs) and Open vSwitch (OVS) to mirror all traffic to XDP mount points, ensuring comprehensive capture of network activity. Next, machine learning algorithms are used to deeply analyze the mirrored traffic, extracting normal communication patterns, including source IP, destination IP, port number, and protocol type. Simultaneously, based on these learned features, the strategy automatically generates a series of security rules, such as whitelists, abnormal traffic detection, and lateral flow control, to prevent unauthorized access and internal threats. Furthermore, this strategy features real-time monitoring and adaptive adjustment capabilities, allowing for regular updates and optimization of security measures based on environmental changes, ensuring the network remains consistently secure.

[0121] Optional, stream learning security policies include: a policy of mirroring all traffic to the XDP mount point.

[0122] Step 2: The first device sends the stream learning security policy to the NFVO, which then forwards it to the VIM; or the first device sends it directly to the VIM.

[0123] Step 3: VIM forwards the stream learning security policy to the SDN controller.

[0124] Step 4: The SDN controller converts the stream learning security policy into a second flow table;

[0125] Optionally, the second flow table includes: a graylist.

[0126] A gray list is a table created to monitor traffic, containing traffic identified as potentially risky but not yet completely blocked. This means that although this traffic will not be immediately blocked, it will be monitored and recorded under certain conditions through a "normal forwarding + mirroring" mechanism, facilitating subsequent analysis and decision-making.

[0127] Specifically, the SDN controller collects and processes network traffic data through traffic monitoring and analysis modules to determine normal communication patterns and abnormal traffic characteristics. Key information is extracted from the results of flow learning, such as legitimate traffic in the whitelist, suspicious traffic in the graylist, and their behavioral patterns. Based on the extracted information, the SDN controller generates corresponding flow table entries. These flow table entries specify matching conditions (such as source / destination IP address, port number, and protocol type) and corresponding actions (such as forwarding, mirroring, or dropping).

[0128] Optionally, the SDN controller can convert the policy of mirroring all traffic to the XDP mount point into a graylist. The graylist action is normal forwarding plus mirroring traffic to the XDP mount point.

[0129] Step 5: The SDN controller sends the second flow table to the OVS control plane.

[0130] Step 6: The OVS control plane sends the second flow table to the OVS forwarding plane on the smart NIC.

[0131] Step 7: After receiving the traffic, the OVS forwarding plane mirrors the traffic to the XDP mount point while processing the traffic normally, according to the second flow table.

[0132] Step 8: After receiving traffic, XDP extracts traffic information (such as traffic 5-tuple information) according to the traffic filtering policy obtained from the Map and stores it in the Map. XDP needs to be provided in advance by the micro-segmentation provider and is mounted to the network port of the smart NIC or the host's network device driver via the agent. The traffic filtering policy in the Map is written by the agent when creating the Map and read by XDP. The performance of XDP mounted on the smart NIC's network port is higher than that of XDP mounted on the host's network device driver. When the smart NIC supports XDP, XDP is mounted on the smart NIC first; when the smart NIC does not support XDP unmounting, XDP is mounted to the host's network device driver.

[0133] Step 9: XDP sends the extracted traffic information to Map, which then stores it.

[0134] Optionally, the traffic information extracted by XDP typically includes the following key elements:

[0135] 1) Traffic 5-tuple information: source IP address, destination IP address, source port number, destination port number, protocol type.

[0136] 2) Traffic size: The number of bytes per data packet or the cumulative size of traffic, for traffic analysis and monitoring.

[0137] 3) Timestamp: Records the time when data packets arrive, providing a reference for subsequent traffic analysis and event tracing.

[0138] 4) Tags or labels: These may be used to identify specific attributes or statuses of traffic, such as security identifiers (whether it is in a whitelist or graylist) or other custom information.

[0139] 5) Traffic direction: Indicates whether traffic is entering or leaving the network device, which helps in understanding the traffic flow. Step 10: The Agent reads traffic information from the Map.

[0140] Step 11: The Agent merges traffic information, which can combine the same five-tuple information into one.

[0141] Step 12: The Agent sends the merged traffic information to the VIM.

[0142] Step 13: VIM is sent directly to the first device, or sent to NFVO and then forwarded to the first device by NFVO.

[0143] Step 14: The first device obtains the asset information of the objects to be monitored from the NFVO, such as the VNF type, VNF instance ID, and included VM ID of the 5GC network element.

[0144] The first device learns from the received traffic information, combines it with asset information, identifies normal access relationships between traffic, and generates security policies for abnormal traffic detection based on these relationships. For example, the security policies may include mirroring whitelisted and unwhitelisted traffic to the XDP mount point.

[0145] Specifically, the first device combines traffic information with acquired asset information to help identify individual VNFs and their communication relationships. For example, by analyzing the traffic of a particular VNF instance, normal access paths to other VNFs (such as databases, API services, etc.) can be observed.

[0146] Specifically, the first device utilizes machine learning and data mining techniques to analyze traffic characteristics, such as source and destination IPs, transport protocols, ports, and traffic frequency, and combines this with acquired asset information to identify normal access relationships between different VNF ​​instances. This analysis helps define which traffic is considered legitimate communication, reflecting how various components in the network interact normally. During this process, the first device also builds a dynamic model for continuous updating and optimization of these access relationships. Finally, based on the identified normal access relationships, the first device generates a primary security policy for anomaly traffic detection. This includes a whitelist policy, allowing normal traffic to pass while also generating rules for handling traffic not on the whitelist, such as mirroring this traffic to an XDP mount point for further analysis. This ensures that even if traffic does not meet expectations, it is not directly blocked but monitored, thereby improving the overall network security and auditability. Ultimately, these security policies will be applied to the network to effectively protect the 5GC system from potential threats.

[0147] Because communication technology (CT) networks have service determinism, secure traffic access relationships can be pre-configured based on the traffic access relationships provided by the manufacturer. Then, the first device generates a first security policy for abnormal traffic detection based on the access relationships.

[0148] Example 3:

[0149] See Figure 5 The specific process is described as follows:

[0150] Step 1: The first device based on the smart network card... Figure 4 The first security policy for abnormal traffic detection is generated by stream learning or by pre-setting traffic access relationships.

[0151] Optionally, the primary security strategy for anomaly traffic detection mainly includes dynamically generated whitelists and graylists. The whitelist explicitly lists permitted legitimate traffic, ensuring that only verified communication can pass through the network. Furthermore, traffic not in the whitelist is marked as graylist traffic; while not completely prohibited, it is subject to stricter monitoring. This traffic is mirrored to the XDP mount point for further analysis to identify potential anomalous behavior or attack patterns. In addition, the strategy may incorporate anomaly detection algorithms to assess whether traffic patterns deviate from the normal baseline through real-time traffic analysis, ensuring that any suspicious activity is quickly detected and addressed. Through these multi-layered security measures, the anomaly traffic detection strategy effectively improves the security and stability of the network environment.

[0152] Step 2: The first device sends the first security policy to the NFVO, which then forwards it to the VIM, or the management module directly sends the first security policy to the VIM.

[0153] Step 3: VIM forwards the first security policy to the SDN controller.

[0154] Step 4: The SDN controller generates the first flow table according to the first security policy. For example, a whitelist is set and traffic outside the whitelist is set as a graylist. Graylist traffic is forwarded normally and a copy is mirrored and sent to the XDP mount point.

[0155] Optionally, the first-order table includes a whitelist and a graylist of items not included in the whitelist.

[0156] Step 5: The SDN controller sends the first flow table to the OVS control plane.

[0157] Step 6: The OVS control plane sends the first flow table to the OVS forwarding plane.

[0158] Example 4:

[0159] See Figure 6 The specific process is described as follows:

[0160] Step 1: The OVS forwarding plane processes the received traffic according to the first flow table. When the received traffic is found to be graylisted, it is forwarded normally while mirroring the traffic to the XDP mount point.

[0161] Step 2: The OVS forwarding plane sends the mirrored traffic to the XDP mount point (such as a network port of the smart network card or the network device driver of the host).

[0162] Step 3: XDP performs traffic filtering based on the traffic filtering strategy obtained from the map in advance, that is, extracts the traffic quintuple information and stores it in the map.

[0163] Optionally, traffic filtering policies are a key measure to ensure network security, mainly including elements such as Access Control Lists (ACLs), content-based filtering, deep packet inspection, and traffic isolation. ACLs define which IP addresses or ports are allowed to access network resources, effectively blocking unauthorized traffic. Meanwhile, content-based filtering analyzes the content of data packets to identify and block malicious code or inappropriate content. Deep packet inspection provides a more in-depth analysis of traffic, discovering potential threats by examining information at the transport and application layers. Furthermore, traffic isolation technology separates different categories of traffic according to policies, thereby reducing the attack surface and limiting potential risks. These policies together constitute a multi-layered protection system to ensure the stability and security of the network environment.

[0164] Step 4: XDP sends the extracted traffic information (such as traffic quintuple information) to the map, which stores it.

[0165] Step 5: The Agent retrieves the stored traffic information from the map.

[0166] Step 6: The Agent merges the acquired traffic information, and can merge the same five-tuple information into one.

[0167] By merging identical 5-tuple information (e.g., source IP, destination IP, source port, destination port, and protocol type), redundancy in network traffic data can be significantly reduced. This means less computational resources are needed for storage and processing, reducing the burden on the system.

[0168] Step 7: The Agent sends the merged traffic information to VIM.

[0169] Step 8: VIM directly sends traffic information to the first device, or sends it to NFVO and then NFVO forwards it to the first device.

[0170] Step 9: The first device identifies the VM of abnormal traffic based on the received traffic information, including the VNF type and VNF instanceid of the VM, and updates the security threat view. The first device can generate security events and update the first security policy. This first security policy may include blacklisting the five-tuple of abnormal traffic, and after manual confirmation, apply the first security policy accordingly. Figure 5 Steps 2-6 are sent to the OVS forwarding plane, which then blocks the abnormal traffic. After blocking the abnormal traffic, the first device updates its security threat view based on the received traffic information.

[0171] A security threat view is a dynamic, centralized interface or database that displays potential security threats and risks in the current network environment. It typically includes the following information:

[0172] 1) Identified threats: such as abnormal traffic, attempts to access restricted resources, etc.

[0173] 2) Relevant asset information: Virtual machines (VMs), Virtual Network Functions (VNFs) types and their instance IDs, network locations, etc.

[0174] 3) Threat Level: Each identified threat is classified and rated according to the risk assessment model.

[0175] 4) Historical event records: Past security incidents and their handling results can provide a reference for real-time decision-making.

[0176] This security threat view helps security teams quickly identify and analyze potential security issues in the network and develop corresponding countermeasures.

[0177] A security incident is a specific, monitored activity that occurs on a network and may indicate a security risk. For example, a virtual machine might generate unusual traffic attempting to connect to an untrusted IP address; or an account might experience multiple failed login attempts. These incidents need to be logged, analyzed, and investigated to determine if they constitute a security threat.

[0178] A security strategy is the specific protective measures taken against identified security threats. This includes how to respond to specific security incidents, including but not limited to:

[0179] 1) Blacklist suspicious traffic or devices;

[0180] 2) Restrict traffic or access permissions by configuring network devices;

[0181] 3) Increase the monitoring frequency of specific virtual machines;

[0182] 4) Issue alerts or notifications for specific events.

[0183] See Figure 6 An embodiment of this application provides an abnormal traffic processing device, including: a first transceiver unit 601 and a first processing unit 602;

[0184] The first processing unit 602 is used to acquire traffic information extracted from the XDP mount point, determine abnormal traffic information based on the traffic information, and perform at least one of the following based on the abnormal traffic information: generate a first security policy for abnormal traffic detection, update the first security policy, generate a security event, generate a security threat view, and update the security threat view.

[0185] In one embodiment of this application, the first processing unit 602 is further configured to send the first security policy to the controller after generating or updating the first security policy, so that the controller converts the first security policy into a first flow table. The first flow table is used by the open-source virtual switch OVS forwarding plane to mirror traffic outside the whitelist to the XDP mount point while forwarding traffic normally.

[0186] In one embodiment of this application, the first processing unit 602 is further configured to generate a second security policy for abnormal traffic detection based on traffic access relationships, wherein the second security policy is configured to instruct the OVS forwarding plane to mirror all traffic to the XDP mount point.

[0187] The first transceiver unit 601 is used to send the second security policy to the controller so that the SDN controller converts the second security policy into a second flow table. The second flow table is used by the OVS forwarding plane to mirror traffic to the XDP mount point while processing traffic normally.

[0188] In one embodiment of this application, the traffic access relationship is determined based on a traffic information learning process or is pre-configured.

[0189] In one embodiment of this application, the first security policy includes at least one of the following: a whitelist, and a policy of mirroring traffic outside the whitelist to the XDP mount point.

[0190] The apparatus provided in this application embodiment can achieve... Figure 1 The various processes implemented in the method embodiments shown achieve the same technical effects, and will not be described again here to avoid repetition.

[0191] like Figure 7 As shown, this application embodiment also provides a communication device 700, including a processor 701, a memory 702, and a program or instructions stored in the memory 702 and executable on the processor 701. When the program or instructions are executed by the processor 701, they implement the above-mentioned... Figure 1 The various processes of the method embodiments shown can achieve the same technical effect. To avoid repetition, they will not be described again here.

[0192] This application embodiment also provides a readable storage medium storing a program or instructions that, when executed by a processor, implement the above-described functionality. Figure 1 The various processes of the method embodiments shown can achieve the same technical effect, and will not be described again here to avoid repetition.

[0193] The processor mentioned above is the processor in the terminal described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0194] The steps of the methods or algorithms described in this application can be implemented in hardware or by executing software instructions on a processor. The software instructions can consist of corresponding software modules, which can be stored in RAM, flash memory, ROM, EPROM, EEPROM, registers, hard disk, portable hard disk, read-only optical disk, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can be housed in an ASIC. Alternatively, the ASIC can be housed in a core network interface device. Of course, the processor and storage medium can also exist as discrete components in the core network interface device.

[0195] Those skilled in the art will recognize that, in one or more of the examples above, the functions described in this application can be implemented using hardware, software, firmware, or any combination thereof. When implemented in software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transfer of a computer program from one place to another. Storage media can be any available medium accessible to a general-purpose or special-purpose computer.

[0196] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of this application. It should be understood that the above description is only a specific embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of this application should be included within the scope of protection of this application.

[0197] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, embodiments of this application can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of this application can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0198] This application describes embodiments of methods, apparatus (systems), and computer program products according to embodiments of this application with reference to flowchart illustrations and / or block diagrams. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0199] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0200] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0201] Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the spirit and scope of this application. Therefore, if these modifications and variations to the embodiments of this application fall within the scope of the claims of this application and their equivalents, this application also intends to include these modifications and variations.

Claims

1. An abnormal flow handling method, applied to a first device, characterized in that, include: Obtain traffic information extracted from the XDP mount point of the fast data channel, and determine abnormal traffic information based on the traffic information; Based on the abnormal traffic information, perform at least one of the following: generate a first security policy for abnormal traffic detection, update the first security policy, generate a security event, generate a security threat view, and update the security threat view.

2. The method according to claim 1, characterized in that, After generating or updating the first security policy, the method further includes: The first security policy is sent to the controller, so that the controller converts the first security policy into a first flow table. The first flow table is used by the open-source virtual switch OVS forwarding plane to mirror traffic outside the whitelist to the XDP mount point while forwarding it normally.

3. The method according to claim 1, characterized in that, The method further includes: A second security policy for detecting abnormal traffic is generated based on traffic access relationships. The second security policy is used to instruct the OVS forwarding plane to mirror all traffic to the XDP mount point. The second security policy is sent to the controller, which then converts the second security policy into a second flow table. The second flow table is used by the OVS forwarding plane to mirror the traffic to the XDP mount point while the traffic is being processed normally.

4. The method according to claim 3, characterized in that, The traffic access relationship is determined based on the traffic information learning process or is pre-configured.

5. The method according to claim 1, characterized in that, The first security policy includes at least one of the following: a whitelist, and a policy of mirroring traffic outside the whitelist to the XDP mount point.

6. A micro-isolation system, characterized in that, include: The first device is XDP, the second device is OVS, and the controller; among them... The first device generates a second security policy for abnormal traffic detection based on traffic access relationships. The second security policy is used to instruct the OVS forwarding plane to mirror all traffic to the XDP mount point. The first device sends the second security policy to the controller; The controller converts the second security policy into a second flow table, and sends the second flow table to the OVS forwarding plane through the OVS control plane; The OVS forwarding plane performs traffic forwarding processing according to the second flow table, and mirrors all traffic to the XDP mount point according to the second flow table; The XDP mount point extracts the traffic information of the received traffic; The first device acquires the traffic information extracted from the XDP mount point, determines abnormal traffic information based on the traffic information, and performs at least one of the following based on the abnormal traffic information: generating a first security policy for abnormal traffic detection, updating the first security policy, generating a security event, generating a security threat view, and updating the security threat view.

7. The micro-isolation system according to claim 6, characterized in that, The first device sends the first security policy to the controller, the controller converts the first security policy into a first flow table, and sends the first flow table to the OVS forwarding plane through the OVS control plane. The OVS forwarding plane mirrors the traffic outside the whitelist to the XDP mount point while forwarding it normally according to the first flow table.

8. The micro-isolation system according to claim 7, characterized in that, The first device sends the first security policy or the second security policy to the controller via Virtualization Infrastructure Manager (VIM) or Network Functions Virtualization Orchestrator (NFVO) and VIM.

9. The micro-isolating system according to claim 6, characterized in that, The micro-segmentation system also includes an agent deployed in a third device, which is used for at least one of the following: loading the XDP program onto the network port of the second device or the network device driver of the third device, creating a mapping map, storing the traffic filtering policy to be executed by the XDP mount point into the map, and reading traffic information from the XDP mount point from the map.

10. The micro-isolating system according to claim 8, characterized in that, The VIM forwards traffic information from the agent to the first device; Alternatively, the VIM forwards traffic information from the agent to the NFVO, which then forwards it to the first device.

11. The micro-isolating system according to claim 6, characterized in that, The XDP mount point is the network device driver for the second device's network port or the third device.

12. The micro-isolating system according to claim 6, characterized in that, The first security policy includes at least one of the following: a whitelist, and a policy of mirroring traffic outside the whitelist to the XDP mount point.

13. An abnormal flow processing device, characterized in that, include: First transceiver unit and first processing unit; The first processing unit is used to acquire traffic information extracted from the XDP mount point, determine abnormal traffic information based on the traffic information, and perform at least one of the following based on the abnormal traffic information: generate a first security policy for abnormal traffic detection, update the first security policy, generate a security event, generate a security threat view, and update the security threat view.

14. A communication device, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method as described in any one of claims 1 to 5.

15. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the method as described in any one of claims 1 to 5.

16. A computer program product, characterized in that, Includes computer instructions that, when executed by a processor, implement the steps of the method as described in any one of claims 1 to 5.

Images