WO2012079462A1

WO2012079462A1 - Method and device for internet key exchange (ike) message negotiation

Info

Publication number: WO2012079462A1
Application number: PCT/CN2011/083230
Authority: WO
Inventors: 谭龙远
Original assignee: 成都市华为赛门铁克科技有限公司
Priority date: 2010-12-16
Filing date: 2011-11-30
Publication date: 2012-06-21
Also published as: CN102025742A

Abstract

The embodiment of the invention discloses a method and device for Internet Key Exchange (IKE) message negotiation. The method includes: transmitting the last negotiation message to be transmitted; determining whether the response message has been received from the opposite end; if the response message has been received from the opposite end, establishing a security alliance (SA); if not, retransmitting the last negotiation message. According to the embodiment of the invention, the quality of the IKE negotiation of phase 1 and phase 2 can be improved.

Description

Method and device for negotiating IKE message This application claims to be submitted to the Chinese Patent Office on December 16, 2010, the application number is 201010592414.X, and the invention name is "an IKE message negotiation method and device" Chinese patent Priority of the application, the entire contents of which are incorporated herein by reference. The present invention relates to the field of communications technologies, and in particular, to a method and device for negotiating IKE packets.

Background technique

Before IPsec (IP Security, IP Security) sends a packet, you need to establish a SA (Security Association). IKE (Internet Key Exchange) is a hybrid protocol used to dynamically establish SAs. Among them, IKE is a key exchange and management protocol for providing key services for IPsec, based on a framework defined by SA and ISAKMP (Internet Security Association and Key Management Protocal, Internet Security Alliance and Key Management Protocol). Above. At the same time, IKE also implements some of the features of the two key management technologies Oakley and SKEME. IKE follows the foundation of ISAKMP, Oakley's model, and SKEME's sharing and key update technology to define authentication encryption material generation techniques and negotiated sharing strategies. Among them, Oakley defines the mode, and ISAKMP defines the negotiation phase.

There are two phases in IKE negotiation. In the first phase, IKE negotiation creates an IKE SA and the IKE is negotiated.

The SA performs authentication to provide confidentiality, data integrity, and data source authentication services for further IKE communication between the two parties. In the second phase, an established IPsec SA is established using the established IKE SA negotiation. The negotiation process of each stage can be implemented by different modes. For example, the first stage can be negotiated by the main mode or the barbaric mode, and the second stage can be negotiated by the fast mode.

Please refer to FIG. 1 , which is a schematic diagram of a negotiation process for implementing the first phase negotiation by the main mode. As discussed in Figure 1. The first four consultations are exchanged for civilized texts, and the last two negotiation messages are encrypted and exchanged. In addition to the main mode, the first stage of negotiation can also be implemented by the barbaric mode. Please refer to Figure 2, which is implemented by the barbaric mode. A schematic diagram of the negotiation process for the first phase of negotiations. As shown in Figure 2, the negotiation between the negotiation initiator and the negotiation responder can complete the first phase of negotiation by sending and receiving three negotiation packets. After completing the first phase of negotiations, enter the second phase of negotiations. Please refer to FIG. 3 , which is a schematic diagram of a negotiation process for implementing the second phase negotiation by the fast mode. As shown in Figure 3, the negotiation between the negotiation initiator and the negotiation responder completes the second phase negotiation by interacting with three negotiation messages.

However, the inventors found in the study that in the negotiation process, due to network instability, such as network failure or congestion, the last negotiation packet of each negotiation process is easily lost in transmission, resulting in the negotiation between the two parties. One party completed the negotiation and the other party did not complete the negotiation. In the first stage, the VPN (Virtual Private Network) network is unavailable before the IKE timeout expires after the negotiation fails. In the second phase, after the negotiation responder in the negotiation party fails to negotiate, the negotiation responder, after receiving the message sent by the negotiation initiator, will completely discard the received message because it cannot be decrypted. At the same time, since the negotiation initiator continues to send packets to the invalid responder's S A (security association), bandwidth is wasted and these packets are dropped into the black hole.

SUMMARY OF THE INVENTION In order to solve the above technical problem, an embodiment of the present invention provides a method and a device for negotiating an IKE packet, so as to ensure that the negotiation in the first phase and the second phase succeeds, and the quality of the IKE negotiation is improved. The embodiment of the present invention discloses the following technical solution: A method for negotiating IKE packets, including: sending a last negotiation packet that needs to be sent by itself; determining whether a peer response packet is received; and receiving the peer response When the packet is received, the SA is established. Otherwise, the last negotiation packet is resent.

A device for implementing IKE packet negotiation includes: a sending unit, configured to send a last negotiation packet that needs to be sent by itself; a determining unit, configured to determine whether a peer response packet is received; and a negotiating unit, configured to receive And the re-sending unit is configured to resend the last negotiation packet when the peer response packet is not received. It can be seen from the foregoing embodiment that after the last negotiation packet that needs to be sent is sent, it is determined whether the peer response packet is received. If the peer response packet is received, the negotiation is successful, and the security association is established. The peer response packet is received, indicating that the negotiation is not successful, and the last negotiation packet is resent, thereby improving the quality of the IKE negotiation. At the same time, when one party fails to negotiate and the other party fails, the party that fails the negotiation in the direction of the successful negotiation sends an encrypted message and wastes bandwidth due to falling into the black hole.

DRAWINGS

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the embodiments or the description of the prior art will be briefly described below. Obviously, the drawings in the following description are only It is a certain embodiment of the present invention, and other drawings can be obtained from those skilled in the art without any inventive labor.

FIG. 1 is a schematic diagram of a negotiation process for implementing the first phase negotiation by the main mode;

2 is a schematic diagram of a negotiation process for implementing the first phase negotiation by the barbaric mode;

FIG. 3 is a schematic diagram of a negotiation process for implementing the second phase negotiation by the fast mode;

4 is a flow chart of an embodiment of a IKE 4 negotiation method;

FIG. 5 is a flowchart of another embodiment of a method for negotiating IKE packets;

6 is a flowchart of another embodiment of a method for negotiating IKE packets;

Figure Ί is a schematic diagram of the negotiation process of the first phase IKE message by the barbaric mode under network failure;

8 is a flowchart of another embodiment of a method for negotiating IKE packets;

FIG. 9 is a flowchart of a method for sending a last negotiation message in a negotiation process;

FIG. 10 is a structural diagram of an embodiment of an apparatus for implementing IKE message negotiation. detailed description

The technical solutions in the embodiments of the present invention will be clearly and completely described in the following with reference to the accompanying drawings in the embodiments of the present invention. It is an embodiment of the invention, but not all of the embodiments. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments of the present invention without departing from the inventive scope should fall within the scope of the present invention.

Embodiment 1

Referring to FIG. 4, it is a flowchart of an embodiment of a method for negotiating IKE packets. Includes the following steps:

Step 401: Send the last negotiation packet that needs to be sent by itself;

Step 402: Determine whether the peer response message is received, and if yes, proceed to step 403, otherwise, go to step 404;

The receiving the peer response packet is specifically: determining whether the peer response packet is received within the preset time, and if yes, determining that the peer response packet is received, otherwise, determining that the peer response packet is not received The peer responds to the message. Or, in the aggressive mode, determining whether the first negotiation message of the next stage arrives before the peer response message, and if yes, determining that the peer response message is not received, otherwise, determining that the message is received The peer responds to the message.

Or,

In the aggressive mode, it is determined whether the preset time or the first negotiation message of the next stage arrives before the peer response message. If yes, it is determined that the peer response message is not received, otherwise, the determination is received. The peer responds to the message.

The preset time may be times x 2 + 5s, where times is the number of times the last negotiation message is retransmitted.

It should be noted that, in the embodiment of the present application, the preset time is not limited, and in addition to the above values, the setting may be arbitrarily set according to the application requirements of the user.

Step 403: When the peer response packet is received, a SA is established.

Step 404: Resend the last association when the peer response message is not received. Business message.

The resending the last negotiation message is specifically:: retrieving the last negotiation message, and sending the retrieved last negotiation message;

Or,

In the main mode, the negotiation process is re-initiated, and the last negotiation message is sent in the re-initiated negotiation process.

In the embodiment of the present application, the life cycle of the message can also be set. When the life cycle of the packet arrives, each executor does not send the message. For example, in the main mode, when the life cycle of the main mode negotiation message (6) arrives, even if the negotiation responder re-receives the main mode negotiation message (5), the main mode negotiation report will not be sent again to the negotiation initiator. Text (6).

The first phase of the message life cycle can be 60s, and the second phase can be 50s. It should be noted that, in the embodiment of the present application, the life cycle is not limited, and in addition to the above values, it may be arbitrarily set according to the application requirements of the user.

It can be seen from the above implementation that after transmitting the last negotiation packet that needs to be sent, it is determined whether the peer response packet is received. If the peer response packet is received, the negotiation succeeds, and the security association is established. The response packet to the peer indicates that the negotiation is unsuccessful and the last negotiation packet is resent. This improves the quality of IKE negotiation. At the same time, when one party fails to negotiate and the other party fails, the party that fails the negotiation in the first direction of negotiation fails to send the encrypted message and wastes the bandwidth because it falls into the black hole. Embodiment 2

In this embodiment, the method for negotiating the packet is described by taking an example of determining whether the peer response packet is received within the preset time. Referring to FIG. 5, it is a flowchart of another embodiment of a method for negotiating IKE packets. Includes the following steps:

Step 501: When the negotiation party does not receive the negotiation response message sent by the negotiation peer within the preset time after sending the last negotiation message that needs to be sent, the negotiation party sends the last negotiation that needs to be sent to the negotiation party. Message

For example, in the first phase, when the negotiation of the first phase is implemented by the primary mode, the negotiation initiator sends the last negotiation packet that should be sent to the negotiation responder, that is, the main mode negotiation message (5), and then The negotiation responder sends a response negotiation message to the negotiation initiator, that is, the main mode negotiation message (6). When the negotiation of the first phase is implemented by the barbaric mode, the negotiation responder sends the last negotiation message that should be sent to the negotiation initiator, that is, the barbaric negotiation message (2), and then the negotiation initiator sends the negotiation responder to the negotiation. Sends a response negotiation packet, which is a bargain mode negotiation message (3).

In the second phase, when the negotiation of the second phase is implemented by the fast mode, the negotiation responder sends the last negotiation message that should be sent to the negotiation initiator, that is, the fast mode negotiation message (2), and then initiated by the negotiation. The sender sends a response negotiation message to the negotiation responder, that is, the fast mode negotiation message (3).

When the negotiation of the first phase is implemented by the primary mode, if the negotiation initiator does not receive the primary mode negotiation message (6) within the preset time after sending the primary mode negotiation message (5), the negotiation will be re-negotiated. The responder sends a main mode negotiation message (5).

When the negotiation of the first phase is implemented by the barbaric mode, if the negotiation responder does not receive the barbarian mode negotiation message (3) within the preset time after sending the barbarian mode negotiation message (2), it will re-negotiate. The initiator sends a barbarian mode negotiation message (2).

When the second phase negotiation is implemented by the fast mode, if the negotiation responder does not receive the fast mode negotiation message (3) within the preset time after sending the fast mode negotiation message (2), the negotiation will be re-negotiated. The initiator sends a fast mode negotiation message (2).

In addition, in the embodiment of the present application, when the life cycle of the packet arrives, each execution entity does not send the message. For example, in the main mode, when the life cycle of the main mode negotiation message (6) arrives, even if the negotiation responder re-receives the main mode negotiation message (5), it will not resend the main mode negotiation report to the negotiation initiator. Text (6). The first phase of the message life cycle can be 60s, and the second phase can be 50s. It should be noted that, in the embodiment of the present application, the life cycle is not limited, and in addition to the above values, it may be arbitrarily set according to the application requirements of the user.

It should also be noted that, in the main mode, when the negotiation initiator does not negotiate the negotiation response message sent by the responder within the preset time, in addition to resending the last negotiation message that needs to be sent by itself, it may also After re-initiating the negotiation and re-initiating the negotiation process, the last negotiation message that needs to be sent is sent to the negotiation responder again.

Step 502: Presetting after the negotiating party sends the last negotiation message that needs to be sent by itself. The security association is established when the negotiation response packet sent by the negotiation peer is received.

It can be seen from the foregoing embodiment that after transmitting the last negotiation packet that needs to be sent, it is determined whether the peer response packet is received within the preset time, and if the peer response packet is received within the preset time, If the negotiation is successful, the security association is established. If the peer response packet is not received within the preset time, the negotiation fails. The last negotiation packet is resent, which improves the quality of IKE negotiation. At the same time, when one party fails to negotiate and the other party fails, the party that failed the negotiation in the direction of negotiation successfully sends an encrypted message and wastes bandwidth due to falling into the black hole. Embodiment 3

This embodiment provides another method for negotiating IKE packets. The IKE packet negotiation method in this embodiment is only applicable to the aggressive mode. Please refer to FIG. 6, which is a flowchart of another embodiment of a method for negotiating IKE messages. The method includes the following steps:

Step 601: In the aggressive mode, after the negotiation responder sends the last negotiation packet that needs to be sent, the first negotiation packet of the second phase is received before receiving the negotiation response packet sent by the negotiation initiator. Resending the last negotiation message that it needs to send;

For example, refer to Figure 7, which is a schematic diagram of the negotiation process of the first-phase IKE message by the aggressive mode under network failure. As shown in FIG. 7, for the negotiation initiator, since the negotiation process of the first phase has been completed and the negotiation process of the second phase is entered, the negotiation initiator will continue to send the second phase to the negotiation responder. The first negotiation message. At this time, the negotiation responder still does not receive the last negotiation packet. For the negotiation responder, the first phase is not established. Therefore, the negotiation responder will resend the last negotiation packet that needs to be sent to the negotiation initiator. .

Step 602: After the negotiation responder sends the last negotiation packet that needs to be sent by itself, if the negotiation response packet sent by the negotiation initiator is received before receiving the first negotiation packet of the second phase, the security association is established. .

At the same time, it should be noted that, in the embodiment of the present application, when the life cycle of the packet arrives, each execution entity does not send the packet. For example, in the aggressive mode, when the life cycle of the barbarian mode negotiation message (3) arrives, even if the negotiation initiator re-receives the barbarian mode negotiation message (2), it will not send the barb mode negotiation to the negotiation responder again. Message (3). The first phase of the message life cycle can be 60s, and the second phase can be 50s. It should be noted that, in the embodiment of the present application, the life cycle is not limited, and in addition to the above values, it may be arbitrarily set according to the application requirements of the user. It can be seen from the foregoing embodiment that after transmitting the last negotiation packet that needs to be sent by itself, it is determined whether the first negotiation packet end of the second phase is received before receiving the negotiation response packet sent by the negotiation initiator. The response packet, if yes, indicates that the negotiation is successful, and the security association is established. If no, the negotiation is not successful, and the last negotiation packet is resent, thereby improving the quality of the IKE negotiation. At the same time, when one party fails to negotiate and the other party fails, the party that fails the negotiation in the direction of the successful negotiation sends an encrypted message and wastes bandwidth due to falling into the black hole. Embodiment 4

This embodiment provides another method for negotiating IKE packets. The IKE message negotiation method in this embodiment is applicable to the negotiation mode. If the preset response time is reached before the peer response message is received, the negotiation responder negotiates after the preset time arrives. The initiator resends the last negotiation packet that needs to be sent by itself. If the first negotiation packet arrives in the second phase before receiving the peer response packet, the negotiation responder receives the first negotiation in the second phase. After the message is sent, the initiator of the negotiation resends the last negotiation packet that needs to be sent. Please refer to FIG. 8, which is a flowchart of another embodiment of a method for negotiating an IKE message. The method includes the following steps: Step 801: In the aggressive mode, after the negotiation responder sends the last negotiation message that needs to be sent, if the preset time arrives before receiving the peer response message, or receives Receiving the first negotiation packet of the next stage before the peer response message arrives, and resending the last negotiation message that needs to be sent by itself;

Step 802: After the negotiation responder sends the last negotiation message that needs to be sent by itself, if the negotiation response message is received before the preset time arrives and the first negotiation message of the next stage is received, the negotiation response message sent by the negotiation initiator is received. Text, establish a security alliance.

At the same time, it should be noted that, in the embodiment of the present application, when the life cycle of the packet arrives, each execution entity does not send the message. For example, in the aggressive mode, when the life cycle of the barbarian mode negotiation message (3) arrives, even if the negotiation initiator receives the barb mode negotiation message (2) again, it will not send the barb mode negotiation to the negotiation responder again. Message (3).

The life cycle of a message can be 60s in the first phase and 50s in the second phase. It should be noted that, in the embodiment of the present application, the life cycle is not limited, and in addition to the above values, it may be arbitrarily set according to the application requirements of the user.

It can be seen from the above embodiment that after transmitting the last negotiation message that needs to be sent by itself, the judgment is The first negotiation message of the next stage is received before the preset time arrives, or the preset time arrives before the first negotiation message of the next stage is received, indicating that the negotiation is successful, and the security association is established. The negotiation response message sent by the negotiation initiator is received before the preset time arrives and the first negotiation message of the next stage is received, indicating that the negotiation is not successful, and the last negotiation message is resent, thereby improving the IKE negotiation. the quality of. At the same time, when one party fails to negotiate and the other party fails, the party that fails the negotiation in the direction of negotiation successfully sends an encrypted message and wastes bandwidth due to falling into the black hole. Embodiment 5

In the following, in the different modes of the two phases of the IKE negotiation, the specific negotiation message is sent when the negotiation party (the negotiation responder in the main mode or the negotiation initiator in the aggressive mode) sends the last negotiation packet. The implementation process is shown in Figure 9, which is a flowchart of a method for sending the last negotiation message in the negotiation process. The implementation steps are as follows:

Step 901: Determine, according to the logical condition, whether the negotiation message to be sent is the last negotiation message of the negotiation process. If the logical condition is true, go to step 902; if the logical condition is false, end the process;

The initiator indicates the identifier of the sender of the negotiation message to be sent currently. If the sender is the negotiation initiator, the initiator is 1 and if it is the negotiation responder, the initiator is 0. Step indicates the negotiation step, step starts counting from 0, step 0 indicates that the negotiation step is 1, and so on. Status indicates the serial number of the negotiation packet to be sent. The status is counted from 1. The status is 1 to indicate that the negotiation packet to be sent is the packet (1). If it is the last negotiation packet in the negotiation process, the status is Ready.

According to the logical condition, it is not difficult to find that if the type of the negotiation packet to be sent is the last negotiation packet of the negotiation process, the logical condition is true.

Step 902: According to the logical condition (last_ sent&& (flag & MSG- LAST)) to determine whether to save the last negotiation message to be sent, if the logical condition is false, proceed to step 903, if the logical condition is true, proceed to step 904;

Step 903: Set the type of the last negotiation packet to be sent to MSG_LAST, record the last negotiation packet to be sent in the variable last_sent, send the last negotiation packet, and end the process;

Step 904: Send the last negotiation message, and end the process.

Among them, (1) if it is the main mode, there is an initiator of 0, and the negotiation responder is based on the logical condition. ( last_sent&& ( flags & MSG_LAST )) to determine whether to save the message. If the ( last- sent && ( flags & MSG- LAST ) condition is false, indicating that the last negotiation message is sent for the first time, the flag needs to be set to MSG_LAST, and the last negotiation report sent for the first time. The text (6) is stored in the variable last_sent and sent, and if the logical condition is true, the last negotiation message is sent repeatedly, because the last negotiation message has been sent the first time. Save, you do not need to save again, but directly retransmit the message.

(2) In the case of the aggressive mode, the initiator is 1, and the negotiation initiator determines whether to save the message according to the logical condition (last_sent &&(flag& MSG- LAST )). If ( last_ sent

The && (flag & MSG- LAST ) condition is false, indicating that the first time the first negotiation message is sent, the flag needs to be set to MSG_LAST, and the last negotiation message (3) sent for the first time is recorded. Save the variable last_sent and send the message; if the condition is true, it means that the last negotiation message is sent repeatedly, because the last negotiation message has been saved when it is sent for the first time. You don't need to save it anymore, but you can retransmit the message directly.

(3) In the fast mode, the same initiator is 1, and the initiator determines whether to save the message according to the logical condition (last_sent && (flag & MSG_LAST)). If ( last_ sent &&

(flag & MSG- LAST )) The condition is false, indicating that the first time the first message is sent, the flag needs to be set to MSG_LAST, and the last negotiation message (3) sent for the first time is recorded in the variable. Saved in last_sent, and sends the message; if the condition is true, it means that the last negotiation message has been sent repeatedly. Since the last negotiation message has been saved when it is sent for the first time, it is not necessary. Save it again, but retransmit the message directly.

It can be seen from the foregoing embodiment that after the last negotiation packet that needs to be sent is sent, it is determined whether the peer response packet is received. If the peer response packet is received, the negotiation is successful, and the security association is established. The peer response packet is received, indicating that the negotiation is not successful, and the last negotiation packet is resent, thereby improving the quality of the IKE negotiation. At the same time, when one party fails to negotiate and the other party fails, the party that fails the negotiation in the direction of the successful negotiation sends an encrypted message and wastes bandwidth due to falling into the black hole. Embodiment 6

Corresponding to the retransmission method of the foregoing negotiation packet, the embodiment of the present invention further provides a retransmission system for negotiating packets. Please refer to FIG. 10 , which is a device for implementing IKE message negotiation according to the present application. The structure diagram of the embodiment includes: a sending unit 1001, a determining unit 1002, a negotiating unit 1003, and a resending unit 1004, where

The sending unit 1001 is configured to send a last negotiation packet that needs to be sent by itself;

The determining unit 1002 is configured to determine whether the peer response message is received.

The negotiating unit 1003 is configured to: when the peer end response message is received, establish a security association SA; the resending unit 1004, configured to resend the last negotiation when the peer end response message is not received Message.

The determining unit 1002 includes: a first determining subunit, configured to determine whether the peer response message is received within the preset time, and if yes, determining that the peer response message is received, otherwise, determining that the peer response message is not received The peer responds to the message.

Or,

a second determining sub-unit, configured to: in the aggressive mode, whether the first negotiation packet of the next phase arrives before the peer response packet, and if yes, determines that the peer response packet is not received, No, it is determined that the peer response message is received.

Or,

a third determining sub-unit, configured to determine, in the aggressive mode, whether the first negotiation message of the preset time or the next phase arrives before the peer response message, and if yes, determine that the peer response is not received. The message, otherwise, determines that the peer response message is received.

The retransmission unit 1004 includes: a first retransmission subunit, configured to retrieve the last negotiation packet, and send the retrieved last negotiation packet;

Or,

And a second retransmission sub-unit, configured to re-initiate the negotiation process in the main mode, and send the last negotiation message in the re-initiated negotiation process.

It can be seen from the foregoing embodiment that after the last negotiation packet that needs to be sent is sent, it is determined whether the peer response packet is received. If the peer response packet is received, the negotiation is successful, and the security association is established. The peer response packet is received, indicating that the negotiation is not successful, and the last negotiation packet is resent. This improves the quality of IKE negotiation. At the same time, when one party fails to negotiate and the other party fails, the party that fails the negotiation in the direction of the successful negotiation sends an encrypted message and wastes bandwidth due to falling into the black hole.

The retransmission method and the retransmission system of the negotiation packet in this application are applicable between the host and the host, and the host An IPSec tunnel is established between the gateway and the gateway and the gateway. An IPsec tunnel is established between the public networks to encrypt traffic. Firewalls A and B can serve as negotiation initiators and negotiation responders to the negotiation process. In addition, the retransmission method and the retransmission system of the negotiation message in the present application are also applicable to the person who is on a business trip. In this case, the firewall can be configured as a template. Install the client software on the PC connected to the public network. When accessing data from the headquarters, each PC establishes its own tunnel to protect the transmission of data on the public network.

It should be noted that those skilled in the art can understand that all or part of the processes in the foregoing embodiments can be implemented by a computer program to instruct related hardware, and the program can be stored in a computer readable storage. In the medium, the program, when executed, may include the flow of an embodiment of the methods as described above. The storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

A person skilled in the art may understand that all or part of the various steps of the foregoing embodiments may be completed by a program instructing related hardware. The program may be stored in a computer readable storage medium, and the storage medium may include: Read-only memory, random access memory, disk or optical disk, etc.

The cloud system distributed denial of service attack protection method and the method provided by the embodiment of the present invention are described above, and the description of the above embodiment is only used to help understand the method and core idea of the present invention. Meanwhile, the general technology in the field In the following, the description of the present invention is not limited to the scope of the present invention.

Claims

Rights request

A method for negotiating 11^^艮, characterized in that it comprises:

Send the last negotiation packet that needs to be sent by itself;

Determine whether the peer response message is received;

When the peer response packet is received, the SA is established. Otherwise, the last negotiation packet is resent.

The method according to claim 1, wherein the determining whether the peer response message is received is:

It is determined whether the peer response message is received within the preset time. If yes, it is determined that the peer response message is received, otherwise, it is determined that the peer response message is not received.

In the aggressive mode, it is determined whether the first negotiation message of the next stage arrives before the peer response message, and if yes, it is determined that the peer response message is not received, otherwise, it is determined that the received message is received. The opposite end responds to the text.

In the aggressive mode, it is determined whether the packet is received within the preset time, or whether the first negotiation packet of the next phase arrives before the peer response packet.

If yes, it is determined that the peer response message is not received, otherwise, it is determined that the peer response message is received.

The method according to any one of claims 1 to 4, characterized in that The last negotiation message sent is specifically:

Retrieving the last negotiation message, and sending the last negotiation message that is retrieved; or

The method according to claim 2, wherein the preset time is times X 2 + 5s, wherein times is the number of times the last negotiation message is retransmitted.

A device for implementing IKE packet negotiation, which is characterized by:

a sending unit, configured to send a last negotiation packet that needs to be sent by itself;

a determining unit, configured to determine whether a peer response message is received;

a negotiating unit, configured to: when receiving the peer response packet, establish a security association SA;

And a retransmission unit, configured to resend the last negotiation packet when the peer response packet is not received.

The device according to claim 7, wherein the determining unit comprises: a first determining sub-unit, configured to determine whether a peer response message is received within a preset time, and if yes, determine that the message is received The peer responds to the message, otherwise, it determines that the peer response message is not received.

The device according to claim 7, wherein the determining unit comprises: a second determining subunit, configured to determine, in the aggressive mode, whether the first negotiation message of the next stage is in the pair The end response message arrives before, if yes, it is determined that the peer response message is not received, otherwise, it is determined that the peer response message is received.

The device according to any one of claims 7-9, wherein the retransmission unit comprises: a first retransmission subunit, configured to retrieve the last negotiation packet, and send the last negotiation packet that is retrieved;

Or,