A data processing method, device, program product, storage medium

Abstract

The application provides a data processing method, device, program product and storage medium. The method comprises the following steps: receiving first cloud access traffic, wherein the first cloud access traffic comprises N first packets, N is a positive integer; performing rate limiting processing on the first cloud access traffic to obtain second cloud access traffic, wherein the second cloud access traffic comprises M first packets, M is a positive integer, and M is less than or equal to N; processing the first packets in the second cloud access traffic to obtain first security packets, wherein the first security packets comprise a security header field; and sending third cloud access traffic to a cloud resource pool, wherein the third cloud access traffic comprises a first security packet corresponding to each first packet in the second cloud access traffic. In this way, the first cloud access traffic is first rate limited and then processed, the overall processing efficiency is improved, the first packets are generated into corresponding first security packets, the safety of the transmission process is ensured, and the network performance is improved.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a data processing method, device, program product, and storage medium. Background Technology

[0002] With the rapid development of cloud computing and hybrid cloud architectures, cloud data centers face increasingly complex cybersecurity threats, particularly distributed denial-of-service (DDoS) attacks, man-in-the-middle (MIMT) attacks, and traffic hijacking. Traditional traffic scrubbing solutions generally adopt a bypass deployment model, with their core mechanism relying on the traffic classification and policy routing matching functions of the core router. However, this traditional architecture has the following significant drawbacks: the BGP protocol itself lacks a strong authentication mechanism, allowing attackers to exploit BGP protocol vulnerabilities to publish false routing announcements, redirecting legitimate traffic to malicious nodes, leading to serious data leaks or service interruptions. It also exposes the internal network topology, enabling attackers to launch precise resource exhaustion attacks against DDoS protection devices. Furthermore, in high-throughput scenarios, the hop-by-hop matching mechanism of PBR can cause excessive CPU load on the core router, affecting overall network performance and potentially overloading DDoS protection devices. Summary of the Invention

[0003] To address the aforementioned technical problems, embodiments of this application provide a data processing method, apparatus, program product, and storage medium.

[0004] The data processing method provided in this application includes: Receive the first inbound cloud traffic, which includes N first messages, where N is a positive integer; The first inbound cloud traffic is rate-limited to obtain the second inbound cloud traffic, which includes M first packets, where M is a positive integer and M is less than or equal to N. The first packet in the second inbound cloud traffic is processed to obtain a first security packet, which includes a security header field; The third inbound traffic is sent to the cloud resource pool, and the third inbound traffic includes the first security message corresponding to each first message in the second inbound traffic.

[0005] The data processing method provided in this application includes: Receive third inbound cloud traffic, the third inbound cloud traffic including multiple first security messages, the first security message including a security header field and an Ethernet frame; Decapsulate the first security message to obtain the Ethernet frame corresponding to the first security message.

[0006] The data processing apparatus provided in this application includes a processor and a memory, wherein the memory is used to store computer programs, and the processor is used to call and run the computer programs stored in the memory to execute any of the above-described data processing methods.

[0007] This application provides a computer program product, comprising: a computer program that, when executed by a processor, implements any of the above-described data processing methods.

[0008] The computer-readable storage medium provided in this application is used to store a computer program that causes a computer to perform any of the above-described data processing methods.

[0009] In the technical solution of this application, a first inbound cloud traffic is received, which includes N first packets, where N is a positive integer; the first inbound cloud traffic is rate-limited to obtain a second inbound cloud traffic, which includes M first packets, where M is a positive integer and M is less than or equal to N; the first packets in the second inbound cloud traffic are processed to obtain a first security packet, which includes a security header field; a third inbound cloud traffic is sent to a cloud resource pool, which includes the first security packet corresponding to each first packet in the second inbound cloud traffic. Thus, by first rate-limiting the first inbound cloud traffic before processing, the overall processing efficiency is improved, and by generating the corresponding first security packet from the first packet, the security of the transmission process is ensured, thereby improving network performance. Attached Figure Description

[0010] The accompanying drawings, which are provided to further illustrate this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application.

[0011] Figure 1 This is a flowchart illustrating the data processing method provided in the embodiments of this application. Figure 1 ; Figure 2 This is a flowchart illustrating the data processing method provided in the embodiments of this application. Figure 2 ; Figure 3 This is a schematic diagram of the inbound traffic flow provided in the embodiments of this application. Figure 1 ; Figure 4 This is a schematic diagram of the inbound traffic flow provided in the embodiments of this application. Figure 2 ; Figure 5 This is a schematic diagram of the structural composition of the data processing apparatus provided in the embodiments of this application. Figure 1 ; Figure 6 This is a schematic diagram of the structural composition of the data processing apparatus provided in the embodiments of this application. Figure 2 ; Figure 7 This is a schematic structural diagram of a data processing device provided in an embodiment of this application; Figure 8 This is a schematic structural diagram of the chip according to an embodiment of this application. Detailed Implementation

[0012] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0013] In the following description, the term "some embodiments" refers to a subset of all possible embodiments. However, it is understood that "some embodiments" can be the same or different subsets of all possible embodiments and can be combined with each other without conflict. It should also be noted that the terms "first," "second," and "third" used in the embodiments of this application are only used to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first," "second," and "third" can be interchanged in a specific order or sequence where permissible, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein. The term "and / or" in this document is merely a description of the association relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship. It should also be understood that the "instruction" mentioned in the embodiments of this application can be a direct instruction, an indirect instruction, or an indication of an association relationship. For example, A instructing B can mean that A directly instructs B, for example, B can obtain information through A; it can also mean that A indirectly instructs B, for example, A instructs C, and B can obtain information through C; it can also mean that there is an association between A and B. It should also be understood that the term "correspondence" mentioned in the embodiments of this application can mean that there is a direct or indirect correspondence between the two, or that there is an association between the two, or that there is an instruction and being instructed, configuration and being configured, etc.

[0014] To facilitate understanding of the technical solutions of the embodiments of this application, the relevant technologies of the embodiments of this application are described below. The following relevant technologies are optional solutions and can be combined with the technical solutions of the embodiments of this application in any way, and they all fall within the protection scope of the embodiments of this application.

[0015] Some solutions provide a method and system for traffic scheduling in Distributed Denial of Service (DDoS) attacks based on the Border Gateway Protocol (BGP). The method includes: when a target Internet Protocol address (IP address) is detected to be under DDoS attack, a control center generates a BGP route advertisement instruction; the BGP route advertisement containing the target IP address is sent to upstream network devices, diverting traffic destined for the target IP address to a scrubbing center; the traffic is scrubbed at the scrubbing center; and when the attack ends, the control center cancels the BGP route advertisement. This achieves dynamic, on-demand traffic scheduling, improves defense efficiency, and reduces resource waste.

[0016] In other solutions, a method, apparatus, and system for scheduling DDoS attack traffic are provided, relating to the field of network security technology. The method includes: a Software-Defined Networking (SDN) controller detecting a DDoS attack; generating a traffic scheduling policy based on attack characteristics, the policy specifying that traffic matching specific characteristics should be redirected to a scrubbing device; distributing flow table rules to a network switching device via a control protocol; and the network switching device redirecting the traffic according to the flow table rules. This achieves fine-grained traffic scheduling and automated response, improving the flexibility and efficiency of network protection.

[0017] Both solutions generally follow a "detection -> diversion -> cleaning" process. The cleaning equipment is the first physical entity to directly face the massive amount of raw traffic and is easily overwhelmed by extremely high traffic volumes. The core objective is efficient scheduling and diversion, accurately sending abnormal traffic to the cleaning center, but it does not address the security issues that arise during traffic transmission along the path.

[0018] With the rapid development of cloud computing and hybrid cloud architectures, cloud data centers face increasingly complex cybersecurity threats, particularly distributed denial-of-service (DDoS) attacks, man-in-the-middle (MITM) attacks, and traffic hijacking. Traditional traffic scrubbing solutions generally adopt a bypass deployment model, with their core mechanism relying on the traffic classification and policy routing matching functions of the core router. However, this traditional architecture has the following significant drawbacks: (1) Risk of BGP route hijacking: In traditional architectures, rate-limiting gateways and DDoS protection devices typically use the BGP protocol to publish routing information and redirect traffic. However, because the BGP protocol itself lacks a strong authentication mechanism, attackers can exploit vulnerabilities to publish fake routing announcements, redirecting legitimate traffic to malicious nodes, leading to serious data breaches or service outages.

[0019] (2) Complexity of PBR strategy: Existing solutions heavily rely on the static configuration of Policy-Based Routing (PBR) on core routers, requiring explicit specification of the physical interface IPs of next-hop devices such as rate-limiting gateways and DDoS protection devices. This design not only exposes the internal network topology, enabling attackers to launch precise resource exhaustion attacks against DDoS protection devices, but also, in high-throughput scenarios, PBR's hop-by-hop matching mechanism can lead to excessive CPU load on core routers, impacting overall network performance.

[0020] (3) Overload protection for DDoS protection devices: When abnormal traffic enters the cleaning equipment without rate limiting, the sudden surge in traffic can easily exceed the design capacity of the anti-DDoS device. For example, an anti-DDoS device with a processing capacity of 100Gbps will inevitably experience service interruption if it encounters an attack traffic of 200Gbps.

[0021] Therefore, it is necessary to address security issues such as BGP hijacking, MITM attacks, and traffic eavesdropping to achieve "schedule-as-security," while also reducing the load and overload risk of cleaning equipment. Thus, how to reduce invalid traffic redirection, ensure the security of transmitted data, and improve overall traffic processing efficiency has become a problem that needs to be considered in the cloud computing field. To this end, the following technical solutions are proposed in the embodiments of this application.

[0022] Figure 1 This is a flowchart illustrating the data processing method provided in the embodiments of this application. Figure 1 ,like Figure 1 As shown, the data processing method includes the following steps: Step 101: Receive the first inbound cloud traffic, which includes N first messages, where N is a positive integer.

[0023] Step 102: Rate-limit the first inbound cloud traffic to obtain the second inbound cloud traffic. The second inbound cloud traffic includes M first packets, where M is a positive integer and M is less than or equal to N.

[0024] Step 103: Process the first packet in the second inbound cloud traffic to obtain the first security packet, which includes a security header field.

[0025] Step 104: Send the third inbound traffic to the cloud resource pool. The third inbound traffic includes the first security message corresponding to each first message in the second inbound traffic.

[0026] Here, this method is applied to a rate-limiting gateway. The rate-limiting gateway receives the first inbound cloud traffic, which is the initial inbound cloud traffic. The first inbound cloud traffic consists of N first packets, where N is a positive integer. After receiving the first inbound cloud traffic, the rate-limiting gateway performs rate-limiting processing. The first inbound cloud traffic after rate-limiting is the second inbound cloud traffic, which consists of M first packets, where M is a positive integer, and M is less than or equal to N.

[0027] For example, the rate limiting gateway implements dynamic rate limiting based on the token bucket algorithm. This application does not specifically limit the particular rate limiting method used.

[0028] In this way, by placing the rate-limiting gateway at the network edge, the proportion of invalid scrubbing traffic can be significantly reduced and the CPU load on the core router can be alleviated.

[0029] In some implementations, sending the third inbound traffic to the cloud resource pool includes: sending the third inbound traffic to the cloud resource pool via a Virtual Extensible Local Area Network (VXLAN) tunnel.

[0030] In some implementations, the rate-limiting gateway and the cloud resource pool are connected via a Virtual Extensible Local Area Network (VXLAN) tunnel. The rate-limiting gateway acts as the sender of the VXLAN tunnel, and the cloud resource pool acts as the receiver. Therefore, after the rate-limiting gateway generates the second inbound traffic, each first packet in the second inbound traffic needs to be processed to obtain the corresponding first secure packet. The first secure packet is a secure VXLAN packet, with a security header field added to it. The security header field can protect the packet's integrity, authenticity, and replay protection.

[0031] In this way, a dynamic VXLAN tunnel is established between the rate-limiting gateway and the cloud resource pool, encapsulating the raw traffic into a load balancer (overlay) network with a specific VNI for transmission. By replacing traditional PBR policy routing with VXLAN tunneling technology, logical network abstraction and topology hiding can be achieved. Specifically, only the VXLAN TunnelEndpoint (VTEP) address is exposed externally, hiding the underlying network physical topology and device physical port IPs, greatly reducing the attack surface and improving overall network security. The VTEP address can be understood as the "identity card" and "address" of each node in the VXLAN network. VXLAN adapts to the isolation and expansion needs of multi-tenant and multi-service scenarios, thereby avoiding the problem of the proliferation of traditional PBR policies. Traffic scheduling policies no longer rely on IP addresses strongly associated with the physical topology, but instead achieve logical traffic redirection by flexibly defining the mapping relationship between VNI virtual network identifiers and VTEPs, greatly simplifying network management and automated deployment.

[0032] In some implementations, processing the first packet in the second inbound traffic to obtain the first security packet includes: The VXLAN header field corresponding to the first message is determined based on the first message and the preset mapping rules. The VXLAN header field includes a Virtual Network Identifier (VNI). The preset mapping rules include a mapping sub-rule between the source VTEP address and the virtual network identifier and a mapping sub-rule between the virtual network identifier and the destination VTEP address. Determine the sequence number and Security Protocol Identifier (SPI) corresponding to the first message; The first message verification code corresponding to the first message is determined based on the first message, the first preset session key, the sequence number, and the security protocol identifier; The security header field corresponding to the first message is determined based on the first message, the first message verification code, the sequence number, and the security protocol identifier; The first security message is determined based on the security header field, the VXLAN message header field, the preset mapping rule, and the first message.

[0033] In some implementations, the rate-limiting gateway first generates the VXLAN header field corresponding to the first packet, then constructs the security header field corresponding to the first packet, completes the outer encapsulation to obtain the first secure packet, and forwards the first secure packet. In this way, while constructing the VXLAN packet, security fields are injected, i.e., the first secure packet is constructed, thereby achieving protection for packet integrity, authenticity, and replay prevention. Furthermore, all processing is completed at the hardware layer at line speed, ensuring no loss in throughput or latency performance.

[0034] In some implementations, preset mapping rules are issued by the control plane to the rate limiting gateway, including mapping sub-rules for the source VTEP address and the Virtual Network Identifier (VNI) and mapping sub-rules for the VNI and the destination VTEP address.

[0035] It can be understood that the source VTEP address and destination VTEP address are the endpoint addresses of the VXLAN tunnel. That is, the source VTEP address is determined by the sending device, and the destination VTEP address is determined by the receiving device. In other words, the source VTEP address is determined by the rate-limiting gateway, and the destination VTEP address is determined by the cloud resource pool.

[0036] Here, the VNI corresponding to the first packet is determined according to the mapping sub-rule of the source VTEP address and VNI, the destination VTEP address is determined according to the mapping sub-rule of the destination VTEP address of the VNI, and the destination VTEP address is encapsulated in the destination IP address in the outer IP header.

[0037] In some implementations, the structure of the first secure message includes a standard outer Ethernet / IP / UDP header field, a VXLAN header field, a security header field, an Ethernet frame, and a Frame Check Sequence (FCS) field. The security header field can also be called the Security Context Header (SCH), and the Ethernet frame refers to the Ethernet frame in the first message, also known as the raw payload or the raw internal Ethernet frame; that is, the data information to be transmitted in each first message of the first inbound traffic.

[0038] Specifically, the structure of the first security message is as follows: [Standard outer Ethernet / IP / UDP header | VXLAN header (8 bytes) | Security Context Header (SCH) | Raw inner Ethernet frame | FCS].

[0039] It is understood that the first security message in this application adds a security header field compared to the VXLAN message, and the first message includes an Ethernet frame.

[0040] In some implementations, determining the first message verification code corresponding to the first message based on the first message, the first preset session key, the sequence number, and the security protocol identifier includes: determining the first message verification code corresponding to the first message based on the Ethernet frame in the first message, the sequence number corresponding to the first message, the first preset session key, and the security protocol identifier. Here, the first message verification code can also be referred to as the first MAC value.

[0041] Specifically, the original Ethernet frame, the current sequence number (SN), and the pre-configured session key (Key) are concatenated to form the data to be calculated; the hash calculation unit (such as CRC32 or SHA-256 hardware engine) built into the switching chip in the rate-limiting gateway is used to generate the MAC value according to the algorithm specified by SPI, that is, to generate the first message verification code corresponding to the first packet.

[0042] Here, the first preset session key corresponds to the sending device, that is, to the rate limiting gateway. For example, the first preset session key is preset for the rate limiting gateway, and the current sequence number is also the sequence number generated by the rate limiting gateway for the first message.

[0043] In some implementations, the security header field includes one or more of the following information: Security Parameters Index (SPI), version identifier, type identifier, serial number, and message verification code.

[0044] The SPI (Security Authentication Code) is a 1-byte field used to identify the security algorithm and mode (e.g., 0x01 represents SHA-256-HMAC, 0x02 represents Advanced Encryption Standard (AES)-GMAC, etc.). The receiver uses this field to select the corresponding verification algorithm and key. Here, the SPI corresponds to the sending device and is preset in the sending device; that is, the sending device determines the SPI of the message. The version identifier and type identifier correspond to the first message, and the corresponding version identifier and type identifier are generated according to the type of the first message. The sequence number (SN) is a 4-byte monotonically increasing counter used to uniquely identify messages within a secure session and defend against replay attacks. Here, the SN is the sequence number written into the secure message by the sending end; that is, the rate-limiting gateway generates the corresponding SN and writes it into the first secure message. The Message Authentication Code (MAC, variable length) is an integrity check value calculated by the sending end based on the internal message. The length depends on the algorithm specified by the SPI (e.g., 32 bytes for SHA-256-HMAC).

[0045] In some implementations, the corresponding version identifier and type identifier are determined based on the first message, and the security header field corresponding to the first message is determined based on the version identifier, type identifier, first message verification code, serial number and security protocol identifier.

[0046] In some implementations, the VXLAN header field and the security header field (including SPI, SN and the calculated MAC) are added in sequence, and then the first security message is obtained after standard UDP / IP / Ethernet encapsulation. The first security message is then forwarded.

[0047] In some implementations, sending the third inbound traffic to the cloud resource pool includes: The third inbound cloud traffic is sent to the cloud resource pool via the core router, which is used to determine whether the third inbound cloud traffic is abnormal.

[0048] In some implementations, after the rate limiting gateway performs the aforementioned process for each first packet to obtain the corresponding first security packet, it constitutes the third inbound cloud traffic and sends the third inbound cloud traffic to the core router. The core router is used to determine whether the third inbound cloud traffic is abnormal traffic. If the third inbound cloud traffic is not abnormal traffic, the third inbound cloud traffic is sent to the cloud resource pool.

[0049] In some implementations, after the rate-limiting gateway identifies the third inbound cloud traffic, it sends the third inbound cloud traffic to the core router. The core router determines whether the third inbound cloud traffic is abnormal. If the third inbound cloud traffic is not abnormal, it sends the third inbound cloud traffic to the cloud resource pool, which is the receiving end of the VXLAN tunnel. If the third inbound cloud traffic is abnormal, it sends the third inbound cloud traffic to the first device, which is used to clean the third inbound cloud traffic.

[0050] In some implementations, after the first device completes traffic scrubbing, it performs traffic reinjection, sending the scrubbing third inbound traffic to the core router to re-evaluate whether the reinjected traffic is abnormal.

[0051] In some implementations, the first device may be an anti-DDoS cleaning device.

[0052] Here, after the rate-limiting gateway receives the initial inbound traffic, it first performs rate-limiting on the initial inbound traffic. Then, it constructs the corresponding first security message. Based on the constructed first security message, it determines the third inbound traffic and sends it to the core router. The core router classifies the traffic, that is, it determines whether the third inbound traffic is abnormal traffic. If it is abnormal traffic, it redirects it to the anti-DDoS cleaning device for fine cleaning. After cleaning, it is injected back into the core router and finally forwarded to the cloud resource pool. A solution based on "pre-rate limiting - traffic classification - on-demand cleaning" is implemented. This reduces the pressure on the cleaning equipment. The rate-limiting gateway, as the first-level traffic filter, can effectively smooth burst traffic and prevent the anti-DDoS cleaning equipment from being overwhelmed by massive invalid requests, significantly reducing its overload risk and improving system reliability and service continuity. It optimizes processing efficiency by reducing the number of queries to core router policies and optimizing data forwarding paths, effectively reducing overall processing latency and improving overall throughput performance under high load scenarios. It improves resource utilization by pre-filtering junk traffic through the rate-limiting gateway, significantly reducing the invalid computational consumption of the anti-DDoS cleaning equipment and improving cleaning efficiency and resource utilization. Scalability is enhanced by the layered and decoupled design, which facilitates future horizontal expansion of the number of rate-limiting gateways and cleaning equipment to adapt to the ever-growing network scale and attack intensity.

[0053] In some implementations, the core router determines whether the third inbound cloud traffic is abnormal based on the first information of the third inbound cloud traffic. The first information includes one or more of the following: the five-tuple information of the third inbound cloud traffic, the flow rate information of the third inbound cloud traffic, the connection behavior characteristic information of the third inbound cloud traffic, the destination address and source address information of the third inbound cloud traffic, and the packet characteristic information of the third inbound cloud traffic.

[0054] For example, if the flow rate of the third inbound cloud traffic after the rate limit is greater than the first preset rate, the third inbound cloud traffic is considered to be abnormal traffic.

[0055] In some implementations, the cloud resource pool determines whether the sequence number of the first security message is a pre-received sequence number; if the sequence number of the first security message is not a pre-received sequence number, the first security message is deleted; if the sequence number of the first security message is a pre-received sequence number, a second message verification code corresponding to the first security message is determined based on the security protocol identifier, the first security message, the sequence number, and the second preset session key; if the second message verification code and the first message verification code are consistent, the first security message is not deleted; if the second message verification code and the first message verification code are inconsistent, the first security message is deleted.

[0056] Here, the process first determines whether the first security message needs to be deleted based on its sequence number. Specifically, it checks whether the sequence number of the first security message is a pre-received sequence number, i.e., whether the first security message is a replay message. If the sequence number of the first security message is not a pre-received sequence number, then the first security message is a replay message, and it can be deleted directly. If the first security message is not a replay message, then the second message verification code corresponding to the first security message is determined based on the security protocol identifier, the first security message, the sequence number, and the second preset session key. The integrity of the first security message is determined by comparing the second message verification code with the first message verification code, i.e., whether the first security message has been tampered with during transmission. If the second message verification code and the first message verification code are the same, it means that the first security message has not been tampered with, and it is not deleted. If the second message verification code and the first message verification code are different, it means that the first security message has been tampered with, and it is deleted.

[0057] In some implementations, when the cloud resource pool receives a third inbound traffic that is not abnormal, it parses each first security message in the third inbound traffic to determine the corresponding Ethernet frame and forwards the Ethernet frame.

[0058] In some implementations, the cloud resource pool determines the security header field from the first security message. Based on the security header field, it performs anti-replay checks and integrity verification on the first security message. If the verification passes, it obtains the Ethernet frame from the first security message and forwards it subsequently. If the verification fails, the first security message is deleted. It can be understood that the Ethernet frame is the data information to be sent in the original traffic. The replay check here determines whether the first security message is a replay message, that is, whether the sequence number of the first security message is a pre-received sequence number.

[0059] In some implementations, the cloud resource pool parses the standard outer header field and VXLAN header field of the first security message to obtain the security header field of the first security message. Based on the sequence number in the security header field, it determines whether the first security message is a replay message. When the sequence number is within the valid receive window, that is, when the sequence number is the pre-received sequence number, the integrity of the first security message is verified. When the sequence number is not within the valid receive window, that is, when the sequence number is not the pre-received sequence number, the first security message is determined to be a replay message and is directly discarded. For example, if the sequence number is less than the already received sequence number, it is determined to be a replay message.

[0060] In some implementations, the local security context is searched based on information such as the SPI and source address in the message to obtain the expected next sequence number. If the SN of the message is not within the valid receiving window (e.g., less than the already received sequence number), it is determined to be a replay message and is discarded directly.

[0061] Specifically, the receiving end maintains a current receiving window in its local security context to record the largest valid sequence number already received and the range of sequences allowed to be received. Upon receiving a new message, the receiving end compares the sequence number (SN) carried in the message with the local expected sequence number and the receiving window: if the SN is too old, duplicated, or exceeds the valid window, it indicates that the message may be a replay message and should be discarded directly; if the SN is within the allowed range, integrity verification and subsequent processing continue.

[0062] Here, the SN is the sequence number carried by the sender in the security message. The reason the receiver first obtains the "expected next sequence number" is for replay prevention checks. The receiver maintains a current receive window in its local security context to record the largest valid sequence number already received and the allowed sequence range. Upon receiving a new message, the receiver compares the SN carried in the message with the local expected sequence number and receive window: if the SN is too old, duplicated, or exceeds the valid window, the message may be a replay message and should be discarded; if the SN is within the allowed range, integrity checks and subsequent processing continue. In other words, the receiver pre-maintains the expected receive sequence number and receive window for the corresponding security context and compares the SN in the message with the expected sequence number to determine whether the message is a duplicate, expired, or valid new message, thereby achieving replay prevention checks.

[0063] In some implementations, the cloud resource pool uses the algorithm specified by the security protocol identifier in the security header field and the corresponding locally stored key to recalculate the second message verification code, i.e., the second MAC value, on the original intrinsic Ethernet frame and SN of the first security message. The second message verification code is then compared with the first message verification code carried in the first security message. If they match, the first security message has not been tampered with; if they do not match, the first security message is considered tampered with and is deleted. Here, the locally stored corresponding key is a second preset security key, determined by the receiving end. It can be understood that the first preset security key and the second preset security key correspond to each other to achieve secure message verification.

[0064] This is understandable; the integrity verification of the first message is being performed here.

[0065] In some implementations, after successful verification, the cloud resource pool obtains the Ethernet frame from the first security message and forwards it subsequently.

[0066] The technical solution provided in this application embodiment receives first inbound cloud traffic, which includes N first packets, where N is a positive integer; the first inbound cloud traffic is rate-limited to obtain second inbound cloud traffic, which includes M first packets, where M is a positive integer and M is less than or equal to N; the first packets in the second inbound cloud traffic are processed to obtain first security packets, which include a security header field; and a third inbound cloud traffic is sent to a cloud resource pool, which includes the first security packets corresponding to each first packet in the second inbound cloud traffic. Thus, by first rate-limiting the first inbound cloud traffic before processing, overall processing efficiency is improved, and the generation of corresponding first security packets from the first packets ensures the security of the transmission process and improves network performance.

[0067] Figure 2 This is a flowchart illustrating the data processing method provided in the embodiments of this application. Figure 2 ,like Figure 2 As shown, the data processing method includes the following steps: Step 201: Receive third inbound cloud traffic, which includes multiple first security messages, each of which includes a security header field and an Ethernet frame.

[0068] Step 202: Decapsulate the first security message to obtain the Ethernet frame corresponding to the first security message.

[0069] Here, the method is applied to a cloud resource pool, which receives third-party inbound traffic sent by a rate-limiting gateway.

[0070] In some implementations, the rate-limiting gateway sends the third inbound traffic to the cloud resource pool via a VXLAN tunnel.

[0071] In some implementations, the rate-limiting gateway and the cloud resource pool are connected via a VXLAN tunnel, with the rate-limiting gateway acting as the sender and the cloud resource pool as the receiver. Therefore, after the rate-limiting gateway generates the second inbound traffic, each first packet in the second inbound traffic needs to be processed to obtain a corresponding first secure packet. This first secure packet is a secure VXLAN packet, with a security header field added to it. This security header field provides protection for packet integrity, authenticity, and replay protection.

[0072] In this way, a dynamic VXLAN tunnel is established between the rate-limiting gateway and the cloud resource pool, encapsulating the raw traffic into a load balancer (overlay) network with a specific VNI for transmission. By replacing traditional PBR policy routing with VXLAN tunneling technology, logical network abstraction and topology hiding can be achieved. Specifically, only the VXLAN TunnelEndpoint (VTEP) address is exposed externally, hiding the underlying network physical topology and device physical port IPs, greatly reducing the attack surface and improving overall network security. The VTEP address can be understood as the "identity card" and "address" of each node in the VXLAN network. VXLAN adapts to the isolation and expansion needs of multi-tenant and multi-service scenarios, thereby avoiding the problem of the proliferation of traditional PBR policies. Traffic scheduling policies no longer rely on IP addresses strongly associated with the physical topology, but instead achieve logical traffic redirection by flexibly defining the mapping relationship between VNI virtual network identifiers and VTEPs, greatly simplifying network management and automated deployment.

[0073] In some implementations, the rate-limiting gateway sends the third inbound traffic to the cloud resource pool via a core router, whereby the core router determines whether the third inbound traffic is abnormal. That is, the cloud resource pool receives the third inbound traffic sent by the rate-limiting gateway via the core router.

[0074] In some implementations, after the rate limiting gateway performs the aforementioned process for each first packet to obtain the corresponding first security packet, it constitutes the third inbound cloud traffic and sends the third inbound cloud traffic to the core router. The core router is used to determine whether the third inbound cloud traffic is abnormal traffic. If the third inbound cloud traffic is not abnormal traffic, the third inbound cloud traffic is sent to the cloud resource pool.

[0075] In some implementations, after the rate-limiting gateway identifies the third inbound cloud traffic, it sends the third inbound cloud traffic to the core router. The core router determines whether the third inbound cloud traffic is abnormal. If the third inbound cloud traffic is not abnormal, it sends the third inbound cloud traffic to the cloud resource pool, which is the receiving end of the VXLAN tunnel. If the third inbound cloud traffic is abnormal, it sends the third inbound cloud traffic to the first device, which is used to clean the third inbound cloud traffic.

[0076] In some implementations, after the first device completes traffic scrubbing, it performs traffic reinjection, sending the scrubbing third inbound traffic to the core router to re-evaluate whether the reinjected traffic is abnormal.

[0077] In some implementations, the first device may be an anti-DDoS cleaning device.

[0078] Here, after the rate-limiting gateway receives the initial inbound traffic, it first performs rate-limiting on the initial inbound traffic. Then, it constructs the corresponding first security message. Based on the constructed first security message, it determines the third inbound traffic and sends it to the core router. The core router classifies the traffic, that is, it determines whether the third inbound traffic is abnormal traffic. If it is abnormal traffic, it redirects it to the anti-DDoS cleaning device for fine cleaning. After cleaning, it is injected back into the core router and finally forwarded to the cloud resource pool. A solution based on "pre-rate limiting - traffic classification - on-demand cleaning" is implemented. This reduces the pressure on the cleaning equipment. The rate-limiting gateway, as the first-level traffic filter, can effectively smooth burst traffic and prevent the anti-DDoS cleaning equipment from being overwhelmed by massive invalid requests, significantly reducing its overload risk and improving system reliability and service continuity. It optimizes processing efficiency by reducing the number of queries to core router policies and optimizing data forwarding paths, effectively reducing overall processing latency and improving overall throughput performance under high load scenarios. It improves resource utilization by pre-filtering junk traffic through the rate-limiting gateway, significantly reducing the invalid computational consumption of the anti-DDoS cleaning equipment and improving cleaning efficiency and resource utilization. Scalability is enhanced by the layered and decoupled design, which facilitates future horizontal expansion of the number of rate-limiting gateways and cleaning equipment to adapt to the ever-growing network scale and attack intensity.

[0079] In some implementations, the core router determines whether the third inbound cloud traffic is abnormal based on the first information of the third inbound cloud traffic. The first information includes one or more of the following: the five-tuple information of the third inbound cloud traffic, the flow rate information of the third inbound cloud traffic, the connection behavior characteristic information of the third inbound cloud traffic, the destination address and source address information of the third inbound cloud traffic, and the packet characteristic information of the third inbound cloud traffic.

[0080] For example, if the flow rate of the third inbound cloud traffic after the rate limit is greater than the first preset rate, the third inbound cloud traffic is considered to be abnormal traffic.

[0081] In some implementations, the step of decapsulating the first security message to obtain the Ethernet frame corresponding to the first security message includes: The security header field corresponding to the first security message is determined based on the first security message. The security header field includes the sequence number of the first security message, the first message verification code, and the security protocol identifier. Determine whether the first security message needs to be deleted based on the security header field; If the first security message does not need to be deleted, the corresponding Ethernet frame is obtained based on the first security message.

[0082] In some implementations, when the cloud resource pool receives a third inbound traffic that is not abnormal, it parses each first security message in the third inbound traffic to determine the corresponding Ethernet frame and forwards the Ethernet frame.

[0083] In some implementations, the cloud resource pool determines the security header field from the first security message. Based on the security header field, it performs anti-replay checks and integrity verification on the first security message. If the verification passes, it obtains the Ethernet frame from the first security message and forwards it subsequently. If the verification fails, the first security message is deleted. It can be understood that the Ethernet frame is the data information to be sent in the original traffic. The replay check here determines whether the first security message is a replay message, that is, whether the sequence number of the first security message is a pre-received sequence number.

[0084] In some implementations, determining whether the first security message needs to be deleted based on the security header field includes: Determine whether the sequence number of the first security message is a pre-received sequence number; If the sequence number of the first security message is not the pre-received sequence number, delete the first security message; When the sequence number of the first security message is a pre-received sequence number, the second message verification code corresponding to the first security message is determined based on the security protocol identifier, the first security message, the sequence number, and the second preset session key. When the second message verification code matches the first message verification code, the first security message is not deleted; If the second message verification code and the first message verification code are inconsistent, delete the first security message.

[0085] Here, the process first determines whether the first security message needs to be deleted based on its sequence number. Specifically, it checks whether the sequence number of the first security message is a pre-received sequence number, i.e., whether the first security message is a replay message. If the sequence number of the first security message is not a pre-received sequence number, then the first security message is a replay message, and it can be deleted directly. If the first security message is not a replay message, then the second message verification code corresponding to the first security message is determined based on the security protocol identifier, the first security message, the sequence number, and the second preset session key. The integrity of the first security message is determined by comparing the second message verification code with the first message verification code, i.e., whether the first security message has been tampered with during transmission. If the second message verification code and the first message verification code are the same, it means that the first security message has not been tampered with, and it is not deleted. If the second message verification code and the first message verification code are different, it means that the first security message has been tampered with, and it is deleted.

[0086] In some implementations, the cloud resource pool parses the standard outer header field and VXLAN header field of the first security message to obtain the security header field of the first security message. Based on the sequence number in the security header field, it determines whether the first security message is a replay message. When the sequence number is within the valid receive window, that is, when the sequence number is the pre-received sequence number, the integrity of the first security message is verified. When the sequence number is not within the valid receive window, that is, when the sequence number is not the pre-received sequence number, the first security message is determined to be a replay message and is directly discarded. For example, if the sequence number is less than the already received sequence number, it is determined to be a replay message.

[0087] In some implementations, the local security context is searched based on information such as the SPI and source address in the message to obtain the expected next sequence number. If the SN of the message is not within the valid receiving window (e.g., less than the already received sequence number), it is determined to be a replay message and is discarded directly.

[0088] Specifically, the receiving end maintains a current receiving window in its local security context to record the largest valid sequence number already received and the range of sequences allowed to be received. Upon receiving a new message, the receiving end compares the sequence number (SN) carried in the message with the local expected sequence number and the receiving window: if the SN is too old, duplicated, or exceeds the valid window, it indicates that the message may be a replay message and should be discarded directly; if the SN is within the allowed range, integrity verification and subsequent processing continue.

[0089] Here, the SN is the sequence number carried by the sender in the security message. The reason the receiver first obtains the "expected next sequence number" is for replay prevention checks. The receiver maintains a current receive window in its local security context to record the largest valid sequence number already received and the allowed sequence range. Upon receiving a new message, the receiver compares the SN carried in the message with the local expected sequence number and receive window: if the SN is too old, duplicated, or exceeds the valid window, the message may be a replay message and should be discarded; if the SN is within the allowed range, integrity checks and subsequent processing continue. In other words, the receiver pre-maintains the expected receive sequence number and receive window for the corresponding security context and compares the SN in the message with the expected sequence number to determine whether the message is a duplicate, expired, or valid new message, thereby achieving replay prevention checks.

[0090] In some implementations, the cloud resource pool uses the algorithm specified by the security protocol identifier in the security header field and the corresponding locally stored key (i.e., the second preset session key) to recalculate the second message verification code, i.e., the second MAC value, on the original internal Ethernet frame and SN of the first security message. The second message verification code is then compared with the first message verification code carried in the first security message. If they match, the first security message has not been tampered with; if they do not match, the first security message is considered to have been tampered with and is deleted. Here, the locally stored corresponding key is the second preset security key, determined by the receiving end. It can be understood that the first preset security key and the second preset security key correspond to each other to achieve secure message verification.

[0091] This is understandable; the integrity verification of the first message is being performed here.

[0092] In some implementations, after successful verification, the cloud resource pool obtains the Ethernet frame from the first security message and forwards it subsequently.

[0093] In some implementations, before sending the third inbound cloud traffic, the rate-limiting gateway receives the first inbound cloud traffic, which includes N first packets (N being a positive integer). The first inbound cloud traffic is rate-limited to obtain the second inbound cloud traffic, which includes M first packets (M being a positive integer, less than or equal to N). The first packets in the second inbound cloud traffic are processed to obtain a first security packet, which includes a security header field. After obtaining the third inbound cloud traffic, it is sent to the cloud resource pool. The third inbound cloud traffic includes the first security packet corresponding to each first packet in the second inbound cloud traffic.

[0094] Here, the rate-limiting gateway receives the first inbound cloud traffic, which is the initial inbound cloud traffic. The first inbound cloud traffic consists of N first packets, where N is a positive integer. After receiving the first inbound cloud traffic, the rate-limiting gateway performs rate-limiting processing. The first inbound cloud traffic after rate-limiting is the second inbound cloud traffic, which consists of M first packets, where M is a positive integer and M is less than or equal to N.

[0095] For example, the rate limiting gateway implements dynamic rate limiting based on the token bucket algorithm. This application does not specifically limit the particular rate limiting method used.

[0096] In this way, by placing the rate-limiting gateway at the network edge, the proportion of invalid scrubbing traffic can be significantly reduced and the CPU load on the core router can be alleviated.

[0097] In some implementations, the rate-limiting gateway determines the VXLAN header field corresponding to the first packet based on the first packet and a preset mapping rule. The VXLAN header field includes a Virtual Network Identifier (VNI), and the preset mapping rule includes a mapping sub-rule between the source VTEP address and the VNI and a mapping sub-rule between the VNI and the destination VTEP address. It then determines the sequence number and Security Protocol Identifier (SPI) corresponding to the first packet; determines the first message verification code corresponding to the first packet based on the first packet, a first preset session key, the sequence number, and the SPI; determines the security header field corresponding to the first packet based on the first packet, the first message verification code, the sequence number, and the SPI; and finally determines the first secure packet based on the security header field, the VXLAN header field, the preset mapping rule, and the first packet.

[0098] In some implementations, the rate-limiting gateway first generates the VXLAN header field corresponding to the first packet, then constructs the security header field corresponding to the first packet, completes the outer encapsulation to obtain the first secure packet, and forwards the first secure packet. In this way, while constructing the VXLAN packet, security fields are injected, i.e., the first secure packet is constructed, thereby achieving protection for packet integrity, authenticity, and replay prevention. Furthermore, all processing is completed at the hardware layer at line speed, ensuring no loss in throughput or latency performance.

[0099] In some implementations, preset mapping rules are issued by the control plane to the rate limiting gateway, including mapping sub-rules for the source VTEP address and VNI, and mapping sub-rules for the VNI and destination VTEP address.

[0100] It can be understood that the source VTEP address and destination VTEP address are the endpoint addresses of the VXLAN tunnel. That is, the source VTEP address is determined by the sending device, and the destination VTEP address is determined by the receiving device. In other words, the source VTEP address is determined by the rate-limiting gateway, and the destination VTEP address is determined by the cloud resource pool.

[0101] Here, the VNI corresponding to the first packet is determined according to the mapping sub-rule of the source VTEP address and VNI, the destination VTEP address is determined according to the mapping sub-rule of the destination VTEP address of the VNI, and the destination VTEP address is encapsulated in the destination IP address in the outer IP header.

[0102] In some implementations, the structure of the first secure message includes a standard outer Ethernet / IP / UDP header field, a VXLAN header field, a security header field, an Ethernet frame, and a Frame Check Sequence (FCS) field. The security header field can also be called the Security Context Header (SCH), and the Ethernet frame refers to the Ethernet frame in the first message, also known as the raw payload or the raw inner Ethernet frame; that is, the data information to be transmitted in each first message of the first inbound traffic.

[0103] Specifically, the structure of the first security message is as follows: [Standard outer Ethernet / IP / UDP header | VXLAN header (8 bytes) | Security Context Header (SCH) | Raw inner Ethernet frame | FCS].

[0104] It is understood that the first security message in this application adds a security header field compared to the VXLAN message, and the first message includes an Ethernet frame.

[0105] In some implementations, the rate-limiting gateway determines the first message verification code corresponding to the first message based on the Ethernet frame in the first message, the sequence number corresponding to the first message, the first preset session key, and the security protocol identifier. Here, the first message verification code can also be referred to as the first MAC value.

[0106] Specifically, the rate limiting gateway concatenates the original internal Ethernet frame, the current sequence number (SN), and the pre-configured session key (Key) to form the data to be calculated; using the hash calculation unit (such as CRC32, SHA-256 hardware engine) built into the switching chip in the rate limiting gateway, it generates the MAC value according to the algorithm specified by SPI, that is, generates the first message verification code corresponding to the first packet.

[0107] Here, the first preset session key corresponds to the sending device, that is, to the rate limiting gateway. For example, the first preset session key is preset for the rate limiting gateway, and the current sequence number is also the sequence number generated by the rate limiting gateway for the first message.

[0108] In some implementations, the security header field includes one or more of the following information: Security Parameters Index (SPI), version identifier, type identifier, serial number, and message verification code.

[0109] The SPI (Security Authentication Code) is 1 byte and is used to identify the security algorithm and mode (e.g., 0x01 represents SHA-256-HMAC, 0x02 represents AES-GMAC, etc.). The receiver uses this field to select the corresponding verification algorithm and key. Here, the SPI corresponds to the sending device and is preset in the sending device; that is, the sending device determines the SPI of the message. The version identifier and type identifier correspond to the first message, and the corresponding version identifier and type identifier are generated according to the type of the first message. The sequence number (SN) is a 4-byte monotonically increasing counter used to uniquely identify a message within a secure session and defend against replay attacks. Here, the SN is the sequence number written by the sender into the secure message; that is, the rate-limiting gateway generates the corresponding SN and writes it into the first secure message. The Message Authentication Code (MAC, variable length) is an integrity check value calculated by the sender based on the internal message. The length depends on the algorithm specified by the SPI (e.g., 32 bytes for SHA-256-HMAC).

[0110] In some implementations, the rate limiting gateway determines the corresponding version identifier and type identifier based on the first message, and determines the security header field corresponding to the first message based on the version identifier, type identifier, first message verification code, serial number, and security protocol identifier.

[0111] In some implementations, the rate-limiting gateway sequentially adds a VXLAN header field and a security header field (including SPI, SN, and the calculated MAC), performs standard UDP / IP / Ethernet encapsulation to obtain a first security message, and then forwards the first security message.

[0112] The technical solution provided in this application embodiment receives third inbound cloud traffic, which includes multiple first security packets. Each first security packet includes a security header field and an Ethernet frame. The first security packet is decapsulated to obtain the corresponding Ethernet frame. Thus, the receiving end obtains the Ethernet frame by decapsulating the first security packet including the security header field, ensuring data transmission security and improving overall network performance.

[0113] The technical solutions of the embodiments of this application are illustrated below with specific application examples.

[0114] This embodiment employs an inbound traffic flow reconstruction approach, placing the rate-limiting gateway at the network edge and implementing dynamic rate limiting based on the token bucket algorithm. This significantly reduces the proportion of invalid cleaning traffic and alleviates the CPU load on core routers. By replacing traditional PBR policy routing with VXLAN tunneling technology, logical network abstraction and topology hiding can be achieved. Furthermore, the introduction of a VXLAN inline security encapsulation mechanism ensures data confidentiality and integrity. Specifically: (I) Restructuring of Inbound Traffic Processing Figure 3 This is a schematic diagram of the inbound traffic flow provided in the embodiments of this application. Figure 1 ,like Figure 3 As shown, in the traditional solution, inbound traffic first undergoes primary traffic classification at the core router. Abnormal traffic is then guided to the anti-DDoS scrubbing device via policy-based routing (PBR). After scrubbing, the traffic is reinjected into the core router to determine if it is abnormal. For inbound traffic that is not abnormal, it is rate-limited by the rate-limiting gateway before being forwarded to the cloud resource pool. This solution has significant drawbacks: First, the anti-DDoS scrubbing device is directly exposed to raw traffic, making it susceptible to sudden traffic surges that could lead to service overload or even outages. Second, the multiple routing hops and policy matching using policy-based routing introduce additional latency and processing overhead. Furthermore, the static configuration of policy-based routing is difficult to adapt to dynamically changing business traffic models, resulting in high operational complexity.

[0115] Figure 4 This is a schematic diagram of the inbound traffic flow provided in the embodiments of this application. Figure 2 ,like Figure 4 As shown, this embodiment reconstructs the processing flow of inbound traffic, proposing a scheme based on "pre-limiting—traffic classification—on-demand cleaning". When initial traffic enters the cloud, it first undergoes rate limiting through a rate-limiting gateway, and then is sent to the core router for traffic classification. If the core router identifies the traffic as abnormal, it diverts it through a VXLAN tunnel to an anti-DDoS cleaning device for fine-grained cleaning. After cleaning, the traffic is injected back into the core router and finally forwarded to the cloud resource pool. If the traffic is not abnormal, it is directly forwarded to the cloud resource pool. This architecture offers the following advantages: Reduced pressure on cleaning equipment: As a first-level traffic filter, the rate-limiting gateway effectively smooths out bursts of traffic, preventing DDoS cleaning equipment from being overwhelmed by massive invalid requests, significantly reducing its overload risk and improving system reliability and service continuity; Optimized processing efficiency: By reducing the number of queries to core router policies and optimizing data forwarding paths, overall processing latency can be effectively reduced, improving overall throughput performance under high load scenarios; Increased resource utilization: The rate-limiting gateway pre-filters out junk traffic, significantly reducing the invalid computational consumption of DDoS cleaning equipment, improving cleaning efficiency and resource utilization; Scalability of the architecture: The layered and decoupled design facilitates future horizontal expansion of the number of rate-limiting gateways and cleaning equipment, adapting to the ever-growing network scale and attack intensity.

[0116] The identification of "abnormal traffic" here is automatically determined by the pre-detection and classification module based on preset rules. Identification criteria may include abnormal source / destination address distribution, abnormal five-tuple statistics, abnormal connection establishment rate, packet characteristics matching known attack characteristics, and blacklist / whitelist policy hits. When any of these abnormality criteria are met, the traffic is marked as abnormal and guided into subsequent secure transmission and cleaning processes. Specifically, the identification of abnormal traffic in the core router can be based on one or more of the following: the traffic's five-tuple information, whether the traffic flow rate exceeds a threshold, connection behavior characteristics, attack feature database matching results, or policy rule hit results. Connection behavior characteristics include one or more of the following features: connection establishment rate, connection completion status, half-connection characteristics, concurrent connection characteristics, connection duration characteristics, connection termination characteristics, retransmission and abnormal characteristics, etc. These features can be obtained from traffic observation and session states. Attack signature matching results are generally obtained from the detection engine's feature comparison of traffic. They indicate whether "this batch of traffic resembles a certain type of known attack," such as matching with known DDoS attack fingerprints, matching with reflection amplification attack features, matching with abnormal packet features, matching with abnormal connection behavior, and matching with abnormal request patterns. This application does not specifically limit the specific attack features. Policy rule hits indicate whether "the current traffic hits a certain handling policy," generally obtained from pre-configured rule matching. When the traffic conforms to a certain rule during processing, it is considered to have hit that rule, i.e., hit a certain policy. The rules that abnormal traffic hits can be determined based on the typical processing of abnormal traffic. If the current traffic's processing method involves a certain processing rule for abnormal traffic, then the current traffic is considered abnormal. Examples include five-tuple matching rule hits, rate-limiting threshold rule hits, and traffic-driving cleaning rule hits. This application does not specifically limit the specific settings for the hit rules.

[0117] (ii) VXLAN tunneling transmission mechanism In traditional solutions, Policy-Based Routing (PBR) requires explicitly specifying the next-hop physical interface IP, exposing internal network topology details to the outside and introducing security risks. Furthermore, its policy configuration is typically static, making it difficult to adapt to the dynamically changing business needs of the cloud environment. As tenants and business scale continuously expand, the number of policy rules grows linearly or even exponentially, leading to redundant device configurations, soaring policy maintenance costs, and increased operational complexity. To overcome the shortcomings of traditional static PBR policy routing in terms of flexibility, scalability, and security, this embodiment establishes a dynamic VXLAN tunnel between the rate-limiting gateway and the cloud resource pool, encapsulating raw traffic into an overlay network with a specific VNI for transmission. This embodiment uses VXLAN tunnels instead of Policy-Based Routing (PBR) to achieve topology concealment: only the VTEP address is exposed externally. Here, the VTEP address can be understood as the "ID card" and "address" of each node in the VXLAN network, hiding the underlying network physical topology and device physical port IPs, greatly reducing the attack surface and improving overall network security; dynamic scalability: VXLAN adapts to the isolation and expansion needs of multi-tenant and multi-service scenarios, thereby avoiding the problem of the number of traditional PBR policies expanding; policy and forwarding decoupling: traffic scheduling policies no longer rely on IP addresses strongly associated with the physical topology, but instead achieve logical traffic redirection by flexibly defining the mapping relationship between the Virtual Network Identifier (VNI) and the VTEP, greatly simplifying network management and automated deployment.

[0118] (iii) VXLAN Inline Security Encapsulation Mechanism This embodiment proposes a lightweight inline security mechanism deeply integrated into the VXLAN encapsulation process. This mechanism injects security fields while constructing VXLAN packets, thereby protecting packet integrity, authenticity, and replay protection. Furthermore, all processing is completed at the hardware layer at line speed, ensuring lossless throughput and latency performance.

[0119] The tunneling process here is as follows: The control plane first establishes a mapping relationship between the VNI and the destination VTEP; based on this mapping relationship, it selects the corresponding VNI and outer VTEP address, and encapsulates the original packet into a VXLAN packet; the encapsulated packet is forwarded in the intermediate network as a normal UDP / IP packet; it is sent to the core router, which identifies the traffic that needs to be transmitted securely. When the core router detects that the traffic is not abnormal, it sends the secure VXLAN packet to the peer VTEP. Then, based on the outer header and VNI, it identifies the corresponding tunnel and security context, completes security verification, decapsulation, and sends the original inner packet to the cleaning, reinjection, or subsequent forwarding module.

[0120] The details are as follows: 1. Define the Extensible Security Context Header (SCH).

[0121] Here, the Extensible Security Context Header is equivalent to the aforementioned Security Header, and the Security Context (SCH) structure includes the following fields: 1) Security Protocol Identifier (SPI, 1 Byte): Used to identify the security algorithm and mode (e.g., 0x01 represents SHA-256-HMAC, 0x02 represents AES-GMAC, etc.). The receiver selects the corresponding verification algorithm and key based on this field. The security protocol identifier corresponds to the sender, for example, but a security protocol identifier corresponding to the sender can be preset.

[0122] 2) Version identifier.

[0123] 3) Type identifier.

[0124] The version identifier and type identifier are determined based on the processed message.

[0125] 4) Serial Number (SN, 4 Bytes): A monotonically increasing counter used to uniquely identify a message within a secure session and defend against replay attacks; 5) Message Authentication Code (MAC, variable length): The integrity verification value is calculated by the sender based on the internal message. The length depends on the algorithm specified by SPI (e.g., SHA-256-HMAC is 32 bytes).

[0126] 2. Sending end processing flow The sending end constructs a secure VXLAN message (equivalent to the aforementioned first secure message) according to the following steps: 1) Traffic Matching and Security Context Association: Flow entries (equivalent to the aforementioned preset mapping rules) issued by the control plane are associated with a security context. Specifically, the traffic is associated with the target security context using the mapping rules issued by the control plane; then, a corresponding VXLAN header field is generated based on the security context. The VXLAN header field includes the VNI, the obtained source / destination VTEP address, etc., for subsequent encapsulation, specifically encapsulated in the outer IP header. That is, first, the flow is bound to a security context based on the original flow's five-tuple or policy identifier; then, VXLAN-related header fields, such as the VNI and the determined outer VTEP address, are generated or filled in based on the security context for subsequent encapsulation. Here, the security context includes the determined VNI, outer source / destination VTEP address, etc.

[0127] 2) Calculate the Message Authentication Code (MAC): Concatenate the original Ethernet frame, the sequence number (SN) corresponding to the current message, and the pre-configured session key (equivalent to the aforementioned first session key) to form the data to be calculated. Utilize the hash calculation unit (such as a CRC32 or SHA-256 hardware engine) built into the switching chip of the sending device to calculate the MAC value (equivalent to the aforementioned first MAC value) from the data to be calculated according to the algorithm specified by the SPI (equivalent to the aforementioned preset algorithm). Here, the SPI algorithm corresponds to the sending end and is also preset; the pre-configured session key corresponds to the sending end.

[0128] 3) Construct and insert the SCH header: Add the VXLAN header and SCH header (containing the SPI algorithm, SN and the calculated MAC) in sequence.

[0129] 4) Complete outer encapsulation and forwarding: Perform standard UDP / IP / Ethernet encapsulation, and then forward it.

[0130] As can be understood, the sending end in this embodiment is a rate-limiting gateway. After the rate-limiting gateway generates a secure VXLAN packet, it sends it to the core router. The core router identifies the original traffic that needs to be transmitted securely, based on information such as the five-tuple or VNI. The specific identification method is as described above and will not be repeated here. A variable-length Security Context Header (SCH) is inserted between the VXLAN header (8 bytes) and the original inner Ethernet frame (also known as the original payload). The specific structure of the constructed secure VXLAN packet is as follows: [Standard outer Ethernet / IP / UDP header | VXLAN header (8 bytes) | Security Context Header (SCH) | Original inner Ethernet frame | FCS].

[0131] 3. Receiving end processing flow The receiving end verifies and decapsulates the secure VXLAN message according to the following steps: 1) Decapsulation and SCH Header Extraction: Parse the outer and VXLAN packet headers, and then identify the following SCH header (determined by a specific UDP destination port or VNI). At the sending end, the control plane pre-establishes a mapping relationship between VNI and target VTEP. After the ingress device identifies the target traffic, it assigns the corresponding VNI according to the mapping relationship and performs VXLAN encapsulation with the target VTEP as the outer destination address. After receiving the packet, the peer device (receiving device) identifies the tunnel based on the outer destination port, VNI, and local security context, and completes verification, decapsulation, and subsequent forwarding. Specifically, after receiving the packet, the peer device first parses the outer Ethernet / IP / UDP header and determines whether it belongs to a secure tunnel service based on the preset destination port (UDP destination port). If so, it then parses the VXLAN header and obtains the VNI. After determining the secure transport context corresponding to the VNI, it continues to parse the SCH header from the beginning of the VXLAN payload and identifies its start position and length based on the version identifier, type identifier, or fixed format field in the SCH header.

[0132] 2) Anti-replay check: Based on information such as the SPI and source address in the message, the local security context is searched to obtain the expected next sequence number. If the message's SN is not within the valid receive window (e.g., less than the already received sequence number), it is determined to be a replay message and is discarded directly.

[0133] Here, the SN is the sequence number carried by the sender in the security message. The reason the receiver first obtains the "expected next sequence number" is to perform replay prevention checks. The receiver maintains a current receive window in its local security context to record the largest valid sequence number already received and the allowed range of sequences. Upon receiving a new message, the receiver compares the SN carried in the message with the local expected sequence number and receive window: if the SN is too old, duplicated, or exceeds the valid window, the message may be a replay message and should be discarded; if the SN is within the allowed range, integrity checks and subsequent processing continue. In other words, the receiver pre-maintains the expected receive sequence number and receive window for the corresponding security context and compares the SN in the message with the expected sequence number to determine whether the message is a duplicate, expired, or valid new message, thereby achieving replay prevention checks.

[0134] 3) Integrity Verification: Using the algorithm indicated by the SPI in the message and the corresponding key stored locally, the MAC (equivalent to the aforementioned second MAC value) of the original internal Ethernet frame and SN of the message is recalculated. The calculated result is then compared with the MAC value carried in the message. If they do not match, the message is determined to have been tampered with and is discarded.

[0135] 4) Security stripping and forwarding: After successful verification, the SCH header and security context are stripped, and only the original inner frame is forwarded.

[0136] In some implementations, a normal / abnormal traffic baseline model can be established. By learning traffic characteristics in real time, the token bucket parameters and rate limiting thresholds can be dynamically adjusted to achieve the evolution from "static rate limiting" to "intelligent adaptive rate limiting". This improves the accuracy of identification and response speed to new DDoS attacks, and realizes intelligent traffic perception and adaptive control.

[0137] In some implementations, application layer feature recognition technology can be introduced on the basis of VXLAN's VNI identifier to achieve fine-grained identification and differentiated processing of specific service traffic. By establishing a service priority mapping mechanism, it can be ensured that critical services receive low-latency, high-priority forwarding guarantees during the cleaning process, thereby achieving fine-grained scheduling with service awareness.

[0138] In some implementations, visualization and monitoring tools can also be built to achieve a visualized monitoring system covering the entire process of rate limiting, encrypted transmission, and cleaning and reinjection.

[0139] In some implementations, a distributed cleaning architecture can also be constructed. For example, an SDN-based distributed cleaning solution can be constructed, in which multiple cleaning nodes are centrally managed by a controller to achieve flexible traffic scheduling, thereby avoiding reliance on traditional centralized cleaning equipment architecture. In some implementations, the combination of VXLAN and lightweight encryption protocols is studied to ensure security while reducing the computational overhead of encryption and decryption, and to be used in high-throughput scenarios; thus, a lightweight encryption scheme is implemented.

[0140] In some implementations, a dynamic rate limiting scheme based on a P4 programmable switch is adopted. The programmable token bucket algorithm is implemented through the P4 program, which supports dynamic rate limiting strategies based on traffic characteristics and avoids the flexibility limitations caused by fixed rate limiting thresholds.

[0141] The technical solution of this application deploys a rate-limiting gateway at the traffic inlet, prioritizing bandwidth rate limiting and then triggering a cleaning process based on actual needs. This restructures the traffic processing flow, effectively reducing invalid traffic redirection and improving overall processing efficiency. By pre-limiting, junk traffic can be curbed at the source, avoiding the high cloud bandwidth costs associated with cleaning large amounts of DDoS traffic and reducing bandwidth costs. VXLAN tunneling technology replaces the traditional PBR mechanism, reducing reliance on PBR. By replacing complex PBR strategies with VXLAN, the high degree of automation greatly simplifies network configuration and maintenance complexity, reduces manpower input, and lowers operation and maintenance costs. A P4 programmable data plane inline secure VXLAN encapsulation mechanism is adopted, deeply integrating security processing into the VXLAN packet construction and parsing process. By inserting, verifying, and stripping the Security Context Header (SCH) in the data plane forwarding pipeline, a deep integration of integrity protection, replay protection, and other security capabilities with overlay network forwarding capabilities is achieved. The innovative "rate limiting-classification-cleaning" process reconstruction fundamentally avoids the risk of DDoS protection systems crashing due to sudden traffic overload, ensuring high availability of protection services, laying the foundation for delivering higher-level service level agreements, and providing deterministic guarantees for critical businesses with extremely high continuity requirements such as online transactions and real-time interactions, enabling them to maintain basic service capabilities even in the face of large-scale DDoS attacks.

[0142] Compared to the aforementioned existing technologies, which are based on BGP and require advertising real IP addresses to the network, thus exposing the network structure to some extent, this embodiment employs VXLAN tunnels to achieve network topology concealment. Only the VTEP address is exposed externally, while the physical IPs of all internal devices (including the core router and the scrubbing center) are hidden, significantly reducing the attack surface. Furthermore, VXLAN's VNI-based forwarding model supports multi-tenancy and service isolation, offering far greater scalability than IP address-based policy routing (PBR). Existing technologies follow a "detection -> traffic redirection -> scrubbing" process, making scrubbing equipment vulnerable to overwhelmed by high traffic volumes. This embodiment proposes a "rate limiting -> classification -> on-demand scrubbing" process, placing a rate-limiting gateway as the first line of defense to limit external traffic, greatly reducing the overload and load risk for subsequent scrubbing equipment. Existing technologies do not consider security issues along the transmission path (such as eavesdropping, hijacking, and tampering). This embodiment uses a VXLAN inline security encapsulation mechanism to ensure the confidentiality and integrity of traffic on the path from the rate-limiting gateway to the scrubbing center. This fundamentally defends against BGP hijacking, MIMT attacks, and traffic attacks, achieving "security through scheduling."

[0143] Figure 5 This is a schematic diagram of the structural composition of the data processing apparatus provided in the embodiments of this application. Figure 1 ,like Figure 5 As shown, the data processing device includes: The first communication unit 501 is used to receive the first inbound cloud traffic, which includes N first messages, where N is a positive integer. The first processing unit 502 is used to perform rate limiting processing on the first inbound cloud traffic to obtain the second inbound cloud traffic, the second inbound cloud traffic including M first packets, M is a positive integer, M is less than or equal to N; and to process the first packets in the second inbound cloud traffic to obtain a first security packet, the first security packet including a security header field. The first communication unit 501 is used to send the third inbound traffic to the cloud resource pool, wherein the third inbound traffic includes the first security message corresponding to each first message in the second inbound traffic.

[0144] In some implementations, the first communication unit 501 is used to send the third inbound traffic to the cloud resource pool via a VXLAN tunnel.

[0145] In some embodiments, the first processing unit 502 is configured to: determine the VXLAN header field corresponding to the first message based on the first message and a preset mapping rule, wherein the VXLAN header field includes a Virtual Network Identifier (VNI), and the preset mapping rule includes a mapping sub-rule between the source VTEP address and the VNI and a mapping sub-rule between the VNI and the destination VTEP address; determine the sequence number and security protocol identifier (SPI) corresponding to the first message; determine the first message verification code corresponding to the first message based on the first message, a first preset session key, the sequence number, and the security protocol identifier; determine the security header field corresponding to the first message based on the first message, the first message verification code, the sequence number, and the security protocol identifier; and determine the first secure message based on the security header field, the VXLAN header field, the preset mapping rule, and the first message.

[0146] In some implementations, the first communication unit 501 is used to send the third inbound cloud traffic to the cloud resource pool via the core router, and the core router is used to determine whether the third inbound cloud traffic is abnormal traffic.

[0147] Those skilled in the art should understand that Figure 5 The functions of each unit in the data processing device shown can be understood by referring to the relevant description of the aforementioned method. Figure 5 The functions of each unit in the data processing device shown can be implemented by a program running on a processor or by specific logic circuits.

[0148] Figure 6 This is a schematic diagram of the structural composition of the data processing apparatus provided in the embodiments of this application. Figure 2 ,like Figure 6 As shown, the data processing device includes: The second communication unit 601 is used to receive third inbound cloud traffic, the third inbound cloud traffic including a plurality of first security messages, the first security message including a security header field and an Ethernet frame; The second processing unit 602 is used to decapsulate the first security message to obtain the Ethernet frame corresponding to the first security message.

[0149] In some implementations, the second processing unit 602 is configured to determine the security header field corresponding to the first security message based on the first security message, wherein the security header field includes the sequence number of the first security message, the first message verification code, and the security protocol identifier; determine whether the first security message needs to be deleted based on the security header field; and if the first security message does not need to be deleted, obtain the corresponding Ethernet frame based on the first security message.

[0150] In some embodiments, the second processing unit 602 is configured to determine whether the sequence number of the first security message is a pre-received sequence number; when the sequence number of the first security message is not a pre-received sequence number, delete the first security message; when the sequence number of the first security message is a pre-received sequence number, determine the second message verification code corresponding to the first security message based on the security protocol identifier, the first security message, the sequence number, and the second preset session key; when the second message verification code and the first message verification code are consistent, do not delete the first security message; when the second message verification code and the first message verification code are inconsistent, delete the first security message.

[0151] Those skilled in the art should understand that Figure 6 The functions of each unit in the data processing device shown can be understood by referring to the relevant description of the aforementioned method. Figure 6 The functions of each unit in the data processing device shown can be implemented by a program running on a processor or by specific logic circuits.

[0152] Figure 7 This is a schematic structural diagram of a data processing device 700 provided in an embodiment of this application. Figure 7 The data processing device 700 shown includes a processor 710, which can call and run computer programs from memory to implement the methods in the embodiments of this application.

[0153] Optionally, such as Figure 7As shown, the data processing device 700 may further include a memory 720. The processor 710 can retrieve and run computer programs from the memory 720 to implement the methods described in this embodiment.

[0154] The memory 720 can be a separate device independent of the processor 710, or it can be integrated into the processor 710.

[0155] Optionally, such as Figure 7 As shown, the data processing device 700 may also include a transceiver 730, which the processor 710 can control to communicate with other devices. Specifically, it can send information or data to other devices or receive information or data sent by other devices.

[0156] The transceiver 730 may include a transmitter and a receiver. The transceiver 730 may further include antennas, and the number of antennas may be one or more.

[0157] The data processing device 700 can implement the corresponding processes implemented by the data processing apparatus in the various methods of the embodiments of this application, which will not be described in detail here for the sake of brevity.

[0158] Figure 8 This is a schematic structural diagram of the chip according to an embodiment of this application. Figure 8 The chip 800 shown includes a processor 810, which can call and run computer programs from memory to implement the methods in the embodiments of this application.

[0159] Optionally, such as Figure 8 As shown, chip 800 may further include memory 820. Processor 810 can retrieve and run computer programs from memory 820 to implement the methods described in this embodiment.

[0160] The memory 820 can be a separate device independent of the processor 810, or it can be integrated into the processor 810.

[0161] Optionally, the chip 800 may also include an input interface 830. The processor 810 can control the input interface 830 to communicate with other devices or chips; specifically, it can acquire information or data sent by other devices or chips.

[0162] Optionally, the chip 800 may also include an output interface 840. The processor 810 can control the output interface 840 to communicate with other devices or chips, specifically, to output information or data to other devices or chips.

[0163] This chip can implement the corresponding processes implemented by the data processing device in the various methods of the embodiments of this application, which will not be described in detail here for the sake of brevity.

[0164] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0165] It should be understood that the processor in the embodiments of this application may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor described above can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0166] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0167] It should be understood that the above-described memory is exemplary and not a limiting description. For example, the memory in the embodiments of this application may also be static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus RAM (DR RAM), etc. That is to say, the memory in the embodiments of this application is intended to include, but is not limited to, these and any other suitable types of memory.

[0168] This application also provides a computer program product, including a computer program.

[0169] When executed by a processor, the computer program implements the corresponding processes implemented by the data processing device in the various methods of the embodiments of this application. For the sake of brevity, these will not be described in detail here.

[0170] This application also provides a computer-readable storage medium for storing computer programs.

[0171] The computer program causes the computer to execute the corresponding processes implemented by the data processing device in the various methods of the embodiments of this application, which will not be described in detail here for the sake of brevity.

[0172] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0173] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0174] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0175] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0176] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0177] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks. The preferred embodiments of this application have been described in detail above with reference to the accompanying drawings. However, this application is not limited to the specific details of the above embodiments. Within the scope of the technical concept of this application, various simple modifications can be made to the technical solution of this application, and these simple modifications all fall within the protection scope of this application. For example, the various specific technical features described in the above embodiments can be combined in any suitable manner without contradiction. To avoid unnecessary repetition, this application will not describe the various possible combinations separately. Furthermore, different embodiments of this application can also be arbitrarily combined, as long as they do not violate the spirit of this application, and should also be considered as the content disclosed in this application. For example, without conflict, the various embodiments and / or technical features described in this application can be arbitrarily combined with existing technology, and the resulting technical solutions should also fall within the protection scope of this application. It should be understood that in the various method embodiments of this application, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0178] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A data processing method, characterized in that, The method includes: Receive the first inbound cloud traffic, which includes N first messages, where N is a positive integer; The first inbound cloud traffic is rate-limited to obtain the second inbound cloud traffic, which includes M first packets, where M is a positive integer and M is less than or equal to N. The first packet in the second inbound cloud traffic is processed to obtain a first security packet, which includes a security header field; The third inbound traffic is sent to the cloud resource pool, and the third inbound traffic includes the first security message corresponding to each first message in the second inbound traffic.

2. The method according to claim 1, characterized in that, The step of sending the third inbound traffic to the cloud resource pool includes: The third inbound traffic is sent to the cloud resource pool via a Virtual Scalable Local Area Network (VXLAN) tunnel.

3. The method according to claim 2, characterized in that, The process of processing the first packet in the second inbound traffic to obtain the first security packet includes: The VXLAN header field corresponding to the first message is determined based on the first message and the preset mapping rules. The VXLAN header field includes a Virtual Network Identifier (VNI). The preset mapping rules include a mapping sub-rule between the source VTEP address and the virtual network identifier and a mapping sub-rule between the virtual network identifier and the destination VTEP address. Determine the sequence number and Security Protocol Identifier (SPI) corresponding to the first message; The first message verification code corresponding to the first message is determined based on the first message, the first preset session key, the sequence number, and the security protocol identifier; The security header field corresponding to the first message is determined based on the first message, the first message verification code, the sequence number, and the security protocol identifier; The first security message is determined based on the security header field, the VXLAN message header field, the preset mapping rule, and the first message.

4. The method according to claim 2, characterized in that, The step of sending the third inbound traffic to the cloud resource pool includes: The third inbound cloud traffic is sent to the cloud resource pool via the core router, which is used to determine whether the third inbound cloud traffic is abnormal.

5. A data processing method, characterized in that, The method includes: Receive third inbound cloud traffic, the third inbound cloud traffic including multiple first security messages, the first security message including a security header field and an Ethernet frame; Decapsulate the first security message to obtain the Ethernet frame corresponding to the first security message.

6. The method according to claim 5, characterized in that, The process of decapsulating the first security message to obtain the corresponding Ethernet frame includes: The security header field corresponding to the first security message is determined based on the first security message. The security header field includes the sequence number of the first security message, the first message verification code, and the security protocol identifier. Determine whether the first security message needs to be deleted based on the security header field; If the first security message does not need to be deleted, the corresponding Ethernet frame is obtained based on the first security message.

7. The method according to claim 6, characterized in that, The step of determining whether the first security message needs to be deleted based on the security header field includes: Determine whether the sequence number of the first security message is a pre-received sequence number; If the sequence number of the first security message is not the pre-received sequence number, delete the first security message; When the sequence number of the first security message is a pre-received sequence number, the second message verification code corresponding to the first security message is determined based on the security protocol identifier, the first security message, the sequence number, and the second preset session key. When the second message verification code matches the first message verification code, the first security message is not deleted; If the second message verification code and the first message verification code are inconsistent, delete the first security message.

8. A data processing device, characterized in that, include: A processor and a memory for storing a computer program, the processor for calling and running the computer program stored in the memory to perform the method as described in any one of claims 1 to 7.

9. A computer program product, characterized in that, include: A computer program that, when executed by a processor, implements the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Used to store a computer program that causes a computer to perform the method as described in any one of claims 1 to 7.

Images