Negotiation method and device of IKEv2 protocol

Abstract

The invention relates to a negotiation method and device of an IKEv2 protocol. The method comprises the following steps: an initiator obtains an IP address of a responder; performing query matching in a pre-stored DH algorithm mapping table according to the IP address; when the table item is matched, extracting DH algorithm group information from the matched table item; generating a KE load according to the DH algorithm group information; an IKESAINIT message is constructed on the basis of the KE load; and sending the IKESAINIT message to a responder so as to carry out negotiation of an IKEv2 protocol. According to the negotiation method and device of the IKEv2 protocol, the number of times of re-negotiation caused by mismatching of the DH algorithm in the IKEv2x protocol can be reduced, so that the negotiation delay is reduced, and the negotiation efficiency is improved.

Description

Technical Field

[0001] The present application relates to the field of computer information processing, and in particular to a negotiation method and apparatus for the IKEv2 protocol. Background Art

[0002] The first phase of IKEv2 negotiation is IKE_SA_INIT, where the message exchange process is as follows:

[0003] Initiator-->HDR,SAi,KEi,Ni-->Responder

[0004] Initiator<--HDR,SAr,KEr,Nr<--Responder

[0005] in:

[0006] HDR: message header;

[0007] Ni / Nr: Random numbers generated by the initiator and responder;

[0008] SAi: security algorithm proposal put forward by the initiator, including encryption algorithm, hash algorithm, integrity algorithm and DH (Diffie-Hellman) algorithm;

[0009] SAr: The matching algorithm proposal selected by the responder from SAi;

[0010] KEi / KEr: Key exchange payload of both parties, containing relevant data for DH key negotiation, based on which both parties generate the same shared key.

[0011] In SAi, the initiator must provide at least one candidate for each algorithm type, and each algorithm type can also contain multiple options. For example, DH algorithms can include multiple groups such as DH1, DH2, and DH5. After receiving SAi, the responder compares it with the locally supported algorithms. If each algorithm type can match at least one option, it assembles it into SAr and replies to the initiator. It should be noted that although SAi can contain multiple DH algorithm candidates, the initiator's KE payload can only generate key material based on one of the DH algorithms. If the DH algorithm selected by the responder is inconsistent with the one used in the KE payload, the negotiation will fail.

[0012] To resolve this inconsistency, the IKEv2 protocol stipulates that when the responder cannot accept the DH algorithm used by the initiator, it will return a notification message of type INVALID_KE_PAYLOAD, indicating the DH algorithm group it supports. Upon receiving this notification, the initiator must re-initiate negotiation, using a DH algorithm supported by the responder in the KE payload, for the negotiation to successfully complete. However, this compensation mechanism in existing solutions requires an additional pair of exchange messages, increasing IKEv2 negotiation latency and impacting overall performance.

[0013] Therefore, a new negotiation method and device for the IKEv2 protocol is needed.

[0014] The above information disclosed in this Background section is only for enhancement of understanding of the background of the application and therefore it may contain information that does not form the prior art that is already known to a person of ordinary skill in the art. Summary of the Invention

[0015] In view of this, the present application provides a negotiation method and apparatus for the IKEv2 protocol, which can reduce the number of renegotiations caused by DH algorithm mismatch in the IKEv2x protocol, thereby reducing negotiation delay and improving negotiation efficiency.

[0016] Other features and advantages of the present application will become apparent from the following detailed description, or may be learned in part by practice of the present application.

[0017] According to one aspect of the present application, a negotiation method for the IKEv2 protocol is proposed, the method comprising: an initiator obtaining an IP address of a responder; performing a query and match in a pre-stored DH algorithm mapping table based on the IP address; when a table entry is matched, extracting DH algorithm group information from the matched table entry; generating a KE payload based on the DH algorithm group information; constructing an IKE_SA_INIT message based on the KE payload; and sending the IKE_SA_INIT message to the responder to negotiate the IKEv2 protocol.

[0018] In an exemplary embodiment of the present application, it also includes: when no table entry is matched in the DH algorithm mapping table, the initiator determines temporary DH algorithm group information; generates a KE payload based on the temporary DH algorithm group information; constructs an IKE_SA_INIT message based on the KE payload; and sends the IKE_SA_INIT message to the responder to negotiate the IKEv2 protocol.

[0019] In an exemplary embodiment of the present application, the initiator determines the temporary DH algorithm group information, including: the initiator selects any one of a plurality of DH algorithm group information as the temporary DH algorithm group information.

[0020] In an exemplary embodiment of the present application, after sending the IKE_SA_INIT message to the responder to negotiate the IKEv2 protocol, the process further includes: the initiator obtains a response message returned by the responder; determines the DH algorithm group information supported by the responder based on the response message; establishes a mapping relationship between the DH algorithm group information and the IP address of the responder, and stores the mapping in the DH algorithm mapping table.

[0021] In an exemplary embodiment of the present application, determining the DH algorithm group information supported by the responder based on the response message includes: when the type of the response message is an INVALID_KE_PAYLOAD message, extracting the DH algorithm group information supported by the responder from the message.

[0022] In an exemplary embodiment of the present application, determining the DH algorithm group information supported by the responder based on the response message includes: when the type of the response message is not an INVALID_KE_PAYLOAD message, determining the temporary DH algorithm group information as the DH algorithm group information supported by the responder.

[0023] In an exemplary embodiment of the present application, a mapping relationship is established between the DH algorithm group information and the IP address of the responder and stored in the DH algorithm mapping table, including: using the IP address as the key; using the DH algorithm group information as the value; and storing the DH algorithm group information and the IP address of the responder in the DH algorithm mapping table in the form of key / value.

[0024] According to one aspect of the present application, a negotiation device for the IKEv2 protocol is proposed, which includes: an address module, used by an initiator to obtain the IP address of a responder; a matching module, used to query and match a pre-stored DH algorithm mapping table based on the IP address; an extraction module, used to extract DH algorithm group information from the matched table entry when a table entry is matched; a payload module, used to generate a KE payload based on the DH algorithm group information; a message module, used to construct an IKE_SA_INIT message based on the KE payload; and a negotiation module, used to send the IKE_SA_INIT message to the responder to negotiate the IKEv2 protocol.

[0025] In an exemplary embodiment of the present application, it also includes: a construction module, which is used for the initiator to determine temporary DH algorithm group information when no table entry is matched in the DH algorithm mapping table; generate a KE payload based on the temporary DH algorithm group information; construct an IKE_SA_INIT message based on the KE payload; and send the IKE_SA_INIT message to the responder to negotiate the IKEv2 protocol.

[0026] In an exemplary embodiment of the present application, it also includes: an update module, which is used by the initiator to obtain the response message returned by the responder; determine the DH algorithm group information supported by the responder based on the response message; establish a mapping relationship between the DH algorithm group information and the IP address of the responder, and store it in the DH algorithm mapping table.

[0027] According to one aspect of the present application, an electronic device is proposed, which includes: one or more processors; a storage device for storing one or more programs; when the one or more programs are executed by the one or more processors, the one or more processors implement the method as described above.

[0028] According to one aspect of the present application, a computer-readable medium is provided, on which a computer program is stored. When the program is executed by a processor, the method described above is implemented.

[0029] According to the IKEv2 protocol negotiation method and device of the present application, the initiator obtains the IP address of the responder; a query and match is performed in a pre-stored DH algorithm mapping table based on the IP address; when a table entry is matched, DH algorithm group information is extracted from the matched table entry; a KE payload is generated according to the DH algorithm group information; an IKE_SA_INIT message is constructed based on the KE payload; and the IKE_SA_INIT message is sent to the responder to negotiate the IKEv2 protocol. This method can reduce the number of renegotiations caused by DH algorithm mismatch in the IKEv2x protocol, thereby reducing negotiation delays and improving negotiation efficiency.

[0030] It should be understood that the foregoing general description and the following detailed description are merely illustrative and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] The above and other objects, features, and advantages of the present application will become more apparent by describing in detail exemplary embodiments thereof with reference to the accompanying drawings. The drawings described below are merely some embodiments of the present application, and it is apparent to those skilled in the art that other drawings can be derived from these drawings without inventive effort.

[0032] Figure 1 The figure is a flowchart of a negotiation method of the IKEv2 protocol according to an exemplary embodiment.

[0033] Figure 2 The figure is a schematic diagram showing a negotiation method of the IKEv2 protocol according to an exemplary embodiment.

[0034] Figure 3 The figure is a flowchart showing a negotiation method of the IKEv2 protocol according to another exemplary embodiment.

[0035] Figure 4 The figure is a flowchart showing a negotiation method of the IKEv2 protocol according to another exemplary embodiment.

[0036] Figure 5 The figure is a block diagram showing a negotiation device of the IKEv2 protocol according to an exemplary embodiment.

[0037] Figure 6 It is a block diagram of an electronic device according to an exemplary embodiment.

[0038] Figure 7 It is a block diagram of a computer-readable medium according to an exemplary embodiment. DETAILED DESCRIPTION

[0039] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be embodied in many forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete and will fully convey the concepts of the example embodiments to those skilled in the art. Like reference numerals in the drawings represent like or similar parts, and thus repetitive description thereof will be omitted.

[0040] In addition, described feature, structure or characteristic can be combined in one or more embodiments in any suitable manner.In the following description, many specific details are provided so as to provide a full understanding of the embodiments of the present application. However, it will be appreciated by those skilled in the art that the technical scheme of the present application can be put into practice without one or more of the specific details, or other methods, components, devices, steps etc. can be adopted. In other cases, known methods, devices, implementations or operations are not shown or described in detail to avoid blurring the various aspects of the application.

[0041] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically separate entities. That is, these functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0042] The flowcharts shown in the accompanying drawings are for illustrative purposes only and do not necessarily include all contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps may be decomposed, while others may be combined or partially combined. Therefore, the actual execution order may vary depending on the actual situation.

[0043] It should be understood that although the terms first, second, third, etc. may be used herein to describe various components, these components should not be limited by these terms. These terms are used to distinguish one component from another. Thus, the first component discussed below could be referred to as the second component without departing from the teachings of the present invention. As used herein, the term "and / or" includes any one and all combinations of one or more of the associated listed items.

[0044] Those skilled in the art will understand that the drawings are merely schematic diagrams of example embodiments, and the modules or processes in the drawings are not necessarily necessary for implementing the present application, and therefore cannot be used to limit the scope of protection of the present application.

[0045] The technical abbreviations involved in this application are explained as follows:

[0046] VPN: (Virtual Private Network) is a remote access technology. Simply put, it uses the public network to build a private network.

[0047] IPSec (Internet Protocol Security) is an open standard framework that uses encrypted security services to ensure confidential and secure communications on IP networks. IPSec is not a single protocol; it provides a complete architecture for network data security at the IP layer, including the Authentication Header (AH), Encapsulating Security Payload (ESP), Internet Key Exchange (IKE), and algorithms for network authentication and encryption. IPSec specifies how to select security protocols, determine security algorithms, and exchange keys between peers, and provides network security services such as access control, data origin authentication, and data encryption.

[0048] IKE (Internet Key Exchange) is a key management protocol. IKE negotiation is divided into two phases. The first phase is used to negotiate a common key used to protect the second phase. The second phase is used to negotiate the key for data protection and network segment protection.

[0049] The Diffie-Hellman (DH) algorithm is a security protocol that allows two parties to establish a secret key over an insecure channel without any prior knowledge of the other party. This key can then be used as a symmetric key to encrypt subsequent communications.

[0050] SA: Security Association (IKE) is a data set negotiated by IKE for VPN gateway encryption and decryption. It mainly includes encryption keys, decryption keys, encryption algorithms, authentication algorithms, and data required for outer header encapsulation.

[0051] To address the problems in the prior art, this application provides a method for IKEv2 negotiation. When the DH algorithm group selected by the responder differs from the DH algorithm group in the KE payload of the initiator, the responder needs to send a message to the initiator with the INVALID_KE_PAYLOAD message type, which carries the DH algorithm group supported by the responder. After receiving this message, the initiator will re-initiate negotiation, and the KE payload carried in the negotiation message will be the DH algorithm group supported by the responder. The negotiation will succeed after the responder receives this message again.

[0052] In this application, the initiator saves the DH algorithm group supported by the responder by recording the first successful negotiation with the responder. When the initiator conducts IKEv2 negotiation with the responder again, the recorded DH algorithm group is used to carry the KE payload to negotiate with the responder, instead of using the unsupported DH algorithm group as in the first negotiation. This reduces the RTT of the subsequent IKEv2 negotiation and greatly improves the user experience.

[0053] The content of this application is described in detail below with the help of specific embodiments.

[0054] Figure 1 FIG1 is a flowchart of an IKEv2 negotiation method according to an exemplary embodiment. The IKEv2 negotiation method 10 includes at least steps S102 to S112.

[0055] like Figure 1 As shown, in S102, the initiator obtains the IP address of the responder. The IP address can be obtained through network configuration, routing rules, DNS resolution, or provided by an upper-layer control module, and is used to identify the target negotiation object.

[0056] In S104, a query and match is performed in a pre-stored DH algorithm mapping table according to the IP address. The initiator performs a query and match in a locally pre-stored DH (Diffie-Hellman) algorithm mapping table according to the IP address.

[0057] This mapping table records the DH algorithm group information for each responder. Entries are typically in the form of IP address → DH algorithm group number. This mapping can be dynamically updated based on historical negotiation records or configured by the administrator.

[0058] In S106, when a matching entry is found, the DH algorithm group information is extracted from the matching entry. When an entry corresponding to the target IP address is found in the mapping table, the initiator extracts the DH algorithm group information supported by the responder, such as DH Groups 14, 19, and 20. This information can be extracted to avoid using DH algorithms unsupported by the responder during negotiation, reducing the probability of negotiation failure.

[0059] In S108, a KE payload is generated based on the DH algorithm group information. The initiator generates a KE (Key Exchange) payload based on the extracted DH algorithm group information. The KE payload is an important component of the IKEv2 protocol used to exchange Diffie-Hellman public key material and is used to subsequently generate a shared key.

[0060] The format of the IKEv2 KE payload (RFC7296-3.4) is as follows Figure 2 As shown, where:

[0061] Next Payload: indicates the type of the next payload;

[0062] C (Critical) flag: used to identify whether the payload is critical. It is usually 0 in IKEv2.

[0063] Payload Length: the total length of the payload;

[0064] DH Group num: indicates the DH algorithm group number used;

[0065] Key Exchange Data: Public key data generated by the DH algorithm, used by both parties to calculate the shared key.

[0066] In S110, an IKE_SA_INIT message is constructed based on the KE payload. The initiator can construct the IKE_SA_INIT message based on the generated KE payload and other necessary information (such as SAi, Ni, etc.). This message is the starting message of the first phase of negotiation in the IKEv2 protocol and typically contains: a message header (HDR), a security proposal (SAi), a key exchange (KEi), and a random number (Ni).

[0067] In S112, the IKE_SA_INIT message is sent to the responder to perform IKEv2 protocol negotiation.

[0068] The initiator sends the constructed IKE_SA_INIT message to the responder, initiating the IKEv2 negotiation process. If the KE payload in the message uses a DH algorithm group supported by the responder, key negotiation is successful. This method significantly reduces the probability of negotiation failures due to DH algorithm mismatches, thereby improving the success rate and efficiency of IKEv2 negotiations.

[0069] According to the IKEv2 protocol negotiation method of the present application, the initiator obtains the IP address of the responder; a query and match is performed in a pre-stored DH algorithm mapping table based on the IP address; when a table entry is matched, DH algorithm group information is extracted from the matched table entry; a KE payload is generated according to the DH algorithm group information; an IKE_SA_INIT message is constructed based on the KE payload; and the IKE_SA_INIT message is sent to the responder to negotiate the IKEv2 protocol. This method can reduce the number of renegotiations caused by DH algorithm mismatch in the IKEv2x protocol, thereby reducing negotiation delays and improving negotiation efficiency.

[0070] It should be clearly understood that this application describes how to form and use specific examples, but the principles of this application are not limited to any details of these examples. On the contrary, based on the teaching of the content disclosed in this application, these principles can be applied to many other embodiments.

[0071] Figure 3 The figure is a flowchart showing a negotiation method of the IKEv2 protocol according to another exemplary embodiment. Figure 3 The process 30 shown is Figure 1 Supplementary description of the process shown.

[0072] like Figure 3 As shown, in S302, when no entry is matched in the DH algorithm mapping table, the initiator determines temporary DH algorithm group information. The initiator can select any one of multiple DH algorithm group information as the temporary DH algorithm group information.

[0073] If the initiator fails to find an entry in the pre-stored DH algorithm mapping table that matches the responder's IP address, it must determine a temporary DH algorithm group to continue negotiation. This temporary DH algorithm group can be selected from multiple DH algorithm groups supported by the initiator.

[0074] The selection method can be based on priority rules, historical experience, default algorithm groups, or dynamically adjusted according to security and performance requirements, but this application is not limited to this.

[0075] For example, DH groups that are widely supported and highly secure are preferred, such as DH Group 14 or DH Group 19. This step ensures that negotiation can be initiated successfully even if algorithm mapping information for the responder is lacking, thus avoiding blocking.

[0076] In S304, a KE payload is generated based on the temporary DH algorithm group information. The initiator generates a corresponding KE (Key Exchange) payload based on the determined temporary DH algorithm group information. This payload contains the public key material required for the selected DH algorithm group and is used for subsequent key exchange. The KE payload format complies with the IKEv2 protocol standard, ensuring that the responder can correctly parse and use this payload in the negotiation.

[0077] In S306, an IKE_SA_INIT message is constructed based on the KE payload. The initiator can construct a complete IKE_SA_INIT message based on the generated KE payload and other necessary parameters of the security protocol, such as the security proposal (SAi) and the random number (Ni). This message is the initial message of the first phase of the IKEv2 protocol and carries the initiator's negotiation intentions and key exchange materials.

[0078] In S308, the IKE_SA_INIT message is sent to the responder to perform IKEv2 protocol negotiation.

[0079] The initiator sends the constructed IKE_SA_INIT message to the responder to initiate the IKEv2 negotiation process. The responder then parses the message and responds based on its supported algorithms. If the selected temporary DH algorithm group does not match the responder's, the responder sends an INVALID_KE_PAYLOAD message to inform the initiator of its supported algorithm groups. The initiator can then update the mapping table and re-initiate negotiation, further improving negotiation success and efficiency.

[0080] Through the above process, even in the absence of pre-mapping information, the initiator can flexibly respond to the algorithm support of different responders, ensuring a continuous and efficient IKEv2 negotiation process and avoiding negotiation failures and unnecessary delays.

[0081] Figure 4 The figure is a flowchart showing a negotiation method of the IKEv2 protocol according to another exemplary embodiment. Figure 4 The process 40 shown is for Figure 3 Supplementary description of the process shown.

[0082] like Figure 4As shown, in S402, the initiator obtains a response message from the responder. The initiator receives and obtains the response message from the responder, which is a reply to the previously sent IKE_SA_INIT message. The response message contains the responder's feedback on the negotiated parameters, particularly regarding the supported encryption algorithms and key exchange algorithms.

[0083] In S404, the DH algorithm group information supported by the responder is determined based on the response message. Based on the received response message, the initiator parses and determines the Diffie-Hellman (DH) algorithm group information supported by the responder. This information is crucial for the smooth progress of subsequent negotiations and can help the initiator adjust its negotiation strategy to match the capabilities of the responder.

[0084] In one embodiment, when the response message is of the INVALID_KE_PAYLOAD message type, information about the DH algorithm groups supported by the responder is extracted from the message. If the response message is of the INVALID_KE_PAYLOAD message type, meaning the responder explicitly indicates that the DH algorithm in the KE payload used by the initiator is unsupported, the initiator extracts information about the DH algorithm groups explicitly supported by the responder from the message. The INVALID_KE_PAYLOAD message carries identifiers of DH algorithms acceptable to the responder, thereby guiding the initiator to reselect an appropriate DH algorithm.

[0085] In one embodiment, when the response message type is not INVALID_KE_PAYLOAD, the temporary DH algorithm group information is determined to be the DH algorithm group information supported by the responder. If the response message type is not INVALID_KE_PAYLOAD, indicating that the responder has accepted the DH algorithm group selected by the initiator, the initiator directly confirms the previously used temporary DH algorithm group information as the DH algorithm group information supported by the responder without any additional adjustment.

[0086] In S406, a mapping relationship is established between the DH algorithm group information and the responder's IP address, and the mapping relationship is stored in the DH algorithm mapping table. The IP address can be used as the key and the DH algorithm group information as the value; the DH algorithm group information and the responder's IP address are stored in the DH algorithm mapping table in a key / value format.

[0087] The initiator establishes a mapping relationship between the determined DH algorithm group information supported by the responder and the responder's IP address, and stores the mapping relationship in a preset DH algorithm mapping table.

[0088] In a specific embodiment, the responder's IP address can be used as the key of the mapping table, and the corresponding DH algorithm group information can be used as the value, stored in the form of a key-value pair. This mapping table enables the initiator to quickly match and select the appropriate DH algorithm for the same responder in the future, improving negotiation efficiency and reducing the probability of negotiation failure.

[0089] Through the above process, the initiator can dynamically update and maintain DH algorithm support information for different responders, realize intelligent and automated algorithm selection, and significantly optimize the negotiation performance and success rate of the IKEv2 protocol.

[0090] Those skilled in the art will appreciate that all or part of the steps implementing the above embodiments can be implemented as a computer program executed by a CPU. When executed by the CPU, the computer program performs the functions defined in the above method provided herein. The program can be stored in a computer-readable storage medium, such as a read-only memory, a magnetic disk, or an optical disk.

[0091] Furthermore, it should be noted that the aforementioned figures are merely illustrative of the processes included in the methods according to exemplary embodiments of the present application and are not intended to be limiting. It is readily understood that the processes illustrated in the aforementioned figures do not indicate or limit the temporal order of these processes. Furthermore, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0092] The following are device embodiments of the present application, which can be used to implement the method embodiments of the present application. For details not disclosed in the device embodiments of the present application, please refer to the method embodiments of the present application.

[0093] Figure 5 FIG. 1 is a block diagram of a negotiation device for an IKEv2 protocol according to an exemplary embodiment. Figure 5 As shown, the negotiation device 50 of the IKEv2 protocol includes: an address module 502, a matching module 504, an extraction module 506, a payload module 508, a message module 510, and a negotiation module 512. The negotiation device 50 of the IKEv2 protocol may further include: a construction module 514 and an update module 516.

[0094] The address module 502 is used by the initiator to obtain the IP address of the responder;

[0095] The matching module 504 is used to perform a query and match in a pre-stored DH algorithm mapping table according to the IP address;

[0096] The extraction module 506 is used to extract DH algorithm group information from the matched entry when the entry is matched;

[0097] The payload module 508 is configured to generate a KE payload according to the DH algorithm group information;

[0098] The message module 510 is used to construct an IKE_SA_INIT message based on the KE payload;

[0099] The negotiation module 512 is configured to send the IKE_SA_INIT message to the responder to perform negotiation of the IKEv2 protocol.

[0100] The construction module 514 is used to, when no entry is matched in the DH algorithm mapping table, determine the temporary DH algorithm group information by the initiator; generate a KE payload according to the temporary DH algorithm group information; construct an IKE_SA_INIT message based on the KE payload; and send the IKE_SA_INIT message to the responder for negotiation of the IKEv2 protocol.

[0101] The update module 516 is used for the initiator to obtain the response message returned by the responder; determine the DH algorithm group information supported by the responder based on the response message; establish a mapping relationship between the DH algorithm group information and the IP address of the responder, and store it in the DH algorithm mapping table.

[0102] According to the negotiation device of the IKEv2 protocol of the present application, the initiator obtains the IP address of the responder; a query and match is performed in a pre-stored DH algorithm mapping table based on the IP address; when a table entry is matched, DH algorithm group information is extracted from the matched table entry; a KE payload is generated according to the DH algorithm group information; an IKE_SA_INIT message is constructed based on the KE payload; and the IKE_SA_INIT message is sent to the responder to negotiate the IKEv2 protocol. This method can reduce the number of renegotiations caused by DH algorithm mismatch in the IKEv2x protocol, thereby reducing negotiation delay and improving negotiation efficiency.

[0103] Figure 6 It is a block diagram of an electronic device according to an exemplary embodiment.

[0104] Refer to the following Figure 6 hereinafter, an electronic device 600 according to this embodiment of the present application is described. Figure 6 The electronic device 600 shown is merely an example and should not limit the functions and scope of use of the embodiments of the present application.

[0105] like Figure 6 As shown, electronic device 600 is implemented as a general-purpose computing device. Components of electronic device 600 may include, but are not limited to, at least one processing unit 610, at least one storage unit 620, a bus 630 connecting various system components (including storage unit 620 and processing unit 610), a display unit 640, and the like.

[0106] The storage unit stores program codes, which can be executed by the processing unit 610, so that the processing unit 610 performs the steps described in this specification according to various exemplary embodiments of the present application. For example, the processing unit 610 can perform the following steps: Figure 1 , Figure 3 , Figure 4 Follow the steps shown in .

[0107] The storage unit 620 may include a readable medium in the form of a volatile storage unit, such as a random access memory unit (RAM) 6201 and / or a cache memory unit 6202 , and may further include a read-only memory unit (ROM) 6203 .

[0108] The storage unit 620 may also include a program / utility 6204 having a set (at least one) of program modules 6205, such program modules 6205 including but not limited to: an operating system, one or more application programs, other program modules and program data, each of which or some combination may include an implementation of a network environment.

[0109] Bus 630 may represent one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processing unit, or a local bus using any of a variety of bus architectures.

[0110] The electronic device 600 can also communicate with one or more external devices 600' (e.g., a keyboard, a pointing device, a Bluetooth device, etc.), devices that allow a user to interact with the electronic device 600, and / or any device that allows the electronic device 600 to communicate with one or more other computing devices (e.g., a router, a modem, etc.). This communication can occur via an input / output (I / O) interface 650. Furthermore, the electronic device 600 can communicate with one or more networks (e.g., a local area network (LAN), a wide area network (WAN), and / or a public network such as the Internet) via a network adapter 660. The network adapter 660 can communicate with other modules of the electronic device 600 via the bus 630. It should be understood that, although not shown in the figure, other hardware and / or software modules can be used in conjunction with the electronic device 600, including but not limited to microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0111] Through the above description of the embodiments, it is easy for those skilled in the art to understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Figure 7 As shown, the technical solution according to the embodiment of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, and includes a number of instructions to enable a computing device (which can be a personal computer, a server, or a network device, etc.) to execute the above method according to the embodiment of the present application.

[0112] The software product can be any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable storage medium can be, for example, but not limited to, a system, device or component of electricity, magnetism, light, electromagnetic, infrared, or semiconductor, or any combination thereof. More specific examples (non-exhaustive list) of readable storage media include: an electrical connection with one or more wires, a portable disk, 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 disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof.

[0113] The computer-readable storage medium may include a data signal propagated in baseband or as part of a carrier wave, wherein the readable program code is carried. The data signal propagated may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The readable storage medium may also be any readable medium other than a readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, device, or component. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical cable, RF, etc., or any suitable combination thereof.

[0114] The program code for performing the operations of the present application can be written in any combination of one or more programming languages, including object-oriented programming languages such as Java, C++, etc., and conventional procedural programming languages such as "C" or similar programming languages. The program code can be executed entirely on the user computing device, partially on the user device, as a separate software package, partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server. In the case of a remote computing device, the remote computing device can be connected to the user computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0115] The computer-readable medium carries one or more programs. When the one or more programs are executed by a device, the computer-readable medium implements the following functions: an initiator obtains an IP address of a responder; performs a query and match in a pre-stored DH algorithm mapping table based on the IP address; when a table entry is matched, extracts DH algorithm group information from the matched table entry; generates a KE payload based on the DH algorithm group information; constructs an IKE_SA_INIT message based on the KE payload; and sends the IKE_SA_INIT message to the responder to negotiate the IKEv2 protocol.

[0116] Those skilled in the art will appreciate that the modules described above can be distributed in the device according to the description of the embodiment, or can be modified accordingly to be used in one or more devices that are different from the embodiment. The modules of the above embodiment can be combined into one module or further divided into multiple submodules.

[0117] Through the description of the above embodiments, it is easy for those skilled in the art to understand that the example embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solution according to the embodiments of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which can be a personal computer, a server, a mobile terminal, or a network device, etc.) to execute the method according to the embodiments of the present application.

[0118] While the exemplary embodiments of the present application have been specifically illustrated and described above, it should be understood that the present application is not limited to the detailed structures, configurations, or implementations described herein; rather, the present application is intended to encompass various modifications and equivalent configurations within the spirit and scope of the appended claims.

Claims

1. A method for generating a pre-screened character string in a regular expression rule, characterized in that: include: A negotiation method for the IKEv2 protocol, comprising: The initiator obtains the IP address of the responder; Perform a query and match in a pre-stored DH algorithm mapping table according to the IP address; When a table entry is matched, the DH algorithm group information is extracted from the matched table entry; Generate a KE payload according to the DH algorithm group information; Constructing an IKE_SA_INIT message based on the KE payload; The IKE_SA_INIT message is sent to the responder to perform IKEv2 protocol negotiation.

2. The method according to claim 1, wherein Also includes: When no entry is matched in the DH algorithm mapping table, the initiator determines temporary DH algorithm group information; Generate a KE payload according to the temporary DH algorithm group information; Constructing an IKE_SA_INIT message based on the KE payload; The IKE_SA_INIT message is sent to the responder to perform IKEv2 protocol negotiation.

3. The method according to claim 2, wherein The initiator determines the temporary DH algorithm group information, including: The initiator selects any one of the multiple DH algorithm group information as the temporary DH algorithm group information.

4. The method according to claim 2, wherein After sending the IKE_SA_INIT message to the responder to negotiate the IKEv2 protocol, the method further includes: The initiator obtains the response message returned by the responder; Determine, based on the response message, DH algorithm group information supported by the responder; A mapping relationship is established between the DH algorithm group information and the responder's IP address, and stored in the DH algorithm mapping table.

5. The method according to claim 4, wherein Determining DH algorithm group information supported by the responder based on the response message includes: When the type of the response message is an INVALID_KE_PAYLOAD message, DH algorithm group information supported by the responder is extracted from the message.

6. The method according to claim 4, wherein Determining DH algorithm group information supported by the responder based on the response message includes: When the type of the response message is not an INVALID_KE_PAYLOAD message, the temporary DH algorithm group information is determined as the DH algorithm group information supported by the responder.

7. The method according to claim 4, wherein Establishing a mapping relationship between the DH algorithm group information and the responder's IP address and storing the mapping relationship in the DH algorithm mapping table includes: Use the IP address as key; Use the DH algorithm group information as value; The DH algorithm group information and the responder's IP address are stored in the DH algorithm mapping table in the form of key / value.

8. A negotiation device for the IKEv2 protocol, characterized in that: include: Address module, used by the initiator to obtain the IP address of the responder; A matching module, configured to perform a query and match in a pre-stored DH algorithm mapping table according to the IP address; An extraction module, configured to extract DH algorithm group information from a matched entry when a matched entry is found; A payload module, configured to generate a KE payload according to the DH algorithm group information; A message module, configured to construct an IKE_SA_INIT message based on the KE payload; The negotiation module is configured to send the IKE_SA_INIT message to the responder to perform negotiation of the IKEv2 protocol.

9. The device according to claim 8, wherein Also includes: A construction module is used to, when no entry is matched in the DH algorithm mapping table, determine temporary DH algorithm group information by the initiator; generate a KE payload according to the temporary DH algorithm group information; construct an IKE_SA_INIT message based on the KE payload; and send the IKE_SA_INIT message to the responder for negotiation of the IKEv2 protocol.

10. The device according to claim 8, wherein Also includes: Update module, used by the initiator to obtain the response message returned by the responder; Determine the DH algorithm group information supported by the responder based on the response message; establish a mapping relationship between the DH algorithm group information and the IP address of the responder, and store it in the DH algorithm mapping table.

Images