IKE request message management method and device, and storage medium

Abstract

The invention provides an IKE request message management method and device and a storage medium, and relates to the field of communication. The method comprises the following steps: establishing a message queue based on an IKE security alliance; determining a to-be-sent request message based on the IKE request end, and judging whether the message queue is empty or not; if not, judging whether the to-be-sent request message meets a preset condition or not; if yes, adding the to-be-sent request message into a message queue; judging whether the to-be-sent request messages in the message queue have response messages sent by the IKE response end one by one; if not, judging whether the sending waiting duration of the to-be-sent request message is greater than the timeout duration or not; if yes, judging whether the sending frequency of the to-be-sent request message exceeds a preset threshold value or not; and if yes, deleting the IKE security alliance and the corresponding IPSec security alliance. According to the method provided by the invention, the technical effect of improving the transmission reliability of the IKE request message is realized.

Description

Technical Field

[0001] The present application relates to the field of communications, and in particular to a method, device and storage medium for managing IKE request messages. Background Art

[0002] Internet Protocol Security (IPsec) provides transparent security services for IP communications, protecting TCP / IP communications from tampering and eavesdropping, and preventing network attacks. IPsec provides access control, connectionless integrity, data authenticity, anti-replay services, and confidentiality. IPsec includes a series of protocols for IP data security including the Internet Key Exchange (IKE) and authentication and encryption algorithms. The two ends of IPsec using packet transmission can be called IPsec peers. The connection between the two peers can be called an IPsec tunnel or an IPsec connection. IPsec uses a Security Association (SA) to protect packets between two peers. SA is a collection of elements including security protocols, encapsulation modes, encryption algorithms, shared keys, and key lifetimes. SA can be established manually or through IKE negotiation. For example, a pair of IPsec peers of two network nodes or devices perform IKE negotiation to negotiate security protocols, exchange IPsec authentication and encryption keys, and manage negotiation keys. The second version of IKE, IKEv2, defines four exchanges: IKE_SA_INIT exchange, IKE_AUTH exchange, CREATE_CHILD_SA exchange, and INFORMATIONAL exchange.

[0003] In this application, the IKE requester and the IKE responder are a pair of IPsec peers. After mutual authentication, an IKE security alliance is established, and a corresponding IPSec security alliance is established. When the request message sent by the IKE requester does not receive the corresponding response message from the IKE responder within the timeout period, the request message may be lost due to network failure and cannot be retransmitted, resulting in an abnormal IPSec virtual private network (VPN) connection or a discontinuous Message ID of the receiving party. Therefore, the IKE security alliance needs to be managed.

[0004] In the prior art, the retransmission of the IKE request message is implemented through the retransmission function of the IKE message, but some implementations such as the IKE plug-in of VPP only support the retransmission of the IKE_SA_INIT exchange, and do not support the retransmission of other exchanges.

[0005] Since the management method of IKE request messages in the prior art does not support IKE_AUTH exchange, CREATE_CHILD_SA exchange and INFORMATIONAL exchange, the loss rate of request messages is high, and the probability of IPSec VPN connection abnormality or discontinuity of the receiving party's received message sequence number Message ID is high. The existing management method of IKE request messages has technical problems such as low IKE request message transmission reliability and VPN tunnel stability. Summary of the invention

[0006] The present application provides an IKE request message management method, device and storage medium to solve the technical problems of low IKE request message transmission reliability and VPN tunnel stability.

[0007] On the one hand, the present application provides a method for managing an IKE request message, the method comprising:

[0008] A message queue is established based on the IKE security association; wherein the message queue is used to store request messages to be sent based on time sequence;

[0009] Based on the IKE request end, determine the request message to be sent, and determine whether the message queue is empty; if not, determine whether the request message to be sent meets the preset conditions; if so, add the request message to be sent to the message queue;

[0010] Determine one by one whether the request messages to be sent in the message queue have response messages sent by the IKE responder; if not, determine whether the waiting time for the request message to be sent is greater than the timeout time; if so, determine whether the number of times the request message to be sent is sent exceeds a preset threshold; if so, delete the IKE security association and the corresponding IPSec security association.

[0011] Optionally, determining whether the request message to be sent meets a preset condition includes:

[0012] Determine whether the message type of the request message to be sent is a dead peer detection DPD message; if so, discard the request message to be sent;

[0013] If not, it is determined whether there is a request message of the message type to be sent in the message queue; if not, it is determined that the request message to be sent meets the preset condition.

[0014] Optionally, when the message type of the request message to be sent is a Dead Peer Detection DPD message, and / or there is a request message to be sent of the same message type in the message queue, the request message to be sent is discarded.

[0015] Optionally, when the number of IKE security associations is greater than 1, determining one by one whether the request messages to be sent in the message queue have response messages sent by the IKE responder includes:

[0016] Establish a management thread based on the IKE security alliance, and traverse the message queues corresponding to multiple IKE security alliances based on the management thread;

[0017] Based on the time sequence of the request messages to be sent in the message queue, it is determined one by one whether the request messages to be sent have response messages sent by the IKE responder.

[0018] Optionally, before establishing a message queue based on the IKE security association, the following steps are included:

[0019] The IKE requester and IKE responder authenticate each other, establish an IKE security association, and establish a corresponding IPSec security association.

[0020] Optionally, when the number of times the request message to be sent is sent does not exceed a preset threshold, the request message to be sent is sent to the IKE responder based on the IKE requester.

[0021] Optionally, when the message queue is empty, the request message to be sent is added to the message queue.

[0022] In a second aspect, the present application provides a management device for an IKE request message, including:

[0023] Establishing a module, used to establish a message queue based on the IKE security alliance; wherein the message queue is used to store request messages to be sent based on time sequence;

[0024] The first processing module is used to determine the request message to be sent based on the IKE request end, and determine whether the message queue is empty; if not, determine whether the request message to be sent meets a preset condition; if so, add the request message to be sent to the message queue;

[0025] The second processing module is used to determine one by one whether the request messages to be sent in the message queue have response messages sent by the IKE responder; if not, determine whether the waiting time for the request message to be sent is greater than the timeout time; if so, determine whether the number of times the request message to be sent is sent exceeds a preset threshold; if so, delete the IKE security association and the corresponding IPSec security association.

[0026] Optionally, the first processing module is further used for:

[0027] Determine whether the message type of the request message to be sent is a dead peer detection DPD message; if so, discard the request message to be sent;

[0028] If not, it is determined whether there is a request message of the message type to be sent in the message queue; if not, it is determined that the request message to be sent meets the preset condition.

[0029] Optionally, the device is also used to:

[0030] When the message type of the request message to be sent is a Dead Peer Detection DPD message, and / or there is a request message to be sent of the same message type in the message queue, the request message to be sent is discarded.

[0031] Optionally, the device is also used to:

[0032] When the number of IKE security alliances is greater than 1, a management thread is established based on the IKE security alliance, and message queues corresponding to multiple IKE security alliances are traversed based on the management thread;

[0033] Based on the time sequence of the request messages to be sent in the message queue, it is determined one by one whether the request messages to be sent have response messages sent by the IKE responder.

[0034] Optionally, the device is also used to:

[0035] The IKE requester and IKE responder authenticate each other, establish an IKE security association, and establish a corresponding IPSec security association.

[0036] Optionally, the device is also used to:

[0037] When the number of times the request message to be sent is sent does not exceed a preset threshold, the request message to be sent is sent to the IKE responder based on the IKE requester.

[0038] Optionally, the device is also used to:

[0039] When the message queue is empty, the request message to be sent is added to the message queue.

[0040] A third aspect of the present application provides an IKE request message management device, including:

[0041] Processor and memory;

[0042] Memory stores computer-executable instructions;

[0043] The processor executes the computer-executable instructions stored in the memory, so that the IKE request message management device executes the IKE request message management method of any one of the first aspects.

[0044] In a fourth aspect, the present application provides a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement the IKE request message management method as described in any one of the first aspects.

[0045] The IKE request message management method, device and storage medium provided by the present application establish a message queue based on the IKE security alliance; wherein the message queue is used to store the request messages to be sent based on the time sequence; the request message to be sent is determined based on the IKE request end, and whether the message queue is empty; if not, whether the request message to be sent meets the preset conditions; if so, the request message to be sent is added to the message queue; whether the request messages to be sent in the message queue have response messages sent by the IKE responder one by one; if not, whether the waiting time for sending the request message to be sent is greater than the timeout time; if so, whether the number of times the request message to be sent is sent exceeds the preset threshold; if If yes, the IKE security association and the corresponding IPSec security association are deleted, thereby realizing that by adding the qualified request messages to be sent to the message queue, the request messages that have timed out and whose number of transmissions does not exceed the preset threshold are retransmitted based on the message queue. The message queue not only supports the retransmission of IKE_SA_INIT exchange, but also supports the retransmission of IKE_AUTH exchange, CREATE_CHILD_SA exchange and INFORMATIONAL exchange, and the request messages in the message queue are not affected by network obstacles, thereby reducing the loss probability of IKE request messages and achieving the technical effect of improving the transmission reliability of IKE request messages and the stability of VPN tunnels. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0047] Figure 1 IKE request message management method process provided in the embodiment of the present application Figure 1 ;

[0048] Figure 2 IKE request message management method process provided in the embodiment of the present application Figure 2 ;

[0049] Figure 3 IKE request message management method process provided in the embodiment of the present application Figure 3 ;

[0050] Figure 4 A schematic diagram of the structure of a management device for IKE request messages provided in an embodiment of the present application;

[0051] Figure 5 A hardware structure diagram of a management device for IKE request messages provided in an embodiment of the present application.

[0052] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0053] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0054] First, the terms involved in this application are explained:

[0055] Security Association (SA) is an agreement between communicating peers on certain elements, such as which protocol to use (AH, ESP, or a combination of the two), the protocol encapsulation mode (transport mode and tunnel mode), the encryption algorithm (DES, 3DES, and AES), the shared key for protecting data in a specific process, and the life cycle of the key.

[0056] The Internet Key Exchange Protocol (IKE) is a hybrid protocol that consists of the Internet Security Association and Key Management Protocol (ISAKMP) and two key exchange protocols, OAKLEY and SKEME. IKE defines two key exchange modes: main mode and aggressive mode. The first phase of IKE: main mode and aggressive mode, generate IKE SA, the second phase: quick mode, generate IPSec SA.

[0057] Internet Protocol Security (IP Security, IPSec) is a three-layer tunnel encryption protocol developed by the Internet Engineering Task Force (The Internet Engineering Task Force, IETF). It provides high-quality, interoperable, cryptography-based security guarantees for data transmitted on the Internet.

[0058] In the existing IKE request message management method, the retransmission of the request message is achieved through the retransmission function of the IKE message, but some implementations such as the IKE plug-in of VPP only support the retransmission of IKE_SA_INIT exchange, and do not support IKE_AUTH exchange, CREATE_CHILD_SA exchange and INFORMATIONAL exchange. Therefore, the loss rate of the request message is high, and the probability of the IPSec VPN connection being abnormal or the receiving party's receiving message sequence number Message ID being discontinuous is high. The existing IKE request message management method has technical problems such as low IKE request message transmission reliability and VPN tunnel stability.

[0059] The IKE request message management method, device and storage medium provided by the present application establish a message queue based on the IKE security alliance; wherein the message queue is used to store the request messages to be sent based on the time sequence; the request message to be sent is determined based on the IKE request end, and whether the message queue is empty; if not, whether the request message to be sent meets the preset conditions; if so, the request message to be sent is added to the message queue; whether the request messages to be sent in the message queue have response messages sent by the IKE responder one by one; if not, whether the waiting time for sending the request message to be sent is greater than the timeout time; if so, whether the number of times the request message to be sent is sent exceeds the preset threshold; if If yes, the IKE security association and the corresponding IPSec security association are deleted, thereby realizing that by adding the qualified request messages to be sent to the message queue, the request messages that have timed out and whose number of transmissions does not exceed the preset threshold are retransmitted based on the message queue. The message queue not only supports the retransmission of IKE_SA_INIT exchange, but also supports the retransmission of IKE_AUTH exchange, CREATE_CHILD_SA exchange and INFORMATIONAL exchange, and the request messages in the message queue are not affected by network obstacles, thereby reducing the loss probability of IKE request messages and achieving the technical effect of improving the transmission reliability of IKE request messages and the stability of VPN tunnels.

[0060] The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0061] Figure 1 IKE request message management method process provided in the embodiment of the present application Figure 1 .like Figure 1 As shown, the management method of the IKE request message provided in this embodiment includes:

[0062] S101, establishing a message queue based on the IKE security alliance; wherein the message queue is used to store request messages to be sent based on time sequence;

[0063] In this embodiment, IKEv2 communication consists of a pair of messages: a request message and a response message. A pair of messages is called an exchange. The second version of IKE defines four exchanges: IKE_SA_INIT exchange, IKE_AUTH exchange, CREATE_CHILD_SA exchange, and INFORMATIONAL exchange. Generally, establishing an IKE SA and the first childSA requires one IKE_SA_INIT exchange and one IKE_AUTH exchange, that is, the communication process includes two request messages and two corresponding response messages. After that, any number of CREATE_CHILD_SA and INFORMATIONAL exchanges can occur in any order.

[0064] S102, based on the IKE request end, determining the request message to be sent, determining whether the message queue is empty; if not, determining whether the request message to be sent meets a preset condition; if so, adding the request message to be sent to the message queue;

[0065] S103, determine one by one whether the request messages to be sent in the message queue have response messages sent by the IKE responder; if not, determine whether the waiting time for sending the request message to be sent is greater than the timeout time; if so, determine whether the number of times the request message to be sent is sent exceeds a preset threshold; if so, delete the IKE security association and the corresponding IPSec security association.

[0066] In this embodiment, the Message ID in the IKEv2 protocol header is used to identify a "request-response" pair. Each time the responder sends a request message, the value of the Message ID increases by one. The sender of the request message is responsible for ensuring the reliability of IKE message transmission. If no response is received within the timeout period, the requester needs to resend the request or abandon the connection. When the number of times the request message is sent exceeds the preset threshold, it is considered that the other end of the VPN tunnel, that is, the IKE responder, is offline and needs to abandon the connection, that is, delete the IKE SA and the IPSec SA created by the IKE SA.

[0067] The IKE request message management method provided by the present application establishes a message queue based on the IKE security alliance; wherein the message queue is used to store the request messages to be sent based on the time sequence; based on the IKE request end determining the request messages to be sent, it is judged whether the message queue is empty; if not, it is judged whether the request messages to be sent meet the preset conditions; if so, the request messages to be sent are added to the message queue; it is judged one by one whether the request messages to be sent in the message queue have response messages sent by the IKE responder; if not, it is judged whether the waiting time for the request messages to be sent is greater than the timeout time; if so, it is judged whether the number of times the request messages to be sent are sent exceeds the preset threshold; if so, the request messages to be sent are deleted. In addition to the IKE security association and the corresponding IPSec security association, it is achieved by adding qualified request messages to be sent to the message queue, and retransmitting the request messages that have timed out and whose number of transmissions does not exceed the preset threshold based on the message queue. The message queue not only supports the retransmission of IKE_SA_INIT exchanges, but also supports the retransmission of IKE_AUTH exchanges, CREATE_CHILD_SA exchanges and INFORMATIONAL exchanges, and the request messages in the message queue are not affected by network obstacles, thereby reducing the loss probability of IKE request messages and achieving the technical effect of improving the transmission reliability of IKE request messages and the stability of VPN tunnels.

[0068] Figure 2 IKE request message management method process provided in the embodiment of the present application Figure 2 .like Figure 2 As shown, the management method of the IKE request message provided in the embodiment of the present application, when the number of IKE SAs is 1, includes:

[0069] S201, the IKE requester and the IKE responder mutually authenticate each other, establish an IKE security alliance, and establish a corresponding IPSec security alliance;

[0070] S202, establishing a message queue based on the IKE security alliance; wherein the message queue is used to store request messages to be sent based on time sequence;

[0071] S203, based on the IKE request end, determining the request message to be sent, judging whether the message queue is empty; if so, adding the request message to be sent to the message queue; if not, judging whether the message type of the request message to be sent is a dead peer detection DPD message;

[0072] S204, if yes, discard the request message to be sent; if no, determine whether there is a request message to be sent of the message type in the message queue;

[0073] S205. If yes, discard the request message to be sent; if no, determine that the request message to be sent meets the preset condition, and add the request message to be sent to the message queue;

[0074] S206, determining one by one whether the request messages to be sent in the message queue have response messages sent by the IKE responder;

[0075] S207, if yes, then delete the request message to be sent from the message queue; if no, then determine whether the waiting time for the request message to be sent is greater than the timeout time;

[0076] S208. If not, continue to wait; if yes, determine whether the number of times the request message to be sent exceeds a preset threshold;

[0077] S209: If yes, delete the IKE security association and the corresponding IPSec security association; if no, send a request message to be sent to the IKE responder based on the IKE requester.

[0078] Figure 3 IKE request message management method process provided in the embodiment of the present application Figure 3 .like Figure 3 As shown, the management method of the IKE request message provided in the embodiment of the present application, when the number of IKE SAs is greater than 1, includes:

[0079] S301, the IKE requester and the IKE responder mutually authenticate each other, establish an IKE security alliance, and establish a corresponding IPSec security alliance;

[0080] S302, establishing a message queue based on the IKE security alliance; wherein the message queue is used to store request messages to be sent based on time sequence;

[0081] S303, based on the IKE request end, determining the request message to be sent, judging whether the message queue is empty; if so, adding the request message to be sent to the message queue; if not, judging whether the message type of the request message to be sent is a DPD message;

[0082] S304, if yes, discard the request message to be sent; if no, determine whether there is a request message to be sent of the message type in the message queue;

[0083] S305, if yes, discard the request message to be sent; if no, determine that the request message to be sent meets the preset conditions, and add the request message to be sent to the message queue;

[0084] S306, establishing a management thread based on the IKE security alliance, and traversing message queues corresponding to multiple IKE security alliances based on the management thread;

[0085] S307, based on the time sequence of the request messages to be sent in the message queue, determine one by one whether the request messages to be sent have response messages sent by the IKE responder;

[0086] S308. If yes, the request message to be sent is deleted from the message queue; if no, it is determined whether the waiting time for the request message to be sent is greater than the timeout time;

[0087] S309, if not, continue to wait; if yes, determine whether the number of times the request message to be sent exceeds a preset threshold;

[0088] S310: If yes, the IKE security association and the corresponding IPSec security association are deleted; if no, a request message to be sent is sent to the IKE responder based on the IKE requester.

[0089] The IKE request message management method provided by the present application establishes a message queue based on the IKE security alliance; wherein the message queue is used to store the request message to be sent based on the time sequence; the request message to be sent is determined based on the IKE request end, and it is judged whether the message queue is empty; if not, it is judged whether the request message to be sent meets the preset conditions; if so, the request message to be sent is added to the message queue; it is judged one by one whether the request message to be sent in the message queue has a response message issued by the IKE responder; if not, it is judged whether the waiting time for the request message to be sent is greater than the timeout time; if so, it is judged whether the number of times the request message to be sent exceeds the preset threshold; if so, the IKE security alliance and the corresponding IPSec security alliance are deleted, thereby realizing that by adding the request message to be sent that meets the conditions to the message queue, the request message that has timed out and the number of times it has been sent does not exceed the preset threshold is resent based on the message queue. When the number of times the request message is sent exceeds the preset threshold, it is considered that the other end of the VPN tunnel, that is, the IKE responder, is offline and needs to abandon the connection, that is, delete the IKE SA and the IPSec security alliance created by the IKE SA. SA, thereby ensuring the reliability of IKE communication and the stability of VPN tunnels; the message queue not only supports the retransmission of IKE_SA_INIT exchanges, but also supports the retransmission of IKE_AUTH exchanges, CREATE_CHILD_SA exchanges and INFORMATIONAL exchanges, and the request messages in the message queue are not affected by network obstacles, thereby reducing the probability of loss of IKE request messages, and achieving the technical effect of improving the reliability of IKE request message transmission and the stability of VPN tunnels.

[0090] Figure 4 The structure diagram of a management device for an IKE request message provided in an embodiment of the present application. The device of this embodiment can be in the form of software and / or hardware. Figure 4As shown, an IKE request message management device 400 provided in an embodiment of the present application includes: an establishment module 401, a first processing module 402, and a second processing module 403.

[0091] Establishing module 401, used to establish a message queue based on the IKE security alliance; wherein the message queue is used to store request messages to be sent based on time sequence;

[0092] The first processing module 402 is used to determine the request message to be sent based on the IKE request end, and determine whether the message queue is empty; if not, determine whether the request message to be sent meets a preset condition; if so, add the request message to be sent to the message queue;

[0093] The second processing module 403 is used to determine one by one whether the request message to be sent in the message queue has a response message sent by the IKE responder; if not, determine whether the waiting time for the request message to be sent is greater than the timeout time; if so, determine whether the number of times the request message to be sent is sent exceeds a preset threshold; if so, delete the IKE security association and the corresponding IPSec security association.

[0094] In a possible implementation, the first processing module 402 is further configured to:

[0095] Determine whether the message type of the request message to be sent is a dead peer detection DPD message; if so, discard the request message to be sent;

[0096] If not, it is determined whether there is a request message of the message type to be sent in the message queue; if not, it is determined that the request message to be sent meets the preset condition.

[0097] In a possible implementation, the device is further used for:

[0098] When the message type of the request message to be sent is a Dead Peer Detection DPD message, and / or there is a request message to be sent of the same message type in the message queue, the request message to be sent is discarded.

[0099] In a possible implementation, the device is further used for:

[0100] When the number of IKE security alliances is greater than 1, a management thread is established based on the IKE security alliance, and message queues corresponding to multiple IKE security alliances are traversed based on the management thread;

[0101] Based on the time sequence of the request messages to be sent in the message queue, it is determined one by one whether the request messages to be sent have response messages sent by the IKE responder.

[0102] In a possible implementation, the device is further used for:

[0103] The IKE requester and IKE responder authenticate each other, establish an IKE security association, and establish a corresponding IPSec security association.

[0104] In a possible implementation, the device is further used for:

[0105] When the number of times the request message to be sent is sent does not exceed a preset threshold, the request message to be sent is sent to the IKE responder based on the IKE requester.

[0106] In a possible implementation, the device is further used for:

[0107] When the message queue is empty, the request message to be sent is added to the message queue.

[0108] The IKE request message management device provided by the present application establishes a message queue based on the IKE security alliance; wherein the message queue is used to store the request message to be sent based on the time sequence; the request message to be sent is determined based on the IKE request end, and it is judged whether the message queue is empty; if not, it is judged whether the request message to be sent meets the preset conditions; if so, the request message to be sent is added to the message queue; it is judged one by one whether the request message to be sent in the message queue has a response message issued by the IKE responder; if not, it is judged whether the waiting time for the request message to be sent is greater than the timeout time; if so, it is judged whether the number of times the request message to be sent exceeds the preset threshold; if so, the IKE security alliance and the corresponding IPSec security alliance are deleted, thereby realizing that by adding the request message to be sent that meets the conditions to the message queue, the request message that has timed out and the number of times it has been sent does not exceed the preset threshold is resent based on the message queue. When the number of times the request message is sent exceeds the preset threshold, it is considered that the other end of the VPN tunnel, that is, the IKE responder, is offline and needs to abandon the connection, that is, delete the IKE SA and the IPSec security alliance created by the IKE SA. SA, thereby ensuring the reliability of IKE communication and the stability of VPN tunnels; the message queue not only supports the retransmission of IKE_SA_INIT exchanges, but also supports the retransmission of IKE_AUTH exchanges, CREATE_CHILD_SA exchanges and INFORMATIONAL exchanges, and the request messages in the message queue are not affected by network obstacles, thereby reducing the probability of loss of IKE request messages, and achieving the technical effect of improving the reliability of IKE request message transmission and the stability of VPN tunnels.

[0109] Figure 5 The hardware structure diagram of the management device of the IKE request message provided in the embodiment of the present application. Figure 5 As shown, the management device 500 of the IKE request message includes:

[0110] Processor 501 and memory 502;

[0111] Memory stores computer-executable instructions;

[0112] The processor executes the computer-executable instructions stored in the memory 502, so that the IKE request message management device executes the IKE request message management method as described above.

[0113] It should be understood that the processor 501 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), or application-specific integrated circuits (ASIC). A general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in the invention may be directly implemented as being executed by a hardware processor, or may be implemented by a combination of hardware and software modules in the processor. The memory 502 may include a high-speed random access memory (RAM), or may also include a non-volatile memory (NVM), such as at least one disk memory, or may be a USB flash drive, a mobile hard disk, a read-only memory, a disk, or an optical disk.

[0114] The embodiment of the present application also provides a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement a method for managing IKE request messages.

[0115] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the invention disclosed herein. The present application is intended to cover any variations, uses or adaptations of the present application, which follow the general principles of the present application and include common knowledge or customary techniques in the art that are not disclosed in the present application. The specification and examples are intended to be exemplary only, and the true scope and spirit of the present application are indicated by the following claims.

[0116] It should be understood that the present application is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A method for managing IKE request messages, characterized in that: include: Establishing a message queue based on the IKE security alliance; wherein the message queue is used to store request messages to be sent based on time sequence; Determine the request message to be sent based on the IKE request end, and judge whether the message queue is empty; if not, judge whether the request message to be sent meets a preset condition; if so, add the request message to be sent to the message queue; Determine one by one whether the request messages to be sent in the message queue have response messages sent by the IKE responder; if not, determine whether the waiting time for sending the request messages to be sent is greater than the timeout time; if so, determine whether the number of times the request messages to be sent are sent exceeds a preset threshold; if so, delete the IKE security association and the corresponding IPSec security association.

2. The management method according to claim 1, characterized in that: The determining whether the request message to be sent meets a preset condition includes: Determine whether the message type of the request message to be sent is a dead peer detection DPD message; if so, discard the request message to be sent; If not, it is determined whether there is a request message of the message type to be sent in the message queue; if not, it is determined that the request message to be sent meets the preset condition.

3. The management method according to claim 2, characterized in that: The method further comprises: When the message type of the request message to be sent is the Dead Peer Detection DPD message, and / or there is a request message to be sent of the message type in the message queue, the request message to be sent is discarded.

4. The management method according to claim 1, characterized in that: When the number of the IKE security associations is greater than 1, determining one by one whether the request messages to be sent in the message queue have response messages sent by the IKE responder, includes: Establishing a management thread based on the IKE security association, and traversing the message queues corresponding to the multiple IKE security associations based on the management thread; Based on the time sequence of the request messages to be sent in the message queue, it is determined one by one whether the request messages to be sent have the response messages sent by the IKE responder.

5. The management method according to claim 1, characterized in that: Before establishing a message queue based on the IKE security association, the method includes: The IKE requester and the IKE responder authenticate each other, establish the IKE security association, and establish the corresponding IPSec security association.

6. The management method according to claim 1, characterized in that: The method further comprises: When the number of times the request message to be sent is sent does not exceed the preset threshold, the request message to be sent is sent to the IKE responder based on the IKE requester.

7. The management method according to claim 1, characterized in that: The method further comprises: When the message queue is empty, the request message to be sent is added to the message queue.

8. A management device for IKE request messages, characterized in that: include: An establishment module, used to establish a message queue based on the IKE security alliance; wherein the message queue is used to store request messages to be sent based on time sequence; A first processing module, configured to determine the request message to be sent based on the IKE request end, and determine whether the message queue is empty; if not, determine whether the request message to be sent meets a preset condition; if so, add the request message to be sent to the message queue; The second processing module is used to determine one by one whether the request message to be sent in the message queue has a response message sent by the IKE responder; if not, determine whether the waiting time for sending the request message to be sent is greater than the timeout time; if so, determine whether the number of times the request message to be sent is sent exceeds a preset threshold; if so, delete the IKE security association and the corresponding IPSec security association.

9. A management device for IKE request messages, comprising: Processor and memory; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory, so that the IKE request message management device performs the IKE request message management method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by a processor, they are used to implement the IKE request message management method according to any one of claims 1 to 7.

Images