Defence scheme against congestion related attacks based on queue diagnosis

Abstract

The application discloses a defense scheme of congestion-related attack based on queue diagnosis, and belongs to the field of computer network security. The scheme comprises the following steps: firstly, a threshold used in queue diagnosis is preconfigured and set in a control plane; then, network flow monitoring based on queue diagnosis is executed in an egress pipeline of a programmable switch to perform queue diagnosis, and after congestion responsibility flow and congestion active flow are monitored, data packets are marked and recycled to an ingress pipeline; subsequently, digest messages are used in the ingress pipeline to report information of suspicious flow to the control plane; finally, the control plane makes a decision according to the suspicious flow information, and after malicious flow of the congestion-related attack is identified, a packet loss rule is issued to a data plane to intercept data packets of the malicious flow. The defense scheme has good effectiveness, flexibility, scalability and real-time performance, can accurately and quickly detect the congestion-related attack in the network, and quickly relieves the influence caused by the attack.

Description

Technical Field

[0001] This invention belongs to the field of computer network security, and specifically relates to a defense scheme against congestion-related attacks based on queue diagnosis. Background Technology

[0002] Modern networks increasingly demand high performance, and network congestion is a significant cause of network performance problems. Attackers may exploit network congestion to cause damage and degrade network performance. Attacks that maliciously create network link congestion are called congestion-related attacks. Congestion-related attacks can generally be divided into two categories: one is attacks that directly manipulate protocol vulnerabilities to create congestion, such as the Optimistic Ack attack; the other is attacks that generate attack data streams to create network link congestion, while further triggering protocol vulnerabilities to enhance the effect, such as the Shrew attack.

[0003] Software-Defined Networking (SDN) is an emerging network paradigm that overcomes the shortcomings of traditional network architectures. It decouples the control plane and data plane, offering advantages such as flexibility, abstraction, programmability, and virtualization. SDN primarily comprises three planes: the application plane, the control plane, and the data plane. The application plane consists of applications that define network behavior, policies, and packet forwarding schemes. These applications include intrusion detection, security monitoring, firewalls, routing, access control, and virtualization. The application plane communicates with the control plane through the Northbound Interface to manage the entire network. The control plane consists of numerous SDN controllers, which act as the brain of the entire SDN network, responsible for controlling traffic, establishing data processing rules, and collecting network data. The controllers abstract network logic to handle various network management tasks and enable the network to flexibly add new functionalities through programming interfaces. The data plane consists of forwarding devices responsible for packet processing and forwarding, including SDN hardware switches and SDN software switches. SDN hardware switches include ASIC-based switches, NP-based switches, and FPGA-based switches, while SDN software switches include Open vSwitch switches and bmv2 switches. The data plane communicates with the control plane through a southbound interface, and the most widely used southbound communication protocol is currently the OpenFlow protocol.

[0004] The latest trend in SDN is the introduction of a programmable data plane, offloading programmability to the switch's data plane, thereby providing opportunities to defend against congestion-related attacks within the switch. The programmable data plane supports programming using domain-specific languages ​​(DSLs), such as P4 (Programming Protocol-Independent Packet Processors), allowing user-defined logic to be used for packet processing within the switch. Furthermore, programs can operate collaboratively between the control plane and the data plane, enabling flexible and complex packet processing. In a programmable switch's pipeline, network packets first enter the parser for header parsing, then proceed to the ingress and egress pipelines, where multiple match / action operations are performed, and finally reach the deparser for packet serialization.

[0005] Existing solutions for detecting and mitigating congestion-related attacks still fall short in terms of effectiveness, flexibility, scalability, and real-time performance. Congestion-related attacks exploit vulnerabilities in network protocols and congestion control, making effective defense against them challenging. One defense approach involves modifying protocol specifications and implementations, but this is difficult to deploy, and protocols always have unknown flaws. Furthermore, congestion-related attacks typically target network links far from the client, making it impossible for host-based defense systems to obtain an accurate network view. Even if host-based systems effectively detect and mitigate attacks, malicious traffic can still flow through the network, impairing network performance. Additionally, there may be multiple principles behind congestion-related attacks, each with different initiation methods; systems targeting specific attacks may struggle to effectively counter congestion-related attacks with different principles and initiation methods. Moreover, most defense systems are deployed on the control plane or middleware, inevitably introducing communication and processing delays and hindering timely attack responses.

[0006] This invention proposes a defense scheme against congestion-related attacks based on queue diagnostics. Deployed on a programmable switch (PSS), this scheme enables real-time monitoring of network queues and network traffic to mitigate congestion-related attacks. The scheme consists of five parts: control plane pre-configuration, queue-based network flow monitoring, suspicious flow reporting, control plane decision-making, and malicious flow mitigation. Control plane pre-configuration uses the Runtime API or Thrift API to pre-set the thresholds required by this scheme to the data plane. Queue-based network flow monitoring performs queue diagnostics in the PPS's Egress Pipeline, monitoring traffic passing through network queues, including congestion-responsible flow monitoring, congestion-active flow monitoring, and suspicious flow packet recirculation. Suspicious flow reporting uses digest messages in the PPS's Ingress Pipeline to report the flow ID (flow_ID) and label information (flow_label) of suspicious flows to the control plane. The control plane determines malicious flows involved in congestion-related attacks based on the contents of the congestion responsibility flow list and the congestion active flow list. If a suspicious flow's flow_ID belongs to both the congestion responsibility flow list and the congestion active flow list, then the suspicious flow is considered a malicious flow involved in a congestion-related attack. Malicious flow mitigation, based on packet loss rules issued by the control plane to the data plane, intercepts malicious flow packets in the programmable switch's Ingress Pipeline to mitigate congestion-related attacks and achieve defense against such attacks. Summary of the Invention

[0007] To address the shortcomings of current congestion-related attack defense schemes, this paper proposes a congestion-related attack defense scheme based on queue diagnosis. This scheme requires no additional equipment or network protocol modifications and can be directly deployed in programmable switches, exhibiting good effectiveness, flexibility, scalability, and real-time performance. Therefore, this scheme is universally applicable to the real-time detection and rapid mitigation of congestion-related attacks.

[0008] The technical solution adopted by the present invention to achieve the above objectives is as follows: the defense scheme for congestion-related attacks based on queue diagnosis mainly includes five steps: control plane pre-configuration, network flow monitoring based on queue diagnosis, suspicious flow reporting, control plane decision-making, and malicious flow mitigation.

[0009] 1. Control Plane Pre-configuration. The congestion-related attack defense scheme based on queue diagnostics diagnoses network queues and monitors network traffic in the data plane, utilizing a packet backlog contribution threshold δ, an activity threshold α, and thresholds τ and γ for determining congestion status. Before running the congestion-related attack defense scheme based on queue diagnostics, the control plane uses the P4Runtime API or P4 Thrift API to set the aforementioned thresholds to be used in the data plane. The data plane uses registers to store these thresholds configured by the control plane. The P4 Runtime API is a control plane specification used to control data plane elements of devices or programs defined by P4 programs, allowing controller applications to communicate with P4 switches to configure and manage P4 programming and inherent functions. The P4 Thrift API is an API for communicating with P4 switches via the Thrift protocol for configuring and managing P4 programming and inherent functions.

[0010] 2. Network Flow Monitoring Based on Queue Diagnostics. Detecting congestion-related attacks is not easy. Therefore, this paper proposes congestion-responsible flows and congestion-active flows to monitor and track network flows that should be responsible for network congestion and those that are abnormally active during congestion, respectively. Based on the fact that attacks can cause network congestion, this solution monitors network queues in real time, identifying the responsible flows that cause packet backlogs in the queues to pinpoint key culprits of network congestion. Furthermore, based on the intent and behavior of attacks to create congestion, this solution measures the activity of network flows under congestion conditions. Flows that remain active during network congestion may be malicious flows attempting to exacerbate the congestion. Queue diagnostics are performed in the programmable switch's Egress Pipeline to monitor network traffic, including three steps: (1) Congestion responsibility flow monitoring: When a network flow passes through a network queue, if the in queuing rate of the network flow is greater than the out queuing rate, the data packets of the network flow will accumulate in the network queue, thereby causing network congestion. By monitoring the data packet accumulation contribution during the process of the network flow passing through the network queue, the congestion responsibility flow can be identified. The definition of congestion responsibility flow is: given a packet backlog contribution threshold δ, within a time range (t... s ,t e Within, if the flow i Data packet backlog contribution i If the value is greater than the threshold δ, it is considered a flow. i It is the time range (t) s ,t e The congestion responsibility flow within. The packet backlog contribution is defined as: within the time range (t) s ,t eWithin the network queue, a total of n flows passed through it. i By m i It consists of data packets, for a time range (t) j ,t j+1 Inside, t j and t j+1 Satisfying t j ∈(t s ,t e ) and t j+1 ∈(t s ,t e There are a total of x j x data packets passed through the network queue. j In each data packet, each flow i The proportion is r i j ,satisfy Time range (t) j ,t j+1 The queue depth within the specified range changes by Δq_depth. j Then flow i The contribution of the packet backlog is r i j ×Δq_depth j ; within the time range (t) s ,t e ] within, flow i Data packet backlog contribution i for: Packet backlog in network queues is a key indicator of network congestion. Congestion-related attacks aim to congest target links, so malicious flows in these attacks are often significant contributors to packet backlogs. Therefore, the detection of malicious congestion-related attack flows can be achieved by measuring the contribution of network flows to packet backlogs. Under normal circumstances, network traffic bursts can also occur, causing packet backlogs in the network queue. Thus, a small portion of benign traffic may contribute significantly to packet backlogs and be identified as congestion-related flows. Therefore, it is necessary to measure network flows from other perspectives to further improve the accuracy of detection. (2) Monitoring of active congestion flows: Attackers use congestion-related attacks to congest target links. Compared with benign flows in the network, malicious flows of attacks will show stronger activity when the network is congested. This solution measures the activity of network traffic in the congested state based on the intent and behavior of the attack in order to identify active congestion flows. The definition of congested active flow is: given an activity threshold α, within the time range (t...s ,t e Within, if the flow i Activity in a congested state i If the value is greater than the threshold α, it is considered a flow. i It is the time range (t) s ,t e Congested active flow within; The activity of a network flow under congestion is defined as: within the time range (t) s ,t e Within the network queue, a total of n flows passed through it. i By m i Composed of data packets, given thresholds τ and γ for determining congestion, if the flow... i data packets When passing through the network queue, its queuing time Greater than the threshold τ, or the queue depth of the network queue If the value is greater than the threshold γ, then the data packet is considered to be... When passing through the network queue, the network is in a congested state, within the time range (t). s ,t e Within ], for each flow i Its activity under congestion i for: Congestion-driven active flow monitoring measures the activity of network flows under congestion. For benign TCP flows, due to adjustments made by congestion control algorithms (such as the Cubic algorithm), the sender, upon sensing network congestion (e.g., retransmission timeouts, redundant acknowledgments), will reduce the congestion window and lower the sending rate, resulting in decreased TCP flow activity during network congestion. For benign UDP flows, since they do not engage in malicious network congestion, their activity is not significant during network congestion. However, malicious flows generated by congestion-related attacks are often major culprits in network congestion, aiming to congest the target link; they exhibit abnormal activity during network congestion. Therefore, measuring the activity of network flows under congestion can further improve the accuracy of detection. (3) Suspicious flow packet recirculation: After detecting congestion-responsible and congestion-active flows in the Egress Pipeline, the defense scheme considers these flows to be suspicious of congestion-related attacks. The packets of these flows are marked and recirculated into the Ingress Pipeline. User metadata fields marked with `@field_list(index)` are sent to the Parser along with the packets, thus marking congestion-responsible and congestion-active flows. `flow_label` is 0 or 1; 0 indicates that the recirculated packets belong to a congestion-responsible flow, and 1 indicates that the recirculated packets belong to a congestion-active flow. It is worth noting that `@field_list` only supports user-defined metadata fields. The recirculation operation `void recirculate_preserving_field_list(bit)` is called in the Egress Pipeline using the extern function provided by P4. <8> (index) enables the recirculation of suspicious flow data packets.

[0011] 3. Suspicious Flow Reporting. The Ingress Pipeline utilizes standard metadata provided by the programmable switch to determine whether incoming packets are looped packets. The `instance_type` parameter, provided by the standard metadata, distinguishes between newly arrived packets from the port and looped packets. If a packet is looped, it indicates that the network flow to which the packet belongs is a suspicious flow related to congestion attacks; a suspicious flow is either a congestion-responsible flow or a congestion-active flow. In the Ingress Pipeline, digest messages are used to report the flow_ID and flow_label of suspicious flows to the control plane, where flow_ID is the five-tuple in the header of the suspicious flow packet.<srcIP,dstIP,srcPort,dstPort,Protocol> IP src Indicates the source IP address, IP dst Indicates the destination IP address, Port src Port indicates the source port number. dst This indicates the destination port number, and Protocol indicates the protocol field. In the Simple Switch architecture, digest messages are implemented using the nanomsg socket library. The data reported in the digest message is a structure containing all variables, headers, or metadata to be sent to the controller.

[0012] 4. Control Plane Decision-Making. The control plane maintains two lists: a congestion-responsible flow list and a congestion-active flow list. Initially, both lists are empty. Upon receiving a suspicious flow's `flow_ID` and `flow_label` reported in the digest message, the control plane adds the suspicious flow's `flow_ID` to the congestion-responsible flow list and the congestion-active flow list respectively based on the `flow_label`, and then makes a decision. Due to the burstiness of the network, even benign flows can become congestion-responsible flows. Therefore, this scheme only identifies suspicious flows that are simultaneously congestion-responsible and congestion-active flows as malicious flows for congestion-related attacks. That is, if a suspicious flow's `flow_ID` belongs to both the congestion-responsible flow list and the congestion-active flow list, then the suspicious flow is considered a malicious flow for congestion-related attacks.

[0013] 5. Malicious Flow Mitigation. The data plane maintains an Access Control List (ACL) to mitigate malicious flows associated with congestion-related attacks. After identifying a malicious flow related to a congestion-related attack, the control plane issues packet loss rules to the data plane's ACL to intercept the malicious flow's packets, thus defending against congestion-related attacks. Beneficial effects

[0014] The congestion-related attack defense scheme based on queue diagnostics offers good effectiveness, flexibility, scalability, and real-time performance. It can accurately and quickly detect malicious flows of congestion-related attacks in the network and achieve rapid mitigation of the attacks. Furthermore, this scheme has low runtime overhead, requires no additional equipment or network protocol modifications, and is easy to deploy in programmable switches. Attached Figure Description

[0015] Figure 1 The diagram illustrates three queuing scenarios for network traffic data packets: a scenario where the network inflow queuing rate is no greater than the outflow rate, a scenario where the network inflow queuing rate is greater than the outflow rate, and a scenario involving congestion-related attacks.

[0016] Figure 2 This is a flowchart for the control plane decision-making process.

[0017] Figure 3 This is a flowchart of the Ingress Pipeline data plane processing.

[0018] Figure 4 This is a flowchart of the Egress Pipeline data plane processing.

[0019] Figure 5 This is a flowchart illustrating the workflow of a defense scheme against congestion-related attacks based on queue diagnostics. Detailed Implementation

[0020] The invention will be further described below with reference to the accompanying drawings.

[0021] like Figure 5 As shown, the defense scheme for congestion-related attacks based on queue diagnosis mainly includes five steps: control plane pre-configuration (①), network flow monitoring based on queue diagnosis (b and ③), suspicious flow reporting (④), control plane decision-making (⑤), and malicious flow mitigation (⑥).

[0022] The control plane is pre-configured using the P4 Runtime API or P4 Thrift API to set thresholds for network flow monitoring based on queue diagnostics in the data plane, including the packet backlog contribution threshold δ, the activity threshold α, and the thresholds τ and γ for determining congestion status.

[0023] Network flow monitoring based on queue diagnostics includes congestion-responsible flow monitoring and congestion-active flow monitoring, used to monitor and track network flows that should be responsible for network congestion and network flows that are abnormally active during congestion, respectively. Based on the fact that attacks can cause network congestion, congestion-responsible flow monitoring monitors the network queue in real time to identify the responsible flows causing packet backlogs in the queue, thus identifying key culprits of network congestion. Furthermore, congestion-active flow monitoring monitors the activity of network flows under congestion conditions based on the intent and behavior of attacks to create congestion; those network flows that remain active during congestion may be malicious flows attempting to exacerbate the congestion. After detecting congestion-responsible and congestion-active flows in the Egress Pipeline, these flows are considered suspicious flows for congestion-related attacks. The packets of these congestion-responsible and congestion-active flows are marked and then recycled back to the Ingress Pipeline.

[0024] Suspicious flow reporting involves reporting the flow_ID and flow_label of the suspicious flow to the control plane. When a network flow packet arrives at the Ingress Pipeline, the standard metadata provided by the programmable switch is used to determine whether the packet is a looped packet. If it is a looped packet, it indicates that the network flow to which the packet belongs is a suspicious flow related to congestion attacks. The flow_ID and flow_label of the suspicious flow are then reported to the control plane using a digest message.

[0025] The control plane makes decisions based on the suspicious flow's `flow_ID` and `flow_label` reported in the received digest message to identify malicious flows involved in congestion-related attacks. The control plane maintains a list of congestion-responsible flows and a list of congestion-active flows, respectively, and adds the `flow_ID` to both lists based on the `flow_label`. If a suspicious flow's `flow_ID` belongs to both the congestion-responsible flow list and the congestion-active flow list, then the flow is considered a malicious flow involved in a congestion-related attack.

[0026] Malicious flow mitigation is achieved by mitigating congestion-related malicious flows based on ACLs maintained by the data plane. The rules in the ACLs are issued by the control plane after identifying malicious flows that are related to congestion attacks.

[0027] Figure 1 This diagram illustrates three queuing scenarios for network traffic packets: a scenario where the inbound queuing rate is no greater than the outbound rate, a scenario where the inbound queuing rate is greater than the outbound rate, and a scenario involving congestion-related attacks. The network queue, which buffers data packets, is a fundamental component of a network. Most packet delays and losses in the network are caused by packet backlog in the network queue. Therefore, the congestion status of a network link can be reflected by the queuing of data packets in network devices. When there is a severe backlog of data packets in the network queue, it indicates that the network link is under severe congestion. When the inbound queuing rate is no greater than the outbound rate, there is no packet backlog in the network queue, and no congestion occurs. When the inbound queuing rate is greater than the outbound rate, there will be a packet backlog in the network queue, and congestion will occur. Under conditions of sufficient network resources, the network queue is usually in scenario 1. However, network traffic bursts can occur, thus scenario 2 also exists. Due to sufficient network resources, even if there is a certain degree of packet backlog in the network queue, it can be gradually cleared within a short period of time. In congestion-related attack scenarios, malicious traffic may be mixed in with the incoming traffic to the network queue. This can cause the inflow rate to far exceed the outflow rate, leading to severe queue congestion and even queue overflow, resulting in packet loss. In such cases, network performance will degrade significantly.

[0028] Figure 2The control plane decision-making flowchart is as follows. The control plane maintains two lists: a congestion-responsible flow list and a congestion-active flow list, both initially empty. When the control plane receives suspicious flow information reported in a digest message, it retrieves the flow_ID and flow_label of the suspicious flow from the digest message. If the flow_label identifies a congestion-responsible flow, the flow_ID is added to the congestion-responsible flow list. Similarly, if the flow_label identifies a congestion-active flow, the flow_ID is added to the congestion-active flow list. Finally, if the flow_ID belongs to both the congestion-responsible flow list and the congestion-active flow list, the suspicious flow is considered a malicious flow involved in a congestion-related attack, and mitigation rules are issued to the data plane.

[0029] Figure 3 This is a flowchart of the Ingress Pipeline data plane processing. When a network flow packet arrives at the Ingress Pipeline, the ACL is used to determine whether the corresponding flow_ID of the packet belongs to a malicious flow involved in a congestion-related attack. If the packet belongs to a malicious flow involved in a congestion-related attack, mitigation actions are performed. Otherwise, the packet type is obtained from the standard metadata. If the packet is a packet that is looping back to the Ingress Pipeline, it indicates that the network flow to which the packet belongs is a suspicious flow, and the flow_ID and flow_label of the packet are reported to the control plane using a digest message.

[0030] Figure 4 This is a flowchart of the Egress Pipeline data plane processing. When a network flow packet arrives at the Egress Pipeline, packet and queue information is obtained, including the packet's flow_ID, timestamp, queue depth, and queuing time. Then, congestion responsibility flow monitoring and congestion active flow monitoring are performed. In congestion responsibility flow monitoring, the packet backlog contribution of the corresponding flow is first calculated. If the packet backlog contribution is greater than a threshold δ, a flow_label is recorded, marking the flow as a congestion responsibility flow, and the packet is then looped back to the Ingress Pipeline. In congestion active flow monitoring, the activity of the corresponding flow under congestion is first calculated. If the activity under congestion is greater than a threshold α, a flow_label is recorded, marking the flow as a congestion active flow, and the packet is then looped back to the Ingress Pipeline.

Claims

1. A defense scheme against congestion-related attacks based on queue diagnosis, characterized in that, Attacks that maliciously create network link congestion are called congestion-related attacks. These can be divided into two categories: one is attacks that directly manipulate protocol vulnerabilities to create congestion, and the other is attacks that generate attack data streams to create network link congestion, while simultaneously triggering protocol vulnerabilities to enhance the effect. Defense schemes against congestion-related attacks include the following steps: Step 1, Control plane pre-configuration: Before running the defense scheme against congestion-related attacks based on queue diagnosis, the control plane uses the P4 Runtime API or P4 Thrift API to set the thresholds to be used by the defense scheme to the data plane, including the packet backlog contribution threshold δ, the activity threshold α, and the thresholds τ and γ for determining the congestion state. The data plane uses registers to store the above thresholds configured by the control plane. Step 2, Network Flow Monitoring Based on Queue Diagnostics: Perform queue diagnostics in the egress pipeline of the programmable switch to monitor network flows passing through the switch. This includes three steps: Step 2.1: Congestion-responsible flow monitoring. When a network flow passes through a network queue, if the inbound rate of the network flow is greater than the outbound rate, the network flow's data packets will accumulate in the network queue, causing network congestion. Monitoring the contribution of data packet backlog during the network flow's passage through the network queue identifies the congestion-responsible flow. The definition of a congestion-responsible flow is: given a data packet backlog contribution threshold δ, within a time range (t... s ,t e Within, if the flow i Data packet backlog contribution i If the value is greater than the threshold δ, it is considered a flow. i It is the time range (t) s ,t e Congestion responsibility flow within; Step 2.2: Monitoring Congestion-Active Flows. Attackers use congestion-related attacks to block network links. Compared to benign flows in the network, malicious flows exhibit stronger activity during network congestion. Monitoring the activity of network flows under congestion conditions helps identify congestion-active flows. A congestion-active flow is defined as: given an activity threshold α, within a time range (t... s ,t e Within, if the flow i Activity in a congested state i If the value is greater than the threshold α, it is considered a flow. i It is the time range (t) s ,t e Congested active flow within; Step 2.3: Suspicious flow data packet recirculation. After detecting congestion-responsible flows and congestion-active flows in the egress pipeline, the data packets of the congestion-responsible flows and congestion-active flows are marked and recirculated to the ingress pipeline. The marking information is 0 or 1, carried by the user metadata marked by @field_list(index). 0 indicates that the flow to which the recirculated data packet belongs is the congestion-responsible flow, and 1 indicates that the flow to which the recirculated data packet belongs is the congestion-active flow. Step 3: Suspicious Flow Reporting: Using standard metadata provided by the programmable switch in the ingress pipeline, determine whether the incoming data packets are looped packets. If they are looped packets, it indicates that the network flow to which the packet belongs is a suspicious flow related to congestion attacks. Suspicious flows are either congestion-responsible flows or congestion-active flows. In the ingress pipeline, a digest message is used to report the flow ID and tagging information of the suspicious flow to the control plane. The flow ID of the suspicious flow is the five-tuple in the header of the suspicious flow data packet. <IP src IP dst Port src Port dst Protocol>, IP src Indicates the source IP address, IP dst Indicates the destination IP address, Port src Port indicates the source port number. dst Indicates the destination port number; Protocol indicates the protocol field. Step 4, Control Plane Decision: The control plane maintains two lists: the congestion responsibility flow list and the congestion active flow list. Initially, both lists are empty. After receiving the flow ID and tag information of a suspicious flow reported by the digest information, the control plane adds the flow ID of the suspicious flow to the congestion responsibility flow list and the congestion active flow list respectively according to the tag information, and makes a decision. If the flow ID of a suspicious flow belongs to both the congestion responsibility flow list and the congestion active flow list, then the suspicious flow is considered to be a malicious flow of congestion-related attack. Step 5, Malicious Flow Mitigation: After the control plane identifies a malicious flow that is related to congestion attacks, it sends packet loss rules to the data plane to intercept the data packets of the malicious flow.

2. The defense scheme according to claim 1, characterized in that, In step 2.1, the contribution of packet backlog is defined as: within the time range (t) s ,t e Within the network queue, a total of n flows passed through it. i By m i It consists of data packets, for a time range (t) j ,t j+1 Inside, t j and t j+1 Satisfy t j ∈(t s ,t e ) and t j+1 ∈(t s ,t e There are a total of x j The data packets passed through the network queue, in this x j In each data packet, each flow i The proportion is r i j ,satisfy Time range (t) j ,t j+1 The queue depth within the specified range changes by Δq_depth. j Then flow i The contribution of the packet backlog is r i j ×Δq_depth j ; within the time range (t) s ,t e ] within, flow i Data packet backlog contribution i for:

3. The defense scheme according to claim 1, characterized in that, In step 2.2, the activity of network flows under congestion is defined as: within the time range (t... s ,t e Within the network queue, a total of n flows passed through it. i By m i Composed of data packets, given thresholds τ and γ for determining congestion, if the flow... i data packets When passing through the network queue, its queuing time Greater than the threshold τ, or the queue depth of the network queue If the value is greater than the threshold γ, then the data packet is considered to be... When passing through the network queue, the network is in a congested state, within the time range (t). s ,t e Within ], for each flow i Its activity under congestion i for:

Images