WO2014056454A1 - Ike报文协商的方法及系统 - Google Patents

Ike报文协商的方法及系统 Download PDF

Info

Publication number
WO2014056454A1
WO2014056454A1 PCT/CN2013/085132 CN2013085132W WO2014056454A1 WO 2014056454 A1 WO2014056454 A1 WO 2014056454A1 CN 2013085132 W CN2013085132 W CN 2013085132W WO 2014056454 A1 WO2014056454 A1 WO 2014056454A1
Authority
WO
WIPO (PCT)
Prior art keywords
identifier
value
message
processor
stored
Prior art date
Application number
PCT/CN2013/085132
Other languages
English (en)
French (fr)
Inventor
张玮
刘瑞瑞
谢文辉
高国鲁
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2014056454A1 publication Critical patent/WO2014056454A1/zh

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/06Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/16Implementing security features at a particular protocol layer
    • H04L63/164Implementing security features at a particular protocol layer at the network layer

Definitions

  • the embodiments of the present invention relate to communication technologies, and in particular, to a method and system for IKE (Internet Key Exchange) message negotiation.
  • IKE Internet Key Exchange
  • IP Security Internet Protocol Security
  • IPSec Internet Protocol Security
  • IKEv2 is divided into initial exchange, auth exchange, create child exchange, and informational exchange.
  • the header of each IKEv2 packet contains a message id field (message identifier). This field is used to identify the sequence number of the text.
  • the two sides of the communication store two message ids: when sending a request message, use send_message_id (send called ms_id), and the message id of the expected message is recv-message-id (rec) — msgid ).
  • send_message_id send called ms_id
  • the message id of the expected message is recv-message-id (rec) — msgid ).
  • the device sends_message_id+1.
  • recv_message_id+1 in the device recv_message_id+1 in the device.
  • the active member is the device that is currently communicating with the peer device
  • the standby member is the backup device of the master device.
  • the backup device turns to Switch to the new primary device to continue communication with the peer.
  • the active device is in IKEv2 negotiation with the peer device, the communication link between the active device and the remote device fails, and the backup device is converted to the new primary device.
  • the message id in the standby device may not be consistent with the message id in the active device.
  • the communication with the peer device may be interrupted due to a message id error.
  • the present invention provides a method and a system for IKE message negotiation, which are used to solve the problem of long-term service interruption caused by handover of a primary device and a backup device in the prior art.
  • the embodiment of the present invention provides a method for IKE message negotiation, including: the backup device updates the value of the stored third identifier according to the update notification of the active device, and the update notification of the active device is the primary Sent by the device after updating the stored value of the second identifier;
  • the new primary device When the standby device is switched to the new primary device, the new primary device sends a second packet for negotiating Internet Protocol security IPSec information to the opposite device according to the updated third identifier.
  • the third identifier is an identifier stored in the standby device for obtaining state information of the active device.
  • the method before the step of updating, by the standby device, the value of the internal third identifier according to the update notification of the active device, the method further includes:
  • the primary device sends a first packet for negotiating IPSec information to the peer device, where the first packet carries a first identifier
  • the primary device updates the value of the stored second identifier
  • the second identifier is an identifier stored in the active device for obtaining state information of the active device.
  • the first identifier is a message_id;
  • the second identifier is next_sendmsg_id;
  • the third identifier is next_sendmsg_id;
  • the initial value of the first identifier, the initial value of the second identifier, and the initial value of the third identifier are the same, and are both N;
  • the primary device updates the value of the stored second identifier, specifically:
  • the primary device updates the stored value of the second identifier to N+1;
  • the standby device updates the value of the stored third identifier according to the update notification of the active device, specifically:
  • the standby device updates the value of the stored third identity to N+1.
  • the new active device sends a second packet that negotiates IPSec information to the peer device according to the updated third identifier. , Specifically:
  • the new primary device sends a second packet for negotiating IPSec information to the peer device, where the value of the first identifier carried in the second packet is N+1.
  • the foregoing method further includes:
  • the new primary device sends a third packet for negotiating IPSec information to the peer device, where the value of the first identifier carried in the third packet is N.
  • the method before the step of updating, by the standby device, the value of the internal third identifier according to the update notification of the active device, the method further includes:
  • the primary device updates the value of its stored second identity and causes the backup device to back up the value of the second identity.
  • the first identifier is message_id
  • the second identifier is recv_message_id
  • the third identifier is msgid_bk_f lag ,
  • the initial value of the first identifier and the second identifier are both ⁇ , and the initial value of the third identifier is 0.
  • the value of the stored second identifier is updated by the active device, specifically:
  • the primary device updates the stored value of the second identifier to ⁇ +1;
  • the standby device updates the value of the internal third identifier according to the update notification of the active device, specifically:
  • the standby device updates the value of the stored third identity to 1.
  • the new active device sends a second packet that negotiates IPSec information to the peer device according to the updated third identifier. Specifically, including:
  • the second packet that is used to negotiate the IPSec information is sent to the peer device, where the value of the first identifier carried in the second packet is N, and the second packet is in the second packet. Carrying the first SA;
  • the value of the third identifier is 1, the value of the third identifier is reset to 0, the value of the second identifier is updated to N, and the second device that negotiates IPSec information is resent to the peer device.
  • the packet has a value of N for the first identifier carried in the second packet, and the second packet carries the second SA.
  • the embodiment of the present invention further provides a system for IKE message negotiation, including: a primary device and a backup device.
  • the primary device includes: a first processor and a first memory; the standby device includes: a second processor and a second memory;
  • the second processor is configured to update a value of the third identifier stored in the second memory according to the update notification of the first processor, where the update notification of the first processor is the first processor update Transmitting the value of the second identifier stored in the first memory;
  • the second processor is configured to send, according to the updated third identifier in the second memory, a second report that negotiates Internet Protocol Security I PSec information to the peer device.
  • the third identifier in the second memory is an identifier for obtaining status information of the active device.
  • the second processor is configured to update a value of the third identifier stored in the second memory according to the update notification of the first processor
  • the first processor is configured to send, to the peer device, a first packet that negotiates IPSec information, where the first packet carries a first identifier;
  • the first processor is further configured to update a value of the second identifier stored in the first memory, where the second identifier is an identifier used to learn status information of the active device.
  • the first identifier is a message_id;
  • the second identifier is next_sendmsg_id;
  • the third identifier is next_sendmsg_id;
  • the initial value of the first identifier, the initial value of the second identifier, and the initial value of the third identifier are the same, and are both N;
  • the first processor is further configured to update a value of the second identifier stored in the first memory, specifically:
  • the first processor is further configured to update a value of the second identifier in the first memory to N+1;
  • the second processor is configured to update, according to the update notification of the first processor, a value of the third identifier stored in the second memory, specifically:
  • the second processor updates the value of the third identifier in the second memory to N+1.
  • the second processor is configured to send the negotiated IPSec information to the peer device according to the updated third identifier in the second memory.
  • the second message is specifically:
  • the second processor sends a second packet for negotiating IPSec information to the peer device, where the value of the first identifier carried in the second packet is N+1.
  • the second processor is further configured to send, to the peer device, a third packet that negotiates IPSec information, where the The value of the first identifier carried in the three packets is N.
  • the second processor is configured to update a value of the third identifier stored in the second memory according to the update notification of the first processor
  • the first processor is configured to receive a first packet that is sent by the peer device to negotiate IPSec information, where the first packet carries a first identifier;
  • the first processor is further configured to update a value of the second identifier stored in the first memory, and cause the second processor to back up the value of the second identifier to the second memory.
  • the first identifier is message_id
  • the second identifier is recv_message_id;
  • the third identifier is msgid_bk_f lag ,
  • the initial value of the first identifier and the second identifier are all N, and the initial value of the third identifier is 0.
  • the first processor updates the second identifier stored in the first memory. Value, specifically:
  • the first processor updates a value of the second identifier in the first memory to N+1; the second processor is configured to update the storage in the second memory according to an update notification of the first processor
  • the value of the third identifier is specifically:
  • the second processor updates the value of the third identifier in the second memory to one.
  • the second processor is configured to send a negotiation IPSec to the peer device according to the updated third identifier in the second memory.
  • the second message of the information specifically includes:
  • the second processor sends a second packet for negotiating IPSec information to the peer device, where the value of the first identifier carried in the second packet is N, and The second packet carries the first security association SA;
  • the second processor If the value of the third identifier is 1, the second processor resets the value of the third identifier to 0, updates the value of the second identifier to N, and sends the value to the peer device again.
  • the second packet of the IPSec information is negotiated.
  • the value of the first identifier carried in the second packet is N, and the second packet carries the second SA.
  • the present invention provides a communication system, including the system for IKE message negotiation described in any of the above.
  • the method and system for IKE message negotiation in the embodiment of the present invention update the value of the stored third identifier after receiving the update notification of the active device in the standby device, and then switch to the new device in the standby device.
  • the new primary device sends a second packet for negotiating IPSec information to the peer device according to the updated third identifier, which solves the long-term service caused by the switching between the primary device and the backup device in the prior art.
  • the problem of interruption BRIEF DESCRIPTION OF THE DRAWINGS
  • the drawings to be used in the embodiments will be briefly described below.
  • FIG. 1A and FIG. 1B are interaction scene diagrams of IKEv2 protocol messages
  • Figure 1 C and Figure 1 D are scene diagrams for switching between dual-system hot standby devices
  • 2A is a scenario diagram of a negotiation method used in an embodiment of the present invention.
  • FIG. 2B is a schematic flowchart of a method for IKE message negotiation according to an embodiment of the present invention
  • FIG. 2C is a schematic flowchart of a method for IKE message negotiation according to another embodiment of the present invention
  • FIG. 3 is a schematic flowchart of a method for IKE message negotiation according to another embodiment of the present invention
  • FIG. 4 is a schematic diagram of an IKE message negotiation method according to another embodiment of the present invention
  • FIG. 5A is a schematic flowchart of a method for IKE message negotiation according to another embodiment of the present invention
  • FIG. 5B is a schematic flowchart of a method for IKE message negotiation according to another embodiment of the present invention
  • FIG. 5A is a schematic flowchart of a method for IKE message negotiation according to another embodiment of the present invention
  • FIG. 5B is a schematic flowchart of a method for IKE message negotiation according to another embodiment of the present invention
  • FIG. 6B is a schematic flowchart of a method for IKE message negotiation according to another embodiment of the present invention
  • FIG. 6C is a schematic diagram of a method for IKE message negotiation according to another embodiment of the present invention
  • FIG. 7A is a schematic structural diagram of a system for IKE message negotiation according to another embodiment of the present invention
  • FIG. 7B is another embodiment of the present invention
  • IKE packet structure diagram provided consultation system.
  • a hot standby cluster which backs up two physical devices and performs the same security policy.
  • a hot standby cluster only one device communicates with the peer at any time.
  • the devices in the hot standby cluster need to synchronize a large amount of information and status (such as send_msgid or recv_msgid). If the active/standby switchover occurs in time, the service may be interrupted.
  • the IPSec VPN service involves enterprises or individuals located in different geographical areas. When they communicate through the Internet, most of the traffic between them needs to traverse the unknown network of the Internet because they are in different physical areas. Secure sending and receiving data Sex.
  • the IPSec protocol provides a way for enterprises and users in different physical areas to establish and manage secure tunnels. It provides authentication and encryption services for transmitted data to prevent data from being illegally viewed or tampered with during transmission over the network or over the public network. .
  • the negotiation device needs to have a request message and a response message for each negotiation of the IPSec VPN.
  • the active device sends the first packet (for example, the request packet) to the peer device.
  • the device returns a response packet (for example, a response packet) according to the first packet, so as to implement negotiation of IPSec information between the active device and the peer device.
  • C initiator
  • A responder
  • message 1 slot called msgl
  • A responder
  • message 2 after receiving msgl (memory called msg2)
  • A considers negotiation completed.
  • C receives msg2, it considers that this negotiation is completed. If there is a packet loss in msgl or msg2, C will retransmit msgl within the preset time. After C receives msg2 and considers that the negotiation is completed, or retransmits a certain number of times, it is considered that the negotiation fails.
  • the IKE packet header has a message id field.
  • the initiator and the responder need to match the same message-id field.
  • only the IKE ⁇ ⁇ interaction (exchange) is allowed to be sent at the same time and in the same direction, as shown in Figure 1B.
  • C actively initiates msgl with the message id n, and the send_msgid of C ⁇ is n;
  • A receives msgl2 with message id n after receiving msgl, A thinks the negotiation is completed; recv- msgid is updated to n after A reply +1 ;
  • C After receiving msg2, it is considered that this negotiation is completed, and send_msgid is updated to n+1.
  • C will retransmit msgl with message id n until C receives msg2 with message id of n, or retransmits a certain number of times and considers that the negotiation failed.
  • the message id of B is obtained through instant backup.
  • A the primary device
  • it updates recv_msgid, for example, recv_msgid n+1
  • B backup device
  • B can continue the subsequent interaction of the IKE SA (including informational and rekey) with the recv_msgid of the backup.
  • SA security association
  • the SA hard timeout of the peer device is re-established, and the service can be restored in a short period of time.
  • the SAs of the two parties are inconsistent and the service is interrupted.
  • RFC631 1 proposes a solution to the above problem, and the standby member as a new active member needs to send a message and the peer re-negotiates a new pair of message ids as a follow-up.
  • the message id of the message is used; the ability to synchronize the message id is first negotiated by the IKEV2 - MESSAGE_ID - SYNC - SUPPORTED payload, and the specific message id value is negotiated through the IKEV2 - MESSAGEJD - SYNC payload.
  • both parties to the negotiation need to support this ability to synchronize the message id, and support the following two types of payloads: IKEV2 - MESSAGE - ID - SYNC - SUPPORTED and I KEV2_M ESS AG E - I D - S YNC.
  • the IKE packet negotiation method in the embodiment of the present invention is mainly applied to the IKEv2/IPSec hot standby scenario.
  • the active device fails, and the active device and the standby device are faulty.
  • the standby member is switched, and the standby device becomes the new active device. How to implement the service between the new primary backup device and the remote device does not occur for a long time when the new primary device negotiates with the remote device. The problem.
  • an embodiment of the present invention provides a method for IKE message negotiation, where the method includes:
  • the standby device updates the value of the stored third identifier according to the update notification of the primary device, and the update notification of the primary device is sent after the primary device updates the stored value of the second identifier;
  • the new primary device is updated according to the third
  • the second packet that sends the negotiated IPSec information to the peer device is identified.
  • the foregoing third identifier is an identifier stored in the standby device for obtaining status information of the active device.
  • the IKE message negotiation method in the foregoing embodiment enables the backup device to obtain the status information of the active device by using the value of the stored third identifier, and when the standby device switches to the new active device, the new active device can be The updated third identifier sends a second packet that negotiates IPSec information to the peer device.
  • FIG. 2A is a flowchart of a method for IKE message negotiation according to an embodiment of the present invention
  • FIG. 2B is a schematic flowchart of a method for IKE message negotiation according to an embodiment of the present invention.
  • the method of IKE message negotiation in the embodiment is as follows.
  • the primary device sends a first packet for negotiating IPSec information to the peer device, where the value of the first identifier carried in the first packet is N (N is a natural number).
  • the first identifier carried in the first packet is message_id.
  • the primary device updates the stored value of the second identifier.
  • the second identifier identifies an identifier stored in the primary device for learning status information of the primary device. That is to say, before the send_message_id of the active device is not updated, the second identifier that can record the intermediate state of the active device can be set.
  • the second identifier in this embodiment can be next_send msg- Id.
  • the backup device updates the value of the stored third identifier according to the update notification of the active device, where the update notification of the active device is sent after the primary device updates the value of the stored second identifier, where the third identifier is An identifier stored in the backup device for learning status information of the primary device.
  • the status information of the master device may be information of the intermediate state of the master device. It can be understood that, at present, the active device backs up the value of the send_message_id and the value of the recv_message_id to the standby device, and the information of the intermediate state of the active device cannot be backed up to the standby device, so
  • the identifier of the information about the intermediate state of the active device can be set in the standby device, and the standby device can know the state of the active device in time when the active/standby switchover is implemented.
  • the third identifier inside the standby device is: next_sendmsg_id.
  • the third identifier may be inconsistent with the second identifier, and the embodiment is merely an example.
  • the new primary device sends a second packet that negotiates IPSec information to the peer device according to the updated third identifier, where the second packet carries the second packet.
  • the value of an identifier is N+1. (N is a natural number)
  • the foregoing method for IKE message negotiation may further include step 205, which is not shown in the following figure.
  • the new active device confirms whether the negotiation is completed.
  • the IKE packet negotiation between the new active device and the peer device is considered complete.
  • the backup device when the backup device and the active device are switched, the backup device can obtain the status information of the active device according to the identifier of the stored third packet, and then can send the peer device to the peer device in time.
  • the packets are parsed. As a result, the negotiation between the new active device and the peer device is normal. The service is not affected.
  • the IKE message negotiation method may include the foregoing steps 201 to 204, in order to prevent the service interruption between the backup device and the peer device after the backup device is switched to the active device, and the method for IKE message negotiation may include the foregoing steps 201 to 204, and After step 204, step 205a, not shown in the following figure, may also be included:
  • the new primary device sends a third packet that negotiates IPSec information to the peer device, where the value of the first identifier carried in the third packet is different from the value of the first identifier carried in the second packet.
  • the value of the first identifier carried in the third packet may be the value of the first identifier in the packet sent by the standby device when negotiating with the peer device for the first time.
  • the foregoing second packet and the third packet further include one of the following information: renegotiating IPSec information, deleting a link, creating a new link, and exchanging a message.
  • the second device after the switch is switched to the new active device, the second device sends the second packet and the third packet, so that the peer device can identify/parse the second packet.
  • a packet in the packet and the third packet can effectively prevent the service interruption between the new active device and the peer device.
  • 2C is a schematic flowchart of a method for IKE message negotiation according to an embodiment of the present invention, as shown in the following figure.
  • the method for IKE message negotiation in this embodiment is as follows.
  • the primary device stores the send_message_id and Recv— message— id;
  • the primary device and the remote device exchange IKE packets for negotiation, and the active device and the peer device are at a certain interval. After that, a new negotiation will be conducted again.
  • the primary device sends the first packet to the peer device (the identifier carried in the first packet is the first identifier), and after receiving the reply message returned by the peer device, the internal_send_message_id of the active device
  • the primary device is further provided with a second identifier for obtaining status information of the active device, that is, the second identifier is used to identify the identifier of the intermediate state information of the primary device, next— Sendmsg—id;
  • the internal device has a third identifier, next—sendmsg—id, which is used to identify the information of the intermediate state of the active device.
  • the initial value of the first identifier, the initial value of the second identifier, and the initial value of the third identifier are the same, and are all natural numbers N.
  • VRRP Virtual Router Redundancy Protocol
  • HRP Huawei Redundancy Protocol
  • VRRP and/or HRP protocols enable switching between primary and backup devices. This embodiment is only for exemplifying the switching between the active device and the standby device. The switching may be performed in any of the existing switching modes, which is not limited in this embodiment.
  • the method for IKE message negotiation in this embodiment may further include the following step 205a'.
  • the new primary device sends a third packet for negotiating IPSec information to the peer device, where
  • the foregoing second request message and the third request message further include one of the following information:
  • Re-negotiate IPSec information delete links, create new links, and exchange messages.
  • the IKE message negotiation method in the embodiment of the present invention updates the value of the stored third identifier after receiving the update notification of the active device in the standby device, and then switches the standby device to the new primary device.
  • the new active device sends a second packet for negotiating IPSec information to the peer device according to the updated third identifier, which solves the problem that the service is interrupted for a long time due to the switching between the active device and the standby device in the prior art. problem.
  • FIG. 3 shows a schematic flowchart of a method for IKE message negotiation according to an embodiment of the present invention.
  • the method for IKE message negotiation in this embodiment is as follows.
  • the primary device stores next_send_msgid and send_msgid, and the initial value of the send_msgid is the same as the initial value of the next_send_msgid, and is N; the next device stores the next_send_msgid , next— send— The initial value of msgid is also N.
  • the new active device checks whether the value of the internal send_msgid is consistent with the value of the next-send_msgid. If not, go to step 307. Otherwise, go to step 308.
  • step 306 If the value of send_msgid in step 306 does not match the value of next_send_msgid, send the second packet and the third packet to the peer device.
  • the second device and the third packet are sent to enable the peer device to identify/parse one of the packets, so as to prevent the peer device from identifying/parsing the request packet sent by the new Active member. The phenomenon appears.
  • the second packet and the third packet may include information for re-negotiating the IPSec information, so that the peer device renegotiates the new SA with the new active device after receiving the packet.
  • send_msgid in step 306 If the value of send_msgid in step 306 is consistent with the value of next_send_msgid, send a third packet to the peer device.
  • the value of the word-send_msgid and the value of the next-send-msgid+1--the new primary device will send the IKE negotiation request message normally, and the second message may not be sent. It is only necessary to send the message that the new primary device is currently sending directly.
  • the packet sequence number is sent twice to ensure that the peer device can correctly process the packets sent by the new master device.
  • the subsequent negotiation may be performed. It can no longer be carried out, resulting in a long-term business interruption.
  • FIG. 4 shows a schematic flowchart of a method for IKE message negotiation according to an embodiment of the present invention.
  • the method for IKE message negotiation in this embodiment is as follows.
  • the primary device receives the first packet that is sent by the peer device to negotiate the IPSec information, where the first packet carries the first identifier.
  • the primary device updates a value of the second identifier stored therein, and causes the standby device to back up the value of the second identifier.
  • the primary device sends an update notification to the backup device after updating the stored value of the second identifier, and the standby device updates the value of the stored third identifier according to the update notification of the active device, where the third identifier is the standby device.
  • the stored identifier for knowing the status information of the primary device.
  • the primary device and the standby device switch, and the standby device switches to the new primary device.
  • the new active device sends a second packet for negotiating IPSec information to the peer device according to the updated third identifier. If the value of the third identifier is 0, the second packet that is used to negotiate the IPSec information is sent to the peer device, where the value of the first identifier carried in the second packet is N, and the second packet is in the second packet. Carrying the first SA;
  • the value of the third identifier is 1, the value of the third identifier is reset to 0, the value of the second identifier is updated to N, and the second device that negotiates IPSec information is resent to the peer device.
  • the packet has a value of N for the first identifier carried in the second packet, and the second packet carries the second SA.
  • the first identifier may be message_id; the second identifier may be recv_message_id; the third identifier may be msgid_bk_flag,
  • the initial value of the first identifier and the second identifier are both N (N is a natural number), and the initial value of the third identifier is 0.
  • step 402 the active device may update the stored value of the second identifier to N+1; in step 403, the standby device may update the value of the stored third identifier to 1.
  • the device when the backup device is switched to the new active device, the device can send a packet to the peer device according to the value of the third identifier, so that the packet sent by the new master device can be made to the opposite end.
  • the subsequent negotiation may no longer be performed, resulting in a long-term service interruption.
  • FIG. 5a is a schematic flowchart of a method for IKE message negotiation according to an embodiment of the present invention.
  • the method for IKE message negotiation in this embodiment is as follows.
  • the primary device has a send_message_id and a recv_message_id, and the initial values may be N, and N is a natural number.
  • the primary device and the remote device exchange IKE packets for negotiation, and the active device and the peer device are at a certain interval. New negotiations after the time.
  • the first packet carries the first identifier, message_id.
  • the receiving identifier recv_message_id inside the active device is the second identifier
  • the third identifier msgid_bk_flag is set inside the standby device; the initial value of the third identifier is 0.
  • a third identifier that is, a msgid_bk_flag, may also be set in the active device.
  • the primary device and the standby device switch, and the standby device switches to the new primary device.
  • the second packet that is used to negotiate the IPSec information is sent to the peer device, where the value of the first identifier carried in the second packet is N, and the second packet carries the first SA.
  • the value of the third packet identifier is 1, the value of the third identifier is reset to 0, the value of the second identifier is updated to N, and the negotiated IPSec information is sent to the peer device again.
  • the second packet carries the value of the first identifier carried in the second packet, and the second packet carries the second SA.
  • the first SA and the second SA are different, and the first SA may be an SA pre-transmitted by the original primary device.
  • the third identifier is an identifier that is set in the backup device for obtaining state information of the active device.
  • FIG. 5B is a schematic flowchart of a method for IKE message negotiation according to an embodiment of the present invention.
  • the method for IKE message negotiation in this embodiment is as follows.
  • the initial value of recv_message_id is N.
  • the active device returns a response packet, that is, the second packet, to the peer device.
  • the primary device and the standby device switch, and the standby device switches to the new primary device.
  • the switching between the primary device and the standby device may occur during the processing of the received message by the primary device, or after the primary device has finished processing the received message.
  • the corresponding processing is executed according to the timing at which the switching occurs.
  • the new active device When the switchover occurs, if the value of the third identifier is 0 (that is, after the original active device finishes processing the received packet, it is in a stable state), the new active device re-sends the negotiated IPSec information to the peer device. a second packet, where the value of the first identifier carried in the second packet is N, and the second packet carries the first SA, where the first SA is synchronized by the original active device to the new active device. middle;
  • the new active device If the value of the third identifier is 1 (ie, the original active device processes the received message in the intermediate state), the new active device resets the value of the third identifier to 0. And updating the value of the second identifier to N, and generating a third packet, where the value of the first identifier carried in the third packet is N, and the third packet carries the second SA.
  • the IKE packet negotiation method in this embodiment improves the high reliability of the IPSec hot standby. After the negotiation of the message id of the IKEv2 in the negotiation process of the prior art, the subsequent negotiation may no longer be possible. The problem is that the service is interrupted for a long period of time, and the two parties negotiate to ensure that the subsequent negotiations are carried out normally.
  • FIG. 6A is a flowchart of a method for IKE message negotiation
  • FIG. 6B is a schematic flowchart of a method for IKE message negotiation according to an embodiment of the present invention.
  • the method of message negotiation is as follows.
  • the identifier of the msgid_bk_flag that is, the third identifier is simultaneously added to the active device and the standby device.
  • C peer device Initiate msgl (first message) to A (primary device), messagegl is included in msgl, and the value of message id is 0.
  • the value of msgid_bk_flag is updated: The initial value of msgid_bk_flag is increased. 1. Where msgid—bk—flag has an initial value of 0, and recv—the initial value of msgid is N (N is a natural number).
  • B After receiving the msgl sent by C, B checks whether the value of the message id is consistent with the value of the stored recv_msgid. If it is determined that the value of the message id is smaller than the value of recv_msgid, it is determined that msgl is a retransmission message.
  • msgid_bk_flag is determined. If the value of msgid_bk_flag is 1, the value of the original recv_msgid is decremented by one, that is, the initial value of 'f gray complex recv_msgid, and ⁇ 1 msgid- Bk_flag is set to 0, a new SA2 is generated (such as SA2 in FIG. 6A, ie, the second SA), and a response message is sent to C (such as msgO in FIG. 6A);
  • the value of msgid_bk_flag is determined. If the value of msgid_bk_flag is 0, the response message sent when B is used as the primary device is retransmitted, and the response message is a response message that the new primary device should send.
  • the response message includes SA1 (ie, the first SA).
  • C receives the response message of msgl, updates the value of send_msgid, generates SA2, and succeeds in negotiation.
  • FIG. 6C is a schematic flowchart of a method for IKE message negotiation according to an embodiment of the present invention.
  • the method for IKE message negotiation in this embodiment is as follows.
  • the identifier of the msgid_bk_flag that is, the third identifier is added to the standby device.
  • C peer device
  • msgl first message
  • A primary device
  • msgl contains message id
  • message id is N.
  • the value of msgid_bk_flag is updated: the value of msgid_bk_flag is set to 1.
  • msgid—bk—flag has an initial value of 0, and recv—the initial value of msgid is N (N is a natural number).
  • step 614 If the active/standby switchover does not occur at this time, proceed to 613. If the active/standby switchover occurs, the process proceeds to step 614.
  • A returns a response message msg2 to the peer device.
  • A waits to receive the next request packet sent by C, and performs the same processing as 611 on the next request packet sent by C, and details are not described herein again.
  • the processing cycle of a packet is used as an example to describe the active/standby switchover of different P segments. If the active/standby switchover occurs, the process proceeds to step 618.
  • B After receiving the msgl of C retransmission, B checks whether the value of the message id is consistent with the value of the stored recv_msgid. If it is determined that the value of the message id (N) is less than the value of recv_msgid (N+1), Then determine msgl as a retransmission message.
  • B judges the value of msgid_bk_flag. If the value of msgid_bk_flag is 1, the msgid_bk_flag is set to 0, and the value of msgid is reduced by one, that is, 'I' gray Complex recv - the initial value N of msgid, generates SA2 (such as SA2 in Figure 6A, that is, the second SA), and sends a response message to C to carry SA2, such as msg3.
  • SA2 such as SA2 in Figure 6A, that is, the second SA
  • C receives the response message msgl3 of msgl, updates the value of send_msgid, generates SA2, and the negotiation succeeds.
  • the B After receiving the msgl sent by C, the B checks whether the value of the msgl message id is the same as the value of the stored recv_msgid, if the value of the msgl message id (N) is less than Recv - the value of msgid ( N+1 ), then determines that msgl is a retransmitted message.
  • B generates msg2, and retransmits the response message msg2 sent by A as the primary device, and the response message includes SA1 (ie, the first SA) synchronized from A.
  • the active/standby switchover may cause the msgid in the SAs of the two parties to be mismatched and the service is interrupted.
  • the present invention further provides a system for IKE message negotiation.
  • the system for IKE message negotiation includes: a primary device 71 and a backup device 72.
  • the device 71 includes: a first processor 711 and a first memory 712;
  • the backup device 72 includes: a second processor 721 and a second memory 722;
  • first memory 712 stores the second identifier
  • second memory 722 stores the third identifier
  • the second processor 721 is configured to update, according to the update notification of the first processor 711, a value of the third identifier stored in the second memory 722, where the update notification of the first processor 711 is the a processor 711, after updating the value of the second identifier stored in the first memory 712, sent;
  • the second processor 721 is configured to send a second packet that negotiates IPSec information to the peer device according to the updated third identifier in the second memory 722.
  • the third identifier in the second memory is an identifier for obtaining status information of the active device.
  • the second processor 721 is used to update the notification according to the first processor 711. Before updating the value of the third identifier stored in the second memory 722,
  • the first processor 711 is configured to send, to the peer device, a first packet that negotiates IPSec information, where the first packet carries a first identifier.
  • the first processor 711 is further configured to update a value of the second identifier stored in the first memory 712;
  • the second identifier is an identifier for obtaining status information of the primary device 71.
  • the first identifier is message_id; the second identifier is next_sendmsg_id; The third identifier is next_sendmsg_id.
  • the initial value of the first identifier, the initial value of the second identifier, and the initial value of the third identifier are the same, and are both N;
  • the first processor 711 is further configured to update a value of the second identifier stored in the first memory 712, specifically:
  • the first processor 711 is further configured to update the value of the second identifier in the first memory 712 to N+1;
  • the second processor 721 is configured to update the value of the third identifier stored in the second memory 722 according to the update notification of the first processor 711, specifically:
  • the second processor 721 updates the value of the third identifier in the second memory 722 to
  • the second processor 721 is configured to send, according to the updated third identifier in the second memory 722, a second packet that negotiates IPSec information to the peer device, specifically:
  • the second processor 722 sends a second packet for negotiating IPSec information to the peer device, where the value of the first identifier carried in the second packet is N+1.
  • the second processor 721 is further configured to send, to the peer device, a third packet that negotiates IPSec information, where the value of the first identifier carried in the third packet is N.
  • the subsequent negotiation may be no longer possible when the values of the first identifiers of the two parties in the IKEV2 negotiation process are inconsistent. Conducting problems that cause long periods of business disruption.
  • the second processor 721 is configured to update according to the first processor 711. Before notifying the update of the value of the third identifier stored in the second memory 722,
  • the first processor 711 is configured to receive a first packet that is sent by the peer device to negotiate IPSec information, where the first packet carries a first identifier.
  • the first processor 711 is further configured to update a value of the second identifier stored in the first memory 712, and cause the second processor 721 to back up the value of the second identifier to the second memory 722.
  • the first identifier is a message_id;
  • the second identifier is a recv_message_id;
  • the third identifier is a msgid_bk_flag, and the first identifier and the initial value of the second identifier are both N, the initial value of the third identifier is 0;
  • the first processor 711 updates the value of the second identifier stored in the first memory 712, specifically:
  • the first processor 711 updates the value of the second identifier in the first memory 712 to N+1;
  • the second processor 721 is configured to update the value of the third identifier stored in the second memory 722 according to the update notification of the first processor 711, specifically:
  • the second processor 721 updates the value of the third identifier in the second memory 722 to 1. Further, the second processor 721 is configured to send a second packet that negotiates IPSec information to the peer device according to the third identifier that is updated in the second memory 722, and specifically includes:
  • the second processor 721 resends the second packet that negotiates the IPSec information to the peer device, where the value of the first identifier carried in the second packet is N, and The second packet carries the first security association SA;
  • the second processor 721 If the value of the third identifier is 1, the second processor 721 resets the value of the third identifier to 0, updates the value of the second identifier to N, and redirects the device to the peer device. And sending a second packet that negotiates the IPSec information, where the value of the first identifier carried in the second packet is N, and the second packet carries the second SA.
  • the subsequent negotiation may be no longer possible when the values of the first identifiers of the two parties in the IKEV2 negotiation process are inconsistent. Conducting problems that cause long periods of business disruption.
  • an embodiment of the present invention further provides a communication system, including the system for IKE message negotiation described in any of the foregoing.
  • the aforementioned program can be stored in a computer readable storage medium.
  • the program when executed, performs the steps including the foregoing method embodiments; and the foregoing storage medium includes: a medium that can store program codes, such as a ROM, a RAM, a magnetic disk, or an optical disk.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

一种IKE报文协商的方法及系统,所述方法包括:备用设备根据主用设备的更新通知更新存储的第三标识的值,所述主用设备的更新通知为所述主用设备更新存储的第二标识的值之后发送的;在备用设备切换为新的主用设备时,所述新的主用设备根据更新的第三标识向对端设备发送协商互联网协议安全性IPSec信息的第二报文;其中,所述第三标识为所述备用设备中存储的用于获知所述主用设备的状态信息的标识。上述方法解决了现有技术中由于主用设备和备用设备的切换导致的业务长时间中断的问题。

Description

IKE报文协商的方法及系统 本申请要求于 2012 年 10 月 12 日提交中国专利局、 申请号为 201210387149.0、发明名称为 "IKE报文协商的方法及系统"的中国专利申请、 以及 2013年 9月 29 日递交中国专利局、 申请号为 201310459948.9、 发明名 称为 "IKE报文协商的方法及系统" 的中国专利申请的优先权, 其全部内容 通过引用结合在本申请中。 技术领域
本发明实施例涉及通信技术,尤其涉及一种 IKE( Internet Key Exchange ) 报文协商的方法及系统。
背景技术 密钥交换协议第二版 ( Internet Key Exchange Protocol Version 2, 筒称 IKEv2 ) , 用来进行虚拟专用网 ( Virtual Private Network, 筒称 VPN ) 中安 全联盟(Security Association, 筒称 SA ) 的认证与密钥的协商, 为 VPN中 通信双方协商因特网协议安全( IP Security, 筒称 IPSec )通信所需要的相关 信息, 如加密算法、 会话密钥、 通信双方身份认证等。
IKEv2的十办商分为 initial交换, auth交换, create child交换, informational 交换, 每一 IKEv2报文的报文头都包含一个 message id 字段(报文标识) , 这个字段用来标识 文的序号。
通常, 通信双方保存有两个 message id : 发起一个请求报文时使用 send— message— id (筒称 send— msgid ) 、 期望收到的 艮文的 messsage id 为 recv— messsage— id (筒称 recv— msgid ) 。 通信发起方发送了一个 message— id 的请求 ( request ) 艮文并且收到了这个请求 艮文的回应 ( response )消息后, 则该设备中的 send— message— id+1。 通信任意一方每 收到一个请求报文, 则该设备中的 recv— messsage— id+ 1。
在 IPSec双机热备场景中, 主用设备 ( active member )是当前正在与对 端设备 ( peer device )通信的设备, 备用设备 ( standby member )为主用设 备的备份设备。 当主用设备与对端设备的通信链路出现故障时, 备用设备转 换为新的主用设备继续与对端通信。
如果主用设备正在与对端设备进行 IKEv2协商, 此时主用设备与对端设 备之间的通信链路出现故障, 备份设备转换为新的主用设备, 此时原主用设 备中的标识信息还没有及时备份给备用设备, 那么备用设备中的 Message id 有可能与主用设备中的 message id不一致,此时与对端设备的通信有可能因 为 message id的错误而中断。
例如, 在 IKEv2协商过程中, 主用设备向对端设备发出 msgl 后, 主用 设备与备用设备发生切换,主用设备的 send— msgid的更新信息还没有及时备 份给备用设备, 这样备用设备转换为新的主用设备, send— msgid尚未更新, 进而上述新的主用设备与对端设备之间的协商过程中会产生 message— id 不 匹配问题, 导致业务长时间中断。 发明内容 有鉴于此, 本发明提供一种 IKE报文协商的方法及系统, 用以解决现有 技术中由于主用设备和备用设备的切换导致的业务长时间中断的问题。
第一方面, 本发明实施例提供一种 IKE报文协商的方法, 包括: 备用设备根据主用设备的更新通知更新存储的第三标识的值, 所述主用 设备的更新通知为所述主用设备更新存储的第二标识的值之后发送的;
在备用设备切换为新的主用设备时, 所述新的主用设备根据更新的第三 标识向对端设备发送协商互联网协议安全性 IPSec信息的第二报文;
其中, 所述第三标识为所述备用设备中存储的用于获知所述主用设备的 状态信息的标识。
结合第一方面, 在一种可能的实现方式中, 所述备用设备根据主用设备 的更新通知更新内部第三标识的值的步骤之前, 还包括:
主用设备向所述对端设备发送协商 IPSec信息的第一报文, 所述第一报 文中携带有第一标识;
所述主用设备更新存储的第二标识的值;
其中, 所述第二标识为所述主用设备中存储的用于获知所述主用设备的 状态信息的标识。
结合第一方面及上述第一种的实现方式中, 在第二种可能的实现方式中, 所述第一标识为 message— id; 所述第二标识为 next— sendmsg— id;
所述第三标识为 next— sendmsg— id;
所述第一标识的初始值、 所述第二标识的初始值和所述第三标识的初始 值相同, 且均为 N;
相应地, 所述主用设备更新存储的第二标识的值, 具体为:
所述主用设备将存储的第二标识的值更新为 N+1 ;
所述备用设备根据主用设备的更新通知更新存储的第三标识的值, 具体 为:
所述备用设备将存储的第三标识的值更新为 N+1。
结合第一方面及上述第二种的实现方式中, 在第三种可能的实现方式中, 所述新的主用设备根据更新的第三标识向对端设备发送协商 IPSec信息的第 二报文, 具体为:
所述新的主用设备向对端设备发送协商 IPSec信息的第二报文, 所述第 二报文中携带的第一标识的值为 N+1。
结合第一方面及上述可能的实现方式中, 在第四种可能的实现方式中, 上述方法还包括:
所述新的主用设备向对端设备发送协商 IPSec信息的第三报文, 所述第 三报文中携带的第一标识的值为 N。
结合第一方面, 在第五种可能的实现方式中, 所述备用设备根据主用设 备的更新通知更新内部第三标识的值的步骤之前, 还包括:
所述主用设备接收所述对端设备发送的协商 IPSec信息的第一报文, 所 述第一报文中携带有第一标识;
所述主用设备更新其存储的第二标识的值, 并使所述备用设备备份所述 第二标识的值。
结合第一方面及第五种可能的实现方式中, 在第六种可能的实现方式中, 所述第一标识为 message— id;
所述第二标识为 recv— message— id;
所述第三标识为 msgid— bk— f lag ,
所述第一标识、所述第二标识初始值均为 Ν,所述第三标识的初始值为 0; 相应地, 所述主用设备更新存储的第二标识的值, 具体为:
所述主用设备将存储的第二标识的值更新为 Ν+1 ; 所述备用设备根据所述主用设备的更新通知更新内部第三标识的值, 具 体为:
所述备用设备将存储的第三标识的值更新为 1。
结合第一方面及第六种可能的实现方式中, 在第七种可能的实现方式中, 所述新的主用设备根据更新的第三标识向对端设备发送协商 IPSec信息的第 二报文, 具体包括:
若第三标识的值为 0, 则重新向对端设备发送协商 IPSec信息的第二报 文, 所述第二报文中携带的第一标识的值为 N, 且所述第二报文中携带第一 SA;
若第三标识的值为 1 , 则将所述第三标识的值重置为 0, 将所述第二标识 的值更新为 N, 并重新向所述对端设备发送协商 IPSec信息的第二报文, 所 述第二报文中携带的第一标识的值为 N, 所述第二报文携带第二 SA。
第二方面, 本发明实施例还提供一种 IKE报文协商的系统, 包括: 主用 设备和备用设备,
所述主用设备包括: 第一处理器和第一存储器; 所述备用设备包括: 第 二处理器和第二存储器;
所述第二处理器用于根据所述第一处理器的更新通知更新所述第二存储 器中存储的第三标识的值, 所述第一处理器的更新通知为所述第一处理器更 新所述第一存储器中存储的第二标识的值之后发送的;
在所述备用设备切换为新的主用设备时, 所述第二处理器用于根据所述 第二存储器中更新的第三标识向对端设备发送协商互联网协议安全性 I PSec 信息的第二报文;
其中, 所述第二存储器中的第三标识为用于获知所述主用设备的状态信 息的标识。
结合第二方面, 在第一种可能的实现方式中, 所述第二处理器用于根据 所述第一处理器的更新通知更新所述第二存储器中存储的第三标识的值之 前,
所述第一处理器用于向所述对端设备发送协商 IPSec信息的第一报文, 所述第一报文中携带有第一标识;
所述第一处理器还用于更新存储在所述第一存储器中的第二标识的值; 其中, 所述第二标识为用于获知所述主用设备的状态信息的标识。 结合第二方面及上述第一种可能的实现方式中, 在第二种可能的实现方 式中, 所述第一标识为 message— id;
所述第二标识为 next— sendmsg— id;
所述第三标识为 next— sendmsg— id;
所述第一标识的初始值、 所述第二标识的初始值和所述第三标识的初始 值相同, 且均为 N;
相应地, 所述第一处理器还用于更新存储在所述第一存储器中的第二标 识的值, 具体为:
所述第一处理器还用于将所述第一存储器中的第二标识的值更新为 N+1 ;
所述第二处理器用于根据所述第一处理器的更新通知更新所述第二存储 器中存储的第三标识的值, 具体为:
所述第二处理器将所述第二存储器中的第三标识的值更新为 N+1。
结合第二方面及上述第二可能的实现方式, 在第三种可能的实现方式中, 所述第二处理器用于根据所述第二存储器中更新的第三标识向对端设备发送 协商 IPSec信息的第二报文, 具体为:
所述第二处理器向对端设备发送协商 IPSec信息的第二报文, 所述第二 报文中携带的第一标识的值为 N+1。
结合第二方面及上述可能的实现方式中, 在第四种可能的实现方式中, 所述第二处理器还用于向所述对端设备发送协商 IPSec信息的第三报文, 所 述第三报文中携带的第一标识的值为 N。
结合第二方面, 在第五种可能的实现方式中, 所述第二处理器用于根据 所述第一处理器的更新通知更新所述第二存储器中存储的第三标识的值之 前,
所述第一处理器用于接收所述对端设备发送的协商 IPSec信息的第一报 文, 所述第一报文中携带有第一标识;
所述第一处理器还用于更新所述第一存储器中存储的第二标识的值, 并 使所述第二处理器向第二存储器中备份所述第二标识的值。
结合第二方面及上述第五种可能的实现方式, 在第六种可能的实现方式 中, 所述第一标识为 message— id;
所述第二标识为 recv— message— id; 所述第三标识为 msgid— bk— f lag ,
所述第一标识、所述第二标识初始值均为 N,所述第三标识的初始值为 0; 相应地, 所述第一处理器更新所述第一存储器中存储的第二标识的值, 具体为:
所述第一处理器将所述第一存储器中的第二标识的值更新为 N+1; 所述第二处理器用于根据所述第一处理器的更新通知更新所述第二存储 器中存储的第三标识的值, 具体为:
所述第二处理器将所述第二存储器中的第三标识的值更新为 1。
结合第二方面及上述第六种可能的实现方式, 在第七种可能的实现方式 中, 所述第二处理器用于根据所述第二存储器中更新的第三标识向对端设备 发送协商 IPSec信息的第二报文, 具体包括:
若第三标识的值为 0,则所述第二处理器重新向对端设备发送协商 IPSec 信息的第二报文, 所述第二报文中携带的第一标识的值为 N, 且所述第二报 文中携带第一安全联盟 SA;
若第三标识的值为 1 , 则所述第二处理器将所述第三标识的值重置为 0, 将所述第二标识的值更新为 N, 并重新向所述对端设备发送协商 IPSec信息 的第二报文, 所述第二报文中携带的第一标识的值为 N, 所述第二报文携带 第二 SA。
第三方面, 本发明还提供一种通信系统, 包括上述任一所述的 IKE报文 协商的系统。
由上述技术方案可知, 本发明实施例的 IKE报文协商的方法及系统, 通 过备用设备中在接收主用设备的更新通知之后更新存储的第三标识的值, 进 而在备用设备切换为新的主用设备时, 新的主用设备根据更新的第三标识向 对端设备发送协商 IPSec信息的第二报文, 解决了现有技术中由于主用设备 和备用设备的切换导致的业务长时间中断的问题。 附图说明 为了更清楚地说明本发明的技术方案, 下面将对实施例中所需要使用的 附图作一筒单地介绍, 显而易见地: 下面附图只是本发明的一些实施例的附 图, 对于本领域普通技术人员来讲, 在不付出创造性劳动性的前提下, 还可 以根据这些附图获得同样能实现本发明技术方案的其它附图。 图 1 A和图 1 B为 IKEv2协议消息的交互场景图;
图 1 C和图 1 D为双机热备设备切换的场景图;
图 2A为本发明实施例所使用的协商方法的场景图;
图 2B为本发明一实施例提供的 IKE报文协商的方法的流程示意图; 图 2C为本发明另一实施例提供的 IKE报文协商的方法的流程示意图; 图 2D为本发明另一实施例提供的 IKE报文协商的方法的流程示意图; 图 3为本发明另一实施例提供的 IKE报文协商的方法的流程示意图; 图 4为本发明另一实施例提供的 IKE报文协商的方法的流程示意图; 图 5A为本发明另一实施例提供的 IKE报文协商的方法的流程示意图; 图 5B为本发明另一实施例提供的 IKE报文协商的方法的流程示意图; 图 6A为本发明另一实施例提供的 IKE报文协商的方法的场景图; 图 6B为本发明另一实施例提供的 IKE报文协商的方法的流程示意图; 图 6C为本发明另一实施例提供的 IKE报文协商的方法的流程示意图; 图 7A为本发明另一实施例提供的 IKE报文协商的系统的结构示意图; 图 7B为本发明另一实施例提供的 IKE报文协商的系统的结构示意图。 具体实施方式 为使本发明的目的、 技术方案和优点更加清楚, 下面将结合本发明实施 例中的附图, 对本发明的技术方案进行清楚、 完整地描述。 显然, 下述的各 个实施例都只是本发明一部分的实施例。 基于本发明下述的各个实施例, 本 领域普通技术人员即使没有作出创造性劳动, 也可以通过等效变换部分甚至 全部的技术特征, 而获得能够解决本发明技术问题, 实现本发明技术效果的 其它实施例, 而这些变换而来的各个实施例显然并不脱离本发明所公开的范 围。
双机热备集群( Hot standby cluster ) , 两台物理设备之相互备份, 执行 相同的安全策略。 在双机热备集群内, 任何时间都只有一个设备与对端通信; 双机热备集群内各设备之间需要同步大量的信息和状态 (如 send— msgid 或 recv_ msgid ) ,设备之间同步不及时在出现主备切换时可能会引起业务中断。
IPSec VPN业务涉及分布于不同地域的企业或个人,当他们通过 Internet 进行通信时, 由于处于不同的物理地域, 他们之间进行通信的绝大部分流量 都需要穿越 Internet 的未知网络, 无法保证在网络上发送和接收数据的安全 性。 IPSec协议能够为处于不同物理地域的企业和用户提供一种建立和管理 安全隧道的方式, 对传输的数据提供认证和加密等服务, 防止数据在网络内 或通过公网传输时被非法查看或篡改。
现有技术中, 协商双方针对 IPSec VPN的每次协商需要有一个 request 报文和一个 response报文, 例如, 主用设备向对端设备发送第一报文(如, request报文) , 对端设备根据所述第一报文返回响应报文(如, response 报文) , 进而实现主用设备和对端设备之间的 IPSec信息的协商。
举例来说,如图 1 A所示, C(发起方)主动发起 message 1 (筒称 msgl ) , A (响应方 )收到 msgl后回复 message 2 (筒称 msg2 ) , 此时 A认为协商 完成, 当 C收到 msg2后认为本次协商完成。 如果 msgl或 msg2有丢包, C 在预设时间内会重传 msgl ,直到 C收到 msg2后认为本次协商完成,或者重 传一定次数之后认为本次协商失败。
在 IKEv2协商中, IKE报文头中有一个 message id字段, 同一次 IKE协 商的过程中, 发起方和响应方需匹配同一个 message— id字段。 另夕卜, 在同一 时间、 同一方向只允许发送一次 IKE · ^艮文的交互(exchange ) , 如图 1 B所 示。
C主动发起 message id为 n 的 msgl , C 匕时的 send— msgid为 n; A 收到 msgl后会进行回复 message id为 n 的 msg2, A认为协商完成; A回 复后的 recv— msgid 更新为 n+1 ; C 收到 msg2 后认为本次协商完成, send— msgid更新为 n+1。
如果 msgl或 msg2有丢包, C在指定时间内会重传 message id为 n 的 msgl直至 C收到 message id为 n 的 msg2, 或者重传一定次数后认为本次 协商失败。
IPSec双机热备场景中, B的 message id通过即时备份获得。 如图 1 C 所示, A (主用设备) 回复 C 的请求报文后, 更新 recv— msgid , 如, recv_msgid=n+1 , 并发送包括 recv— msgid的备份消息给 B (备份设备) , 以使 B根据备份消息备份 recv_msgid=n+1。 主备设备切换后, B可以使用备 份的 recv— msgid继续此 IKE SA的后续交互 (包括 informational和 rekey ) 。
然而, 如图 1 D所示, C发起 IKE重协商消息 msg1 (msg— id = n), A收 到后认为本次协商成功, 更新 recv— msgid= n+1 , 并将 recv— msgid= η+1备份 到 B; 此时 A与 C之间通信链路中断, 发生主备切换。 C未收到回应报文, 重传 msgl给 B。 B的 recv— msgid为 n+1 , :到 msgl (msg— id = n)后判断十办 商消息中的 msg— id与存储的 recv— msgid不一致, B可能做如下处理: a )不 回应,此时 C与 B之间的协商失败,发起方的安全联盟( security association, 筒称 SA )硬超时删除; b )回应 Informational消息, 此时 C与 B之间的协商 失败, 发起方的 SA硬超时删除; c ) 回应重协商消息(如发送设定 B作为新 的主用设备时的响应消息) , 此时 C与 B之间的 SA协商错误, 导致 C与 B 之间的业务中断。
对于上述 a )和 b ) 两种情况, 对端设备的 SA硬超时重新建立, 业务在 短时间内可以恢复; 对于 c ) 的情况, 协商双方 SA不一致, 业务中断。
另外, 现有技术中, RFC631 1 提出对以上问题的解决方案, 备用设备 ( standby member )作为新的主用设备 ( active member ) 需要发送消息与 对端重协商出一对新的 message id作为后续的报文的 message id使用; 先 通过 IKEV2— MESSAGE—ID— SYNC— SUPPORTED 这个载荷协商这种同步 message id的能力, 再通过 IKEV2—MESSAGEJD— SYNC 载荷协商具体的 message id值。
然而,协商双方都需要支持这种同步 message id 的能力, 支持处理以下 两 种 载 荷 IKEV2— MESSAGE— ID— SYNC— SUPPORTED 和 I KEV2_M ESS AG E— I D— S YNC。
现存得大多设备是无法支持发送和处理这两个载荷的, 进而无法解决上 述业务长时间中断的问题。 如何保证在业务不中断时实现与对端的通信成为 当前需要解决的技术问题。
本发明实施例的 IKE报文协商的方法主要应用在 IKEv2/IPSec双机热备 场景, IKEv2的协商过程中因某些原因主用设备 ( active member )发生了故 障, 主用设备和备用设备(standby member )发生切换, 备用设备变为新的 主用设备, 如何实现在新的主用设备与对端设备协商时, 新的主备用设备和 对端设备之间的业务不会发生长时间中断的问题。
为解决现有技术中的问题, 本发明实施例中提供一种 IKE报文协商的方 法, 该方法包括:
备用设备根据主用设备的更新通知更新存储的第三标识的值, 所述主用 设备的更新通知为所述主用设备更新存储的第二标识的值之后发送的;
在备用设备切换为新的主用设备时, 所述新的主用设备根据更新的第三 标识向对端设备发送协商 IPSec信息的第二报文。
应说明的是, 上述的第三标识为备用设备中存储的用于获知主用设备的 状态信息的标识。
上述实施例中的 IKE报文协商的方法使得备用设备通过存储的第三标识 的值获知主用设备的状态信息, 进而在备用设备切换为新的主用设备时, 新 的主用设备可以根据更新的第三标识向对端设备发送协商 IPSec信息的第二 报文。
结合图 2A和图 2B所示, 图 2A示出了本发明实施例的 IKE报文协商的 方法的场景图,图 2B示出了本发明实施例的 IKE报文协商的方法的流程示意 图, 本实施例中的 IKE报文协商的方法如下所述。
201、主用设备向对端设备发送协商 IPSec信息的第一报文,所述第一报 文中携带的第一标识的值为 N ( N为自然数) 。
举例来说, 在 IKEv2 的协商过程中, 第一报文中携带的第一标识为 message— id。
202、 主用设备更新存储的第二标识的值。
在本实施例中, 第二标识为主用设备中存储的用于获知所述主用设备的 状态信息的标识。 也就是说, 在主用设备的 send— message— id未更新之前, 可以设置能够记录主用设备的中间状态的标识即第二标识, 本实施例中的第 二标识可为 next— send msg— id。
203、备用设备根据主用设备的更新通知更新存储的第三标识的值, 所述 主用设备的更新通知为所述主用设备更新存储的第二标识的值之后发送的, 第三标识为备用设备中存储的用于获知所述主用设备的状态信息的标识。
在本实施例中主用设备的状态信息可为主用设备的中间状态的信息。 可 以理解的是, 当前, 主用设备在稳定状态会将 send— message— id 的值和 recv— message— id 的值备份至备用设备, 而主用设备中间状态的信息无法备 份至备用设备, 所以本实施例中可使备用设备中设置用于获知主用设备的中 间状态的信息的标识, 用以实现主备切换时, 备用设备及时获知主用设备的 状态。
在本实施例中, 备用设备内部的第三标识为: next— sendmsg— id。 当然, 在其他实施例中, 该处第三标识可以与第二标识不一致, 本实施例仅为举例 说明。 204、 在备用设备切换为新的主用设备后, 所述新的主用设备根据更新的 第三标识向对端设备发送协商 IPSec信息的第二报文, 该第二报文中携带的 第一标识的值为 N+1。 ( N为自然数)
在一种可选的应用场景中, 上述的 IKE报文协商的方法还可包括下述的 图中未示出的步骤 205。
205、 所述新的主用设备确认协商是否完成。
举例来说, 若新的主用设备接收到对端设备返回的回复消息, 则可认为 新的主用设备和对端设备之间的 IKE报文协商完成。
在上述实施例中, 在备用设备和主用设备切换时, 由于备用设备可根据 存储的第三报文的标识获知主用设备的状态信息, 进而能够及时的向对端设 备发送对端设备能够解析的报文, 由此, 可以保证新的主用设备和对端设备 的协商正常进行, 业务不受影响。
在一种优选的应用场景中, 为防止备用设备在切换为主用设备之后, 备 用设备和对端设备之间业务中断的问题, IKE报文协商的方法可包括上述的步 骤 201至 204, 且在步骤 204之后, 还可包括如下图中未示出的步骤 205a:
205a, 新的主用设备向对端设备发送协商 IPSec信息的第三报文, 所述 第三报文中携带的第一标识的值与第二报文中携带的第一标识的值不同。
举例来说, 若第二报文中携带的第一标识的值为 N+1 , 如 message— id=N+1 , 则第三报文中携带的第一标识的值为 N , 如 message— id=N。
可以理解的是, 该处第三报文中携带的第一标识的值可为备用设备第一 次与对端设备协商时发送的报文中的第一标识的值。
举例来说, 上述的第二报文和第三报文还包括如下信息中的一种信息: 重协商 IPSec信息、 删除链接、 新建链接和消息交换等。
由此, 本实施例中的 IKE报文协商的方法, 通过备用设备在切换为新的 主用设备之后, 发送第二报文和第三报文, 以使对端设备能够识别 /解析第二 报文和第三报文中的一个报文, 进而可有效防止新的主用设备和对端设备之 间业务中断的问题。
图 2C示出了本发明实施例的 IKE报文协商的方法的流程示意图, 如图
2C所示, 本实施例中的 IKE报文协商的方法如下所述。
根据 IKEv2 协议, 主用设备中存储有 send— message— id 和 recv— message— id;
在主用设备和对端设备之间的链路未发生异常时, 主用设备和对端设备 交互一次 IKE报文, 用以协商 SA, 以及主用设备和对端设备会在间隔一定的 时间之后再次进行新的协商。 在主用设备向对端设备发送第一报文(第一报 文中携带的标识为第一标识) , 且接收到对端设备返回的回复消息之后, 主 用设备内部的 send— message— id的值增力口一, 即 send— message— id=N+1。
在本实施例中, 主用设备内部还设置有用于获知主用设备的状态信息的 第二标识, 也就是说, 该第二标识用于标识主用设备的中间状态的信息的标 识, next— sendmsg— id; 备用设备内部设置有第三标识, next— sendmsg— id, 该第三标识用于获知主用设备的中间状态的信息的标识。
特别地, 第一标识的初始值、 第二标识的初始值、 第三标识的初始值相 同, 均为自然数 N。
201 '、 主用设备向对端设备发送协商 IPSec信息的第一报文, 第一报文 中携带有 message— id=N。
202'、 主用设备更新存储的第二标识的值, 将第二标识的值更新为 N+1 , 即 next— sendmsg— id=N+1。
203'、主用设备向备用设备发送更新第三标识的值的更新通知,备用设备 在接收更新通知之后, 更新内部存储的第三标识的值, 将第三标识的值更新 为 N+1 , 即 next— sendmsg— id=N+1。
204'、在备用设备切换为新的主用设备之后,新的主用设备向对端设备发 送协商 IPSec信息的第二报文, 所述第二报文携带的第一标识的值为 N+1 , message— id=N+1。
需要说明的是, 主用设备和备用设备之间是通过虚拟路由器冗余协议 ( Virtual Router Redundancy Protocol, 筒称 VRRP )和 HRP协议 ( Huawei Redundancy Protocol )交互信息的, 当主用设备发生故障时, 通过 VRRP和 /或 HRP协议可实现主用设备和备用设备的切换。本实施例仅为举例说明主用 设备和备用设备的切换, 该切换可采用现有中的任意切换方式, 本实施例不 对其进行限定。
可选地, 如图 2D所示, 上述步骤 204'和步骤 204之后, 本实施例中的 IKE报文协商的方法还可包括如下的步骤 205a'。
205a'、 新的主用设备向对端设备发送协商 IPSec信息的第三报文, 所述 第三报文中携带的第一标识的值为 N, message— id=N。
举例来说, 上述的第二请求报文和第三请求报文还包括如下信息中的一 种信息:
重协商 IPSec信息、 删除链接、 新建链接和消息交换。
由上述实施例可知, 本发明实施例的 IKE报文协商的方法, 通过备用设 备中在接收主用设备的更新通知之后更新存储的第三标识的值, 进而在备用 设备切换为新的主用设备时, 新的主用设备根据更新的第三标识向对端设备 发送协商 IPSec信息的第二报文, 解决了现有技术中由于主用设备和备用设 备的切换导致的业务长时间中断的问题。
如图 3所示, 图 3示出了本发明实施例的 IKE报文协商的方法的流程示 意图, 本实施例中的 IKE报文协商的方法如下文所述。
301、 主用设备中存储有 next— send— msgid 和 send— msgid , 且 send— msgid的初始值与 next— send— msgid的初始值相同, 均为 N; 备用设 备中存储有 next— send— msgid, next— send— msgid的初始值也为 N。
302、 主用设备向对端设备发送第一报文(request报文), 第一报文中携 带 message— id=N。
303、 主用设备将内部存储的 next— send— msgid 的值更新, 如 next— send— msgid=N+1 , 同时, 向备用设备发送更新 next— send— msgid的更 新通知。
304、 备用设备根据更新通知更新内部存储的 next— send— msgid 的值, 即 next— send— msgid=N+1。
305、若主用设备和对端设备的通信链路发生异常,或主用设备出现故障, 主用设备和备用设备进行切换, 备用设备切换为新的主用设备。
306、 新的主用设备查看内部的 send— msgid 的值与 next— send— msgid 的值是否一致, 若不一致, 则执行步骤 307, 否则, 执行步骤 308。
其中, 备用设备切换为新的主用设备时, 新的主用设备中的 send— msgid=N, next— send— msgid=N+1。
307、 若步骤 306中的 send— msgid的值与 next— send— msgid的值不一 致, 则向对端设备发送第二报文和第三报文。
在本实施例中, 第二报文携带的 message— id=N+1; 第三报文携带的 message— id=N。 需要说明的是, message— id的初始值和 send— msgid的初始值是一致的。 通过发送第二报文和第三报文, 使得对端设备能够识别 /解析上述报文中 的一个, 避免对端设备无法识别 /解析新的 Active member发送的请求报文而 导致的业务中断的现象出现。
通常, 第二报文和第三报文可包括重协商 IPSec信息的信息, 以使对端 设备在接收上述报文之后, 和新的主用设备重新协商新的 SA。
308、 若步骤 306中的 send— msgid的值与 next— send— msgid的值一致, 则向对端设备发送第三报文。
例如, send— msgid=N, next— send— msgid=N, 或者, send— msgid=N+1 , next— send— msgid=N+1。
也就是说, ^口果 send— msgid的值与 next— send— msgid+1的值——致, 么新的主用设备就正常发送 IKE协商的请求报文, 可以不发送第二报文, 只 需要把新的主用设备当前要发送的报文直接发送出去就可以了。
在本实施例中, 在出现上述异常情况时, 备用设备还可以采用两次探测 的方法, 可以优先使用携带 message— id=N+1作为报文序列号发送, 再使用 message— id=N 作为报文序列号发送两次探测, 确保对端设备能正确处理新 的主用设备发送的报文, 解决了现有技术的 IKEv2的协商过程中的协商双方 message id不一致情况后, 后续的协商可能再也无法进行, 导致长时间的业 务中断的问题。
如图 4所示, 图 4示出了本发明实施例的 IKE报文协商的方法的流程示 意图, 本实施例中的 IKE报文协商的方法如下文所述。
401、主用设备接收所述对端设备发送的协商 IPSec信息的第一报文,所 述第一报文中携带有第一标识。
402、 主用设备更新其存储的第二标识的值, 并使所述备用设备备份所述 第二标识的值。
403、 主用设备更新存储的第二标识的值之后向备用设备发送更新通知, 备用设备根据主用设备的更新通知更新存储的第三标识的值, 所述第三标识 为所述备用设备中存储的用于获知所述主用设备的状态信息的标识。
404、 当主用设备和对端设备的通信链路发生异常, 或主用设备出现故障 时, 主用设备和备用设备进行切换, 备用设备切换为新的主用设备。 新的主 用设备根据更新的第三标识向对端设备发送协商 IPSec信息的第二报文。 若第三标识的值为 0, 则重新向对端设备发送协商 IPSec信息的第二报 文, 所述第二报文中携带的第一标识的值为 N, 且所述第二报文中携带第一 SA;
若第三标识的值为 1 , 则将所述第三标识的值重置为 0, 将所述第二标识 的值更新为 N, 并重新向所述对端设备发送协商 IPSec信息的第二报文, 所 述第二报文中携带的第一标识的值为 N, 所述第二报文携带第二 SA。
在本实施例中, 第一标识可为 message— id; 第二标识可为 recv— message— id; 第三标识可为 msgid— bk— flag,
第一标识、 所述第二标识初始值均为 N ( N为自然数), 所述第三标识的 初始值为 0。
同理, 步骤 402中, 主用设备可将存储的第二标识的值更新为 N+1 ; 在 步骤 403中, 备用设备可将存储的第三标识的值更新为 1。
在本实施例中, 备用设备在切换为新的主用设备时, 可以根据第三标识 的值相适应向对端设备发送报文, 可以使得新的主用设备发送的报文能够使 对端设备解析, 进而解决现有技术的 IKEv2 的协商过程中的协商双方 message id不一致情况后, 后续的协商可能再也无法进行, 导致长时间的业 务中断的问题。
如图 5a所示, 图 5a示出了本发明实施例的 IKE报文协商的方法的流程 示意图, 本实施例中的 IKE报文协商的方法如下文所述。
在本实施例中, 根据 IKEv2协议, 主用设备内部存在 send— message— id 和 recv— message— id, 其初始值均可为 N, N为自然数。
在主用设备和对端设备之间的链路未发生异常时, 主用设备和对端设备 交互一次 IKE报文, 用以协商建立 SA, 以及主用设备和对端设备会在间隔一 定的时间之后进行新的协商。 在主用设备接收到对端设备发送的第一报文, 贝 夺 recv— message— id ό 值更新 recv— message— id=N+1 ,主用设备向对端 设备返回响应 文, 对端设备接收响应 文之后将内部存储的 send— message— id更新为 N+1。 第一报文中携带第一标识即 message— id。
在本实施例中, 主用设备内部的接收标识 recv— message— id即为第二标 识,且在备用设备内部设置第三标识 msgid— bk— flag;第三标识的初始值为 0。
可选地, 主用设备中也可设置有第三标识即 msgid— bk— flag。
501、主用设备接收所述对端设备发送的协商 IPSec信息的第一报文,所 述第一报文中携带有第一标识, message— id=N, N为自然数。
502、 主用设备更新其存储的第二标识的值, recv— message— id=N+1 , 并通知所述备用设备备份所述第二标识的值,即备份 recv— message— id=N+1。
503、 主用设备向备用设备发送更新第三标识的更新通知, 备用设备根据 主用设备的更新通知更新内部第三标识的值, msgid— bk— flag=0+1。
504、 当主用设备和对端设备的通信链路发生异常, 或主用设备出现故障 时, 主用设备和备用设备进行切换, 备用设备切换为新的主用设备, 此时, 若第三标识的值为 0, 则重新向对端设备发送协商 IPSec信息的第二报文, 所述第二报文中携带的第一标识的值为 N, 且所述第二报文中携带第一 SA; 若第三报文标识的值为 1 , 则将所述第三标识的值重置为 0, 将所述第二 标识的值更新为 N,并重新向所述对端设备发送协商 IPSec信息的第二报文, 所述第二报文中携带的第一标识的值为 N, 所述第二报文携带第二 SA。
在本实施例中, 第一 SA和第二 SA是不同的, 第一 SA可为原主用设备 预发送的 SA。
其中, 所述第三标识为所述备用设备中设置的用于获知所述主用设备的 状态信息的标识。
如图 5B所示, 图 5B示出了本发明实施例的 IKE报文协商的方法的流程 示意图, 本实施例中的 IKE报文协商的方法如下文所述。
本实施例中, recv— message— id的初始值为 N。
511、主用设备接收对端设备发送的协商 IPSec信息的第一报文, 所述第 一报文中携带有第一标识, message— id=N, N为自然数。
512、主用设备生成第二报文,所述第二报文为所述第一报文的响应报文, 第二报文中携带的第一标识的值为 N, 即 message— id=N, 且所述第二报文 中携带第一 SA;
更新其存储的第二标识的值, recv— message— id=N+1 , 并
通知备用设备备份所述第二标识的值, 即备份 recv— message— id=N+1。
513、 主用设备向备用设备发送更新第三标识的更新通知, 备用设备根据 主用设备的更新通知更新内部第三标识的值, msgid— bk—flag=1。
514、 主用设备向对端设备返回响应报文, 即所述第二报文。
515、 主用设备向备用设备发送更新第三标识的更新通知, 备用设备根据 主用设备的更新通知更新内部第三标识的值, msgid— bk—flag=0。 主用设备在对接收到的报文进行处理的过程中 (是指接收到第一报文, 但尚未发送完第一报文对应的响应报文第二报文之间的时间段 ), 通过发送更 新通知, 使得备用设备将第三标识的值置为 1 , 即 msgid— bk— flag=1。 主用设 备在对接收到的报文处理结束后 (是指发送完第一报文对应的响应报文第二 报文之后), 通过再次发送更新通知, 使得备用设备将第三标识的值置为 0, 即 msgid— bk—flag=0。
516、 当主用设备和对端设备的通信链路发生异常, 或主用设备出现故障 时, 主用设备和备用设备进行切换, 备用设备切换为新的主用设备。 主用设 备和备用设备的切换可以发生在主用设备对接收到的报文进行处理的过程 中, 也有可能发生在主用设备对接收到的报文处理结束之后。 根据切换发生 时机执行对应的处理。
发生切换时, 若第三标识的值为 0 (即原有主用设备对接收到的报文处理 结束之后, 在稳定状态), 则新的主用设备重新向对端设备发送协商 IPSec信 息的第二报文, 所述第二报文中携带的第一标识的值为 N, 且所述第二报文 中携带第一 SA, 该第一 SA是原主用设备同步到新的主用设备中的;
若第三标识的值为 1 (即原有主用设备对接收到的报文进行处理的过程 中, 在中间状态), 则新的主用设备将所述第三标识的值重置为 0, 将所述第 二标识的值更新为 N, 并生成第三报文, 所述第三报文中携带的第一标识的 值为 N, 所述第三报文携带第二 SA。
本实施例中的 IKE报文协商的方法提高了 IPSec双机热备的高可靠性, 解决了现有技术的 IKEv2的协商过程中的协商双方 message id不一致情况 后, 后续的协商可能再也无法进行, 导致长时间的业务中断的问题, 进而协 商双方保证后续协商正常进行。
如图 6A和图 6B所示, 图 6A示出了 IKE报文协商的方法的场景图, 图 6B示出了本发明实施例的 IKE报文协商的方法的流程示意图, 本实施例中的 IKE报文协商的方法如下文所述。
本实施例中, 在主用设备和备用设备中同时增加 msgid— bk— flag的标识, 即第三标识。
601 、 C (对端设备) 向 A (主用设备)发起 msgl (第一报文) , msgl 中包含 message id, message id的值为 0。
602、 A收到 msgl之后, 生成 SA1 (第一 SA ) , 更新 recv— msgid的 值, 并使 B (备用设备)备份更新后的 recv— msgid, 同时向 B发送更新通知, 使 B根据更新通知更新 msgid— bk— flag的值, 即 msgid— bk—flag=1。
此时, B中 msgid— bk— flag=1 , recv— msgid=N+1 .
本实施例中,更新 msgid— bk— flag的值为: 将 msgid— bk— flag的初始值增 力。 1。 其中, msgid— bk— flag的初始值为 0, recv— msgid的初始值为 N ( N为 自然数) 。
603、 若此时 A与 C的通信接口的物理链路中断或 A发生故障, 引起主 备切换, B变为新的主用设备, A变为新的备用设备,此时 C并没有收到 msgl 的响应消息; 如果 C在间隔预设时间内还没有收到 msgl 的响应消息, 重新 发送携带 message id=0的 msgl。
604、 B在接收到 C发送的 msgl之后, 查看 message id的值和存储的 recv— msgid的值是否一致, 若确定 message id的值小于 recv— msgid的值, 则确定 msgl为重传消息,
进一步, 判断 msgid— bk— flag的值, 若 msgid— bk— flag的值为 1 , 则将原 recv— msgid的值减一, 即' f灰复 recv— msgid 的初始值, 并^1 msgid— bk— flag 置 0, 生成新的 SA2 (如图 6A中的 SA2, 即第二 SA ) , 并向 C发送响应消 息(如图 6A中的 msgO ) ;
判断 msgid— bk— flag的值,若 msgid— bk— flag的值为 0,则重传 B作为主 用设备时发送的响应消息, 该响应消息为新的主用设备应该发送的响应消息, 所述响应消息中包括 SA1 (即第一 SA ) 。
605、 C接收 msgl的响应消息, 更新 send— msgid的值, 生成 SA2; 协 商成功。
如图 6C示出了本发明实施例的 IKE报文协商的方法的流程示意图,本实 施例中的 IKE报文协商的方法如下文所述。
本实施例中, 在备用设备中增加 msgid— bk— flag的标识, 即第三标识。 61 1 、 C (对端设备) 向 A (主用设备 )发起 msgl (第一报文) , msgl 中包含 message id, message id的值为 N。
612、 A收到 msgl之后, 根据 recv— msgid, 生成 SA1 (第一 SA ) , 生 成对应的响应艮文 msg2, msg2的 message— id=N。
更新 recv— msgid的值, 并使 B (备用设备)备份更新后的 recv— msgid, 同时向 B发送更新通知, 使 B根据更新通知更新 msgid— bk— flag 的值, 即 msgid— bk—flag=1。
此时, B中 msgid— bk— flag=1 , recv— msgid=N+1 .
本实施例中, 由于是 Α在处理 msgl 的过程中对 msgid— bk— flag的值进 行更新,所以更新 msgid— bk— flag的值为:将 msgid— bk— flag的值置 1。其中, msgid— bk— flag的初始值为 0, recv— msgid的初始值为 N ( N为自然数 ) 。
如果此时未发生主备切换, 则继续执行 613。 若发生主备切换, 则进入 步骤 614。
613、 A向对端设备返回响应报文 msg2。 同时向 B发送更新通知, 使 B 根据更新通知更新 msgid— bk— flag的值, 即 msgid— bk—flag=0。
若未发生主备切换, 则 A等待接收 C发来的下一个请求报文, 对 C发来 的下一个请求报文重复执行与 611 类似的处理, 在这里不再赘述, 本实施例 仅以一个报文的处理周期为例, 对其中不同 P介段发生的主备切换进行描述。 若发生主备切换, 则进入步骤 618。
614、 此时 C并没有收到 msgl 的响应消息; 如果 C在间隔预设时间内 还没有收到 msgl的响应消息, 重新发送携带 message id=0的 msg1。
615、 B在接收到 C重发的 msgl之后, 查看 message id的值和存储的 recv— msgid的值是否一致, 若确定 message id的值 ( N ) 小于 recv— msgid 的值(N+1 ) , 则确定 msgl为重传消息。
616、 B 判断 msgid— bk— flag 的值, 若 msgid— bk— flag 的值为 1 , 将 msgid— bk— flag置 0, 并^!夺原 recv— msgid的值减一, 即' I"灰复 recv— msgid 的 初始值 N, 生成 SA2 (如图 6A中的 SA2, 即第二 SA ) , 并向 C发送响应消 息携带 SA2, 如 msg3。
617、 C接收 msgl的响应消息 msg3,更新 send— msgid的值,生成 SA2; 协商成功。
618、如果 C在间隔预设时间内还没有收到 msgl的响应消息, 重新发送 携带 message id=0的 msg1。 如果 C收到了 msg2, 则可以发送下一个请求 报文, B等待接收 C发来的下一个请求报文, 对 C发来的下一个请求报文进 行处理, 在这里不再重复。
619、 B在接收到 C发送的 msgl后, 查看 msgl的 message id的值和 存储的 recv— msgid的值是否一致, 若 msgl 的 message id的值 ( N ) 小于 recv— msgid的值 ( N+1 ) , 则确定 msgl为重传消息。
620、 B生成 msg2, 重传 A作为主用设备时发送的响应消息 msg2, 所 述响应消息中包括从 A同步来的 SA1 (即第一 SA ) 。
621 X接收 msgl的响应消息 msg2,更新 send— msgid的值,生成 SA1; 协商成功。
上述 IKE报文协商的方法, 解决了 IPSEC双机热备场景, IKE重协商过 程中主备切换可能引起的协商双方 SA中的 msgid不匹配, 业务中断问题。
根据本发明的另一方面, 本发明还提供一种 IKE报文协商的系统, 如图 7A和图 7B所示, IKE报文协商的系统包括: 主用设备 71和备用设备 72, 所述主用设备 71 包括: 第一处理器 711和第一存储器 712; 所述备用设 备 72包括: 第二处理器 721和第二存储器 722;
需要说明的是, 第一存储器 712存储有第二标识, 第二存储器 722中存 储有第三标识。
所述第二处理器 721用于根据所述第一处理器 711 的更新通知更新所述 第二存储器 722中存储的第三标识的值, 所述第一处理器 711 的更新通知为 所述第一处理器 711 更新所述第一存储器 712中存储的第二标识的值之后发 送的;
在所述备用设备 72切换为新的主用设备时,所述第二处理器 721用于根 据所述第二存储器 722中更新的第三标识向对端设备发送协商 IPSec信息的 第二报文;
其中, 所述第二存储器中的第三标识为用于获知所述主用设备的状态信 息的标识。
在一种应用场景中, 如图 7A所示, 上述的 IKE报文协商的系统作为 IKE 报文协商中的主动发送者时, 在第二处理器 721用于根据第一处理器 711 的 更新通知更新所述第二存储器 722中存储的第三标识的值之前,
所述第一处理器 711用于向所述对端设备发送协商 IPSec信息的第一报 文, 所述第一报文中携带有第一标识;
所述第一处理器 711还用于更新存储在所述第一存储器 712中的第二标 识的值;
其中, 所述第二标识为用于获知所述主用设备 71的状态信息的标识。 举例来说,第一标识为 message— id;所述第二标识为 next— sendmsg— id; 所述第三标识为 next— sendmsg— id。
另外, 第一标识的初始值、 所述第二标识的初始值和所述第三标识的初 始值相同, 且均为 N;
相应地, 所述第一处理器 711还用于更新存储在所述第一存储器 712中 的第二标识的值, 具体为:
所述第一处理器 711还用于将所述第一存储器 712中的第二标识的值更 新为 N+1 ;
所述第二处理器 721用于根据所述第一处理器 711 的更新通知更新所述 第二存储器 722中存储的第三标识的值, 具体为:
所述第二处理器 721 将所述第二存储器 722 中的第三标识的值更新为
N+1。
可选地, 第二处理器 721用于根据所述第二存储器 722中更新的第三标 识向对端设备发送协商 IPSec信息的第二报文, 具体为:
所述第二处理器 722向对端设备发送协商 IPSec信息的第二报文, 所述 第二报文中携带的第一标识的值为 N+1。
在一种优选的应用场景中, 第二处理器 721 还用于向所述对端设备发送 协商 IPSec信息的第三报文, 所述第三报文中携带的第一标识的值为 N。
上述的 IKE报文协商的系统作为 IKE报文协商中的主动发送者时, 可有 效解决现有技术中 IKEV2的协商过程中的协商双方第一标识的值不一致时, 后续的协商可能再也无法进行, 导致长时间的业务中断的问题。
在另一应用场景中, 上述的 IKE报文协商的系统作为 IKE报文协商中的 被动接收者时, 如图 7B所示, 第二处理器 721用于根据所述第一处理器 711 的更新通知更新所述第二存储器 722中存储的第三标识的值之前,
所述第一处理器 711用于接收所述对端设备发送的协商 IPSec信息的第 一报文, 所述第一报文中携带有第一标识;
所述第一处理器 711还用于更新所述第一存储器 712中存储的第二标识 的值,并使所述第二处理器 721向第二存储器 722中备份所述第二标识的值。
举例来说, 所述第一标识为 message— id; 所述第二标识为 recv— message— id; 所述第三标识为 msgid— bk— flag, 第一标识、 所述第二标 识初始值均为 N, 所述第三标识的初始值为 0;
相应地, 所述第一处理器 711 更新所述第一存储器 712中存储的第二标 识的值, 具体为:
所述第一处理器 711 将所述第一存储器 712 中的第二标识的值更新为 N+1 ;
所述第二处理器 721用于根据所述第一处理器 711 的更新通知更新所述 第二存储器 722中存储的第三标识的值, 具体为:
所述第二处理器 721将所述第二存储器 722中的第三标识的值更新为 1。 进一步地, 第二处理器 721用于根据所述第二存储器 722中更新的第三 标识向对端设备发送协商 IPSec信息的第二报文, 具体包括:
若第三标识的值为 0, 则所述第二处理器 721 重新向对端设备发送协商 IPSec信息的第二报文,所述第二报文中携带的第一标识的值为 N,且所述第 二报文中携带第一安全联盟 SA;
若第三标识的值为 1 , 则所述第二处理器 721 将所述第三标识的值重置 为 0, 将所述第二标识的值更新为 N, 并重新向所述对端设备发送协商 IPSec 信息的第二报文, 所述第二报文中携带的第一标识的值为 N, 所述第二报文 携带第二 SA。
上述的 IKE报文协商的系统作为 IKE报文协商中的被动接收者时, 可有 效解决现有技术中 IKEV2的协商过程中的协商双方第一标识的值不一致时, 后续的协商可能再也无法进行, 导致长时间的业务中断的问题。
根据本发明的再一方面, 本发明实施例还提供一种通信系统, 包括上述 本发明任意所述的 IKE报文协商的系统。
本领域普通技术人员可以理解: 实现上述各方法实施例的全部或部分步 骤可以通过程序指令相关的硬件来完成。 前述的程序可以存储于一计算机可 读取存储介质中。 该程序在执行时, 执行包括上述各方法实施例的步骤; 而 前述的存储介质包括: ROM、 RAM, 磁碟或者光盘等各种可以存储程序代码 的介质。
最后应说明的是: 以上各实施例仅用以说明本发明的技术方案, 而非对 其限制; 尽管参照前述各实施例对本发明进行了详细的说明, 本领域的普通 技术人员应当理解: 其依然可以对前述各实施例所记载的技术方案进行修改, 或者对其中部分或者全部技术特征进行等同替换; 而这些修改或者替换, 并 不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims

权 利 要 求
1、 一种 IKE报文协商的方法, 其特征在于, 包括:
备用设备根据主用设备的更新通知更新存储的第三标识的值, 所述主用 设备的更新通知为所述主用设备更新存储的第二标识的值之后发送的;
在备用设备切换为新的主用设备时, 所述新的主用设备根据更新的第三 标识向对端设备发送协商互联网协议安全性 IPSec信息的第二报文;
其中, 所述第三标识为所述备用设备中存储的用于获知所述主用设备的 状态信息的标识。
2、 根据权利要求 1所述的方法, 其特征在于, 所述备用设备根据主用设 备的更新通知更新存储的第三标识的值的步骤之前, 还包括:
主用设备向所述对端设备发送协商 IPSec信息的第一报文, 所述第一报 文中携带有第一标识;
所述主用设备更新存储的第二标识的值;
其中, 所述第二标识为所述主用设备中存储的用于获知所述主用设备的 状态信息的标识。
3、 根据权利要求 2所述的方法, 其特征在于,
所述第一标识为 message— id;
所述第二标识为 next— sendmsg— id;
所述第三标识为 next— sendmsg— id;
所述第一标识的初始值、 所述第二标识的初始值和所述第三标识的初始 值相同, 且均为 N;
相应地, 所述主用设备更新存储的第二标识的值, 具体为:
所述主用设备将存储的第二标识的值更新为 N+1 ;
所述备用设备根据主用设备的更新通知更新存储的第三标识的值, 具体 为:
所述备用设备将存储的第三标识的值更新为 N+1。
4、 根据权利要求 3所述的方法, 其特征在于,
所述新的主用设备根据更新的第三标识向对端设备发送协商 IPSec信息 的第二报文, 具体为:
所述新的主用设备向对端设备发送协商 IPSec信息的第二报文, 所述第 二报文中携带的第一标识的值为 N+1。
5、 根据权利要求 1至 4任一所述的方法, 其特征在于, 还包括: 所述新的主用设备向所述对端设备发送协商 IPSec信息的第三报文, 所 述第三报文中携带的第一标识的值为 N。
6、 根据权利要求 1所述的方法, 其特征在于, 所述备用设备根据主用设 备的更新通知更新内部第三标识的值的步骤之前, 还包括:
所述主用设备接收所述对端设备发送的协商 IPSec信息的第一报文, 所 述第一报文中携带有第一标识;
所述主用设备生成所述第二报文, 所述第二报文为所述第一报文的响应 报文;
所述主用设备更新其存储的第二标识的值, 并使所述备用设备备份所述 第二标识的值。
7、 根据权利要求 6所述的方法, 其特征在于,
所述第一标识为 message— id;
所述第二标识为 recv— message— id;
所述第三标识为 msgid— bk— f lag ,
所述第一标识、所述第二标识初始值均为 Ν,所述第三标识的初始值为 0; 相应地, 所述主用设备更新存储的第二标识的值, 具体为:
所述主用设备将存储的第二标识的值更新为 Ν+1 ;
所述备用设备根据所述主用设备的更新通知更新内部第三标识的值, 具 体为:
所述备用设备将存储的第三标识的值更新为 1。
8、 根据权利要求 7所述的方法, 其特征在于,
所述新的主用设备根据所述第二存储器中更新的第三标识向对端设备发 送协商 IPSec信息的第二报文, 具体包括:
若第三标识的值为 1 , 则新的主用设备将所述第三标识的值重置为 0, 将 所述第二标识的值更新为 N, 并生成第三报文, 所述第三报文中携带的第一 标识的值为 N, 所述第三报文携带第二 SA。
9、 根据权利要求 7所述的方法, 其特征在于, 所述在备用设备切换为新 的主用设备之前, 还包括: 所述主用设备将所述第二报文发送给对端设备, 所述第二报文携带的第 一标识的值为 N, 且所述第二报文中携带第一安全联盟 SA;
所述备用设备根据所述主用设备的更新通知将存储的第三标识的值更新 为 0;
所述新的主用设备根据更新的第三标识向对端设备发送协商 IPSec信息 的第二报文, 具体包括:
若第三标识的值为 0,则新的主用设备重新向所述对端设备发送所述第二 报文。
10、 根据权利要求 7所述的方法, 其特征在于,
所述新的主用设备根据更新的第三标识向对端设备发送协商 IPSec信息 的第二报文, 具体包括:
若第三标识的值为 0, 则重新向对端设备发送协商 IPSec信息的第二报 文, 所述第二报文中携带的第一标识的值为 N, 且所述第二报文中携带第一 安全联盟 SA;
若第三标识的值为 1 , 则将所述第三标识的值重置为 0, 将所述第二标识 的值更新为 N, 并重新向所述对端设备发送协商 IPSec信息的第二报文, 所 述第二报文中携带的第一标识的值为 N, 所述第二报文携带第二 SA。
11、 一种 IKE报文协商的系统, 其特征在于, 包括: 主用设备和备用设 备,
所述主用设备包括: 第一处理器和第一存储器; 所述备用设备包括: 第 二处理器和第二存储器;
所述第二处理器用于根据所述第一处理器的更新通知更新所述第二存储 器中存储的第三标识的值, 所述第一处理器的更新通知为所述第一处理器更 新所述第一存储器中存储的第二标识的值之后发送的;
在所述备用设备切换为新的主用设备时, 所述第二处理器用于根据所述 第二存储器中更新的第三标识向对端设备发送协商互联网协议安全性 I PSec 信息的第二报文;
其中, 所述第二存储器中的第三标识为用于获知所述主用设备的状态信 息的标识。
12、 根据权利要求 11所述的系统, 其特征在于, 所述第二处理器用于根 据所述第一处理器的更新通知更新所述第二存储器中存储的第三标识的值之 所述第一处理器用于向所述对端设备发送协商 IPSec信息的第一报文, 所述第一报文中携带有第一标识;
所述第一处理器还用于更新存储在所述第一存储器中的第二标识的值; 其中, 所述第二标识为用于获知所述主用设备的状态信息的标识。
13、 根据权利要求 12所述的系统, 其特征在于,
所述第一标识为 message— id;
所述第二标识为 next— sendmsg— id;
所述第三标识为 next— sendmsg— id;
所述第一标识的初始值、 所述第二标识的初始值和所述第三标识的初始 值相同, 且均为 N;
相应地, 所述第一处理器还用于更新存储在所述第一存储器中的第二标 识的值, 具体为:
所述第一处理器还用于将所述第一存储器中的第二标识的值更新为 N+1 ;
所述第二处理器用于根据所述第一处理器的更新通知更新所述第二存储 器中存储的第三标识的值, 具体为:
所述第二处理器将所述第二存储器中的第三标识的值更新为 N+1。
14、 根据权利要求 13所述的系统, 其特征在于, 所述第二处理器用于根 据所述第二存储器中更新的第三标识向对端设备发送协商 IPSec信息的第二 报文, 具体为:
所述第二处理器向对端设备发送协商 IPSec信息的第二报文, 所述第二 报文中携带的第一标识的值为 N+1。
15、 根据权利要求 11至 14任一所述的系统, 其特征在于, 所述第二处 理器还用于向所述对端设备发送协商 IPSec信息的第三报文, 所述第三报文 中携带的第一标识的值为 N。
16、 根据权利要求 11所述的系统, 其特征在于, 所述第二处理器用于根 据所述第一处理器的更新通知更新所述第二存储器中存储的第三标识的值之 前,
所述第一处理器用于接收所述对端设备发送的协商 IPSec信息的第一报 文, 所述第一报文中携带有第一标识; 所述第一处理器还用于生成所述第二报文, 所述第二报文为所述第一报 文的响应报文; 更新所述第一存储器中存储的第二标识的值, 并使所述第二 处理器向第二存储器中备份所述第二标识的值。
17、 根据权利要求 16所述的系统, 其特征在于,
所述第一标识为 message— id;
所述第二标识为 recv— message— id;
所述第三标识为 msgid— bk— f lag ,
所述第一标识、所述第二标识初始值均为 Ν,所述第三标识的初始值为 0; 相应地, 所述第一处理器更新所述第一存储器中存储的第二标识的值, 具体为:
所述第一处理器将所述第一存储器中的第二标识的值更新为 Ν+1; 所述第二处理器用于根据所述第一处理器的更新通知更新所述第二存储 器中存储的第三标识的值, 具体为:
所述第二处理器将所述第二存储器中的第三标识的值更新为 1。
18、 根据权利要求 17所述的系统, 其特征在于,
所述第二处理器用于根据更新的第三标识向对端设备发送协商 IPSec信 息的第二报文, 具体包括:
若第三标识的值为 1 , 则所述第二处理器将所述第三标识的值重置为 0, 将所述第二标识的值更新为 N, 并生成第三报文, 所述第三报文中携带的第 一标识的值为 N, 所述第三报文携带第二 SA。
19、 根据权利要求 17所述的系统, 其特征在于, 所述在备用设备切换为 新的主用设备之前, 所述第一处理器还用于将所述第二报文发送给对端设备, 所述第二报文携带的第一标识的值为 N, 且所述第二报文中携带第一安全联 盟 SA; 所述第二处理器还用于根据所述主用设备的更新通知将存储的第三标 识的值更新为 0;
所述第二处理器用于根据更新的第三标识向对端设备发送协商 IPSec信 息的第二报文, 具体包括:
若第三标识的值为 0,则所述第二处理器重新向所述对端设备发送所述第 二报文。
20、 根据权利要求 17所述的系统, 其特征在于,
所述第二处理器用于根据所述第二存储器中更新的第三标识向对端设备 发送协商 IPSec信息的第二报文, 具体包括:
若第三标识的值为 0,则所述第二处理器重新向对端设备发送协商 IPSec 信息的第二报文, 所述第二报文中携带的第一标识的值为 N, 且所述第二报 文中携带第一安全联盟 SA;
若第三标识的值为 1 , 则所述第二处理器将所述第三标识的值重置为 0, 将所述第二标识的值更新为 N, 并重新向所述对端设备发送协商 IPSec信息 的第二报文, 所述第二报文中携带的第一标识的值为 N, 所述第二报文携带 第二 SA。
21、 一种通信系统, 其特征在于, 包括上述权利要求 11至 20任一所述 的 IKE报文协商的系统。
PCT/CN2013/085132 2012-10-12 2013-10-12 Ike报文协商的方法及系统 WO2014056454A1 (zh)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
CN201210387149 2012-10-12
CN201210387149.0 2012-10-12
CN201310459948.9A CN103731407B (zh) 2012-10-12 2013-09-29 Ike报文协商的方法及系统
CN201310459948.9 2013-09-29

Publications (1)

Publication Number Publication Date
WO2014056454A1 true WO2014056454A1 (zh) 2014-04-17

Family

ID=49488463

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2013/085132 WO2014056454A1 (zh) 2012-10-12 2013-10-12 Ike报文协商的方法及系统

Country Status (4)

Country Link
US (1) US9438566B2 (zh)
EP (1) EP2720438B1 (zh)
CN (1) CN103731407B (zh)
WO (1) WO2014056454A1 (zh)

Families Citing this family (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10749711B2 (en) 2013-07-10 2020-08-18 Nicira, Inc. Network-link method useful for a last-mile connectivity in an edge-gateway multipath system
US10454714B2 (en) 2013-07-10 2019-10-22 Nicira, Inc. Method and system of overlay flow control
US9961054B2 (en) * 2014-01-29 2018-05-01 Honeywell International Inc. Apparatus and method for establishing secure communication with redundant device after switchover
US10057767B2 (en) * 2014-12-19 2018-08-21 Apple Inc. Methods and apparatus to support location specific control of access to services through untrusted wireless networks
CN104579774B (zh) * 2014-12-31 2018-08-03 北京山石网科信息技术有限公司 主控设备的切换方法和装置
US10498652B2 (en) 2015-04-13 2019-12-03 Nicira, Inc. Method and system of application-aware routing with crowdsourcing
US10425382B2 (en) 2015-04-13 2019-09-24 Nicira, Inc. Method and system of a cloud-based multipath routing protocol
US10135789B2 (en) 2015-04-13 2018-11-20 Nicira, Inc. Method and system of establishing a virtual private network in a cloud service for branch networking
EP3151599A1 (en) 2015-09-30 2017-04-05 Apple Inc. Authentication failure handling for cellular network access through wlan
CN106304071B (zh) * 2016-08-15 2019-06-18 迈普通信技术股份有限公司 一种网络接入认证方法、接入认证设备及系统
CN106169952B (zh) * 2016-09-06 2019-05-07 杭州迪普科技股份有限公司 一种英特网密钥管理协议重协商的认证方法及装置
US11252079B2 (en) 2017-01-31 2022-02-15 Vmware, Inc. High performance software-defined core network
US10992558B1 (en) 2017-11-06 2021-04-27 Vmware, Inc. Method and apparatus for distributed data network traffic optimization
US10992568B2 (en) 2017-01-31 2021-04-27 Vmware, Inc. High performance software-defined core network
US11121962B2 (en) 2017-01-31 2021-09-14 Vmware, Inc. High performance software-defined core network
US20180219765A1 (en) 2017-01-31 2018-08-02 Waltz Networks Method and Apparatus for Network Traffic Control Optimization
US11706127B2 (en) 2017-01-31 2023-07-18 Vmware, Inc. High performance software-defined core network
US20200036624A1 (en) 2017-01-31 2020-01-30 The Mode Group High performance software-defined core network
US10778528B2 (en) 2017-02-11 2020-09-15 Nicira, Inc. Method and system of connecting to a multipath hub in a cluster
US10609008B2 (en) * 2017-06-08 2020-03-31 Nxp Usa, Inc. Securing an electronically transmitted communication
CN107332885A (zh) * 2017-06-19 2017-11-07 杭州迪普科技股份有限公司 一种IPSec VPN实现双机热备的方法和装置
US10523539B2 (en) 2017-06-22 2019-12-31 Nicira, Inc. Method and system of resiliency in cloud-delivered SD-WAN
US11115480B2 (en) 2017-10-02 2021-09-07 Vmware, Inc. Layer four optimization for a virtual network defined over public cloud
US10999165B2 (en) 2017-10-02 2021-05-04 Vmware, Inc. Three tiers of SaaS providers for deploying compute and network infrastructure in the public cloud
US10999100B2 (en) 2017-10-02 2021-05-04 Vmware, Inc. Identifying multiple nodes in a virtual network defined over a set of public clouds to connect to an external SAAS provider
US11005684B2 (en) 2017-10-02 2021-05-11 Vmware, Inc. Creating virtual networks spanning multiple public clouds
US10959098B2 (en) 2017-10-02 2021-03-23 Vmware, Inc. Dynamically specifying multiple public cloud edge nodes to connect to an external multi-computer node
US11089111B2 (en) 2017-10-02 2021-08-10 Vmware, Inc. Layer four optimization for a virtual network defined over public cloud
US11223514B2 (en) * 2017-11-09 2022-01-11 Nicira, Inc. Method and system of a dynamic high-availability mode based on current wide area network connectivity
JP7278806B2 (ja) * 2019-03-04 2023-05-22 株式会社東芝 通信制御装置および通信システム
JP7191726B2 (ja) * 2019-03-04 2022-12-19 株式会社東芝 通信制御装置および通信システム
JP7191727B2 (ja) * 2019-03-04 2022-12-19 株式会社東芝 通信制御装置および通信システム
JP7278807B2 (ja) * 2019-03-04 2023-05-22 株式会社東芝 通信制御装置および通信システム
US11368298B2 (en) * 2019-05-16 2022-06-21 Cisco Technology, Inc. Decentralized internet protocol security key negotiation
US11310170B2 (en) 2019-08-27 2022-04-19 Vmware, Inc. Configuring edge nodes outside of public clouds to use routes defined through the public clouds
US11044190B2 (en) 2019-10-28 2021-06-22 Vmware, Inc. Managing forwarding elements at edge nodes connected to a virtual network
US11394640B2 (en) 2019-12-12 2022-07-19 Vmware, Inc. Collecting and analyzing data regarding flows associated with DPI parameters
US11489783B2 (en) 2019-12-12 2022-11-01 Vmware, Inc. Performing deep packet inspection in a software defined wide area network
US11606712B2 (en) 2020-01-24 2023-03-14 Vmware, Inc. Dynamically assigning service classes for a QOS aware network link
US11245641B2 (en) 2020-07-02 2022-02-08 Vmware, Inc. Methods and apparatus for application aware hub clustering techniques for a hyper scale SD-WAN
US11709710B2 (en) 2020-07-30 2023-07-25 Vmware, Inc. Memory allocator for I/O operations
US11575591B2 (en) 2020-11-17 2023-02-07 Vmware, Inc. Autonomous distributed forwarding plane traceability based anomaly detection in application traffic for hyper-scale SD-WAN
US11575600B2 (en) 2020-11-24 2023-02-07 Vmware, Inc. Tunnel-less SD-WAN
US11929903B2 (en) 2020-12-29 2024-03-12 VMware LLC Emulating packet flows to assess network links for SD-WAN
US11792127B2 (en) 2021-01-18 2023-10-17 Vmware, Inc. Network-aware load balancing
US11979325B2 (en) 2021-01-28 2024-05-07 VMware LLC Dynamic SD-WAN hub cluster scaling with machine learning
US11509571B1 (en) 2021-05-03 2022-11-22 Vmware, Inc. Cost-based routing mesh for facilitating routing through an SD-WAN
US12009987B2 (en) 2021-05-03 2024-06-11 VMware LLC Methods to support dynamic transit paths through hub clustering across branches in SD-WAN
US11729065B2 (en) 2021-05-06 2023-08-15 Vmware, Inc. Methods for application defined virtual network service among multiple transport in SD-WAN
US12015536B2 (en) 2021-06-18 2024-06-18 VMware LLC Method and apparatus for deploying tenant deployable elements across public clouds based on harvested performance metrics of types of resource elements in the public clouds
US11489720B1 (en) 2021-06-18 2022-11-01 Vmware, Inc. Method and apparatus to evaluate resource elements and public clouds for deploying tenant deployable elements based on harvested performance metrics
US11375005B1 (en) 2021-07-24 2022-06-28 Vmware, Inc. High availability solutions for a secure access service edge application
US11943146B2 (en) 2021-10-01 2024-03-26 VMware LLC Traffic prioritization in SD-WAN
CN114301653B (zh) * 2021-12-22 2024-02-02 山石网科通信技术股份有限公司 抵御半连接攻击的方法、装置、存储介质以及处理器
US11909815B2 (en) 2022-06-06 2024-02-20 VMware LLC Routing based on geolocation costs

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101577725A (zh) * 2009-06-26 2009-11-11 杭州华三通信技术有限公司 一种防重放机制中的信息同步方法、装置和系统
CN101605060A (zh) * 2009-07-14 2009-12-16 中兴通讯股份有限公司 一种单板级的IPSec主备方法及装置
CN101714916A (zh) * 2009-11-26 2010-05-26 成都市华为赛门铁克科技有限公司 一种备份方法、设备和系统

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7266715B1 (en) * 2003-04-29 2007-09-04 Cisco Technology, Inc. Methods and apparatus for maintaining a virtual private network connection
US7836497B2 (en) * 2006-12-22 2010-11-16 Telefonaktiebolaget L M Ericsson (Publ) Apparatus and method for resilient IP security/internet key exchange security gateway
WO2009125153A2 (fr) * 2008-03-31 2009-10-15 France Telecom Procede de commutation d'un terminal mobile d'un premier routeur d'acces vers un deuxieme routeur d'acces
JP5392034B2 (ja) * 2009-12-01 2014-01-22 富士通株式会社 通信装置および通信方法
US8457130B2 (en) * 2011-05-02 2013-06-04 Acme Packet, Inc. Synchronizing sequence numbers

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101577725A (zh) * 2009-06-26 2009-11-11 杭州华三通信技术有限公司 一种防重放机制中的信息同步方法、装置和系统
CN101605060A (zh) * 2009-07-14 2009-12-16 中兴通讯股份有限公司 一种单板级的IPSec主备方法及装置
CN101714916A (zh) * 2009-11-26 2010-05-26 成都市华为赛门铁克科技有限公司 一种备份方法、设备和系统

Also Published As

Publication number Publication date
US20140108781A1 (en) 2014-04-17
EP2720438A1 (en) 2014-04-16
EP2720438B1 (en) 2015-04-22
CN103731407B (zh) 2017-08-11
CN103731407A (zh) 2014-04-16
US9438566B2 (en) 2016-09-06

Similar Documents

Publication Publication Date Title
WO2014056454A1 (zh) Ike报文协商的方法及系统
US7836497B2 (en) Apparatus and method for resilient IP security/internet key exchange security gateway
CN110024325B (zh) 用于设备之间mka协商的系统、方法和设备
US8656481B2 (en) System and method for IPSec link configuration
CN109286593B (zh) 传输重连的方法及装置、计算机设备及存储介质
EP2521335B1 (en) Synchronizing sequence numbers
WO2013166696A1 (zh) 数据传输方法、系统及装置
JP2009501454A (ja) リンク管理システム
JP2012175199A (ja) ネットワークシステム、及び通信復旧方法
JP2012516654A (ja) アドレス生成、通信および、または正当性検査に関連する方法および装置
US9300642B2 (en) Restarting network reachability protocol sessions based on transport layer authentication
JP2016213670A (ja) 通信装置、通信システム、通信方法及びプログラム
CN110771117B (zh) 一种采用面向id的网络的会话层通信
US10630479B2 (en) Network communication method having function of recovering terminal session
WO2011020369A1 (zh) Diameter链路的建立方法和Diameter网元
WO2014124561A1 (zh) 实现在wlan中的通信的方法和系统
WO2011143888A1 (zh) 一种对协议状态的设备间备份的方法及系统
EP2770778B1 (en) Method, system, and enb for establishing secure x2 channel
CN110120907B (zh) 一种基于提议组的IPSec VPN隧道的通信方法及装置
CN108270613B (zh) 发送消息方法及网络设备
KR101730405B1 (ko) 네트워크 경로를 관리하는 방법 및 이를 수행하는 네트워크 엔티티
WO2014176718A1 (zh) 一种通道建立方法、基站及通道建立系统
WO2011035514A1 (zh) 一种基于隧道技术的三元鉴别可扩展方法及其系统
CN114040389B (zh) 一种适用于物联网应用场景的高速安全传输方法
WO2022089245A1 (zh) 一种业务传输方法、通信设备及存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13845649

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13845649

Country of ref document: EP

Kind code of ref document: A1