Update the key of the security association SA

Abstract

During an IKE SA or IPSec SA rekey, whether the rekey exchange includes the cryptographic suite in the payload depends on whether the cryptographic suite used in the old SA at either end (e.g., the initiator and responder) has changed. If the cryptographic suite has not changed, the rekey exchange does not include the cryptographic suite. Furthermore, during an IPSec SA rekey, if the flow information at either end has not changed, the rekey exchange does not include the traffic selector (TS). This reduces the payload size, saving bandwidth, processing time, and power during the IKE SA or IPSec SA rekey process.

Description

Technical Field

[0001] The present disclosure relates generally to telecommunications, more particularly to Internet security protocols, and even more particularly to methods, devices, and systems for rekeying security associations for mobile devices having, for example, limited power, bandwidth, and / or processing capabilities. Background Art

[0002] Internet Key Exchange Version 2 (IKEv2) is a protocol defined by RFC 7296, the entire contents of which are incorporated herein by reference, except where expressly disclosed herein to the contrary. Terms used herein have the meanings given in RFC 7296, except where expressly disclosed herein to the contrary.

[0003] IKEv2 is used to establish a security association (SA) within the IPSec protocol suite. The SA can be an IKE tunnel or an IPSec tunnel. Internet Protocol Security (IPSec) is a network protocol suite that authenticates and encrypts data packets sent over a network.

[0004] The IKE message flow consists of a request and a response. The requester is responsible for ensuring reliability. If no response is received within the timeout, the requester needs to retransmit the request (or abandon the connection). A pair of first request / response messages (IKE_SA_INIT) between the requester and responder of the IKE session negotiates the security parameters of the IKE_SA, sends random numbers, and sends Diffie-Hellman values. A pair of second request / response messages (IKE_AUTH) transmits identities, proves knowledge of the secrets corresponding to the two identities, and establishes an SA for the first (and usually only) Authentication Header (AH) and / or Encapsulating Security Payload (ESP) CHILD_SA.

[0005] The IKE key update process in IKEv2 is defined in RFC 7296, which is incorporated herein by reference in its entirety, except where expressly disclosed herein to the contrary. Terms used herein have the meanings given in RFC 7296, except where expressly disclosed herein to the contrary.

[0006] By definition, key renewal is the creation of a new SA to replace the expiring SA before the SA expires.

[0007] For example, an IKE rekey exchange between a requester and a responder carries one or more SA payloads, which include one or more proposal payloads. Each proposal includes a set of cipher suites (e.g., one or more cipher suites). Typically, these suites do not change during a rekey. The minimum size of an SA payload (e.g., for a single cipher suite set) is typically 52 bytes. For an IKE rekey, the minimum possible size is 44 bytes. This can include a 44-byte SA payload size and a 40-byte proposal size. The minimum value is determined by the type and number of cipher suites selected and sent in the SA payload.

[0008] The SA payload structure typically consists of an SA payload, a proposal, a transcode, and attributes. The SA payload contains one or more proposal payloads, each containing a protocol ID and SPI. The proposal payload also contains a transcode containing the encryption algorithm and, optionally, attributes containing the key length. Further defining a specific proposal by specifying attributes, etc., increases the size of the SA payload. Those skilled in the art will appreciate that the traditional SA payload is detailed in Section 3.3 of RFC 7296.

[0009] For example, the IPSec rekey exchange between the requester and responder also carries an SA payload, which contains a cipher suite (e.g., a single or multiple cipher suites) and a TS payload (e.g., a TSi payload and a TSr payload). In most cases, these payloads remain unchanged during a rekey, similar to the IKE rekey process. The minimum size of an SA payload is typically 40 bytes, and each TS is 24 bytes (2 * 24 = 48 bytes).

[0010] Figure 1A Some examples of the structure of traditional SA payloads are provided. The first SA payload does not contain any attributes, the second SA payload contains attributes, and each of the two SA payloads contains a proposal. The third SA payload contains two proposals, each of which contains attributes.

[0011] When rekeying an IKE SA and / or IPSec SA, the payload size increases proportionally to the number of cipher suites. This rekeying is triggered periodically, and each rekeying consumes bandwidth and power to process the payload. Summary of the Invention

[0012] This disclosure is intended to introduce concepts related to methods, devices, and systems for rekeying security associations. Furthermore, it modifies existing message types exchanged during the known SA rekeying process. Furthermore, it introduces new messages for the SA rekeying process. While this disclosure is discussed with reference to IKEv2, it should be understood that the present disclosure is equally applicable to other rekeying mechanisms.

[0013] According to a first aspect, an embodiment of the present application provides a method for rekeying a security association (SA) in a network system including a first network device and a second network device, wherein an Internet Key Exchange (IKE) tunnel and an Internet Protocol Security (IPSec) tunnel are established between the first network device and the second network device. In this method, the first network device determines whether a cryptographic suite associated with the first network device has changed. If the cryptographic suite associated with the first network device has not changed, the first network device sends a first request for rekeying the SA to the second network device. The first rekeying request carries a first security parameter index (SPI) and does not carry the cryptographic suite associated with the first network device. Then, if the cryptographic suite associated with the first network device and the cryptographic suite associated with the second network device have not changed, the first network device rekeys the SA based on the first SPI and the second SPI. Specifically, the first network device rekeys the SA based on the first SPI, the second SPI, and the cryptographic suite used by the SA for which rekeying is to be performed.

[0014] In the above technical solution, the key update request and the key update response do not carry the encryption suite to reduce the size of the payload in the key update, thereby saving bandwidth, processing time and power in the key update process such as IKE SA key update and IPSec SA key update.

[0015] In conjunction with the first aspect, in a first possible implementation, when the SA is an IPSec SA and the IPSec SA is a sub-SA of an IKE SA, if the flow information associated with the first network device changes, the first key update request does not carry the TS payload that carries the flow information associated with the first network device. If the flow information associated with the second network device does not change, the first key update response does not carry the TS payload that carries the flow information associated with the second network device. Therefore, the first network device performs a key update on the SA without changing the flow information associated with the first network device or the flow information associated with the second network device.

[0016] In the aforementioned IPsec rekeying scenario, the rekeying request and rekeying response do not carry the TS payload (TSi and TSr) to further reduce the payload. In an IPsec SA, the payload size is proportionally reduced when multiple cipher suites are present. Lightweight payloads can also save bandwidth, processing time, and power during IPsec rekeying.

[0017] In combination with the first aspect, in a second possible implementation, when the SA is an IKE SA, the first key update request is a CREATE_CHILD_SA request for updating the key of the IKE SA, the CREATE_CHILD_SA request carries a NEW_SPI notification payload or a lightweight SA payload, the NEW_SPI notification payload carries the first SPI, and the lightweight SA payload carries the first SPI. The first key update response is a CREATE_CHILD_SA response for updating the key of the IKE SA, the CREATE_CHILD_SA response carries another NEW_SPI notification payload or another lightweight SA payload, the other NEW_SPI notification payload carries the second SPI, and the other lightweight SA payload carries the second SPI. Correspondingly, when the SA is an IPSec SA and the IPSec SA is a sub-SA of the IKE SA, the first key update request is a CREATE_CHILD_SA request for updating the key of the sub-SA, the CREATE_CHILD_SA request carries a NEW_SPI notification payload or carries a lightweight SA payload, the NEW_SPI notification payload carries the first SPI, and the lightweight SA payload carries the first SPI. The first key update response is a CREATE_CHILD_SA response for updating the key of the sub-SA, the CREATE_CHILD_SA response carries a NEW_SPI notification payload or carries another lightweight SA payload, the NEW_SPI notification payload carries the second SPI, and the other lightweight SA payload carries the second SPI.

[0018] For example, by using the lightweight key update method described in this embodiment, the NEW_SPI notification payload or lightweight SA payload can save a minimum of 36 bytes. The number of bytes saved increases proportionally for multiple encryption suites, which reduces the processing of complex verification and thus reduces the processing of SA payloads in IKE key updates or IPSec key update exchanges. For example, the size of the NEW_SPI notification payload can be in the range of 12 to 16 bytes.

[0019] According to a second aspect, an embodiment of the present application provides a method for rekeying a security association (SA). The security association is applied to a network system including a first network device and a second network device, wherein an Internet Key Exchange (IKE) tunnel and an Internet Protocol Security (IPSec) tunnel are established between the second network device and the first network device. In the method, the second network device receives a first rekey request from the first network device for rekeying the SA. The first rekey request carries a first security parameter index (SPI) and does not carry a cryptographic suite associated with the first network device. The second network device determines whether the cryptographic suite associated with the second network device has changed. When the second network device determines that the cryptographic suite associated with the second network device has not changed, the second network device sends a first rekey response, the first rekey response carrying a second SPI and not carrying the cryptographic suite associated with the second network device. The SA is rekeyed based on the first SPI and the second SPI.

[0020] In the above technical solution, the key update request and the key update response do not carry the encryption suite to reduce the size of the payload in the key update, thereby saving bandwidth, processing time and power in the key update process such as IKE SA key update and IPSec SA key update.

[0021] In conjunction with the second aspect, in a first possible implementation, when the SA is an IPSec SA and the IPSec SA is a sub-SA of an IKE SA, if the flow information associated with the first network device changes, the first key update request does not carry the TS payload that carries the flow information associated with the first network device. If the flow information associated with the second network device does not change, the first key update response does not carry the TS payload that carries the flow information associated with the second network device. Therefore, the SA key is updated by changing the flow information associated with the first network device and the flow information associated with the second network device.

[0022] In the aforementioned IPsec rekeying scenario, the rekeying request and rekeying response do not carry the TS payload (TSi and TSr) to further reduce the payload. In an IPsec SA, the payload size is proportionally reduced when multiple cipher suites are present. Lightweight payloads can also save bandwidth, processing time, and power during IPsec rekeying.

[0023] According to a third aspect, an embodiment of the present application provides a network device for performing a key update on a security association (SA) in a network system including a first network device and a second network device. An Internet Key Exchange (IKE) tunnel and an Internet Protocol Security (IPSec) tunnel are established between the first network device and the second network device, and the network device serves as the first network device. The network device includes a determination module, a sending module, a receiving module, and a key update module. The determination module is configured to determine whether a cryptographic suite associated with the first network device has changed. The sending module is configured to, when the cryptographic suite associated with the first network device has not changed, send a first key update request to the second network device for performing a key update on the SA, wherein the first key update request carries a first security parameter index (SPI) and does not carry the cryptographic suite associated with the first network device. The receiving module is configured to receive a first key update response from the second network device. When the cryptographic suite associated with the second network device has not changed, the first key update response carries a second SPI and does not carry the cryptographic suite associated with the second network device. The key updating module is configured to update the key of the SA according to the first SPI and the second SPI when the encryption suite associated with the first network device and the encryption suite associated with the second network device do not change.

[0024] In the above technical solution, the key update request and key update response do not carry the cipher suite, reducing the payload size during the key update. This saves bandwidth, processing time, and power during key update processes, such as IKE SA key update and IPSec SA key update. In IKE SA key update and IPsec SA key update scenarios, the payload size is proportionally reduced when multiple cipher suites are present during the key update process.

[0025] According to a fourth aspect, an embodiment of the present application provides a network device for performing a key update on a security association (SA) in a network system including a first network device and a second network device. An Internet Key Exchange (IKE) tunnel and an Internet Protocol Security (IPSec) tunnel are established between the first network device and the second network device, and the network device serves as the second network device. The network device includes a receiving module, a determining module, and a sending module. The receiving module is configured to receive a first key update request from the first network device for performing a key update on the SA. The first key update request carries a first security parameter index (SPI) and does not carry a cryptographic suite associated with the first network device. The determining module is configured to determine whether the cryptographic suite associated with the second network device has changed. The sending module is configured to send a first key update response to the first network device. If the cryptographic suite associated with the second network device has not changed, the first key update response carries a second SPI and does not carry the cryptographic suite associated with the second network device. The SA is key updated based on the first SPI and the second SPI.

[0026] In the above technical solution, the key update request and key update response do not carry the cipher suite, reducing the payload size during the key update. This saves bandwidth, processing time, and power during key update processes, such as IKE SA key update and IPSec SA key update. In IKE SA key update and IPsec SA key update scenarios, the payload size is proportionally reduced when multiple cipher suites are present during the key update process.

[0027] According to a fifth aspect, an embodiment of the present application provides a network system for updating a key of a security association (SA), the network system comprising a first network device according to the third aspect of the present application as described above and a second network device according to the fourth aspect of the present application.

[0028] In the above technical solution, the key update request and key update response do not carry the cipher suite, reducing the payload size during the key update. This saves bandwidth, processing time, and power during key update processes, such as IKE SA key update and IPSec SA key update. In IKE SA key update and IPsec SA key update scenarios, the payload size is proportionally reduced when multiple cipher suites are present during the key update process.

[0029] According to a sixth aspect, an embodiment of the present application provides a network device for performing a key update on a security association (SA) in a network system including a first network device and a second network device. An Internet Key Exchange (IKE) tunnel and an Internet Protocol Security (IPSec) tunnel are established between the first network device and the second network device, and the network device serves as the first network device. The network device includes a processor and a memory. The memory is configured to store software instructions. The processor is configured to execute the software instructions in the memory, causing the network device to: determine whether a cryptographic suite associated with the first network device has changed; when the cryptographic suite associated with the first network device has not changed, send a first key update request to the second network device for performing a key update on the SA, wherein the first key update request carries a first security parameter index (SPI) and does not carry the cryptographic suite associated with the first network device; when the cryptographic suite associated with the second network device has not changed, receive a first key update response, the first key update response carrying a second SPI and not carrying the cryptographic suite associated with the second network device; and when the cryptographic suite associated with the first network device and the cryptographic suite associated with the second network device have not changed, perform a key update on the SA based on the first SPI and the second SPI.

[0030] In the above technical solution, the key update request and key update response do not carry the cipher suite, reducing the payload size during the key update. This saves bandwidth, processing time, and power during key update processes, such as IKE SA key update and IPSec SA key update. In IKE SA key update and IPsec SA key update scenarios, the payload size is proportionally reduced when multiple cipher suites are present during the key update process.

[0031] According to a seventh aspect, an embodiment of the present application provides a network device for performing a key update on a security association (SA) in a network system including a first network device and a second network device. An Internet Key Exchange (IKE) tunnel and an Internet Protocol Security (IPSec) tunnel are established between the first network device and the second network device, and the network device serves as the second network device. The network device includes a processor and a memory. The memory is configured to store software instructions. The processor is configured to execute the software instructions in the memory, causing the network device to: receive a first key update request from the first network device for performing a key update on the SA, wherein the first key update request carries a first security parameter index (SPI) and does not carry a cryptographic suite associated with the first network device; determine whether the cryptographic suite associated with the second network device has changed; and send a first key update response to the first network device; wherein, if the cryptographic suite associated with the second network device has not changed, the first key update response carries a second SPI and does not carry the cryptographic suite associated with the second network device. Key updates are performed on the SA based on the first SPI and the second SPI.

[0032] In the above technical solution, the key update request and key update response do not carry the cipher suite, reducing the payload size during the key update. This saves bandwidth, processing time, and power during key update processes, such as IKE SA key update and IPSec SA key update. In IKE SA key update and IPsec SA key update scenarios, the payload size is proportionally reduced when multiple cipher suites are present during the key update process.

[0033] According to the eighth aspect, an embodiment of the present application provides a network system for updating keys of a security association (SA), the network system comprising a first network device according to the sixth aspect of the present application as described above and a second network device according to the seventh aspect of the present application.

[0034] In the above technical solution, the key update request and key update response do not carry the cipher suite, reducing the payload size during the key update. This saves bandwidth, processing time, and power during key update processes, such as IKE SA key update and IPSec SA key update. In IKE SA key update and IPsec SA key update scenarios, the payload size is proportionally reduced when multiple cipher suites are present during the key update process.

[0035] According to a ninth aspect, an embodiment of the present application provides a computer-readable storage medium for storing computer software instructions for executing the method according to the first aspect or the method according to the second aspect as described above.

[0036] In the above technical solution, the key update request and key update response do not carry the cipher suite, reducing the payload size during the key update. This saves bandwidth, processing time, and power during key update processes, such as IKE SA key update and IPSec SA key update. In IKE SA key update and IPsec SA key update scenarios, the payload size is proportionally reduced when multiple cipher suites are present during the key update process.

[0037] Other aspects and features of the present disclosure will become apparent to those of ordinary skill in the art after reading the following description of specific embodiments of the disclosure in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] The detailed description is described with reference to the accompanying drawings. The leftmost digit(s) of a reference number in the accompanying drawings identifies the drawing in which the reference number first appears. The same numerals are used throughout the drawings to refer to the same features and components.

[0039] Figure 1A The structures of some SA payloads according to conventional techniques are shown.

[0040] Figure 1B FIG. 1 is a flowchart of an IKE SA key update process according to conventional technology.

[0041] Figure 1C An example of the structure of a delete request is shown.

[0042] Figure 2 FIG. 1 shows IPSec SA key update according to conventional technology.

[0043] Figure 3A The present invention is a flowchart of negotiating support for lightweight key update between an initiator and a responder according to an embodiment of the present disclosure.

[0044] Figure 3B An example of the structure of a notification payload is shown.

[0045] Figure 4 FIG2 is another flow chart of negotiating support for lightweight key update between an initiator and a responder according to an embodiment of the present disclosure.

[0046] Figure 5 FIG2 is another flow chart of negotiating support for lightweight key update between an initiator and a responder according to an embodiment of the present disclosure.

[0047] Figure 6 The flowchart is a method for performing a key update on an SA using a lightweight key update method according to an embodiment of the present disclosure.

[0048] Figure 7A The present invention is a flowchart of performing a key update on an IKE SA using a lightweight key update method according to an embodiment of the present disclosure.

[0049] Figure 7B An example of the IKE SA key update request message format is shown.

[0050] Figure 7C An example of the NEW_SPI payload of IKE is shown.

[0051] Figure 7D An example of a lightweight SA payload of IKE is shown.

[0052] Figure 7E An example of the structure of a payload in which no proposal notification is selected is shown.

[0053] Figure 8 The flowchart is a flowchart of performing key update on IKE SA in a specific scenario according to an embodiment of the present disclosure.

[0054] Figure 9 FIG. 4 is another flowchart of performing a key update on an IKE SA using a lightweight key update method according to another embodiment of the present disclosure.

[0055] Figure 10A The flowchart is a flowchart of performing key update on an IPSec SA using a lightweight key update method according to an embodiment of the present disclosure.

[0056] Figure 10B An example of the IPSec SA key update request message format is shown.

[0057] Figure 10C An example of the NEW_SPI payload of AH is shown.

[0058] Figure 10D Two examples of lightweight SAs are shown, which are the payloads of the newly defined IPSec SAs.

[0059] Figure 11 The flowchart is a flowchart of performing key update on IPSec SA in a specific scenario according to an embodiment of the present disclosure.

[0060] Figure 12 FIG2 is another flowchart of performing key update on an IPSec SA using a lightweight key update method according to another embodiment of the present disclosure.

[0061] Figure 13 Schematic diagram of a network device serving as an initiator of a key update for an SA according to an embodiment of the present disclosure.

[0062] Figure 14 Schematic diagram of a network device serving as a responder for performing a key update on an SA according to an embodiment of the present disclosure.

[0063] Figure 15 FIG. 1 is a schematic diagram of a network device serving as a responder for performing a key update on an SA according to another embodiment of the present disclosure.

[0064] Figure 16 FIG. 1 is a schematic diagram of a network device according to an embodiment of the present disclosure serving as an initiator or responder of a key update for an SA.

[0065] Figure 17 Schematic diagram of a network system for updating a key of an SA according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0066] The present invention can be implemented in a variety of ways, such as a process, an apparatus, a system, a computer-readable medium (e.g., a computer-readable storage medium), or a computer network in which program instructions are sent via various types of optical or electronic communication links. In this specification, these implementations or any other form that the present invention may take may be referred to as techniques. In general, the order of the steps of the disclosed processes may be changed within the scope of the present invention.

[0067] Provided below are detailed descriptions of one or more embodiments of the present invention and accompanying drawings illustrating the principles of the present invention. Although the present invention is described in conjunction with these embodiments, the present invention is not limited to any embodiment. The scope of the present invention is limited only by the claims, and the present invention includes numerous alternatives, modifications, and equivalents. Many specific details are set forth in the following description to provide a thorough understanding of the present invention. These details are provided for illustrative purposes, and the present invention can be practiced according to the claims without some or all of these specific details. For the sake of clarity, technical information known in the technical field of the present invention is not described in detail to avoid unnecessary confusion in the present invention.

[0068] The following detailed description sets forth numerous specific details to provide a thorough understanding of the present invention. However, those skilled in the art will appreciate that the present disclosure may be practiced without these specific details. In other instances, well-known methods, procedures, components, modules, units, and / or circuits have not been described in detail to avoid obscuring the present invention.

[0069] Although embodiments of the present invention are not limited in this regard, discussions using terms such as process, compute, determine, establish, create, examine, etc. may refer to operations and / or processes on a computer, computing platform, computing system, or other electronic computing device that manipulate and / or transform data (which data is represented as physical (e.g., electronic) quantities within computer registers and / or memories) into other data that is similarly represented as physical quantities within computer registers and / or memories, or other informational non-transitory storage media that may store instructions to perform the operations and / or processes.

[0070] Figure 1B The flowchart is for performing key update after IKE and IPSec SA are established between a first network device (eg, a requester or sometimes referred to as an initiator) and a second network device (eg, a responder).

[0071] In the disclosed embodiments, the first network device or the second network device may include any one of a computer, a mobile device (e.g., a mobile phone), a remote health monitoring device, a gateway, a router, a server, an access point (AP) device embedded with a sensor, or a home or personal device with an IP stack. In particular, one of the network devices may be a device with limited power, processing power, or bandwidth capabilities. The present invention is particularly advantageous for such situations because the size and / or number of payloads can be reduced overall, thereby saving processing power, time, and therefore power consumption.

[0072] Similarly, in the disclosed embodiments, another of the network devices may be a security gateway / ePDG or a CRAN / Cloud-based device that can support multiple IKE / IPSec tunnels. In this case, by reducing the amount of data transmitted, bandwidth and packet fragmentation can be reduced, thereby reducing processing requirements.

[0073] The IKE SA and IPSec SA are established (operation 110) after performing the initial exchange including the IKE_SA_INIT and IKE_AUTH exchanges (operations 102 to 108). These initial exchanges typically include four messages, but this number may increase in some scenarios. The first pair of messages (IKE_SA_INIT) negotiates the encryption suite, exchanges random numbers and Diffie-Hellman (DH). The second pair of messages (IKE_AUTH) authenticates the previous messages, exchanges identities and certificates, negotiates the encryption suite and traffic selector (TS), and establishes the first sub-SA. A portion of these messages is encrypted and integrity protected using the keys established through the IKE_SA_INIT exchange. The messages after the initial exchange are encrypted and protected using the encryption algorithm and keys negotiated in the IKE_SA_INIT exchange. For each of the IKE SA and IPSec SA, the key usage time is typically limited, which can be called the SA lifecycle. When the lifecycle is about to expire, the SA is rekeyed by creating a new SA and deleting the old SA. For the detailed process of the initial exchange, those skilled in the art refer to RFC 7296, the entire content of which is incorporated herein by reference, except where contrary to the explicit disclosure herein.

[0074] After establishing the IKE SA and the IPSec SA (operation 110), if either of the lifecycle of the IKE SA and the lifecycle of the IPSec SA is about to expire, the first network device and the second network device perform an SA key update procedure.

[0075] It should be understood that either the first network device or the second network device can initiate an SA key update request, as each device can maintain a lifecycle policy on its own side that manages the lifecycle of the SA. In another embodiment, the SAs shared by both parties can have the same lifecycle. The first network device or the second network device can periodically trigger SA key updates. In other scenarios, a device can detect the expiration time of each SA associated with the device, and then, if the device detects that the key of an IKE SA or IPSec SA is about to expire, it initiates the SA key update process.

[0076] As the name implies, an SA rekeying involves creating an SA with a new key that has the same attributes as the current SA, unless there is a policy change. This policy change can occur, for example, when a child SA is rekeyed, by the end user changing the encryption policy (also known as the encryption suite) and / or the encryption suite lifecycle, or by the end user changing the flow policy (also known as flow information). Flow information can include source and destination IP addresses, port ranges or port numbers, etc. Rekeying an SA involves re-creating the key for that SA, i.e., changing the key. Other elements of the established SA may or may not be changed.

[0077] Taking the first network device initiating an IKE SA key update as an example, the first network device sends a key update request to the second network device for performing a key update on the IKE SA. In one embodiment, a CREATE_CHILD_SA exchange is used to perform a key update on the IKE SA. This exchange includes a request / response pair. The SA key update can be initiated by either end of the IKE SA (e.g., the first network device or the second network device) after the initial exchange is completed. The end initiating the SA key update can be considered the initiator, and the initiator's peer can be considered the responder.

[0078] According to one embodiment, performing a key update on the IKE SA may include at least the following operations:

[0079] Operation 112: The initiator sends a CREATE_CHILD_SA request to the responder for updating the key of the IKE SA.

[0080] The CREATE_CHILD_SA request contains an HDR, which is an IKE header (not a payload) and a payload. The payload includes an SA payload, a Ni payload, and a KEi payload. The SA payload includes one or more encryption suites provided by the SA, such as those supported by the initiator. The encryption suite may include an authentication algorithm, an encryption algorithm, and / or a DH group for key calculation. In addition, the SA payload may also include a new initiator security parameter index (SPI) provided in the SPI field of the SA payload. The new initiator SPI in the SA payload will be obtained by the responder, and a new key will be calculated on the responder side. The Ni payload includes a random number, and the KEi payload includes a Diffie-Hellman value. In this disclosure, the term "encryption suite" refers to a set of algorithms used to protect the SA. In the case of an IPsec SA or an IKE SA, the encryption suite may also call an IPsec security proposal or an IKE security proposal in some cases. The new initiator SPI can be used to identify the new IKE SA after a key update on the initiator side.

[0081] Operation 114: After receiving the request for updating the key of the IKE SA, the responder sends a CREATE_CHILD_SA response for updating the key of the IKE SA to the initiator.

[0082] The CREATE_CHILD_SA response includes an HDR and a payload, which includes an SA payload, an Nr payload, and a KEr payload. The SA payload includes the new responder SPI in the SPI field of the SA payload. The SA payload also includes the encryption suite selected by the responder from the initiator's offer. The Nr payload includes a random number, and if the selected encryption suite includes this group, the KE payload includes a Diffie-Hellman value. The new responder SPI can be used to identify the new IKE SA after a key update on the responder side. Therefore, the combination of the new responder SPI and the new initiator SPI is used to identify the new IKE SA. In addition, the new responder SPI in the SA payload is obtained by the initiator, and a new key is calculated on the initiator side.

[0083] Operation 116: Establish a new IKE SA. The new IKE SA is used to protect IKE control messages.

[0084] The new IKE SA, i.e. the IKE SA after the key is updated, inherits all the child SAs of the IKE SA. This means that after the key is successfully updated, the existing child SAs linked to the old IKE SA will be moved to the new IKE SA.

[0085] After the IKE CREATE_CHILD_SA exchange as shown in operations 112 and 114, a new IKE SA is created with the new key and the selected cipher suite and is identified with the new initiator SPI and new responder SPI, which are exchanged in the SA payload as described above.

[0086] Operation 118: The initiator sends an old IKE SA deletion request to the responder to delete the old SA.

[0087] The old IKE deletion request may include an HDR and a D payload. The D payload may include information such as the protocol identifier (ID) of the SA to be deleted. The deletion of the SA may be implemented according to RFC 7296 through an INFORMATIONAL exchange between the initiator and the responder. For example, Figure 1C An example of the structure of a delete request according to RFC 7296 is shown.

[0088] Operation 120: After receiving the old IKE SA deletion request, the responder sends an old IKE SA deletion response to the initiator.

[0089] The old IKE SA deletion response may include an HDR and a D payload. The D payload may include information such as the protocol ID of the SA to be deleted. SA deletion may be implemented according to RFC 7296 through an INFORMATIONAL exchange between the initiator and the responder.

[0090] refer to Figure 2 , provides an embodiment of a first network device initiating a child SA or IPSec SA key update. Similar to the IKE SA key update, the CREATE_CHILD_SA exchange can also be used to update the key of the child SA.

[0091] In this embodiment, updating the key of the IKE SA may include at least the following operations:

[0092] Operations 202 to 210 may refer to operations 102 to 110 .

[0093] Operation 212: The initiator sends a CREATE_CHILD_SA request to the responder for performing a key update on the child SA.

[0094] The CREATE_CHILD_SA request includes the HDR (which is the IKE header) and payloads, including the N(REKEY_SA) payload, SA payload, Ni payload, TSi and TSr payloads, and an optional KEi payload.

[0095] The REKEY_SA payload, defined in RFC 7296, is used to notify other peers that a rekey is being performed on an existing child SA. The SPI field in the REKEY_SA payload contains the SPI of the existing child SA being rekeyed. The responder can use this SPI to identify the SA. Additionally, the Protocol ID field in the REKEY_SA payload is set to match the protocol of the SA being rekeyed, for example, 3 for ESP and 2 for AH.

[0096] The SA payload includes the SA provision, such as one or more cipher suites supported by the initiator. The SA payload may also include a new initiator SPI provided in the SPI field of the SA payload.

[0097] The new initiator SPI can be used as the inbound SPI for the initiator of a new IPSec SA after a key update, and as the outbound SPI for the responder of a new IPSec SA after a key update. The Ni payload includes a random number, and the optional KEi payload includes a Diffie-Hellman value. The proposed traffic selector for the proposed child SA is included in the TSi payload and the TSr payload. The traffic selector includes flow information associated with the initiator to be rekeyed, which is used by the initiator for traffic communication, such as the address range (IPv4 or IPv6), port range, and IP protocol ID.

[0098] Assuming the responder accepts the proposal, the responder sends back the same TS payload. In another case, the responder is allowed to select a subset of the traffic proposed by the initiator. This may occur, for example, when the flow configuration of both ends is being updated, but only one end receives the new information. Because the two ends may be configured by different end users (such as network administrators), incompatibility may persist for a long time even without errors. When the responder selects a subset of the traffic proposed by the initiator, the traffic selector is narrowed down to a subset of the initiator's proposal (provided that the set has not become empty).

[0099] Operation 214: After receiving the request for updating the key of the child SA, the responder sends a CREATE_CHILD_SA response for updating the key of the child SA to the initiator.

[0100] The CREATE_CHILD_SA response includes an HDR and a payload, where the payload includes an SA payload, an Nr payload, a TSi and TSr payload, and an optional KEr payload.

[0101] The SA payload includes the new responder SPI in the SPI field of the SA payload. The new responder SPI can be used as the inbound SPI for the responder of a new IPSec SA after a key update, and as the outbound SPI for the initiator of a new IPSec SA after a key update. The SA payload also includes the cipher suite selected by the responder from the initiator's offer. The Nr payload contains a random number, and if the selected cipher suite includes this group, the KEr payload contains the Diffie-Hellman value.

[0102] As mentioned above, the responder can send the same TS payload back to the initiator, or it can select a subset of the traffic proposed by the initiator and send it back to the initiator.

[0103] In one embodiment, the responder performs the shrinking process as follows:

[0104] If the responder's policy does not allow acceptance of any part of the proposed traffic selector, it responds with a TS_UNACCEPTABLE notification message.

[0105] If the responder's policy allows the entire set of traffic covered by TSi and TSr, no reduction is required and the responder can return the same TSi and TSr values.

[0106] If the responder's policy allows acceptance of the first selectors of TSi and TSr, the responder narrows the traffic selector to a subset that includes the initiator's first selector.

[0107] If the responder's policy does not allow the first selector of TSi and TSr to be accepted, the responder narrows down to an acceptable subset of TSi and TSr.

[0108] Operation 216: Create a new IPSec SA.

[0109] After the new IPSec SA is established, the new IPSec SA (i.e., the IPSec SA after the rekey) is added to the IKE SA. The IPSec SA to be rekeyed is associated with this IKE SA, which means that there is a link between the IKE SA and its corresponding child SA. Therefore, the child SA created after the rekey is added to the IKE SA.

[0110] After the IKE CREATE_CHILD_SA exchange as shown in operations 212 and 214, a new IPSec SA is created with the new keys and the selected cipher suite and is identified with the new initiator SPI and new responder SPI, which are exchanged in the SA payload as described above.

[0111] Operation 218: The initiator sends an old sub-SA deletion request to the responder to delete the old SA.

[0112] The old sub-deletion request may include an HDR and a D payload. The D payload may include information such as the protocol ID of the SA to be deleted. SA deletion may be implemented according to RFC 7296 through an INFORMATIONAL exchange between the initiator and the responder.

[0113] Operation 220: After receiving the old sub-SA deletion request, the responder sends an old sub-SA deletion response to the initiator.

[0114] The old sub-SA deletion response may include an HDR and a D payload. The D payload may include information such as the protocol ID of the SA to be deleted. SA deletion may be implemented according to RFC 7296 through an INFORMATIONAL exchange between the initiator and the responder.

[0115] From the above Figures 1A-1C and Figure 2 As known from the prior art methods, when performing a rekey for an IKE SA, the exchange between the initiator and the responder includes an SA payload containing one or more cipher suites, even if the encryption policy (e.g., the encryption suite) associated with the rekey for the SA has not changed. In other words, even if the initiator and / or responder changes the encryption suites associated with them, the rekey exchange between the initiator and the responder still includes an SA payload containing one or more encryption suites. For IPSec SA rekey, when performing a rekey, the exchange between the initiator and the responder includes an SA payload containing one or more encryption suites, as well as TSi and TSr payloads, even if the encryption policy associated with the rekey and flow policy for the SA has not changed.

[0116] Since rekeying the SA is triggered periodically, bandwidth and power are consumed to process these payloads. The problem becomes more serious when there are multiple cipher suites, because in IKE SA and IPSec SA, the payload size increases proportionally with multiple cipher suites.

[0117] For example, reducing the size of IKEv2 messages is highly desirable for Internet of Things (IoT) devices that use low-power technologies. For some of these devices, transmitting additional bits over the network can be quite power-intensive. Many of these devices are battery-powered and lack the ability to recharge or replace batteries over the device's lifetime (often several years). Therefore, reducing the power consumption of these devices is crucial.

[0118] Furthermore, large UDP messages can also cause fragmentation at the IP level, which can cause poor interaction with Network Address Translators (NATs). In particular, some NATs will discard IP fragments that do not contain TCP / UDP port numbers (non-initial IP fragments). Most IoT devices have a single set of keys or do not want to change their selected key set during key updates.

[0119] In one example, when rekeying an IKE SA using the CREATE_CHILD_SA exchange, the minimum size of the SA payload (single cipher suite) is 52 bytes. In this embodiment, however, these payloads are replaced with the Notification Payload N (NEW_SPI) to obtain a 16-byte SPI, saving 36 bytes.

[0120] In another example, when the CREATE_CHILD_SA exchange is used to rekey the child SA, the minimum size of the SA payload is 40 bytes, and each TS is 24 bytes (2*24=48 bytes), so the total size is 88 bytes. In an embodiment of the present invention, these payloads are replaced with the notification payload N (NEW_SPI) to obtain an SPI of 12 bytes, thus saving a total of 76 bytes.

[0121] The present disclosure provides a lightweight key update scheme to solve the above-mentioned problems. In this scheme, when the encryption policy remains unchanged, the exchanges between the initiator and the responder during the IKE key update and the IPSec SA key update process do not carry SA payloads. Instead, the SPI is transmitted, for example, in a new notification type payload referred to herein as "NEW_SPI notification" (which can replace the existing SA payload), or in a new payload referred to herein as "lightweight SA payload", or in any other payload used to send the SPI. The NEW_SPI notification uses fewer bits than the existing SA payload. Another way to save transmission bits is that when the flow information has not changed, the exchanges between the initiator and the responder when the key of the IPSec SA is updated do not carry a TS payload. For example, the "lightweight SA payload" format can only include the SA payload header and the proposal payload. Therefore, compared with traditional payloads (such as those sent in Sai1 and SAr1), the payload is trimmed.

[0122] To implement the lightweight key update method, both ends can exchange their respective capabilities to perform the lightweight key update method. This exchange can be performed before the key update process, for example, during the initial exchange to establish the IKE or IPSec SA as described above.

[0123] According to one embodiment of the present disclosure, the exchange of lightweight key update capabilities may include the following operations between two peers:

[0124] The initiator sends a notification to the second network device to indicate that the initiator supports lightweight key update, for example, supports the key update optional payload.

[0125] The responder sends a response to indicate that the responder also supports lightweight key update, such as supporting the key update optional payload.

[0126] Through this initial support process, both ends can know whether the other end supports the lightweight key update method.

[0127] Figures 3A to 5Three different methods for negotiating lightweight key update support between an initiator and a responder are shown. All three methods use the initial exchange process to implement lightweight key update negotiation. As mentioned above, this disclosure is not limited to using only the initial exchange process to implement lightweight key update negotiation. Those skilled in the art will be able to conceive of other methods after reading this disclosure.

[0128] In such Figure 3A In the illustrated embodiment, the lightweight key update support notification is carried in the notification payload of the INIT request (e.g., IKE_SA_INIT request message) sent by the initiator to the responder, and correspondingly, the lightweight key update support confirmation is carried in the notification payload of the INIT response (e.g., IKE_SA_INIT response message) sent by the responder to the initiator. For example, Figure 3B The structure of the notification payload is shown, where the notification message type is IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED, which is a new notification message type different from the traditional notification payload. The new notification message type (such as IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED) is included in the notification payload and indicates that the initiator or responder supports lightweight key update.

[0129] In such Figure 4 In the illustrated embodiment, a notification of support for lightweight key update is carried in the Notification payload of an AUTH request (e.g., an IKE_SA_AUTH Request message) sent by the initiator to the responder. Correspondingly, a notification of support for lightweight key update is carried in the Notification payload of an AUTH request (e.g., an IKE_SA_AUTH Response message) sent by the responder to the initiator. The Notification payload type may be an IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED payload.

[0130] In such Figure 5 In the illustrated embodiment, a notification of support for lightweight key update is carried in the Notification payload of an INIT request (e.g., an IKE_SA_INIT request message) sent by the initiator to the responder. Correspondingly, a notification of support for lightweight key update is carried in the Notification payload of an AUTH response (e.g., an IKE_SA_AUTH response message) sent by the responder to the initiator. The Notification payload type may be an IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED payload.

[0131] It should be noted that lightweight key update negotiation may not be performed before the key update process (for example, during IKE INIT or AUTH), which means that the two parties have not reached an agreement on this. Then, if either the initiator or the responder is not allowed to send NEW_SPI or lightweight SA payload, the other party may discard it and regard it as an error.

[0132] Figure 6 The flowchart of using the lightweight key update method to update the key of SA.

[0133] After the IKE SA and IPSec SA are established between the initiator and responder, if the lifetime of either the IKE SA or the IPSec SA is nearing expiration according to the SA lifetime policy on each end, the initiator initiates a key update process, which may include the following operations:

[0134] Operation 602: The initiator determines whether the encryption suite associated with the initiator has changed.

[0135] In this disclosure, a cipher suite associated with an initiator means a cipher suite supported by the initiator and used for a specific SA established by the initiator, such as a key-updated SA (ie, a new SA) in the case of an SA key update.

[0136] After establishing an SA associated with a weak encryption suite, if the lifecycle of any SA is about to expire, the initiator wishes to rekey the SA by creating a new SA and deleting the SA to be rekeyed (also referred to as the old SA), with or without changing the encryption suite used for the old SA (also referred to as the encryption suite associated with the old SA). In other words, the fact that the encryption suite associated with the initiator has not changed means that the encryption suite used by the old SA can still be used for the SA after the rekey (i.e., the new SA). The fact that the encryption suite associated with the initiator has changed means that the encryption suite associated with the old SA is changed to another encryption suite that is supported by the initiator and used for the new SA (i.e., associated with the new SA). The following provides some situations in which the encryption suite associated with the initiator changes.

[0137] One scenario is when the initiator's supported cipher suites change. For example, the initiator currently supports only the first cipher suite (e.g., a weak cipher suite). After establishing the old SA, for some reason (e.g., the initiator plays a more important role and has higher security requirements), the network administrator configures the initiator through the user interface to change its support for the second cipher suite (a strong cipher suite). After the cipher suite is changed, if the initiator wishes to rekey the old SA, it must change the cipher suite for the new SA, as the initiator currently supports only strong cipher suites.

[0138] Another scenario is when the initiator's supported cipher suites haven't changed. For example, the initiator currently supports two or more cipher suites. During a rekey, for some reason, such as increased requirements for the SA (which necessitates a stronger cipher suite for the new SA), the initiator wishes to use a new cipher suite for the new SA instead of the one associated with the old SA. In this case, the rekey request sent by the initiator to the responder needs to include the second cipher suite for the new SA, since the first cipher suite associated with the old SA is no longer associated with the new SA. Figures 7A to 12 The detailed implementation is disclosed in the description.

[0139] Furthermore, another situation is that if the initiator only supports the first encryption suite, such as a weak encryption suite, and the initiator wishes to change the first encryption suite to the second encryption suite (for example, to a strong encryption suite) for some reason when performing a key update on the old SA. In this case, the initiator needs to be reconfigured because the initiator currently only supports the first encryption suite. The network administrator can choose to reconfigure the initiator to support the second encryption suite, or to support both the first encryption suite and the second encryption suite. And the configuration is stored in the initiator or some other database or device. For example, there is a correspondence between the initiator and the encryption suite supported by the initiator, and the correspondence can be stored in the initiator or some other place. The configuration process on the responder side is similar to the above configuration process. After reconfiguration, the initiator can select the second encryption suite to support and place the second encryption suite in the key update request for the SA key update exchange.

[0140] The following provides some scenarios where the cipher suite associated with the initiator does not change.

[0141] One situation is that the initiator only supports the first encryption suite, such as a weak encryption suite, and the initiator hopes to change the first encryption suite when updating the key of the old SA (that is, the first encryption suite is still used for the SA after the key is updated). The key update request sent by the initiator to the responder does not carry the encryption suite of the new SA because the first encryption suite associated with the old SA is still associated with the new SA.

[0142] Another case is that the initiator supports two or more encryption suites, such as a first encryption suite (e.g., a weak encryption suite) and a second encryption suite (e.g., a strong encryption suite), and the initiator does not want to change the first encryption suite to the second encryption suite when rekeying the old SA. In this case, the key update request sent by the initiator to the responder does not need to carry the encryption suite of the new SA, because the first encryption suite associated with the old SA is still used for the new SA. For detailed implementation, please refer to Figures 7A to 12 Description.

[0143] Operation 604: When the encryption suite associated with the initiator has not changed, the initiator sends a first key update request for updating the key of the SA to the responder.

[0144] As mentioned above, the fact that the cipher suite associated with the initiator has not changed means that the cipher suite used by the old SA can still be used for the SA after the key update (ie, the new SA). The initiator does not need to carry the cipher suite of the new SA.

[0145] The first key update request carries the first SPI and does not carry the encryption suite associated with the initiator because the initiator will not change the encryption suite after the SA is established; or the initiator has changed the encryption suite and the changed encryption suite is restored to the original encryption suite, and the current encryption suite is the same as the encryption suite when the SA was established.

[0146] In an IKE rekey scenario, the first SPI is the new initiator's SPI. Because an IKE SA can be identified by a pair of SPIs at both ends, when one end initiates a rekey, the rekey request includes a new SPI, which serves as the initiator's SPI for the new IKE SA after the rekey. When the responder responds to the IKE rekey, it adds the new SPI to the rekey response, which serves as the responder's SPI for the new IKE SA after the rekey.

[0147] In an IPSec SA rekey scenario, the first SPI serves as the inbound SPI for the initiator of the new IPSec SA after the rekey, and serves as the outbound SPI for the responder of the new IPSec SA after the rekey. Furthermore, as described above, the first rekey request also carries the SPI in the N[REKEY_SA] payload to identify the SA for which the rekey is to be performed.

[0148] The detailed implementation of this operation can be found in the following Figures 7A to 9 The IKE key update process is shown.

[0149] Operation 606: The responder sends a first key update response to the initiator. When the encryption suite associated with the responder has not changed, the first key update response carries the second SPI but does not carry the encryption suite associated with the second network device.

[0150] As described above, in the IKE key update scenario, the second SPI is the new responder SPI. When the responder responds to the IKE key update in the reply, the responder adds the new responder SPI in the key update response, which is used as the responder SPI of the new IKE SA after the key update.

[0151] In the IPSec SA key update scenario, the second SPI is used as the inbound SPI of the responder of the new IPSec SA after the key update, and is used as the outbound SPI of the initiator of the new IPSec SA after the key update.

[0152] The detailed implementation of this operation can be found in the following Figures 8 to 10A The IKE key update process is shown.

[0153] Operation 608: When the encryption suite associated with the first network device and the encryption suite associated with the second network device do not change, the initiator updates the key of the SA according to the first SPI and the second SPI.

[0154] Key update includes creating a new SA and deleting the old SA to be key updated. Specifically, the initiator uses the initiator SPI, responder SPI and the unchanged cipher suite to update the key of the SA. The unchanged cipher suite is used to obtain the new key of the new SA from the old SA. The detailed implementation method can be referred to as follows. Figures 7A to 9 The IKE key update process is shown.

[0155] Figure 7A FIG2 is a flow chart of performing a key update on an IKE SA according to an embodiment of the present disclosure. In this embodiment, the initiator does not change the cipher suite used when establishing the SA to be key updated, for example, a stronger cipher suite with a higher encryption algorithm set.

[0156] In this embodiment, there are two scenarios: the first scenario is that the responder does not change the encryption suite, and the second scenario is that the responder wants to change the encryption suite.

[0157] According to the first scenario of this embodiment, the IKE key update process includes the following operations:

[0158] Operation 702: The initiator sends an INIT request to the responder. In addition to the normal HDR header and payload described above, the INIT request also carries a notification payload. In this embodiment, the notification payload is the IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED payload, which indicates that the initiator supports lightweight rekeying.

[0159] Operation 704: The responder sends an INIT response to the initiator. In addition to the normal HDR header and payload described above, the INIT response also carries a notification payload. In this embodiment, the notification payload is the IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED payload, which indicates that the responder supports the lightweight rekey method.

[0160] According to the initial exchange discussed, after performing operations 706 and 708, an IKE SA and an IPSec SA are established between the initiator and the responder.

[0161] It should be understood that Figures 3A to 5 Other methods of negotiating lightweight key update capability described in can also be applied to this embodiment.

[0162] Operation 710: Establish IKE SA and IPSec SA, and the initiator periodically triggers IKE key update.

[0163] The initiator can periodically detect whether the lifecycle of the IKE SA is about to expire. As described above, the initiator can maintain a lifecycle policy on the initiator side. The lifecycle policy can set different lifecycles for different SAs. When the initiator detects that the lifecycle of the IKE SA is about to expire, operation 712 is performed.

[0164] Operation 712: The initiator sends a CREATE_CHILD_SA request to the responder for rekeying the IKE SA. The CREATE_CHILD_SA request includes an HDR header, a Ni payload, and a KEi payload. The CREATE_CHILD_SA request does not carry an SA payload (which carries one or more cipher suites), but instead carries a notification payload, such as a NEW_SPI notification. The SPI field of the NEW_SPI payload can carry the new initiator's SPI and does not carry a cipher suite. Figure 7B An example of the key update request message format is shown.

[0165] Alternatively, a lightweight SA payload or other payloads may be used to carry the new initiator SPI.

[0166] NEW_SPI is a newly defined notification payload that carries the initiator SPI, which identifies the new IKE SA after the key is updated.

[0167] For example, Figure 7C The NEW_SPI for IKE is shown.

[0168] For example, Figure 7D The following diagram shows the lightweight SA payload for IKE. In this example, the lightweight SA payload contains a single proposal payload without transcoding or attributes. Based on this structure, the value specified in "SPI" is used as the initiator / responder SPI for the IKE SA during an IKE key update.

[0169] Operation 714: The responder sends a CREATE_CHILD_SA response to the initiator for performing a key update on the IKE SA.

[0170] The CREATE_CHILD_SA response includes an HDR header, an Nr payload, and a KE payload. The CREATE_CHILD_SA response does not carry an SA payload (which carries one or more cipher suites), but instead carries a notification payload, such as a NEW_SPI notification. The SPI field in the NEW_SPI payload can carry the new responder SPI and does not carry a cipher suite.

[0171] Operation 716: Create a new IKE SA.

[0172] Specifically, as described above, in this scenario, neither the initiator nor the responder changes the cipher suite. A new IKE SA is created based on the initiator's SPI, the responder's SPI, and the original cipher suite. This original cipher suite is used to rekey the old SA. The new IKE SA protects IKE control messages. The new IKE SA, i.e., the rekeyed IKE SA, inherits all child SAs of the old IKE SA. This means that after a successful rekey, any existing child SAs linked to the old IKE SA are moved to the new IKE SA.

[0173] Operation 718: The initiator sends an old IKE SA deletion request to the responder to delete the old IKE SA.

[0174] The old IKE deletion request may include an HDR and a D payload. The D payload may include information such as a protocol identifier (ID) indicating the old SA to be deleted. For detailed implementation, please refer to operation 216.

[0175] Operation 718: After receiving the old IKE SA deletion request, the responder sends an old IKE SA deletion response to the initiator.

[0176] The old IKE SA deletion response may include an HDR and a D payload. The D payload may include information such as the protocol ID of the SA to be deleted. For detailed implementation, please refer to operation 218.

[0177] For example, by using the lightweight key update method described in this embodiment, the NEW_SPI notification payload can save a minimum of 36 bytes. The number of bytes saved increases proportionally for multiple cipher suites, which reduces the processing of complex authentication and thus reduces the processing of SA payloads in the IKE key update exchange. For example, the size of the NEW_SPI notification payload can be in the range of 12 to 16 bytes.

[0178] Figure 8A second scenario is shown in which the responder changes the cipher suite currently used by the responder (e.g., the cipher suite used when establishing the SA to be rekeyed). In this case, in operation 814, the responder may send a no proposal chosen notification payload to the initiator in the CREATE_CHILD_SA response, rather than a NEW_SPI notification or an SA payload carrying the changed cipher suite. The no proposal chosen notification payload may be a NO_PROPOSAL_CHOSEN payload, which indicates that there is no matching cipher suite in the cipher suite carried in the CREATE_CHILD_SA request. The initiator, upon receiving this indication, then resends the CREATE_CHILD_SA request, but this time with an SA payload carrying the updated cipher suite, to renegotiate the cipher suite with the responder until the initiator and responder reach an agreement on the cipher suite. The cipher suite renegotiation process may refer to any of the scenarios described in this disclosure. An example of renegotiation is described below.

[0179] In this example, operations 802-812 are the same as operations 702 to 712 described above. However, in operation 814, the CREATE_CHILD_SA response carries an HDR header and a notification payload. The notification payload may be a NO_PROPOSAL_CHOSEN type payload, which indicates that there is no matching encryption suite in the encryption suite carried in the CREATE_CHILD_SA request. For example, Figure 7E The structure of the notification payload is shown, where the notification message type is NO_PROPOSAL_CHOSEN. Therefore, for other new notifications disclosed in this document, the traditional notification structure is used, but with the new notification type. Then, after receiving the indication, the initiator resends the CREATE_CHILD_SA request, which carries the SA payload (which carries the updated encryption suite) to renegotiate the encryption suite with the responder until the initiator and the responder reach an agreement on the encryption suite. The encryption suite renegotiation process can refer to any of the scenarios described in this disclosure. An example of renegotiation is described below.

[0180] Then, in operation 816, the initiator resends the CREATE_CHILD_SA request to the responder. This second CREATE_CHILD_SA request includes an HDR header, an N(REKEY_SA) payload, an SA payload, a Ni payload, and an optional KEi payload. The contents of the Ni and KEi payloads can be found in operations 212 and 712. The SA payload carries an SPI field, which contains the new initiator's SPI and one or more cipher suites proposed by the initiator.

[0181] In operation 818, the responder sends a CREATE_CHILD_SA response to the initiator. The CREATE_CHILD_SA response carries an HDR header, an SA payload, an Nr payload, and a KEr payload.

[0182] Operation 820: Create a new IKE SA. The implementation of this operation can refer to the above-mentioned operation 716.

[0183] Operation 820: The initiator sends an old IKE SA deletion request to the responder to delete the old IKE SA.

[0184] The old IKE deletion request may include an HDR and a D payload. The D payload may include information such as the protocol ID of the SA to be deleted. For detailed implementation, please refer to operations 216 and 718 described above.

[0185] Operation 822: After receiving the old IKE SA deletion request, the responder sends an old IKE SA deletion response to the initiator.

[0186] The old sub-SA deletion response may include an HDR and a D payload. The D payload may include information such as the protocol ID of the SA to be deleted. For detailed implementation, please refer to operations 218 and 720 described above.

[0187] Figure 9 FIG2 is a flow chart of performing a key update on an IKE SA according to an embodiment of the present disclosure. In this embodiment, the initiator changes the encryption suite.

[0188] This embodiment includes three scenarios. The first scenario is that the responder does not change the encryption suite. For example, in this scenario, the initiator may support two encryption suites (e.g., a weak encryption suite and a strong encryption suite) and wish to change from the weak encryption suite to the strong encryption suite, but the responder only supports the weak encryption suite and does not wish to change the encryption suite. In this case, the responder may not negotiate the encryption suite with the initiator, but may use a lightweight key update method. For example, the responder may use a NEW_SPI notification, a lightweight SA payload, or any other payload to include the responder SPI.

[0189] The second scenario involves the responder changing the cipher suite. For example, in this scenario, the initiator supports two cipher suites (e.g., a weak cipher suite and a strong cipher suite) and wishes to change the weak cipher suite to a strong one. The responder also wishes to change the weak cipher suite (the one used when the SA to be rekeyed was first established) to a strong one. In this case, the responder can include an SA payload (with the strong cipher suite) in the rekey response.

[0190] The third scenario is that the responder changes the encryption suite. For example, in this scenario, the initiator only supports one suite (such as a strong encryption suite) and wants to change the weak encryption suite to a strong encryption suite, while the responder only supports weak encryption suites. In this case, the responder sends a notification payload to indicate that there is no matching encryption suite in the encryption suite carried in the key update request sent by the initiator. Then, after receiving the indication, the initiator will resend the key update request, but this time carrying an SA payload (which carries the updated encryption suite) to renegotiate the encryption suite with the responder until the initiator and the responder reach an agreement on the encryption suite. The encryption suite renegotiation process can refer to any scenario described in this disclosure.

[0191] According to this embodiment, the IKE key update process includes the following operations:

[0192] The detailed implementation of operations 902 to 910 can be found in Figure 7A Operations 702 to 710 described in .

[0193] Operation 912: The initiator sends a CREATE_CHILD_SA request to the responder for rekeying the IKE SA. The CREATE_CHILD_SA request includes an HDR header, an SA payload, a Ni payload, and a KEi payload. The information contained in each payload can be found in operation 112. In this case, for example, the SA payload contains two encryption suites, such as a weak encryption suite and a strong encryption suite.

[0194] Operation 914: The responder sends a CREATE_CHILD_SA response to the initiator to rekey the IKE SA. The CREATE_CHILD_SA response includes an HDR header, an Nr payload, and a KEr payload. The CREATE_CHILD_SA request does not carry an SA payload (which carries the cipher suite), but instead carries a notification payload, such as a NEW_SPI notification. The SPI field of the NEW_SPI payload carries the new responder SPI and does not carry the cipher suite.

[0195] It should be understood that in operation 914, as an optional manner, the responder may send a CREATE_CHILD_SA response carrying an SA payload that carries the currently used (i.e., used when establishing the SA) encryption suite and the new responder SPI, even if the responder does not want to change the currently used encryption suite.

[0196] According to the second scenario of this embodiment, when the responder wishes to change the currently used encryption suite, for example, to change a weak encryption suite to a strong encryption suite, the CREATE_CHILD_SA response carries an SA payload that carries the changed encryption suite, i.e., the strong encryption suite, which the initiator supports.

[0197] The detailed implementation of operations 916 to 918 can be found in Figure 8 Operations 716 to 718 and Figure 2 Operations 216 to 218 described in .

[0198] According to a third scenario of this embodiment, for example, the initiator supports only one encryption suite (e.g., a strong encryption suite) and changes the encryption suite, for example, changing a weak encryption suite to a strong encryption suite. The responder only supports the weak encryption suite. In this scenario, the encryption suite in the responder does not match the encryption suite proposed by the initiator. In operation 914, after determining that there is no match between the responder and the initiator regarding the encryption suite, the responder may send a "No Proposal Chosen Notification" payload to the initiator in a CREATE_CHILD_SA response, rather than an SA payload. The "No Proposal Chosen Notification" payload may be a NO_PROPOSAL_CHOSEN payload, indicating that there is no matching encryption suite in the encryption suite carried in the CREATE_CHILD_SA request. After receiving this indication, the initiator resends a CREATE_CHILD_SA request carrying an SA payload with the updated encryption suite to renegotiate the encryption suite with the responder until the initiator and responder reach an agreement on the encryption suite. The encryption suite renegotiation process may refer to any of the scenarios described in this disclosure.

[0199] For example, by introducing the NEW_SPI notification payload in the IKE key update, a minimum of 36 bytes can be saved for each IKE key update, thereby reducing the processing of complex verification and the processing of the SA payload.

[0200] Figure 10A The following is a flowchart illustrating rekeying an IPsec SA according to an embodiment of the present disclosure. In this embodiment, the initiator does not change the encryption suite used when establishing the SA to be rekeyed, for example, a stronger encryption suite with a higher encryption algorithm set. Regarding flow information, the initiator may or may not change it. If the initiator does not change the flow information, the rekey request does not need to carry a TS payload. However, if the initiator changes the flow information, the rekey request carries the flow information to reflect the changed flow information, such as the address range, port range, and IP protocol ID.

[0201] In this embodiment, there are two scenarios: the first scenario is that the responder does not change the encryption suite, and the second scenario is that the responder changes the encryption suite.

[0202] It should be understood that in the case where both the IKE SA and the IPSec SA are rekeyed simultaneously, the operations (i.e., the negotiation of the IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED message in the IKE_SA_INIT or AUTH request message, and / or the negotiation of the "NEW_SPI Notification" or "Lightweight SA Payload" or any other payload containing the SPI for rekeying the SA) remain similar to the embodiments described in this disclosure. If rekeying is performed simultaneously, it is preferred that the rekeying procedures be performed independently without merging the messages.

[0203] According to the first scenario of this embodiment, the IPsec key update process includes the following operations:

[0204] The detailed implementation of operations 1002 to 1010 can be found in Figure 8 Operations 802 to 810 described in .

[0205] Operation 1012: The initiator sends a CREATE_CHILD_SA request to the responder for performing a key update on the child SA.

[0206] When the initiator does not change the stream information, the CREATE_CHILD_SA request includes an HDR header, an N(REKEY_SA) payload, a NEW_SPI payload, a Ni payload, and an optional KEi payload, but does not include a TS payload. The N(REKEY_SA) payload carries an SPI to indicate the child SA for which the key update is to be performed. The contents of the Ni payload and the KEi payload can refer to operation 212. The CREATE_CHILD_SA request does not carry an SA payload (which carries one or more encryption suites), but carries a notification payload, such as a NEW_SPI notification payload. The SPI field of the NEW_SPI payload carries the new initiator SPI and does not carry an encryption suite. Alternatively, a lightweight SA payload or other payload can be used to carry the new initiator SPI.

[0207] NEW_SPI is a newly defined notification payload that carries the initiator SPI, which identifies the new IPSec SA after the key is updated. Figure 10B An example of the key update request message format is shown, which shows the new fields in the IPSec key update request (such as NEW_SPI notification payload).

[0208] For example, Figure 10C The NEW_SPI for AH is shown.

[0209] For example, Figure 10D Two lightweight SAs are shown, which are newly defined payloads for IPSec SA. Figure 10D As shown, the top lightweight SA payload contains a single proposal payload without transcoding or attributes, while the lower lightweight SA payload contains an SA bundle. There are two methods for establishing an IPSec tunnel: one using either AH or ESP, and the other using both AH and ESP, also known as SA bundles. SA bundles are used when you want to use both AH and ESP.

[0210] In case of IPSec key update, the value mentioned in the "SPI" field is used as the inbound / outbound direction SPI for the AH / ESP SA.

[0211] Alternatively, when the initiator changes the flow configuration, for example, when changing the flow information such as the IP address range of the new SA after the key update, in addition to the payloads mentioned above, the CREATE_CHILD_SA request may also carry a TS payload. The content of the TS payload can be referred to in operation 212.

[0212] Operation 1014: The responder sends a CREATE_CHILD_SA response to the initiator for performing a key update on the child SA.

[0213] The CREATE_CHILD_SA response includes an HDR header, an Nr payload, and an optional KEr payload (depending on whether the CREATE_CHILD_SA request carries a KEi payload). The CREATE_CHILD_SA response does not carry an SA payload (which carries one or more cipher suites), but instead carries a notification payload, such as a NEW_SPI notification. The SPI field in the NEW_SPI payload can carry the new responder SPI and no cipher suite.

[0214] Since the CREATE_CHILD_SA request does not carry a TS payload, which carries stream information associated with the initiator, the responder has the following two options for whether to carry a TS payload in the CREATE_CHILD_SA response:

[0215] The first option is that when the flow information associated with the responder has not changed and the currently used flow information is still used for the new IPSec SA after the key update, the CREATE_CHILD_SA response does not carry the TS payload associated with the responder.

[0216] The second option is that when the flow information associated with the responder changes, the CREATE_CHILD_SA response carries a TS unacceptable notification. The TS unacceptable notification can be a TS_UNACCEPTABLE notification payload, which is used to indicate that the information between the initiator and the responder does not match. Then, after receiving the TS unacceptable notification, the initiator resends the CREATE_CHILD_SA request, which this time carries a TS payload, and the TS payload carries the updated flow information to renegotiate the flow information with the responder until the initiator and the responder reach an agreement on the flow information. The renegotiation process of the flow information can refer to any scenario of the encryption suite negotiation or the flow information negotiation as described in the present disclosure.

[0217] It should be noted that if either the encryption suite negotiation or the flow information negotiation fails in the first round of negotiation, both ends can renegotiate both the encryption suite and the flow information in the second round of negotiation. In this case, the resent CREATE_CHILD_SA request can be sent with or without the SA payload to renegotiate the encryption suite and negotiate the flow information with the responder. For details on the encryption suite, refer to any of the IPSec SA encryption suite scenarios described in this disclosure.

[0218] It should be understood that encryption suite negotiation and stream information negotiation can be performed independently. In this case, both ends can record the encryption suite agreement reached in the first round of negotiation. The resent CREATE_CHILD_SA request in the second round of negotiation can renegotiate the encryption suite without carrying or without an SA payload.

[0219] When the initiator changes the stream information and, accordingly, the CREATE_CHILD_SA request carries a TS payload (which carries the changed stream information associated with the initiator), the responder has the following three options regarding whether to carry the TS payload in the CREATE_CHILD_SA response:

[0220] The first option is that when the stream information associated with the responder has not changed and the currently used stream information associated with the responder exists in the stream information associated with the initiator carried in the CREATE_CHILD_SA request, the CREATE_CHILD_SA response does not carry a TS payload.

[0221] The second option is to include a TS payload in the CREATE_CHILD_SA response when the flow information associated with the responder changes and the responder selects the flow information associated with the initiator carried in the CREATE_CHILD_SA request as the flow information associated with the responder. As described in operation 212, the responder can select a subset of the flows proposed by the initiator, i.e., narrow the flow selector to a subset of the initiator's proposal. The responder can also send the same TS payload to the initiator.

[0222] The third option is that when there is no matching flow information between the flow information proposed by the initiator carried in the CREATE_CHILD_SA request and the flow information support, the CREATE_CHILD_SA response carries a TS unacceptable notification to indicate that there is no matching flow information. Then, after receiving the notification, the initiator resends the CREATE_CHILD_SA request, which carries a TS payload, and the TS payload carries the updated flow information to renegotiate the flow information with the responder until the initiator and the responder reach an agreement on the flow information. As described in the present disclosure, if necessary, the process of renegotiation of flow information can refer to any scenario of encryption suite negotiation or flow information negotiation. As described above, the renegotiation process can perform encryption suite negotiation and flow information negotiation together, or can perform the failed flow information negotiation only in the first negotiation round without renegotiating the encryption suite that has been agreed upon.

[0223] The detailed implementation of operations 1016 to 1020 can be found in Figure 8 Operations 716 to 720 and Figure 2 Operations 216 to 220 described in .

[0224] For example, in IPSec key updates, the NEW_SPI notification payload can save a minimum of 76 bytes, and the number of bytes saved increases proportionally when there are multiple cipher suites and / or TS payloads. This reduces the processing of complex authentication, thereby reducing the processing of SA, TSi, and TSr payloads.

[0225] Figure 11 The second scenario of this embodiment is shown, in which the responder changes the encryption suite, for example, the responder changes the encryption suite currently used by the responder when establishing the SA to be key updated.

[0226] In this scenario, operations 1102 to 1112 are the same as the above operations. However, in operation 1114, the CREATE_CHILD_SA response carries an HDR header, a no-proposal-chosen notification payload, or a TS unacceptable notification payload. The no-proposal-chosen notification payload may be a NO_PROPOSAL_CHOSEN payload, which is used to indicate that there is no matching encryption suite in the encryption suite carried in the CREATE_CHILD_SA request. The TS unacceptable notification payload may be a TS_UNACCEPTABLE notification, which is used to indicate that there is no matching stream information in the stream information carried in the CREATE_CHILD_SA request. Then, after receiving the indication, the initiator resends the CREATE_CHILD_SA request, which carries an SA payload, and the SA payload carries the updated encryption suite to renegotiate the encryption suite with the responder until the initiator and the responder reach an agreement on the encryption suite. The encryption suite renegotiation process may refer to any scenario described in the present disclosure. An example of renegotiation is described below.

[0227] In operation 1116 , the initiator resends the CREATE_CHILD_SA request to the responder (which may be referred to as a second CREATE_CHILD_SA request).

[0228] The second CREATE_CHILD_SA request includes an HDR header, an N(REKEY_SA) payload, an SA payload, an Ni payload, an optional KEi payload, and an optional TS payload (depending on whether the initiator changes the stream information). The N(REKEY_SA) payload carries the SPI, which indicates the child SA for which the key update is to be performed. The contents of the Ni and KEi payloads can be found in operations 212 and 1012. The SA payload carries an SPI field, which carries the new initiator's SPI and one or more cipher suites proposed by the initiator.

[0229] In operation 1118, the responder sends a CREATE_CHILD_SA response to the initiator. The CREATE_CHILD_SA response carries an HDR header, an N(REKEY_SA) payload, a NEW_SPI notification payload or an SA payload, an NR payload, an optional KEr response (depending on whether the CREATE_CHILD_SA request carries a KEi payload), and an optional TS payload carrying stream information associated with the responder (depending on whether the responder changes the stream information associated with the responder). It should be understood that during the renegotiation process, encryption suite negotiation and stream information negotiation can be performed according to any of the encryption suite negotiation methods and stream information negotiation methods described in the present disclosure.

[0230] Operation 1120: The implementation of this operation may refer to the operation 216 described above.

[0231] Operation 1122: The initiator sends an old IPSec SA deletion request to the responder to delete the old IPSec SA.

[0232] The old sub-deletion request may include an HDR and a D payload. The D payload may include an SPI identifying the SA to be deleted. For detailed implementation, please refer to operation 216.

[0233] Operation 1124: After receiving the old IPSec SA deletion request, the responder sends an old IPSec SA deletion response to the initiator.

[0234] The old sub-SA deletion response may include an HDR and a D payload. The D payload may include an SPI identifying the SA to be deleted. For detailed implementation, please refer to operation 218.

[0235] The renegotiation process combines encryption suite negotiation and stream information negotiation. If either negotiation fails, a renegotiation process is triggered, which renegotiates both the encryption suite and stream information. As mentioned above, encryption suite negotiation and stream information negotiation can be performed separately.

[0236] The following describes the flow information negotiation of the second scenario.

[0237] In operation 1112, when the CREATE_CHILD_SA request does not carry a TS payload (the TS payload carries stream information associated with the initiator), in operation 1114, the responder may have the following two options regarding whether to carry a TS payload in the CREATE_CHILD_SA response:

[0238] The first option is that when the flow information associated with the responder has not changed and the currently used flow information is still used for the new IPSec SA after the key update, the CREATE_CHILD_SA response does not carry the TS payload associated with the responder.

[0239] The second option is that when the flow information associated with the responder changes, the CREATE_CHILD_SA response carries a TS unacceptable notification. The TS unacceptable notification can be a TS_UNACCEPTABLE notification payload, which is used to indicate that the information between the initiator and the responder does not match. Then, after receiving the TS unacceptable notification, the initiator resends the CREATE_CHILD_SA request, which carries a TS payload, and the TS payload carries the updated flow information to renegotiate the flow information with the responder until the initiator and the responder reach an agreement on the flow information. As described in the present disclosure, if necessary, the process of renegotiation of flow information can refer to any scenario of encryption suite negotiation or flow information negotiation.

[0240] It should be noted that if either the encryption suite negotiation or the flow information negotiation fails in the first round of negotiation, both ends can renegotiate both the encryption suite and the flow information in the second round of negotiation. In this case, the resent CREATE_CHILD_SA request can be sent with or without the SA payload to renegotiate the encryption suite and negotiate the flow information with the responder. If necessary, the encryption suite details can be referred to in any of the IPSec SA encryption suite scenarios described in this disclosure.

[0241] It should be understood that encryption suite negotiation and stream information negotiation can be performed independently. In this case, both ends can record the encryption suite agreement reached in the first round of negotiation. The resent CREATE_CHILD_SA request in the second round of negotiation can renegotiate the encryption suite without carrying or without an SA payload.

[0242] It should be understood that during a second key update request with an updated cryptographic suite or TS, the device can reuse the SPI in the NEW_SPI notification or lightweight SA payload, or during a second key update request with a new cryptographic suite, the device can completely generate a new SPI. This method can be applied to the renegotiation process as discussed in the present disclosure.

[0243] When the initiator changes the stream information and, accordingly, the CREATE_CHILD_SA request carries a TS payload (which carries the changed stream information associated with the initiator), the responder has the following three options regarding whether to carry the TS payload in the CREATE_CHILD_SA response:

[0244] The first option is that when the stream information associated with the responder has not changed and the currently used stream information associated with the responder exists in the stream information associated with the initiator carried in the CREATE_CHILD_SA request, the CREATE_CHILD_SA response does not carry a TS payload.

[0245] The second option is to include a TS payload in the CREATE_CHILD_SA response when the flow information associated with the responder changes and the responder selects the flow information associated with the initiator carried in the CREATE_CHILD_SA request as the flow information associated with the responder. As described in operation 212, the responder can select a subset of the flows proposed by the initiator, i.e., narrow the flow selector to a subset of the initiator's proposal. The responder can also send the same TS payload to the initiator.

[0246] A third option is that when there is no matching flow information between the flow information proposed by the initiator carried in the CREATE_CHILD_SA request and the flow information supported, the CREATE_CHILD_SA response carries a TS unacceptable notification to indicate that there is no matching flow information. Then, after receiving the notification, the initiator resends the CREATE_CHILD_SA request with a TS payload carrying updated flow information to renegotiate the flow information with the responder until the initiator and responder reach an agreement on the flow information. As described in the present disclosure, if necessary, the process of renegotiation of flow information can refer to any scenario of encryption suite negotiation or flow information negotiation.

[0247] As described above, the renegotiation process may perform the encryption suite negotiation and the stream information negotiation together, or may perform only the failed negotiation in the first round of negotiation.

[0248] Figure 12 The present invention is a flowchart of performing a key update on an IPsec SA according to an embodiment of the present disclosure. In this embodiment, the initiator changes the encryption suite used when establishing the SA to be key updated, for example, changing a weak encryption suite to a stronger encryption suite, such as a stronger encryption suite with a higher encryption algorithm set. With respect to flow information, the initiator may or may not change the flow information. When the initiator does not change the flow information, the key update request does not need to carry a TS payload. Conversely, when the initiator changes the flow information, the key update request will carry the flow information to reflect the changed flow information, such as any of the address range, port range, IP protocol ID, etc.

[0249] There are three scenarios in this embodiment. The first scenario is that the responder does not change the encryption suite. In this scenario, the responder may not negotiate the encryption suite with the initiator and use a lightweight key update method. For example, the responder can use a NEW_SPI notification or a lightweight SA payload or any other payload to include the responder SPI. The second scenario is that the responder changes the encryption suite. In this case, the responder can carry an SA payload (which carries the changed encryption suite) in the key update response. The third scenario is that the encryption suite carried in the key update request does not match the encryption suite supported by the responder. In this case, the responder sends a notification payload to indicate that there is no matching encryption suite in the encryption suite carried in the key update request sent by the initiator. Then, the two ends renegotiate the encryption suite until an agreement is reached on the encryption suite. Detailed negotiation of the encryption suite can refer to the corresponding Figure 9 Detailed description.

[0250] Return Reference Figure 12 , which is a flowchart according to this embodiment, including the following operations.

[0251] The detailed implementation of operations 1202 to 1210 can be found in Figure 8 Operations 802 to 810 described in .

[0252] Operation 1212: The initiator sends a CREATE_CHILD_SA request to the responder for rekeying the IPsec SA. The CREATE_CHILD_SA request includes an HDR header, an N(REKEY_SA) payload (carrying the SPI indicating the child SA to be rekeyed), an SA payload (carrying one or more cipher suites and the new initiator SPI), an Ni payload, an optional KEi payload, and an optional TS payload (depending on whether the initiator changes the stream information associated with the initiator). For detailed information about each payload, see operation 112.

[0253] Operation 914: The responder sends a CREATE_CHILD_SA response to the initiator for rekeying the IPsec SA. The CREATE_CHILD_SA response includes an HDR header, a NEW_SPI notification payload or an SA payload (depending on whether the responder changes the cipher suite associated with the responder), an Nr payload, an optional KEr payload (depending on whether the CREATE_CHILD_SA request includes a KEi payload), and an optional TS payload (depending on whether the responder changes the stream information associated with the responder). The SPI field of the NEW_SPI payload may carry the new responder SPI and not the cipher suite.

[0254] It should be understood that in operation 1214, as an optional manner, the responder may send a CREATE_CHILD_SA response carrying an SA payload that carries the currently used (i.e., used when establishing the SA) encryption suite and the new responder SPI, even when the responder does not change the currently used encryption suite.

[0255] According to the second scenario of this embodiment, the responder changes the currently used encryption suite. The CREATE_CHILD_SA response carries an SA payload, which carries the changed encryption suite, and the initiator also supports the changed encryption suite.

[0256] The detailed implementation of operations 1216 to 1218 can be found in Figure 8 Operations 816 to 818 and Figure 2 Operations 216 to 218 described in .

[0257] According to the third scenario of this embodiment, the encryption suite in the CREATE_CHILD_SA request does not match the encryption suite that the responder wishes to change. In this scenario, in operation 1214, the responder may send a no proposal chosen notification payload to the initiator in the CREATE_CHILD_SA response instead of the SA payload. The no proposal chosen notification payload may be a NO_PROPOSAL_CHOSEN payload, which is used to indicate that there is no matching encryption suite in the encryption suite carried in the CREATE_CHILD_SA request. Then, after receiving the indication, the initiator resends the CREATE_CHILD_SA request carrying the SA payload, which carries the updated encryption suite, to renegotiate the encryption suite with the responder until the initiator and the responder reach an agreement on the encryption suite. If necessary, the encryption suite renegotiation process may refer to any of the scenarios described in this disclosure.

[0258] The flow information negotiation in this embodiment is described below.

[0259] In operation 1212, when the CREATE_CHILD_SA request does not carry a TS payload (the TS payload carries stream information associated with the initiator), in operation 1214, the responder may have the following two options regarding whether to carry a TS payload in the CREATE_CHILD_SA response:

[0260] The first option is that when the flow information associated with the responder has not changed and the currently used flow information is still used for the new IPSec SA after the key update, the CREATE_CHILD_SA response does not carry the TS payload associated with the responder.

[0261] The second option is that when the flow information associated with the responder changes, the CREATE_CHILD_SA response carries a TS unacceptable notification. The TS unacceptable notification can be a TS_UNACCEPTABLE notification payload, which is used to indicate that the information between the initiator and the responder does not match. Then, after receiving the TS unacceptable notification, the initiator resends the CREATE_CHILD_SA request, which carries a TS payload, and the TS payload carries the updated flow information to renegotiate the flow information with the responder until the initiator and the responder reach an agreement on the flow information. As described in the present disclosure, if necessary, the process of renegotiation of flow information can refer to either the encryption suite negotiation or the flow information negotiation method.

[0262] It should be noted that if either the encryption suite negotiation or the flow information negotiation fails in the first round of negotiation, both ends can renegotiate both the encryption suite and the flow information in the second round of negotiation. In this case, the resent CREATE_CHILD_SA request can be sent with or without the SA payload to renegotiate the encryption suite and to negotiate the flow information with the responder.

[0263] It should be understood that encryption suite negotiation and stream information negotiation can be performed independently. In this case, both ends can record the encryption suite agreement reached in the first round of negotiation. The resent CREATE_CHILD_SA request in the second round of negotiation can renegotiate the encryption suite without carrying or without an SA payload.

[0264] When the initiator changes the stream information and, accordingly, the CREATE_CHILD_SA request carries a TS payload (which carries the changed stream information associated with the initiator), the responder has the following three options regarding whether to carry the TS payload in the CREATE_CHILD_SA response:

[0265] The first option is that when the stream information associated with the responder has not changed and the currently used stream information associated with the responder exists in the stream information associated with the initiator carried in the CREATE_CHILD_SA request, the CREATE_CHILD_SA response does not carry a TS payload.

[0266] The second option is to include a TS payload in the CREATE_CHILD_SA response when the flow information associated with the responder changes and the responder selects the flow information associated with the initiator carried in the CREATE_CHILD_SA request as the flow information associated with the responder. As described in operation 212, the responder can select a subset of the flows proposed by the initiator, i.e., narrow the flow selector to a subset of the initiator's proposal. The responder can also send the same TS payload to the initiator.

[0267] A third option is that when there is no matching flow information between the flow information proposed by the initiator carried in the CREATE_CHILD_SA request and the flow information supported, the CREATE_CHILD_SA response carries a TS unacceptable notification to indicate that there is no matching flow information. Then, after receiving the notification, the initiator resends the CREATE_CHILD_SA request with a TS payload carrying updated flow information to renegotiate the flow information with the responder until the initiator and responder reach an agreement on the flow information. As described in the present disclosure, if necessary, the process of renegotiation of flow information can refer to any scenario of encryption suite negotiation or flow information negotiation.

[0268] As described above, the renegotiation process may perform the encryption suite negotiation or the stream information negotiation together, or may perform only the failed negotiation in the first round of negotiation.

[0269] For example, by introducing the NEW_SPI notification payload in IPsec key updates or not carrying the TS payload, a minimum of 76 bytes can be saved for each IPsec key update, thereby reducing the processing of complex verification and the processing of SA, TSi, and TSr payloads.

[0270] Figure 13 1300 is a schematic diagram of a network device according to an embodiment of the present disclosure. The network device is configured to perform a key update for a security association (SA) in a network system including a first network device (e.g., the initiator described in the above embodiments) and a second network device (e.g., the responder described in the above embodiments), wherein an IKE tunnel and an IPSec tunnel are established between the first and second network devices. In this embodiment, the network device serves as the first network device and includes a determination module 1302, a sending module 1304, a receiving module 1306, and a key update module 1308.

[0271] The determination module 1302 is used to determine whether the encryption suite associated with the first network device has changed. The sending module 1304 is used to send a first key update request for updating the key of the SA to the second network device when the encryption suite associated with the first network device has not changed, wherein the first key update request carries a first SPI and does not carry the encryption suite associated with the first network device. The receiving module 1306 is used to receive a first key update response from the second network device, wherein, when the encryption suite associated with the second network device has not changed, the first key update response carries a second SPI and does not carry the encryption suite associated with the second network device; the key update module 1308 is used to update the key of the SA according to the first SPI and the second SPI when the encryption suite associated with the first network device and the encryption suite associated with the second network device have not changed. The details of the implementation of the various modules of the network device of this embodiment can be referred to. Figure 7A and Figure 10A The implementation method of the initiator in the embodiment.

[0272] In another embodiment, the network device further includes: a renegotiation module 1310. When the encryption suite associated with the second network device changes, the first key update response carries a notification of no proposal being selected from the second network device. The renegotiation module 1310 is used to renegotiate with the second network device until the negotiated encryption suite is obtained, and the key update module 1308 is used to update the key of the SA based on the renegotiated encryption suite. It should be understood that the renegotiation module 1310 is used to determine whether to renegotiate the encryption suite or flow information in the case of an IPSec SA key update, and the renegotiation process is performed through the sending module 1304 and the receiving module 1306. In some embodiments, the renegotiation module 1310 can be incorporated into the determination module 1302. An example of a notification of no proposal being selected may be the NO_PROPOSAL_CHOSEN notification payload. Details of the renegotiation implementation method of the network device of this embodiment can be referred to. Figure 8 and Figure 11 The implementation method of the initiator in the embodiment.

[0273] It should be understood that the network device 1300 can implement the above Figures 1A to 12 The operation performed by the initiator in the embodiment of the present invention can be referred to the above embodiment for detailed implementation. No further details will be given here.

[0274] Figure 14FIG1 is a schematic diagram of another network device 1400 according to an embodiment of the present disclosure. Network device 1400 is configured to perform a key update for a security association (SA) in a network system including a first network device (e.g., the initiator described in the above embodiments) and a second network device (e.g., the responder described in the above embodiments), wherein an IKE tunnel and an IPSec tunnel are established between the first network device and the second network device. In this embodiment, the network device serves as the second network device and includes a receiving module 1402, a determining module 1404, a sending module 1406, and a key update module 1408.

[0275] The receiving module 1402 is used to receive a first key update request from the first network device for updating the key of the SA. The first key update request carries a first SPI and does not carry the encryption suite associated with the first network device. The determining module 1404 is used to determine whether the encryption suite associated with the second network device has changed. The sending module 1406 is used to send a first key update response to the first network device. When the encryption suite associated with the second network device has not changed, the first key update response carries a second SPI and does not carry the encryption suite associated with the second network device. Accordingly, the key update module 1408 is used to update the key of the SA according to the first SPI and the second SPI. The details of the implementation of each module in the network device of this embodiment can be referred to. Figure 7A and Figure 10A Description.

[0276] In another embodiment of network device 1400, when the encryption suite associated with the second network device changes, the first key update response carries a notification that no proposal was selected. Thus, receiving module 1402 is further configured to receive a second key update request from the first network device for rekeying the SA, the second key update request carrying the first SPI and the encryption suite associated with the first network device. Sending module 1406 is further configured to send a second key update response, the second key update response carrying another notification that no proposal was selected, indicating that no matching encryption suite exists for the encryption suite associated with the first network device carried in the second key update request. The network device also includes a renegotiation module 1410 configured to renegotiate with the first network device until a negotiated encryption suite is obtained. Thus, the SA is further rekeyed based on the renegotiated encryption suite. It should be understood that renegotiation module 1410 is configured to determine whether to renegotiate the encryption suite or flow information during an IPSec SA key update, and the renegotiation process is performed via sending module 1406 and receiving module 1402. In some embodiments, renegotiation module 1410 may be incorporated into determination module 1404. For details on the renegotiation implementation method of the network device in this embodiment, please refer to Figure 8 and Figure 11 The implementation method of the initiator in the embodiment.

[0277] It should be understood that the network device 1400 can implement the above Figures 1A to 12 The operation performed by the responder in the embodiment of FIG. Detailed implementation can be referred to the above embodiment. No further details will be given here.

[0278] Figure 15 FIG1 is a schematic diagram of another network device 1500 according to an embodiment of the present disclosure. Network device 1500 is used to perform a key update for a security association (SA) in a network system including a first network device (e.g., the initiator described in the above embodiments) and a second network device (e.g., the responder described in the above embodiments), with an IKE tunnel and an IPSec tunnel established between the first and second network devices. In this embodiment, the network device serves as the second network device and includes a receiving module 1502, a determining module 1504, a sending module 1506, and a key update module 1508.

[0279] The receiving module 1502 is used to receive a first key update request from the first network device for updating the key of the SA, and the first key update request carries a first SPI and an encryption suite associated with the first network device. The determining module 1504 is used to determine whether the encryption suite associated with the second network device has changed. The sending module 1506 is used to send a first key update response to the first network device. When the encryption suite associated with the second network device has not changed, the first key update response carries a second SPI and does not carry the encryption suite associated with the second network device. The key update module is used to update the key of the SA according to the first SPI and the second SPI. The implementation method of the key update can refer to the above Figures 6 to 12 Detailed description in .

[0280] In another embodiment of the network device 1500, the first key update response carries a notification that no proposal was selected, indicating that there is no matching encryption suite in the encryption suite associated with the first network device carried in the first key update request. In this case, the network device 1500 also includes a renegotiation module 1510 for renegotiating with the first network device until the negotiated encryption suite is obtained. Therefore, the SA is also rekeyed according to the negotiated encryption suite. It can be understood by those skilled in the art that the renegotiation module 1510 is used to determine whether to renegotiate the encryption suite or flow information in the case of an IPSec SA key update, and the renegotiation process is performed through the sending module 1506 and the receiving module 1502. In some embodiments, the renegotiation module 1510 can be incorporated into the determination module 1504. The details of the renegotiation implementation method of the network device 1500 in the above embodiment can be referred to. Figure 9 and Figure 12 Implementation of the responder in the embodiment.

[0281] Those skilled in the art will appreciate that the network device 1500 can implement the above Figures 1A to 12 The operation performed by the responder in the embodiment of FIG. Detailed implementation can be referred to the above embodiment. No further details will be given here.

[0282] Figure 16 FIG1 is a schematic diagram of another network device 1600 according to an embodiment of the present disclosure. The network device 1600 is used to update the key of a security association (SA) in a network system including a first network device (e.g., the initiator described in the above embodiment) and a second network device (e.g., the responder described in the above embodiment), and an IKE tunnel and an IPSec tunnel are established between the first network device and the second network device. In some embodiments, the network device 1600 can be used as Figures 1A to 12 The initiator described in the embodiment and executes Figures 1A to 12 In other embodiments, the network device 1600 can be used as Figures 1A to 12 The responder described in the embodiment and performs Figures 1A to 12 The operations of the responder described in the embodiment.

[0283] The network device includes a processor 1602, a memory 1604 coupled to the processor 1602, a transceiver (Tx / Rx) 1606, and a port 1608 coupled to the Tx / Rx 1606. The processor 1602 can be implemented as a general-purpose processor, or can be part of one or more application-specific integrated circuits (ASICs) and / or digital signal processors (DSPs). The processor 1602 can refer to a single processor or multiple processors. The memory 1604 can include a cache for temporarily storing content, such as a random-access memory (RAM). In addition, the memory 1604 can include a long-term memory, such as a read-only memory (ROM). When the processor 1602 is used as an initiator, it is used to execute Figures 1A to 12 When the processor 1602 is used as the responder, it is used to perform Figures 1A to 12 The operations of the responder described in the embodiment.

[0284] Furthermore, in one embodiment, the memory 1604 may include multiple software modules, such as Figure 13 In another embodiment, the memory 1604 may include multiple software modules, such as Figure 14 In another embodiment, the memory 1604 may include multiple software modules, such as Figure 15 The modules described in the embodiments.

[0285] By executing the instructions of the software module, the processor 1602 can perform various operations. In some embodiments, when the module is used to perform an operation, it can actually mean that the processor 1602 is used to execute the instructions in the module to perform the operation. By executing the instructions in the memory 1604, the processor 1602 can perform all or part of the operations performed by the software module. Figures 1A to 12 All operations performed by the initiator or responder as described in .

[0286] Figure 17FIG. 1 is a schematic diagram of a network system 1700. The network system 1700 may include at least a first network device 1702 (i.e., an initiator) and a second network device 1704 (i.e., a responder). The first network device 1702 may be Figure 13 The second network device 1704 may be as follows: Figure 14 and Figure 15 In another embodiment, the first network device may be the network device 1600, which is used as the network device 1400 or the network device 1500 described in the embodiment. Figures 1A to 12 The initiator described in the embodiment and executes Figures 1A to 12 The second network device may be the network device 1600, which is used as Figures 1A to 12 The responder described in the embodiment and performs the following Figures 1A to 12 The operations of the responder described in the embodiment.

[0287] After reading this disclosure, those skilled in the art will understand that any known or new algorithm can be used to implement the present disclosure. However, it should be noted that the present disclosure provides a method for achieving the above benefits and technological advancements, in which any known or new algorithm is used.

[0288] After reading this disclosure, those skilled in the art will appreciate that, in conjunction with the various examples described in the embodiments disclosed in this specification, the units and algorithm steps can be implemented in electronic hardware, or in a combination of computer software and electronic hardware. Whether the function is performed by hardware or software depends on the specific application and design constraints of the technical solution. After reading this disclosure, those skilled in the art may use different methods to implement the described functions for each specific application, but it should not be considered that such implementation is beyond the scope of this disclosure.

[0289] It should be understood that while several embodiments are provided in this disclosure, the disclosed systems and methods may be implemented in other ways. For example, the described embodiments of network devices are merely exemplary. For example, unit division is merely a logical functional division, and in actual implementations, other divisions may be employed. For example, multiple units or modules may be merged or integrated into another system, or some features may be omitted or not implemented. Furthermore, the mutual coupling, direct coupling, or communication connection shown or discussed may be implemented through some interface. Direct coupling or communication connection between devices or units may be implemented electronically, mechanically, or in other ways.

[0290] When these functions are implemented in the form of software functional units and sold or used as independent products, these functions can be stored in a computer-readable storage medium. These functions can be represented by computer codes forming a computer program product, and the computer program product can instruct appropriate hardware to perform these functions. Based on such an understanding, the technical solution of the present disclosure, or the part that contributes to the prior art, or a part of the technical solution, can be implemented in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for instructing a computer node (which can be a personal computer, a server or a network node, i.e., a processor) to perform all or part of the steps of the method described in the embodiment of the present disclosure. The aforementioned storage medium includes: any medium that can store program code, such as a USB flash drive, a removable hard disk, a read-only memory (ROM), a random access memory (RAM), a disk or an optical disk.

[0291] Devices that are in communication with each other need not be in continuous communication with each other unless expressly specified otherwise. In addition, devices that are in communication with each other may communicate directly or indirectly through one or more intermediaries.

[0292] When this paper describes a single device or article, it is obvious that more than one device / article (no matter whether they collaborate) can be used to replace a single device / article. Similarly, for the situation of more than one device or article described herein (no matter whether they collaborate), it is obvious that a single device / article can be used to replace more than one device or article, or the device / article of different numbers can be used to replace the device or program of the number shown. Or the function and / or feature of equipment can be implemented by one or more other equipment that is not clearly described as having such function / feature. Therefore, other embodiments of the present invention do not need to include the equipment itself.

Claims

1. A network device, characterized in that: A network device is configured to update a key for a security association (SA) in a network system including a first network device and a second network device, wherein an Internet Key Exchange (IKE) tunnel and an Internet Protocol Security (IPSec) tunnel are established between the first network device and the second network device. The network device serves as the first network device and includes: a processor and a memory, wherein the memory is configured to store software instructions; the processor executes the software instructions in the memory, so that the network device performs the following operations: When the encryption suite associated with the first network device has not changed, the first network device sends a first key update request to the second network device, wherein the first key update request is used to update the key of the SA, and the first key update request carries a first security parameter index SPI and does not carry the encryption suite associated with the first network device; The first network device receives a first key update response from the second network device, wherein when the encryption suite associated with the second network device has not changed, the first key update response carries the second SPI and does not carry the encryption suite associated with the second network device; When the encryption suite associated with the first network device and the encryption suite associated with the second network device do not change, the first network device updates the key of the SA according to the first SPI and the second SPI.

2. The network device according to claim 1, wherein: When the processor executes the instruction, the network device further causes the network device to perform the following operations: Before the first network device sends a first key update request to the second network device, the first network device determines whether a cryptographic suite associated with the first network device has changed.

3. The network device according to claim 1, wherein: When the processor executes the instruction, the network device further performs the following operations: Before the first network device sends the first key update request to the second network device, the first network device sends a first support notification to the second network device, where the first support notification indicates that the first network device supports lightweight key update; The first network device receives a first response, where the first response carries a second support notification, and the second support notification indicates that the second network device also supports lightweight key update.

4. The network device according to claim 3, wherein: The first support notification is carried in a notification payload of an IKE_SA_INIT request message, and the second support notification is carried in a notification payload of an IKE_SA_INIT response message or an IKE_SA_AUTH response message; or The first support notification is carried in a notification payload of an IKE_SA_AUTH request message, and the second support notification is carried in a notification payload of an IKE_SA_AUTH response message.

5. The network device according to claim 4, characterized in that The type of the notification payload is IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED.

6. The network device according to claim 1, wherein: The SA includes an IKE SA or an IPSec SA.

7. The network device according to claim 6, wherein: Updating the key of the SA includes creating a new SA and deleting the SA; Wherein, when the SA is the IKE SA, updating the key of the SA includes creating a new IKE SA and deleting the IKE SA; the first SPI is the SPI of the first network device used for the new IKE SA; the second SPI is the SPI of the second network device used for the new IKE SA; Wherein, when the SA is an IPSec SA and the IPSec SA is a sub-SA of an IKE SA, updating the key of the SA includes creating a new IPSec SA and deleting the IPSec SA; the first SPI is used as the inbound SPI of the new IPSec SA in the first network device and as the outbound SPI of the new IPSec SA in the second network device, and the second SPI is used as the inbound SPI of the new IPSec SA in the second network device and as the outbound SPI of the new IPSec SA in the first network device.

8. The network device according to claim 6 or 7, characterized in that: When the SA is the IKE SA, the first key update request is a CREATE_CHILD_SA request for performing a key update on the IKE_SA, the CREATE_CHILD_SA request carries a first NEW_SPI notification payload or a first lightweight SA payload, the first NEW_SPI notification payload carries the first SPI, and the first lightweight SA payload carries the first SPI; the first key update response is a CREATE_CHILD_SA response for performing a key update on the IKE_SA, the CREATE_CHILD_SA response carries a second NEW_SPI notification payload, or the CREATE_CHILD_SA response carries a second lightweight SA payload, the second NEW_SPI notification payload carries the second SPI, and the second lightweight SA payload carries the second SPI; When the SA is the IPSec SA and the IPSec SA is a child SA of the IKE SA, the first key update request is a CREATE_CHILD_SA request for updating the key of the child SA, the CREATE_CHILD_SA request carries a first NEW_SPI notification payload or a first lightweight SA payload, the first NEW_SPI notification payload carries the first SPI, and the first lightweight SA payload carries the first SPI. The first key update response is a CREATE_CHILD_SA response for updating the key of the child SA, the CREATE_CHILD_SA response carries a second NEW_SPI notification payload or a second lightweight SA payload, the second NEW_SPI notification payload carries the second SPI, and the second lightweight SA payload carries the second SPI.

9. The network device according to any one of claims 1 to 7, characterized in that: When the encryption suite associated with the first network device changes, the first network device sends a second key update request to the second network device for updating the key of the SA, wherein the second key update request carries the first SPI and the encryption suite associated with the first network device; When the encryption suite associated with the second network device has not changed, and the currently used encryption suite associated with the second network device exists in the encryption suite associated with the first network device in the second key update request, the first network device receives a second key update response, where the second key update response carries the second SPI and does not carry the encryption suite associated with the second network device; When the processor executes the instruction, the processor further causes the network device to perform the following operations: the first network device updates the key of the SA according to the first SPI, the second SPI, and the currently used encryption suite associated with the second network device.

10. The network device according to claim 9, characterized in that When the SA is an IPSec SA and the IPSec SA is a sub-SA of an IKE SA, when the flow information associated with the first network device changes, the second key update request further carries a TS payload, where the TS payload carries the flow information associated with the first network device; wherein, when the encryption suite associated with the second network device does not change and the currently used flow information associated with the second network device exists in the flow information associated with the first network device carried in the second key update request, the second key update response does not carry the TS payload associated with the second network device; When the processor executes the instruction, the processor further causes the network device to perform the following operations: the first network device also updates the key of the SA according to the currently used flow information associated with the second network device.

11. The network device according to claim 9, wherein: When the SA is an IPSec SA and the IPSec SA is a sub-SA of an IKE SA, when the flow information associated with the first network device changes, the second key update request further carries a TS payload, where the TS payload carries the flow information associated with the first network device; wherein, when the flow information associated with the second network device changes and the second network device selects the flow information associated with the first network device carried in the second key update request as the flow information associated with the second network device, the second key update response carries a TS payload, where the TS payload carries the flow information associated with the second network device; When the processor executes the instruction, the processor further causes the network device to perform the following operations: the first network device also updates the key of the SA according to the selected flow information.

12. The network device according to claim 9, wherein: When the SA is an IPSec SA and the IPSec SA is a sub-SA of an IKE SA, when the flow information associated with the first network device changes, the second key update request further carries a TS payload, where the TS payload carries the flow information associated with the first network device; wherein the second key update response carries a TS unacceptable notification, indicating that no matching flow information exists in the flow information associated with the first network device carried in the second key update request; When the processor executes the instruction, the network device further performs the following operations: The first network device renegotiates with the second network device until the negotiated flow information is obtained; The first network device further updates the key of the SA according to the negotiated flow information.

13. The network device according to claim 9, wherein: When the SA is an IPSec SA and the IPSec SA is a child SA of an IKE SA, the second key update request does not carry a TS payload, and the TS payload carries flow information associated with the first network device; wherein, when the flow information associated with the second network device has not changed, the second key update response does not carry a TS payload of the flow information associated with the second network device; When the processor executes the instruction, the network device further performs the following operations: The first network device updates the key of the SA without changing flow information associated with the SA.

14. The network device according to claim 9, wherein: When the SA is an IPSec SA and the IPSec SA is a child SA of an IKE SA, if the flow information has not changed, the second key update request does not carry a TS payload, and the TS payload carries the flow information; wherein, when the encryption suite associated with the second network device has changed, the second key update response carries a notification that the TS is unacceptable; When the processor executes the instruction, the network device further performs the following operations: The first network device renegotiates with the second network device until the negotiated flow information is obtained; The first network device further updates the key of the SA according to the negotiated flow information.

15. The network device according to claim 14, wherein: The TS unacceptable notification is the TS_UNACCEPTABLE notification payload carried in the second key update response.

16. The network device according to claim 9, wherein: When the SA is the IKE SA, the second key update request is a CREATE_CHILD_SA request for updating the key of the IKE SA, the CREATE_CHILD_SA request carries an SA payload, the SA payload carries the first SPI and the encryption suite associated with the first network device, and the second key update response is a CREATE_CHILD_SA response for updating the key of the IKE SA, the CREATE_CHILD_SA response carries a NEW_SPI notification payload or a lightweight SA payload, the NEW_SPI notification payload carries the second SPI, and the lightweight SA payload carries the second SPI; In which, when the SA is the IPSec SA and the IPSec SA is a sub-SA of the IKE SA, the second key update request is a CREATE_CHILD_SA request for updating the key of the sub-SA, the CREATE_CHILD_SA request carries an SA payload, the SA payload carries the first SPI and the encryption suite associated with the first network device, and the second key update response is a CREATE_CHILD_SA response for updating the key of the sub-SA, the CREATE_CHILD_SA response carries a NEW_SPI notification payload or a lightweight SA payload, the NEW_SPI notification payload carries the second SPI, and the lightweight SA payload carries the second SPI.

17. A network device, characterized in that: The network device is configured to update a key of a security association (SA) in a network system including a first network device and a second network device, wherein an Internet Key Exchange (IKE) tunnel and an Internet Protocol Security (IPSec) tunnel are established between the first network device and the second network device. The network device functions as the second network device and includes: a processor and a memory, wherein the memory is configured to store software instructions, and the processor is configured to execute the software instructions in the memory, so that the network device performs the following operations: The second network device receives a first key update request from the first network device, wherein the first key update request is used to update the key of the SA, the first key update request carries a first security parameter index SPI, and does not carry a cryptographic suite associated with the first network device; The second network device sends a first key update response to the first network device; wherein, when the encryption suite associated with the second network device has not changed, the first key update response carries the second SPI and does not carry the encryption suite associated with the second network device; When the encryption suite associated with the first network device and the encryption suite associated with the second network device do not change, the second network device updates the key of the SA according to the first SPI and the second SPI.

18. The network device according to claim 17, wherein: When the processor executes the instruction, the network device further causes the network device to perform the following operations: The second network device determines whether a cryptographic suite associated with the second network device has changed.

19. The network device according to claim 17, wherein: When the processor executes the instruction, the network device further performs the following operations: Before the second network device receives the first key update request from the first network device, the second network device receives a notification from the first network device indicating that the first network device supports a key update optional payload; The second network device sends a response indicating that the second network device also supports the key update optional payload.

20. The network device according to claim 19, wherein: The notification is carried in the notification payload of the IKE_SA_INIT request message, and the response is sent via the notification payload in the IKE_SA_INIT response message or the IKE_SA_AUTH response message; or The notification is carried in the notification payload of the IKE_SA_AUTH request message, and the response is sent via the notification payload in the IKE_SA_AUTH response message.

21. The network device according to claim 20, wherein: The type of the notification payload is IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED.

22. The network device according to any one of claims 17 to 21, characterized in that: receiving a second key update request for updating a key of an SA sent by the first network device to the second network device when the encryption suite associated with the first network device changes, wherein the second key update request carries the first SPI and the encryption suite associated with the first network device; When the encryption suite associated with the second network device has not changed, and the currently used encryption suite associated with the second network device exists in the encryption suite associated with the first network device in the second key update request, sending a second key update response, where the second key update response carries the second SPI and does not carry the encryption suite associated with the second network device; When the processor executes the instruction, the network device further causes the network device to perform the following operations: update the key of the SA according to the first SPI, the second SPI, and the currently used encryption suite associated with the second network device.

23. The network device according to claim 22, wherein: When the SA is an IPSec SA and the IPSec SA is a sub-SA of an IKE SA, when the flow information associated with the first network device changes, the second key update request further carries a TS payload, where the TS payload carries the flow information associated with the first network device; wherein, when the encryption suite associated with the second network device does not change and the currently used flow information associated with the second network device exists in the flow information associated with the first network device carried in the second key update request, the second key update response does not carry the TS payload associated with the second network device; The SA further updates the key according to the currently used flow information associated with the second network device.

24. The network device according to claim 22, wherein: When the SA is an IPSec SA and the IPSec SA is a sub-SA of an IKE SA, when the flow information associated with the first network device changes, the second key update request further carries a TS payload, where the TS payload carries the flow information associated with the first network device; wherein, when the flow information associated with the second network device changes and the second network device selects the flow information associated with the first network device carried in the second key update request as the flow information associated with the second network device, the second key update response carries a TS payload, where the TS payload carries the flow information associated with the second network device; The SA further performs key update according to the selected flow information.

25. The network device according to claim 22, wherein: When the SA is an IPSec SA and the IPSec SA is a sub-SA of an IKE SA, when the flow information associated with the first network device changes, the second key update request further carries a TS payload, where the TS payload carries the flow information associated with the first network device; wherein the second key update response carries a TS unacceptable notification, indicating that no matching flow information exists in the flow information associated with the first network device carried in the second key update request; When executed by the processor, the instructions further cause the network device to perform the following operations: renegotiate with the first network device until the negotiated flow information is obtained; The SA further performs key update according to the negotiated flow information.

26. The network device according to claim 22, wherein: When the SA is an IPSec SA and the IPSec SA is a child SA of an IKE SA, the second key update request does not carry a TS payload, and the TS payload carries flow information associated with the first network device; wherein, when the flow information associated with the second network device has not changed, the second key update response does not carry a TS payload of the flow information associated with the second network device; The SA also performs key update without changing the flow information associated with the SA.

27. The network device according to claim 22, wherein: When the SA is an IPSec SA and the IPSec SA is a child SA of an IKE SA, if the flow information has not changed, the second key update request does not carry a TS payload, and the TS payload carries the flow information; wherein, when the encryption suite associated with the second network device has changed, the second key update response carries a notification that the TS is unacceptable; When executed by the processor, the instructions further cause the network device to perform the following operations: renegotiate with the first network device until the negotiated flow information is obtained; The SA further performs key update according to the negotiated flow information.

28. The network device according to claim 27, wherein: The TS unacceptable notification is the TS_UNACCEPTABLE notification payload carried in the second key update response.

29. A network system for updating a security association (SA) key, characterized in that: The network system includes the first network device according to any one of claims 1 to 16 and the second network device according to any one of claims 17 to 28.

Images