CN118540153A - Information transmission method, device, medium, electronic equipment and program product for preventing IP counterfeiting - Google Patents

Information transmission method, device, medium, electronic equipment and program product for preventing IP counterfeiting Download PDF

Info

Publication number
CN118540153A
CN118540153A CN202410814361.3A CN202410814361A CN118540153A CN 118540153 A CN118540153 A CN 118540153A CN 202410814361 A CN202410814361 A CN 202410814361A CN 118540153 A CN118540153 A CN 118540153A
Authority
CN
China
Prior art keywords
message
field
toa
tag
address
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202410814361.3A
Other languages
Chinese (zh)
Inventor
陈国�
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Volcano Engine Technology Co Ltd
Original Assignee
Beijing Volcano Engine Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Volcano Engine Technology Co Ltd filed Critical Beijing Volcano Engine Technology Co Ltd
Priority to CN202410814361.3A priority Critical patent/CN118540153A/en
Publication of CN118540153A publication Critical patent/CN118540153A/en
Pending legal-status Critical Current

Links

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

The present disclosure relates to an information transmission method, apparatus, medium, electronic device, and program product for preventing IP forgery. The information transmission method for preventing IP counterfeiting comprises the following steps: in response to receiving a first message sent by a client, replacing a source address in the first message with an address of load balancing equipment, generating a TOA (time of arrival) based on the source address in the first message, and generating a first label corresponding to a destination address in the first message by utilizing a generation mode pre-agreed with a target server; writing TOA and a first label into the first message obtained after address replacement to obtain a second message; and sending the second message to the target server so as to determine whether the TOA field in the second message is credible or not based on the first label and the generation mode by the target server. According to the scheme, the problem that the server obtains the forged source address by forging the TOA field and the tag by the attack end can be solved, and the protection effect of the security system of the server is guaranteed.

Description

Information transmission method, device, medium, electronic equipment and program product for preventing IP counterfeiting
Technical Field
The present disclosure relates to the field of computer networks, and in particular, to an information transmission method, apparatus, medium, electronic device, and program product for preventing IP forgery.
Background
The four-layer load balancing is mainly based on internet protocol addresses (Internet Protocol Address, abbreviated as IP addresses) and ports for load balancing. When the load balancing device receives a request from a client, it decides which source station (REAL SERVER, RS) to forward the request to in the end, depending on the destination address and port in the message, and the server selection mode set by the device itself. Taking the transmission control protocol (Transmission Control Protocol, TCP) as an example, when the load balancing device receives the first synchronization sequence number (Synchronize Sequence Numbers, SYN) request from the client, it selects one RS and forwards the message to the selected RS. The four-layer load balancing is mainly used for solving the port limitation and high availability problems of seven-layer load balancing. It can forward both TCP/IP protocol and user datagram protocol (User Datagram Protocol, UDP).
At present, when forwarding a message of a client, a four-layer load balancing device performs source network address conversion on the message, namely, replaces a source address in the message with address information of the load balancing device. Therefore, when the background server receives the message forwarded by the load balancing device, the background server cannot acquire the real client source address from the message, so that security systems such as a Web firewall, an anticreeper system and a brushing prevention system of the server cannot analyze and protect the client source address, and security risks are caused.
In order to make the server obtain the real client source address, as shown in fig. 3, a TCP option address (TCP option address, TOA) is introduced, that is, the load balancing device inserts a TOA field containing the source address of the normal client (that is, IP address 1.1.1.1 in fig. 3) in the forwarded message, and the server can easily obtain the real client source address from the TOA field of the received message. However, the attack end (i.e. the malicious client) may construct a malicious TOA field and write a fake source address in the TOA, and since the TOA module of the current load balancing device cannot well eliminate the malicious TOA, the client source address acquired by the server is actually fake, and these fake client source addresses will cause the security system of the server to fail, resulting in security risk.
Disclosure of Invention
This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
In a first aspect, the present disclosure provides an IP forgery prevention information transmission method, applied to a load balancing device, including:
in response to receiving a first message sent by a client, replacing a source address in the first message with an address of load balancing equipment, generating a TCP option address TOA based on the source address in the first message, and generating a first label corresponding to a destination address in the first message by utilizing a generation mode pre-agreed with a target server;
Writing the TOA and the first label into the first message obtained after address replacement to obtain a second message;
And sending the second message to the target server so as to determine whether the TOA field in the second message is credible or not based on the first tag and the generation mode by the target server.
In a second aspect, the present disclosure provides an IP forgery prevention information transmission method, applied to a server, including:
Responding to a target message sent by a client or load balancing equipment, if the target message contains a TOA field and a tag field of a TCP option address, generating a second tag corresponding to a destination address in the target message by using a generation mode which is agreed in advance with the load balancing equipment, wherein the message sent by the load balancing equipment contains the TOA field and the tag field at the same time, and the value of the tag field in the message sent by the load balancing equipment is a tag which is generated by the load balancing equipment by using the generation mode and corresponds to the destination address in the message;
determining whether a second TOA field in the target message is credible according to a matching result of the second tag and a second tag field in the target message;
if the second TOA field is trusted, the second TOA field is parsed to obtain a client source address.
In a third aspect, the present disclosure provides an IP forgery prevention information transmission apparatus applied to a load balancing device, including:
The first generation module is used for responding to a first message sent by a client, replacing a source address in the first message with an address of the load balancing equipment, generating a TCP option address TOA based on the source address in the first message, and generating a first label corresponding to a destination address in the first message by utilizing a generation mode pre-agreed with a destination server;
The writing module is used for writing the TOA and the first label into the first message obtained after address replacement to obtain a second message;
And the sending module is used for sending the second message to the target server so as to determine whether the TOA field in the second message is credible or not based on the first tag and the generation mode by the target server.
In a fourth aspect, the present disclosure provides an IP forgery prevention information transmission apparatus applied to a server, including:
A second generating module, configured to generate a second label corresponding to a destination address in a target packet according to a generation mode pre-agreed by a load balancing device if the target packet simultaneously includes a TCP option address TOA field and a label field in response to receiving the target packet sent by a client or the load balancing device, where the packet sent by the load balancing device simultaneously includes the TOA field and the label field, and a value of the label field in the packet sent by the load balancing device is a label corresponding to the destination address in the packet generated by the load balancing device according to the generation mode;
The first determining module is used for determining whether the second TOA field in the target message is credible according to a matching result of the second tag and the second tag field in the target message;
And the analysis module is used for analyzing the second TOA field if the second TOA field is trusted so as to acquire the source address of the client.
In a fifth aspect, the present disclosure provides a computer-readable medium having stored thereon a computer program which, when executed by a processing device, implements the steps of the IP falsification-preventing information transmission method provided in the first aspect of the present disclosure or the steps of the IP falsification-preventing information transmission method provided in the second aspect of the present disclosure.
In a sixth aspect, the present disclosure provides an electronic device, comprising:
A storage device having a computer program stored thereon;
Processing means for executing the computer program in the storage means to realize the steps of the IP falsification-preventing information transmission method provided in the first aspect of the present disclosure or the steps of the IP falsification-preventing information transmission method provided in the second aspect of the present disclosure.
In a seventh aspect, the present disclosure provides a computer program product comprising a computer program which, when executed by a processor, implements the steps of the IP falsification prevention information transmission method provided in the first aspect of the present disclosure or the steps of the IP falsification prevention information transmission method provided in the second aspect of the present disclosure.
In the above technical solution, the message forwarded by the load balancing device to the server includes not only the TOA field but also the tag. The label is generated by the load balancing device by utilizing a generation mode which is agreed with the server in advance, namely, only the load balancing device and the server know the generation mode of the label, and an attack end cannot forge the correct label naturally because the attack end does not know the generation mode of the label. Therefore, after the server receives the message, the expected label can be generated in the same mode as that of the label generated by the load balancing device, and whether the TOA field in the received message is credible or not is determined according to the matching condition of the expected label and the label field in the received message, namely whether the source address in the TOA field is counterfeit or not is determined, so that the problem that an attack end obtains the counterfeit source address through the server caused by counterfeiting the TOA field and the label is solved, the problem that a security system of the server is invalid due to bypass of a security policy aiming at the source address of the client on the server is avoided, and the protection effect of the security system of the server is ensured. In addition, the attack end cannot collect the label in the message received by the server from the load balancing device, but can only grasp the label in the message of the cloud server configuration test, and the label grasped by the attack end is inconsistent with the label in the message received by the server because the label is associated with the destination address in the message, so that the attack end cannot realize attack by replaying the message.
Additional features and advantages of the present disclosure will be set forth in the detailed description which follows.
Drawings
The above and other features, advantages, and aspects of embodiments of the present disclosure will become more apparent by reference to the following detailed description when taken in conjunction with the accompanying drawings. The same or similar reference numbers will be used throughout the drawings to refer to the same or like elements. It should be understood that the figures are schematic and that elements and components are not necessarily drawn to scale. In the drawings:
Fig. 1 is a schematic structural diagram of an Ipv4 packet according to an exemplary embodiment.
Fig. 2 is a schematic structural diagram of an Ipv6 packet according to an exemplary embodiment.
Fig. 3 is a schematic diagram of a process in which an attack end sends a malicious TOA field to a load balancing device to enable a server to acquire a fake source address in the related art.
Fig. 4 is a schematic diagram of a process in which an attack end sends a malicious TOA field to a server to enable the server to obtain a fake source address in the related art.
Fig. 5 is a schematic diagram of a process for alleviating the risk of falsifying a source address in the TOA field in the related art.
Fig. 6 is a flowchart illustrating an information transmission method applied to a load balancing apparatus according to an exemplary embodiment.
Fig. 7 is a schematic diagram showing the structure of a variable portion according to an exemplary embodiment.
Fig. 8 is a flowchart illustrating an information transmission method applied to a load balancing apparatus according to another exemplary embodiment.
Fig. 9 is a flowchart illustrating an information transmission method applied to a server according to an exemplary embodiment.
Fig. 10 is a block diagram illustrating an information transmission apparatus applied to a load balancing device according to an exemplary embodiment.
Fig. 11 is a block diagram illustrating an information transmission apparatus applied to a server according to an exemplary embodiment.
Fig. 12 is a schematic diagram showing a structure of an electronic device according to an exemplary embodiment.
Detailed Description
Before describing specific embodiments of the present disclosure, a description is first given of basic concepts related to the present disclosure.
As shown in fig. 1, the IPv4 message is composed of a header (i.e., a header) and data, wherein the data is data that needs to be transmitted by a higher layer, and the header is control information added for correctly transmitting the higher layer data. The former part of the header is fixed in length (i.e., fixed part), for a total of 20 bytes, which is all IP datagrams must have. Following the fixed part of the header is an optional field (i.e. the variable part), of variable length. I.e. the header of the IPv4 message comprises a fixed part and a variable part.
As shown in fig. 2, the IPv6 message is composed of a header (i.e., a header) and data, wherein the data is data that needs to be transmitted by a higher layer, and the header is control information added for correctly transmitting the higher layer data. The former part of the header is fixed in length (i.e. the base header), for a total of 20 bytes, which is all IP datagrams must have. Following the fixed portion of the header is an extension header. I.e., the header of the IPv6 message includes a base header and an extension header (also referred to as an extension header).
As discussed in the background art, the attack end may construct a malicious TOA field and write a fake source address in the TOA, and since the TOA module of the current load balancing device cannot well eliminate the malicious TOA, the client source address acquired by the server is actually fake, and these fake client source addresses will cause the security system of the server to fail, resulting in security risk.
At present, there are two main scenarios in which malicious TOA fields cause source address falsification. As shown in fig. 3, the first scenario is that the attack end intentionally adds a TOA of a fake source address (i.e., IP address 1.1.1.1 in fig. 3) to a variable part (including option) field of a header of an IPv4 packet sent to the load balancing device, and the attack end fills other option fields of the variable part to make the total length of the variable part in the whole packet greater than 32 bytes, because the TCP protocol stack specifies that the total length of the variable part cannot exceed 40 bytes (i.e., the maximum limit length), so if the current length of the variable part in the packet sent to the load balancing device by the attack end is greater than 32 bytes, the remaining length of the variable part is less than 8 bytes, and the length of the TOA field is 8 bytes, so after the load balancing device receives the packet sent by the attack end, since there is not enough space to write a real TOA field (i.e., the TOA field containing the source address of the attack end belongs to the TOA field), the current general handling method is to discard the real TOA field written, and forward the TOA field carried by the attack end to the server directly to the server. After receiving the message sent by the load balancing device, the server extracts the source address from the TOA field of the received message, and finally obtains the source address forged by the attack end, but not the real source address of the attack end.
The second scenario is that the attack end directly sends a malicious TOA field to the server, so that the server obtains a fake source address. As shown in fig. 4, the server can be accessed by the load balancing device and can also be directly accessed by the client, so that when the server receives the message, if the message does not carry the TOA field, the message is considered to be directly accessed by the client, and at this time, the source address of the client can be directly extracted from the current TCP connection; if the message carries a TOA field, it is considered a load balancing device access, at which point the client source address is extracted from the TOA field. When the attack end deliberately carries the TOA field containing the falsified source address in the message, the server cannot distinguish whether the TOA field is falsified, so that the source address can only be extracted from the TOA field, and finally the falsified client source address of the attack end is obtained.
In order to mitigate the risk of falsifying a source address by a malicious TOA field, for the first scenario described above, the present stage is implemented by adjusting a writing manner of the TOA field. Specifically, as shown in fig. 5, after the load balancing device receives a packet from the client, it first detects whether the packet contains a TOA field, if the packet does not contain the TOA field, it inserts a real TOA field, and if the packet contains the TOA field, it uses the real TOA field to cover the original TOA field in the packet. Although the malicious TOA can be prevented from being transmitted to the server in a penetrating way, the attack end can launch the attack through another mode, namely the variable part of the message of the attack end does not carry any TOA field, but various common option fields are used for filling, so that the current length of the variable part exceeds 32 bytes, the TOA field can not be inserted into the load balancing equipment, the TOA field can not be covered, the load balancing equipment can only transmit the message which does not contain any TOA field to the server, the server can not extract the source address of the client from the TOA field, the address established by TCP can only be used as the source address of the client, the source address of the load balancing equipment is finally used as the source address of the client, the aim of forging the source address of the attack end is achieved, and the problem that the server can not acquire the real source address of the attack end is finally caused.
In order to alleviate the risk of falsifying the source address by the malicious TOA field, aiming at the second scenario, under the condition that the attack end sends the malicious TOA field to the server, the server sets an address white list of the load balancing device, and only analyzes the TOA field in the message sent by the load balancing device in the address white list. Although the interference of malicious TOA can be avoided to a certain extent in the mode, an address white list needs to be maintained, if the address of the last load balancing device is changed, the address white list needs to be updated synchronously, and when the updating is not completed, the TOA field can not be extracted correctly by a message sent by the load balancing device, so that the real source address of a client can not be obtained, and the protection effect of security systems such as an anticreeper system, a anti-brushing system and the like of a server is affected.
In view of this, the present disclosure provides an information transmission method, apparatus, medium, electronic device, and program product that prevent IP forgery.
Before describing the specific embodiments of the present disclosure, an application scenario of the present disclosure will be first described. In the current software service model, in order to provide a large-scale access capability, a plurality of servers are typically deployed to provide services to the outside. In the service system of the present stage, a client sends a message to a load balancing device, wherein a source address in the message is an IP address of the client, and a destination address is a Virtual IP (VIP) address of the load balancing device. The load balancing device selects one of the plurality of servers as a target server according to a policy configured by the load balancing device for ensuring load balancing, and converts the received message through a source network address conversion (Source Network Address Translation, SNAT) technology, specifically, the load balancing device modifies a source address in the message received from the client into an IP address of the load balancing device, and sends the modified message to the target server. After the target server accesses the shared database, generating a response message for the modified message, and sending the response message to the load balancing device based on the source address of the load balancing device; the load balancing device converts the destination address in the response message into the source address of the client and forwards the source address to the corresponding client.
Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While certain embodiments of the present disclosure have been shown in the accompanying drawings, it is to be understood that the present disclosure may be embodied in various forms and should not be construed as limited to the embodiments set forth herein, but are provided to provide a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are for illustration purposes only and are not intended to limit the scope of the present disclosure.
It should be understood that the various steps recited in the method embodiments of the present disclosure may be performed in a different order and/or performed in parallel. Furthermore, method embodiments may include additional steps and/or omit performing the illustrated steps. The scope of the present disclosure is not limited in this respect.
The term "including" and variations thereof as used herein are intended to be open-ended, i.e., including, but not limited to. The term "based on" is based at least in part on. The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments. Related definitions of other terms will be given in the description below.
It should be noted that the terms "first," "second," and the like in this disclosure are merely used to distinguish between different devices, modules, or units and are not used to define an order or interdependence of functions performed by the devices, modules, or units.
It should be noted that references to "one", "a plurality" and "a plurality" in this disclosure are intended to be illustrative rather than limiting, and those of ordinary skill in the art will appreciate that "one or more" is intended to be understood as "one or more" unless the context clearly indicates otherwise.
The names of messages or information interacted between the various devices in the embodiments of the present disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.
It will be appreciated that prior to using the technical solutions disclosed in the embodiments of the present disclosure, the user should be informed and authorized of the type, usage range, usage scenario, etc. of the personal information related to the present disclosure in an appropriate manner according to the relevant legal regulations.
For example, in response to receiving an active request from a user, a prompt is sent to the user to explicitly prompt the user that the operation it is requesting to perform will require personal information to be obtained and used with the user. Thus, the user can autonomously select whether to provide personal information to software or hardware such as an electronic device, an application program, a server or a storage medium for executing the operation of the technical scheme of the present disclosure according to the prompt information.
As an alternative but non-limiting implementation, in response to receiving an active request from a user, the manner in which the prompt information is sent to the user may be, for example, a popup, in which the prompt information may be presented in a text manner. In addition, a selection control for the user to select to provide personal information to the electronic device in a 'consent' or 'disagreement' manner can be carried in the popup window.
It will be appreciated that the above-described notification and user authorization process is merely illustrative and not limiting of the implementations of the present disclosure, and that other ways of satisfying relevant legal regulations may be applied to the implementations of the present disclosure.
Meanwhile, it can be understood that the data (including but not limited to the data itself, the acquisition or the use of the data) related to the technical scheme should conform to the requirements of the corresponding laws and regulations and related regulations.
Fig. 6 is a flowchart illustrating an information transmission method applied to a load balancing apparatus according to an exemplary embodiment. As shown in fig. 6, the method may include the following S101 to S103.
In S101, in response to receiving the first packet sent by the client, the source address in the first packet is replaced with the address of the load balancing device itself, and the TCP option address TOA is generated based on the source address in the first packet, and the first tag corresponding to the destination address in the first packet is generated by using a generation manner pre-agreed with the destination server.
In the present disclosure, after receiving a first packet sent by a client, source address conversion may be performed on the first packet first, that is, a source address in the first packet is modified to an address of a load balancing device itself (i.e., an IP address of the load balancing device).
As shown in fig. 7 (taking a message as an example of IPv 4), the variable portion of the message sent by the load balancing device to the server includes not only the TOA field, but also a tag field, where the tag field may be generated based on the destination address in the current message, and the server may automatically identify, based on the tag field, whether the TOA field in the received message is trusted, that is, determine whether the source address in the TOA field in the message is forged.
As shown in fig. 7, the tag field may be divided into 3 parts, i.e., an operation code (Opcode) field, a length (Opsize) field, and a DATA (DATA) field. The length of the Optode field is1 byte, and is used for identifying the option category, and the value of the Optode field is used for identifying the tag field category, and is usually a preset identification, and is generally distinguished from the common option; opsize fields are 1 byte in length and are used to characterize the length of the entire tag field; the DATA field has a length of 2 bytes, in particular Label DATA, i.e. the value of the Label field.
After receiving the first message, the load balancing device may select one server from the multiple servers as a target server according to a policy configured by the load balancing device for ensuring load balancing. Then, a first label corresponding to the destination address in the first message can be generated by utilizing a generation mode pre-agreed with the destination server; and generating TOA based on the source address in the first message.
In S102, writing to the first message obtained after address replacement, a TOA and a first tag generated based on a source address in the first message, and obtaining a second message.
In the present disclosure, the second message includes one TOA field, i.e., the second message includes only one TOA field. When the first message obtained after address replacement does not contain the TOA field, the first TOA field and the first tag field can be written into the first message obtained after address replacement in an inserting mode; when the first message obtained after address replacement contains the TOA field, the first TOA field can be written into the first message obtained after address replacement in a coverage mode, namely, the original TOA field in the first message obtained after address replacement is covered by the first TOA field, and the first tag field is written into the first message obtained after address replacement in an inserting mode. The first TOA field includes a TOA generated based on a source address in the first message, the first tag field includes a first tag and a preset identifier for identifying a tag field class, the first tag is a value of the first tag field, specifically a value of a DATA field of the first tag field, and the preset identifier is a value of an Opcode field.
In S103, the second message is sent to the target server, so that the target server determines whether the TOA field in the second message is trusted based on the first tag and the generation mode pre-agreed with the load balancing device.
In the disclosure, after receiving a second message sent by a load balancing device, a target server may generate a tag corresponding to a destination address in the second message by using a generation manner predetermined by the load balancing device, determine, according to a matching result of the tag and the first tag, whether a TOA field in the second message is trusted, and when the TOA field in the second message is trusted, parse the TOA field in the second message to obtain a source address of the client, and when the TOA field in the second message is not trusted, ignore the TOA field, that is, not parse the TOA field in the second message.
In the above technical solution, the message forwarded by the load balancing device to the server includes not only the TOA field but also the tag. The label is generated by the load balancing device by utilizing a generation mode which is agreed with the server in advance, namely, only the load balancing device and the server know the generation mode of the label, and an attack end cannot forge the correct label naturally because the attack end does not know the generation mode of the label. Therefore, after the server receives the message, the expected label can be generated in the same mode as that of the label generated by the load balancing device, and whether the TOA field in the received message is credible or not is determined according to the matching condition of the expected label and the label field in the received message, namely whether the source address in the TOA field is counterfeit or not is determined, so that the problem that an attack end obtains the counterfeit source address through the server caused by counterfeiting the TOA field and the label is solved, the problem that a security system of the server is invalid due to bypass of a security policy aiming at the source address of the client on the server is avoided, and the protection effect of the security system of the server is ensured. In addition, the attack end cannot collect the label in the message received by the server from the load balancing device, but can only grasp the label in the message of the cloud server configuration test, and the label grasped by the attack end is inconsistent with the label in the message received by the server because the label is associated with the destination address in the message, so that the attack end cannot realize attack by replaying the message.
The following describes in detail the specific embodiment of generating the first tag corresponding to the destination address in the first message by using the generation method predetermined with the destination server in S101. Specifically, the detailed description may be made by various embodiments, and in one embodiment, it may be achieved by the following steps (a 1) and (a 2).
Step (a 1): and carrying out hash mapping on the destination address in the first message by utilizing a hash mapping mode pre-agreed with the destination server to obtain a first hash value.
In the present disclosure, hash mapping may be performed on a destination address in a first Message by using a hash mapping manner such as cyclic redundancy check (Cyclic Redundancy Check, cr 32), MD5 Message-Digest Algorithm (MD 5 Message-Digest Algorithm) and the like, so as to obtain a first hash value.
Step (a 2): based on the first hash value, a first tag is generated.
Since the length of the DATA field of the tag field is 2 bytes, after the first hash value corresponding to the destination address in the first packet is obtained in the above step (a 1), when the length of the first hash value is greater than two bytes, the first two bytes of the first hash value may be intercepted as the value of the DATA field of the first tag field, and when the length of the first hash value is less than or equal to two bytes, the first hash value may be directly taken as the DATA field of the first tag field, thereby generating the first tag.
In another embodiment, the first tag field may be formed by the following steps (b 1) to (b 3):
Step (b 1): and encrypting the destination address in the first message by using a salt value which is agreed with the destination server in advance to obtain a first ciphertext.
Step (b 2): and carrying out hash mapping on the first ciphertext by utilizing a hash mapping mode which is agreed with the target server in advance to obtain a second hash value.
Step (b 3): the first tag is generated based on the second hash value.
Since the length of the DATA field of the tag field is 2 bytes, after the second hash value corresponding to the first ciphertext is obtained in the step (b 2), when the length of the second hash value is greater than two bytes, the first two bytes of the second hash value may be intercepted to be the value of the DATA field of the first tag field, and when the length of the second hash value is less than or equal to two bytes, the second hash value may be directly used as the value of the DATA field of the first tag field, thereby generating the first tag.
In the above embodiment, before performing hash operation on the destination address in the first message, the destination address is encrypted by using a salt value predetermined in advance with the destination server, and then hash mapping is performed on the first ciphertext obtained after the encryption. Therefore, even if the attack end guesses the hash mapping mode agreed by the load balancing equipment and the target server, the agreed salt values of the load balancing equipment and the target server are difficult to obtain, and correct labels cannot be forged, so that the server can accurately identify whether the source address in the TOA field in the message is forged according to the labels in the received message.
The following describes in detail the specific embodiment of writing the TOA and the first tag generated based on the source address in the first packet into the first packet obtained after the address replacement in S102, and obtaining the second packet.
Specifically, if the first message obtained after address replacement does not contain the TOA field, inserting the first TOA field and the first tag field into the header of the first message obtained after address replacement to obtain a second message; if the first message obtained after the address replacement contains a TOA field, covering the TOA field in the header of the first message obtained after the address replacement by using the first TOA field, and inserting a first tag field into the header obtained after the field coverage to obtain a second message.
In the present disclosure, as shown in fig. 8, before writing a first TOA field and a first tag field into a first packet obtained after address replacement, a load balancing device determines whether the first packet obtained after address replacement includes the TOA field, so as to determine whether to write the first TOA field in an inserted manner or write the first TOA field in an overlapping manner. When the first message obtained after address replacement does not contain the TOA field, an attempt can be made to write the first TOA field in an inserting mode, namely, an attempt is made to insert the first TOA field and the first tag field into the header of the first message obtained after address replacement so as to obtain a second message; when the first message obtained after address replacement contains a TOA field, the first TOA field can be written in an overlay mode, namely, the original TOA field in the header of the first message obtained after address replacement is attempted to be overlaid by the first TOA field, and a first tag field is inserted into the header obtained after field overlay, so that a second message is obtained.
As shown in fig. 8, if the load balancing device attempts to insert the first TOA field and the first tag field successfully, or attempts to use the first TOA field to cover the original TOA field in the header of the first packet obtained after the address replacement and insert the first tag field into the header obtained after the field coverage successfully, the load balancing device adopts the real TOA back source and carries the tag field, that is, the load balancing device sends the second packet carrying the first TOA field and the first tag field to the target server.
As shown in fig. 8, if the load balancing device fails to write due to the limited option length, that is, attempts to insert the first TOA field and the first tag field, then deletes the unnecessary option field in the first packet obtained after address replacement, so as to vacate the option space, and then inserts the first TOA field and the first tag field; or the load balancing device tries to cover the original TOA field in the header of the first message obtained after address replacement by using the first TOA field, and fails to insert the first tag field into the header obtained after field coverage, then deletes the unnecessary option field in the first message obtained after address replacement, so as to vacate the option space, and then covers the original TOA field in the header of the first message obtained after address replacement by using the first TOA field, and inserts the first tag field. And then, the load balancing equipment adopts a real TOA (time of arrival) back source and carries a tag field.
Where the optional field refers to a field that does not affect TCP protocol transmission and control. The maximum message segment length (Maximum Segment Size, MSS) field (4 bytes), the SACK enable (SACK-PERMITTED) field (2 bytes) and the Window expansion (Window Scale) field (3 bytes) affect TCP transmission, belong to the necessary option fields, the load balancing device must transmit to the server, and all other option fields except for the variable part of the header of the first message obtained after address replacement belong to the unnecessary option fields.
The following describes in detail the specific embodiment of inserting the first TOA field and the first tag field into the header of the first packet obtained after the address replacement to obtain the second packet.
Specifically, when the first packet is an IPv4 packet, the first TOA field and the first tag field may be inserted into a variable portion of a header of the first packet that is obtained after address replacement. Since the TCP protocol stack specifies that the length of the variable portion of the IPv4 packet cannot exceed 40 bytes, before inserting the first TOA field and the first tag field into the variable portion of the header of the first packet obtained after address replacement, it is necessary to determine whether the remaining length of the variable portion satisfies the plug condition, that is, whether the remaining length of the variable portion is greater than or equal to the total length of the first TOA field and the first tag field, where the remaining length is the difference between the maximum limit length (i.e., 40 bytes) of the variable portion and the current length of the variable portion. When the remaining length of the variable part of the header of the first message obtained after the address replacement is greater than or equal to the total length of the first TOA field and the first tag field, determining that the insertion condition is satisfied, and at this time, directly inserting the first TOA field and the first tag field into the variable part of the header of the first message obtained after the address replacement; and when the remaining length of the variable part of the header of the first message obtained after the address replacement is smaller than the total length of the first TOA field and the first tag field, deleting at least part of unnecessary option fields in the variable part of the header of the first message obtained after the address replacement, so that the remaining length of the variable part obtained after the deletion of the fields is greater than or equal to the total length of the first TOA field and the first tag field, namely, a space of the variable part is vacated, and then inserting the first TOA field and the first tag field into the variable part obtained after the deletion of the fields to obtain the second message.
In the present disclosure, all unnecessary option fields in the variable portion may be deleted, or some unnecessary option fields in the variable portion may be deleted, as long as the remaining length of the variable portion obtained after deletion of the fields is made greater than or equal to the total length of the first TOA field and the first tag field.
When the first message is an IPv6 message, a first TOA field and a first tag field may be inserted into an extension header of a header of the first message obtained after address replacement, to obtain a second message. Because the extension header of the IPv6 packet has no length limitation, the first TOA field and the first tag field may be directly inserted into the extension header of the first packet obtained after address replacement, so as to obtain the second packet.
The following describes in detail the above description of the specific embodiment of inserting the first tag field into the header obtained after field coverage.
When the first packet is an IPv4 packet, the first tag field may be inserted into a variable portion of the header obtained after the field of the first packet obtained after the address replacement is covered. Since the TCP protocol stack specifies that the length of the variable portion of the IPv4 packet cannot exceed 40 bytes, it is necessary to determine whether the remaining length of the variable portion of the header after field coverage satisfies the plug condition before inserting the first tag field into the variable portion of the header after field coverage, that is, whether the remaining length of the variable portion of the header after field coverage is greater than or equal to the length of the first tag field. When the remaining length of the variable part obtained after field coverage is greater than or equal to the length of the first tag field, the first tag field can be directly inserted into the variable part obtained after field coverage; and when the remaining length of the variable part obtained after the field coverage of the first message obtained after the address replacement is smaller than the length of the first tag field, deleting at least part of unnecessary option fields in the variable part obtained after the field coverage, so that the remaining length of the variable part obtained after the field deletion is greater than or equal to the length of the first tag field, namely, a space of the variable part is vacated, and then inserting the first tag field into the variable part obtained after the field deletion to obtain the second message.
In the present disclosure, all unnecessary option fields in the variable portion obtained after field coverage may be deleted, or some unnecessary option fields in the variable portion obtained after field coverage may be deleted, as long as the remaining length of the variable portion obtained after field deletion is made greater than or equal to the length of the first tag field.
When the first message is an IPv6 message, a first tag field may be inserted into an extension header of a header obtained after field coverage of the first message obtained after address replacement. Because the extension header of the IPv6 packet has no length limitation, the first tag field may be directly inserted into the extension header of the header obtained after field coverage, so as to obtain the second packet.
Fig. 9 is a flowchart illustrating an information transmission method applied to a server according to an exemplary embodiment. As shown in fig. 9, the method may include the following S201 to S203.
In S201, in response to receiving the target packet sent by the client or the load balancing device, if the target packet includes both the TOA field and the tag field of the TCP option address, a second tag corresponding to the destination address in the target packet is generated by using a generation manner pre-agreed with the load balancing device.
In the present disclosure, the server may be accessed by the load balancing device and may also be accessed directly by the client, so that the target message received by the server may be sent by the client or may be sent by the load balancing device. The message sent by the load balancing device simultaneously comprises a TOA field and a tag field, and the value of the tag field in the message sent by the load balancing device is a tag which is generated by the load balancing device in a generating mode and corresponds to a destination address in the message. The attacker can forge both the TOA field and the tag, which expects to bypass the security policy of the server for itself.
In S202, it is determined whether the second TOA field in the target packet is trusted according to the result of matching the second tag with the second tag field in the target packet.
In S203, if the second TOA field is authentic, the second TOA field is parsed to obtain the source address of the client.
If the second tag is consistent with the value of the second tag field in the target message, determining that the second TOA field is trusted, that is, determining that the source address in the second TOA field is not fake, but is a real client source address, at this time, the second TOA field may be resolved to obtain the client source address. If the second tag is inconsistent with the value of the second tag field in the target message, determining that the second TOA field is not trusted, that is, determining that the source address in the second TOA field is fake and not the real client source address, and at this time, omitting the second TOA field, that is, not resolving the second TOA field.
In the above technical solution, the message forwarded by the load balancing device to the server includes not only the TOA field but also the tag. The label is generated by the load balancing device by utilizing a generation mode which is agreed with the server in advance, namely, only the load balancing device and the server know the generation mode of the label, and an attack end cannot forge the correct label naturally because the attack end does not know the generation mode of the label. Therefore, after the server receives the message, the expected label can be generated in the same mode as that of the label generated by the load balancing device, and whether the TOA field in the received message is credible or not is determined according to the matching condition of the expected label and the label field in the received message, namely whether the source address in the TOA field is counterfeit or not is determined, so that the problem that an attack end obtains the counterfeit source address through the server caused by counterfeiting the TOA field and the label is solved, the problem that a security system of the server is invalid due to bypass of a security policy aiming at the source address of the client on the server is avoided, and the protection effect of the security system of the server is ensured. In addition, the attack end cannot collect the label in the message received by the server from the load balancing device, but can only grasp the label in the message of the cloud server configuration test, and the label grasped by the attack end is inconsistent with the label in the message received by the server because the label is associated with the destination address in the message, so that the attack end cannot realize attack by replaying the message.
The following describes in detail the specific embodiment of generating the second label corresponding to the destination address in the target packet by using the generation method predetermined by the load balancing device in S201.
In one embodiment, a hash mapping mode pre-agreed with the load balancing device may be used to perform hash mapping on the destination address in the target message to obtain a third hash value; then, a second tag is generated based on the third hash value.
In another embodiment, the destination address in the target message may be encrypted by using a salt value pre-agreed with the load balancing device to obtain the second ciphertext; then, carrying out hash mapping on the second ciphertext by utilizing a hash mapping mode pre-agreed with the load balancing equipment to obtain a fourth hash value; finally, a second tag is generated based on the fourth hash value.
In the present disclosure, the server may generate, in a similar manner to the generation manner previously agreed with the target server, the first label corresponding to the destination address in the first packet, and generate, in a generation manner previously agreed with the load balancing device, the second label corresponding to the destination address in the target packet, which is not described in detail in this disclosure.
In one possible embodiment, the method may further include the steps of:
if the target message contains a TOA field and does not contain a tag field, determining that the second TOA field is not trusted.
In order to bypass the security policy of the server for the client, the attack end may forge the TOA field and the tag at the same time, or may forge only the TOA field, and the message sent by the load balancing device includes the TOA field and the tag field at the same time, and the message directly sent by the normal client to the server does not include the TOA field, so when the target message includes the TOA field and does not include the tag field, it is indicated that the target message is sent by the attack end, and at this time, it may be determined that the second TOA field is not trusted.
In one possible embodiment, the method may further include the steps of:
If the target message does not contain the TOA field, the source address of the TCP connection used to transmit the target message is determined to be the client source address.
In the present disclosure, when the target message does not include the TOA field, it is determined that the target message is sent by the client, and at this time, the source address of the client cannot be obtained by parsing the TOA, so that the TCP connection for transmitting the target message may be determined first, and then, the source address of the TCP connection is determined as the source address of the client.
In one possible embodiment, the method may further include the following two steps:
if the target message contains a TOA field and does not contain a tag field, determining that the second TOA field is not trusted;
If the target message does not contain the TOA field, the source address of the TCP connection used to transmit the target message is determined to be the client source address.
In one possible embodiment, the method may further include the steps of:
If the header of the target message is detected to contain a preset identifier for identifying the tag field category, determining that the target message contains the tag field;
And determining a field in which the preset identifier is located as a second tag field.
In the present disclosure, after receiving a target message, a target server determines whether a tag field is included in the target message by identifying whether a header of the target message includes a preset identifier.
Fig. 10 is a block diagram illustrating an IP forgery prevention information transmission apparatus applied to a load balancing device according to an exemplary embodiment. As shown in fig. 10, the IP forgery prevention information transmission apparatus 300 applied to the load balancing device includes:
A first generating module 301, configured to replace a source address in a first packet with an address of the load balancing device itself in response to receiving the first packet sent by a client, generate a TCP option address TOA based on the source address in the first packet, and generate a first tag corresponding to a destination address in the first packet by using a generation manner predetermined with a destination server;
a writing module 302, configured to write the TOA and the first tag into the first packet obtained after address replacement, to obtain a second packet;
and a sending module 303, configured to send the second packet to the target server, so that the target server determines whether the TOA field in the second packet is trusted based on the first tag and the generation manner.
In the above technical solution, the message forwarded by the load balancing device to the server includes not only the TOA field but also the tag. The label is generated by the load balancing device by utilizing a generation mode which is agreed with the server in advance, namely, only the load balancing device and the server know the generation mode of the label, and an attack end cannot forge the correct label naturally because the attack end does not know the generation mode of the label. Therefore, after the server receives the message, the expected label can be generated in the same mode as that of the label generated by the load balancing device, and whether the TOA field in the received message is credible or not is determined according to the matching condition of the expected label and the label field in the received message, namely whether the source address in the TOA field is counterfeit or not is determined, so that the problem that an attack end obtains the counterfeit source address through the server caused by counterfeiting the TOA field and the label is solved, the problem that a security system of the server is invalid due to bypass of a security policy aiming at the source address of the client on the server is avoided, and the protection effect of the security system of the server is ensured. In addition, the attack end cannot collect the label in the message received by the server from the load balancing device, but can only grasp the label in the message of the cloud server configuration test, and the label grasped by the attack end is inconsistent with the label in the message received by the server because the label is associated with the destination address in the message, so that the attack end cannot realize attack by replaying the message.
Optionally, the writing module 302 includes:
And the first inserting sub-module is used for inserting a first TOA field and a first tag field into the header of the first message obtained after the address is replaced if the first message obtained after the address is replaced does not contain the TOA field, so as to obtain a second message, wherein the first TOA field comprises the TOA, and the first tag field comprises the first tag and a preset identifier for identifying the type of the tag field.
Optionally, the first message is an IPv4 message;
the first insertion submodule includes:
A first deletion submodule, configured to delete at least a part of unnecessary option fields in the variable part if a remaining length of the variable part of the header is less than a total length of the first TOA field and the first tag field, so that the remaining length of the variable part obtained after deleting the fields is greater than or equal to the total length, where the remaining length is a difference between a maximum limit length of the variable part and a current length of the variable part;
And the second inserting sub-module is used for inserting the first TOA field and the first tag field into the variable part obtained after the field is deleted to obtain a second message.
Optionally, the first message is an IPv6 message;
The first inserting sub-module is configured to insert the first TOA field and the first tag field into an extension header of a first packet obtained after address replacement, to obtain a second packet.
Optionally, the writing module 302 further includes:
and the covering sub-module is used for covering the TOA field in the header by using the first TOA field if the TOA field is contained in the first message obtained after the address is replaced, and inserting the first tag field into the header obtained after the field is covered to obtain the second message.
Optionally, the covering sub-module includes:
a second deletion submodule, configured to delete at least part of unnecessary option fields in a variable part obtained after field coverage if the first packet is an IPv4 packet and a remaining length of a header obtained after field coverage is smaller than a length of the first tag field, so that a remaining length of the variable part obtained after field coverage is greater than or equal to a length of the first tag field, where the remaining length is a difference between a maximum limit length of the variable part and a current length of the variable part; a third inserting sub-module, configured to insert the first tag field into the variable portion obtained after deleting the field;
and a fourth inserting sub-module, configured to insert the first tag field into an extension header of the header obtained after the field coverage if the first packet is an IPv6 packet.
Optionally, the first generating module 301 includes:
The first mapping sub-module is used for carrying out hash mapping on the destination address in the first message by utilizing a hash mapping mode pre-agreed with the target server to obtain a first hash value;
and the first generation sub-module is used for generating the first label based on the first hash value.
Optionally, the first generating module 301 includes:
The first encryption sub-module is used for encrypting the destination address in the first message by utilizing a salt value which is agreed in advance with the target server to obtain a first ciphertext;
the second mapping sub-module is used for carrying out hash mapping on the first ciphertext by utilizing a hash mapping mode which is agreed in advance with the target server to obtain a second hash value;
and the second generation sub-module is used for generating the first tag based on the second hash value.
Fig. 11 is a block diagram illustrating an IP forgery prevention information transmission apparatus applied to a server according to an exemplary embodiment. As shown in fig. 11, the IP forgery prevention information transmission apparatus 400 applied to a server includes:
A second generating module 401, configured to, in response to receiving a target packet sent by a client or a load balancing device, generate a second label corresponding to a destination address in the target packet by using a generation manner predefined by the load balancing device if the target packet includes both a TOA field and a label field, where the packet sent by the load balancing device includes both the TOA field and the label field, and a value of the label field in the packet sent by the load balancing device is a label corresponding to the destination address in the packet generated by the load balancing device by using the generation manner;
a first determining module 402, configured to determine whether a second TOA field in the target packet is trusted according to a result of matching the second tag with a second tag field in the target packet;
And the parsing module 403 is configured to parse the second TOA field to obtain the source address of the client if the second TOA field is trusted.
In the above technical solution, the message forwarded by the load balancing device to the server includes not only the TOA field but also the tag. The label is generated by the load balancing device by utilizing a generation mode which is agreed with the server in advance, namely, only the load balancing device and the server know the generation mode of the label, and an attack end cannot forge the correct label naturally because the attack end does not know the generation mode of the label. Therefore, after the server receives the message, the expected label can be generated in the same mode as that of the label generated by the load balancing device, and whether the TOA field in the received message is credible or not is determined according to the matching condition of the expected label and the label field in the received message, namely whether the source address in the TOA field is counterfeit or not is determined, so that the problem that an attack end obtains the counterfeit source address through the server caused by counterfeiting the TOA field and the label is solved, the problem that a security system of the server is invalid due to bypass of a security policy aiming at the source address of the client on the server is avoided, and the protection effect of the security system of the server is ensured. In addition, the attack end cannot collect the label in the message received by the server from the load balancing device, but can only grasp the label in the message of the cloud server configuration test, and the label grasped by the attack end is inconsistent with the label in the message received by the server because the label is associated with the destination address in the message, so that the attack end cannot realize attack by replaying the message.
Optionally, the first determining module 402 is configured to determine that the second TOA field is trusted if the second tag is consistent with a value of the second tag field.
Optionally, the second generating module 401 includes:
a third mapping sub-module, configured to perform hash mapping on a destination address in the target packet by using a hash mapping manner pre-agreed with the load balancing device, to obtain a third hash value;
and a third generation sub-module, configured to generate the second tag based on the third hash value.
Optionally, the second generating module 401 includes:
The second encryption sub-module is used for encrypting the destination address in the target message by utilizing a salt value which is agreed in advance with the load balancing equipment to obtain a second ciphertext;
a fourth mapping sub-module, configured to perform hash mapping on the second ciphertext by using a hash mapping manner that is pre-agreed with the load balancing device, to obtain a fourth hash value;
and a fourth generation sub-module, configured to generate the second tag based on the fourth hash value.
Optionally, the IP forgery prevention information transmission apparatus 400 applied to the server further includes:
A second determining module, configured to determine that the second TOA field is not trusted if the target packet includes the TOA field and does not include the tag field; and/or
And the third determining module is used for determining the source address of the TCP connection for transmitting the target message as the source address of the client if the target message does not contain the TOA field.
Optionally, the IP forgery prevention information transmission apparatus 400 applied to the server further includes:
A fourth determining module, configured to determine that the target packet includes a tag field if it is detected that the header of the target packet includes a preset identifier for identifying a tag field class;
And a fifth determining module, configured to determine a field in which the preset identifier is located as the second tag field.
In addition, the present disclosure also provides a computer-readable medium having stored thereon a computer program which, when executed by a processing apparatus, implements the steps of the above-described IP forgery prevention information transmission method for a load balancing device provided by the present disclosure or the steps of the above-described IP forgery prevention information transmission method for a server provided by the present disclosure.
In addition, the present disclosure also provides a computer program product, which includes a computer program, where the computer program when executed by a processor implements the steps of the above-mentioned IP forgery prevention information transmission method applied to a load balancing device provided by the present disclosure or the steps of the above-mentioned IP forgery prevention information transmission method applied to a server provided by the present disclosure.
Referring now to fig. 12, a schematic diagram of an electronic device (client or server) 600 suitable for use in implementing embodiments of the present disclosure is shown. The terminal devices in the embodiments of the present disclosure may include, but are not limited to, mobile terminals such as mobile phones, notebook computers, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and the like, and stationary terminals such as digital TVs, desktop computers, and the like. The electronic device shown in fig. 12 is merely an example and should not be construed to limit the functionality and scope of use of the disclosed embodiments.
As shown in fig. 12, the electronic device 600 may include a processing means (e.g., a central processing unit, a graphic processor, etc.) 601, which may perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM) 602 or a program loaded from a storage means 608 into a Random Access Memory (RAM) 603. In the RAM 603, various programs and data required for the operation of the electronic apparatus 600 are also stored. The processing device 601, the ROM 602, and the RAM 603 are connected to each other through a bus 604. An input/output (I/O) interface 605 is also connected to bus 604.
In general, the following devices may be connected to the I/O interface 605: input devices 606 including, for example, a touch screen, touchpad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, and the like; an output device 607 including, for example, a Liquid Crystal Display (LCD), a speaker, a vibrator, and the like; storage 608 including, for example, magnetic tape, hard disk, etc.; and a communication device 609. The communication means 609 may allow the electronic device 600 to communicate with other devices wirelessly or by wire to exchange data. While fig. 12 shows an electronic device 600 having various means, it is to be understood that not all of the illustrated means are required to be implemented or provided. More or fewer devices may be implemented or provided instead.
In particular, according to embodiments of the present disclosure, the processes described above with reference to flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a non-transitory computer readable medium, the computer program comprising program code for performing the method shown in the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network via communication means 609, or from storage means 608, or from ROM 602. The above-described functions defined in the methods of the embodiments of the present disclosure are performed when the computer program is executed by the processing device 601.
It should be noted that the computer readable medium described in the present disclosure may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this disclosure, a computer-readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present disclosure, however, the computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, with the computer-readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: electrical wires, fiber optic cables, RF (radio frequency), and the like, or any suitable combination of the foregoing.
In some embodiments, the clients, servers may communicate using any currently known or future developed network protocol, such as HTTP (HyperText Transfer Protocol ), and may be interconnected with any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network ("LAN"), a wide area network ("WAN"), the internet (e.g., the internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future developed networks.
The computer readable medium may be contained in the electronic device; or may exist alone without being incorporated into the electronic device.
The computer readable medium carries one or more programs which, when executed by the electronic device, cause the electronic device to: in response to receiving a first message sent by a client, replacing a source address in the first message with an address of load balancing equipment, generating a TCP option address TOA based on the source address in the first message, and generating a first label corresponding to a destination address in the first message by utilizing a generation mode pre-agreed with a target server; writing the TOA and the first label into the first message obtained after address replacement to obtain a second message; and sending the second message to the target server so as to determine whether the TOA field in the second message is credible or not based on the first tag and the generation mode by the target server.
Or the computer readable medium carries one or more programs which, when executed by the electronic device, cause the electronic device to: responding to a target message sent by a client or load balancing equipment, if the target message contains a TOA field and a tag field of a TCP option address, generating a second tag corresponding to a destination address in the target message by using a generation mode which is agreed in advance with the load balancing equipment, wherein the message sent by the load balancing equipment contains the TOA field and the tag field at the same time, and the value of the tag field in the message sent by the load balancing equipment is a tag which is generated by the load balancing equipment by using the generation mode and corresponds to the destination address in the message; determining whether a second TOA field in the target message is credible according to a matching result of the second tag and a second tag field in the target message; if the second TOA field is trusted, the second TOA field is parsed to obtain a client source address.
Computer program code for carrying out operations of the present disclosure may be written in one or more programming languages, including, but not limited to, an object oriented programming language such as Java, smalltalk, C ++ and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computer (for example, through the Internet using an Internet service provider).
The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The modules described in the embodiments of the present disclosure may be implemented in software or hardware. The name of the module is not limited to the module itself in some cases, for example, the parsing module may also parse the second TOA field if the second TOA field is trusted, so as to obtain a module of the source address of the client.
The functions described above herein may be performed, at least in part, by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: a Field Programmable Gate Array (FPGA), an Application Specific Integrated Circuit (ASIC), an Application Specific Standard Product (ASSP), a system on a chip (SOC), a Complex Programmable Logic Device (CPLD), and the like.
In the context of this disclosure, a machine-readable medium may be a tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. The machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
According to one or more embodiments of the present disclosure, example 1 provides an IP forgery prevention information transmission method applied to a load balancing device, including:
in response to receiving a first message sent by a client, replacing a source address in the first message with an address of load balancing equipment, generating a TCP option address TOA based on the source address in the first message, and generating a first label corresponding to a destination address in the first message by utilizing a generation mode pre-agreed with a target server;
Writing the TOA and the first label into the first message obtained after address replacement to obtain a second message;
And sending the second message to the target server so as to determine whether the TOA field in the second message is credible or not based on the first tag and the generation mode by the target server.
According to one or more embodiments of the present disclosure, example 2 provides the method of example 1, where writing the TOA and the first tag to the first packet obtained after address replacement, to obtain the second packet, includes:
If the first message obtained after address replacement does not contain a TOA field, a first TOA field and a first tag field are inserted into the header of the first message obtained after address replacement to obtain a second message, wherein the first TOA field comprises the TOA, and the first tag field comprises the first tag and a preset identifier for identifying the tag field type.
Example 3 provides the method of example 2, the first message being an IPv4 message, according to one or more embodiments of the present disclosure;
The first TOA field and the first tag field are inserted into the header of the first message obtained after address replacement to obtain a second message, which comprises the following steps:
Deleting at least part of unnecessary option fields in the variable part if the remaining length of the variable part of the header is less than the total length of the first TOA field and the first tag field, so that the remaining length of the variable part obtained after deleting the fields is greater than or equal to the total length, wherein the remaining length is the difference between the maximum limit length of the variable part and the current length of the variable part;
And inserting the first TOA field and the first tag field into the variable part obtained after the field is deleted to obtain a second message.
Example 4 provides the method of example 2, the first message being an IPv6 message, according to one or more embodiments of the present disclosure;
The first TOA field and the first tag field are inserted into the header of the first message obtained after address replacement to obtain a second message, which comprises the following steps:
And inserting the first TOA field and the first tag field into an extension header of a header of the first message obtained after address replacement to obtain a second message.
According to one or more embodiments of the present disclosure, example 5 provides the method of example 2, where the writing the first TOA field and the first tag field to the first packet obtained after address replacement, to obtain a second packet, further includes:
And if the first message obtained after the address replacement contains the TOA field, covering the TOA field in the header by using the first TOA field, and inserting the first tag field into the header obtained after the field coverage to obtain the second message.
According to one or more embodiments of the present disclosure, example 6 provides the method of example 5, the inserting the first tag field into the header obtained after field coverage, comprising:
If the first message is an IPv4 message and the remaining length of the header obtained after field coverage is less than the length of the first tag field, deleting at least part of the unnecessary option fields in the variable portion obtained after field coverage, so that the remaining length of the variable portion obtained after field deletion is greater than or equal to the length of the first tag field, where the remaining length is the difference between the maximum limit length of the variable portion and the current length of the variable portion; inserting the first tag field into the variable part obtained after deleting the field;
If the first message is an IPv6 message, the first tag field is inserted into an extension header of the header obtained after the field coverage.
According to one or more embodiments of the present disclosure, example 7 provides the method of any one of examples 1 to 6, wherein the generating, by using a generation manner agreed in advance with the target server, the first tag corresponding to the destination address in the first packet includes:
performing hash mapping on the destination address in the first message by utilizing a hash mapping mode pre-agreed with the target server to obtain a first hash value;
the first tag is generated based on the first hash value.
According to one or more embodiments of the present disclosure, example 8 provides the method of any one of examples 1 to 6, wherein the generating, by using a generation manner agreed in advance with the target server, the first tag corresponding to the destination address in the first packet includes:
Encrypting a destination address in the first message by using a salt value pre-agreed with the target server to obtain a first ciphertext;
Carrying out hash mapping on the first ciphertext by utilizing a hash mapping mode pre-agreed with the target server to obtain a second hash value;
The first tag is generated based on the second hash value.
According to one or more embodiments of the present disclosure, example 9 provides an IP forgery prevention information transmission method applied to a server, including:
Responding to a target message sent by a client or load balancing equipment, if the target message contains a TOA field and a tag field of a TCP option address, generating a second tag corresponding to a destination address in the target message by using a generation mode which is agreed in advance with the load balancing equipment, wherein the message sent by the load balancing equipment contains the TOA field and the tag field at the same time, and the value of the tag field in the message sent by the load balancing equipment is a tag which is generated by the load balancing equipment by using the generation mode and corresponds to the destination address in the message;
determining whether a second TOA field in the target message is credible according to a matching result of the second tag and a second tag field in the target message;
if the second TOA field is trusted, the second TOA field is parsed to obtain a client source address.
In accordance with one or more embodiments of the present disclosure, example 10 provides the method of example 9, the determining whether the second TOA field in the target message is trusted according to a result of the matching of the second tag with the value of the second tag field in the target message, comprising:
And if the second tag is consistent with the value of the second tag field, determining that the second TOA field is trusted.
According to one or more embodiments of the present disclosure, example 11 provides the method of example 9, wherein the generating, by using a generation manner pre-agreed with the load balancing device, a second label corresponding to a destination address in the target packet includes:
carrying out hash mapping on the destination address in the target message by utilizing a hash mapping mode pre-agreed with the load balancing equipment to obtain a third hash value;
and generating the second label based on the third hash value.
According to one or more embodiments of the present disclosure, example 12 provides the method of example 9, wherein the generating, using a generation manner pre-agreed with the load balancing device, the second label corresponding to the destination address in the target packet includes:
Encrypting a destination address in the target message by using a salt value pre-agreed with the load balancing equipment to obtain a second ciphertext;
Carrying out hash mapping on the second ciphertext by utilizing a hash mapping mode pre-agreed with the load balancing equipment to obtain a fourth hash value;
And generating the second label based on the fourth hash value.
According to one or more embodiments of the present disclosure, example 13 provides the method of any one of examples 9-12, the method further comprising:
If the target message contains a TOA field and does not contain a tag field, determining that the second TOA field is not trusted; and/or
If the target message does not contain the TOA field, determining the source address of the TCP connection for transmitting the target message as the source address of the client.
In accordance with one or more embodiments of the present disclosure, example 14 provides the method of any one of examples 9-12, the method further comprising:
If the header of the target message is detected to contain a preset identifier for identifying the tag field category, determining that the target message contains a tag field;
and determining a field in which the preset identifier is located as the second tag field.
According to one or more embodiments of the present disclosure, example 15 provides an IP forgery prevention information transmission apparatus applied to a load balancing device, including:
The first generation module is used for responding to a first message sent by a client, replacing a source address in the first message with an address of the load balancing equipment, generating a TCP option address TOA based on the source address in the first message, and generating a first label corresponding to a destination address in the first message by utilizing a generation mode pre-agreed with a destination server;
The writing module is used for writing the TOA and the first label into the first message obtained after address replacement to obtain a second message;
And the sending module is used for sending the second message to the target server so as to determine whether the TOA field in the second message is credible or not based on the first tag and the generation mode by the target server.
According to one or more embodiments of the present disclosure, example 16 provides an IP forgery prevention information transmission apparatus applied to a server, including:
A second generating module, configured to generate a second label corresponding to a destination address in a target packet according to a generation mode pre-agreed by a load balancing device if the target packet simultaneously includes a TCP option address TOA field and a label field in response to receiving the target packet sent by a client or the load balancing device, where the packet sent by the load balancing device simultaneously includes the TOA field and the label field, and a value of the label field in the packet sent by the load balancing device is a label corresponding to the destination address in the packet generated by the load balancing device according to the generation mode;
The first determining module is used for determining whether the second TOA field in the target message is credible according to a matching result of the second tag and the second tag field in the target message;
And the analysis module is used for analyzing the second TOA field if the second TOA field is trusted so as to acquire the source address of the client.
According to one or more embodiments of the present disclosure, example 17 provides a computer-readable medium having stored thereon a computer program which, when executed by a processing device, implements the steps of the IP forgery prevention information transmission method of any of examples 1 to 14.
Example 18 provides an electronic device, according to one or more embodiments of the present disclosure, comprising:
A storage device having a computer program stored thereon;
Processing means for executing the computer program in the storage means to realize the steps of the IP forgery prevention information transmission method according to any one of examples 1 to 14.
According to one or more embodiments of the present disclosure, example 19 provides a computer program product comprising a computer program which, when executed by a processor, implements the steps of the IP forgery prevention information transmission method of any one of examples 1 to 14.
The foregoing description is only of the preferred embodiments of the present disclosure and description of the principles of the technology being employed. It will be appreciated by persons skilled in the art that the scope of the disclosure referred to in this disclosure is not limited to the specific combinations of features described above, but also covers other embodiments which may be formed by any combination of features described above or equivalents thereof without departing from the spirit of the disclosure. Such as those described above, are mutually substituted with the technical features having similar functions disclosed in the present disclosure (but not limited thereto).
Moreover, although operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of the present disclosure. Certain features that are described in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination.
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are example forms of implementing the claims. The specific manner in which the various modules perform the operations in the apparatus of the above embodiments have been described in detail in connection with the embodiments of the method, and will not be described in detail herein.

Claims (19)

1. An information transmission method for preventing IP forgery, which is applied to load balancing equipment, comprises the following steps:
In response to receiving a first message sent by a client, replacing a source address in the first message with an address of load balancing equipment, generating a TCP option address TOA based on the source address, and generating a first label corresponding to a destination address in the first message by utilizing a generation mode pre-agreed with a destination server;
Writing the TOA and the first label into the first message obtained after address replacement to obtain a second message;
And sending the second message to the target server so as to determine whether the TOA field in the second message is credible or not based on the first tag and the generation mode by the target server.
2. The method of claim 1, wherein writing the TOA and the first tag to the first message obtained after address replacement to obtain a second message comprises:
If the first message obtained after address replacement does not contain a TOA field, a first TOA field and a first tag field are inserted into the header of the first message obtained after address replacement to obtain a second message, wherein the first TOA field comprises the TOA, and the first tag field comprises the first tag and a preset identifier for identifying the tag field type.
3. The method of claim 2, wherein the first message is an IPv4 message;
The first TOA field and the first tag field are inserted into the header of the first message obtained after address replacement to obtain a second message, which comprises the following steps:
Deleting at least part of unnecessary option fields in the variable part if the remaining length of the variable part of the header is less than the total length of the first TOA field and the first tag field, so that the remaining length of the variable part obtained after deleting the fields is greater than or equal to the total length, wherein the remaining length is the difference between the maximum limit length of the variable part and the current length of the variable part;
And inserting the first TOA field and the first tag field into the variable part obtained after the field is deleted to obtain a second message.
4. The method of claim 2, wherein the first message is an IPv6 message;
The first TOA field and the first tag field are inserted into the header of the first message obtained after address replacement to obtain a second message, which comprises the following steps:
And inserting the first TOA field and the first tag field into an extension header of a header of the first message obtained after address replacement to obtain a second message.
5. The method of claim 2, wherein writing the first TOA field and the first tag field to the first message obtained after address replacement to obtain a second message, further comprises:
And if the first message obtained after the address replacement contains the TOA field, covering the TOA field in the header by using the first TOA field, and inserting the first tag field into the header obtained after the field coverage to obtain the second message.
6. The method of claim 5, wherein the inserting the first tag field into the field-overlaid resultant header comprises:
If the first message is an IPv4 message and the remaining length of the header obtained after field coverage is less than the length of the first tag field, deleting at least part of the unnecessary option fields in the variable portion obtained after field coverage, so that the remaining length of the variable portion obtained after field deletion is greater than or equal to the length of the first tag field, where the remaining length is the difference between the maximum limit length of the variable portion and the current length of the variable portion; inserting the first tag field into the variable part obtained after deleting the field;
If the first message is an IPv6 message, the first tag field is inserted into an extension header of the header obtained after the field coverage.
7. The method according to any one of claims 1-6, wherein generating a first tag corresponding to a destination address in the first message using a generation scheme pre-agreed with a destination server, comprises:
performing hash mapping on the destination address in the first message by utilizing a hash mapping mode pre-agreed with the target server to obtain a first hash value;
the first tag is generated based on the first hash value.
8. The method according to any one of claims 1-6, wherein generating a first tag corresponding to a destination address in the first message using a generation scheme pre-agreed with a destination server, comprises:
Encrypting a destination address in the first message by using a salt value pre-agreed with the target server to obtain a first ciphertext;
Carrying out hash mapping on the first ciphertext by utilizing a hash mapping mode pre-agreed with the target server to obtain a second hash value;
The first tag is generated based on the second hash value.
9. An IP forgery prevention information transmission method, which is applied to a server, includes:
Responding to a target message sent by a client or load balancing equipment, if the target message contains a TOA field and a tag field of a TCP option address, generating a second tag corresponding to a destination address in the target message by using a generation mode which is agreed in advance with the load balancing equipment, wherein the message sent by the load balancing equipment contains the TOA field and the tag field at the same time, and the value of the tag field in the message sent by the load balancing equipment is a tag which is generated by the load balancing equipment by using the generation mode and corresponds to the destination address in the message;
determining whether a second TOA field in the target message is credible according to a matching result of the second tag and a second tag field in the target message;
if the second TOA field is trusted, the second TOA field is parsed to obtain a client source address.
10. The method of claim 9, wherein the determining whether the second TOA field in the target message is trusted based on a result of the matching of the second tag with the value of the second tag field in the target message comprises:
And if the second tag is consistent with the value of the second tag field, determining that the second TOA field is trusted.
11. The method according to claim 9, wherein the generating, by using a generation manner pre-agreed with the load balancing device, a second tag corresponding to a destination address in the target packet includes:
carrying out hash mapping on the destination address in the target message by utilizing a hash mapping mode pre-agreed with the load balancing equipment to obtain a third hash value;
and generating the second label based on the third hash value.
12. The method according to claim 9, wherein the generating, by using a generation manner pre-agreed with the load balancing device, a second tag corresponding to a destination address in the target packet includes:
Encrypting a destination address in the target message by using a salt value pre-agreed with the load balancing equipment to obtain a second ciphertext;
Carrying out hash mapping on the second ciphertext by utilizing a hash mapping mode pre-agreed with the load balancing equipment to obtain a fourth hash value;
And generating the second label based on the fourth hash value.
13. The method according to any one of claims 9-12, wherein the method further comprises:
If the target message contains a TOA field and does not contain a tag field, determining that the second TOA field is not trusted; and/or
If the target message does not contain the TOA field, determining the source address of the TCP connection for transmitting the target message as the source address of the client.
14. The method according to any one of claims 9-12, wherein the method further comprises:
If the header of the target message is detected to contain a preset identifier for identifying the tag field category, determining that the target message contains a tag field;
and determining a field in which the preset identifier is located as the second tag field.
15. An IP forgery prevention information transmission apparatus, which is applied to a load balancing device, comprising:
The first generation module is used for responding to a first message sent by a client, replacing a source address in the first message with an address of the load balancing equipment, generating a TCP option address TOA based on the source address in the first message, and generating a first label corresponding to a destination address in the first message by utilizing a generation mode pre-agreed with a destination server;
The writing module is used for writing the TOA and the first label into the first message obtained after address replacement to obtain a second message;
And the sending module is used for sending the second message to the target server so as to determine whether the TOA field in the second message is credible or not based on the first tag and the generation mode by the target server.
16. An IP forgery prevention information transmission apparatus, which is applied to a server, comprising:
A second generating module, configured to generate a second label corresponding to a destination address in a target packet according to a generation mode pre-agreed by a load balancing device if the target packet simultaneously includes a TCP option address TOA field and a label field in response to receiving the target packet sent by a client or the load balancing device, where the packet sent by the load balancing device simultaneously includes the TOA field and the label field, and a value of the label field in the packet sent by the load balancing device is a label corresponding to the destination address in the packet generated by the load balancing device according to the generation mode;
The first determining module is used for determining whether the second TOA field in the target message is credible according to a matching result of the second tag and the second tag field in the target message;
And the analysis module is used for analyzing the second TOA field if the second TOA field is trusted so as to acquire the source address of the client.
17. A computer-readable medium, on which a computer program is stored, characterized in that the program, when being executed by a processing device, realizes the steps of the IP forgery prevention information transmission method as claimed in any one of claims 1 to 14.
18. An electronic device, comprising:
A storage device having a computer program stored thereon;
Processing means for executing said computer program in said storage means to implement the steps of the IP forgery prevention information transmission method as claimed in any one of claims 1 to 14.
19. A computer program product comprising a computer program, characterized in that the computer program, when being executed by a processor, realizes the steps of the IP forgery prevention information transmission method as claimed in any one of claims 1 to 14.
CN202410814361.3A 2024-06-21 2024-06-21 Information transmission method, device, medium, electronic equipment and program product for preventing IP counterfeiting Pending CN118540153A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202410814361.3A CN118540153A (en) 2024-06-21 2024-06-21 Information transmission method, device, medium, electronic equipment and program product for preventing IP counterfeiting

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202410814361.3A CN118540153A (en) 2024-06-21 2024-06-21 Information transmission method, device, medium, electronic equipment and program product for preventing IP counterfeiting

Publications (1)

Publication Number Publication Date
CN118540153A true CN118540153A (en) 2024-08-23

Family

ID=92391338

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202410814361.3A Pending CN118540153A (en) 2024-06-21 2024-06-21 Information transmission method, device, medium, electronic equipment and program product for preventing IP counterfeiting

Country Status (1)

Country Link
CN (1) CN118540153A (en)

Similar Documents

Publication Publication Date Title
CN110049022B (en) Domain name access control method and device and computer readable storage medium
CN106412024B (en) A kind of page acquisition methods and device
US20170257383A1 (en) Deterministic reproduction of client/server computer state or output sent to one or more client computers
US9294463B2 (en) Apparatus, method and system for context-aware security control in cloud environment
CN112235266B (en) Data processing method, device, equipment and storage medium
US10341286B2 (en) Methods and systems for updating domain name service (DNS) resource records
US7613828B2 (en) Store-and-forward messaging channel for occasionally connected mobile applications
CN111930709B (en) Data storage method, apparatus, electronic device, and computer readable medium
CN111865996A (en) Data detection method and device and electronic equipment
CN112511565B (en) Request response method and device, computer readable storage medium and electronic equipment
US20200210584A1 (en) Deterministic Reproduction of Client/Server Computer State or Output Sent to One or More Client Computers
CN113765846A (en) Intelligent detection and response method and device for network abnormal behavior and electronic equipment
CN110545230B (en) Method and device for forwarding VXLAN message
CN115834584A (en) Cross-network data transmission method, device, equipment and medium
CN118540153A (en) Information transmission method, device, medium, electronic equipment and program product for preventing IP counterfeiting
CN113225348B (en) Request anti-replay verification method and device
CN115348082A (en) Data desensitization method and device, computer equipment and storage medium
CN111343295B (en) Method and device for determining risk of IPv6 address
Yu et al. A new approach Customizable distributed network service discovery system
CN108833418B (en) Method, device and system for defending attack
CN117560168B (en) SRv6 message generation and transmission method based on zero trust
CN116938598B (en) Information transmission method, apparatus, electronic device, and computer-readable medium
CN115549900B (en) Quantum security data transmitting and receiving method and communication system
CN115001701B (en) Method and device for authorization authentication, storage medium and electronic equipment
CN118410093B (en) Multi-protocol data integrated control method, device, system and storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination