Method, device and system for sharing secure protocol tunnel

Abstract

The present application relates to the technical field of communications. Disclosed are a method, device and system for sharing a secure protocol tunnel, which can share the same secure tunnel by means of a plurality of service instances, such that services are ensured to operate more reliably and efficiently and the utilization rate of the secure tunnel is improved. In the present application, network devices support a plurality of operators to share the same secure tunnel between the network devices. Moreover, the network devices can establish and manage an association relationship between the secure tunnel and service instances, such that service isolation can still be achieved even when the secure tunnel is shared by the plurality of operators. On this basis, system resources, such as computing, storage and IP addresses, can also be saved on, thereby reducing customers' operation and maintenance costs, and facilitating the selection of a secure tunnel and smooth identification and parsing at a receiving end during subsequent data transmission between network devices.

Description

A method, device and system for sharing a secure protocol tunnel

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on November 24, 2023, with application number 202311591930.4 and application name “A method, device and system for sharing a secure protocol tunnel”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of communication technology, and in particular to a method, device, and system for sharing a secure protocol tunnel. Background Art

[0003] The current 3rd Generation Partnership Project (3GPP) supports secure self-establishment of the X2 / Xn interface, such as the direct establishment of a secure protocol tunnel (hereinafter referred to as a "secure tunnel") between two base stations, such as an IPsec (Internet Protocol Security) tunnel. In multi-operator base station scenarios, where a single base station serves multiple operators simultaneously, different operators typically use different virtual routing and forwarding (VRFs) to isolate transmission and data between operators. These VRFs require separate secure tunnels.

[0004] However, due to IPsec resource limitations, the number of secure tunnels that base stations can establish is usually limited. Based on this, when the number of base station secure tunnels is limited, how to improve the utilization of secure tunnels in multi-operator base station scenarios is a problem that needs to be solved.

[0005] Summary of the Invention

[0006] The present application provides a method, device, and system for sharing a security protocol tunnel, which can share the same security tunnel through multiple business instances, thereby improving the utilization rate of the security tunnel and ensuring more reliable and efficient operation of the business.

[0007] To achieve the above objectives, this application adopts the following technical solutions:

[0008] In a first aspect, a method for creating a security protocol tunnel is provided, which is applied to a first network device. The method may include: first, the first network device sends a first message containing first information to a second network device, wherein the first message is used to indicate the creation of a security protocol tunnel between the first network device and the second network device, and the first information is used to indicate a service instance of the first network device; then, the first network device receives a second message from the second network device, wherein the second message is a response of the second network device to the first message, and the second message carries second information, and the second information is used to indicate the service instance of the second network device; finally, the first network device completes the creation of the security protocol tunnel with the second network device according to the second message, and associates the security protocol tunnel with the service instance of the first network device and the service instance determined by the second network device based on the first information.

[0009] As an example, one or more security protocol tunnels may be established between the first network device and the second network device. Any security protocol tunnel between the first network device and the second network device may be established based on the above method and associated with the corresponding service instance.

[0010] The solution provided in the first aspect above is that the first network device can support multiple operators it serves to share the security protocol tunnel between the first network device and other network devices (such as the second network device), and can establish and manage the association between the security tunnel and the business instance to support business isolation even when the security tunnel is shared by multiple operators. Based on this, it can also save system computing, storage, IP address and other resources, reduce customer operation and maintenance costs, and facilitate the selection of security tunnels and smooth identification and analysis of the receiving end during subsequent data transmission between network devices.

[0011] As a possible implementation, the method further includes: the first network device sending a third message to the second network device, wherein the third message is used to instruct modification of the security protocol tunnel between the first network device and the second network device; and the first network device modifying one or more security protocol tunnels between the first network device and the second network device. This allows for more flexible security tunnel sharing. For example, network devices can negotiate with other network devices regarding security tunnel management at any time based on actual needs, including modifying security tunnels on demand. This on-demand adjustment supports on-demand allocation of system computing, storage, IP address, and other resources, achieving more efficient resource allocation.

[0012] As a possible implementation, the method further includes: the first network device instructing the second network device to update the key of a service instance associated with the security protocol tunnel between the first network device and the second network device. For example, in response to a request to update the key of a service instance, the first network device may instruct the second network device to update the key of a service instance associated with a certain security protocol tunnel. Based on this, more secure and reliable secure tunnel data transmission can be achieved by updating the key of the service instance. As an example, the first network device may instruct the second network device to update the key of a service instance associated with a certain security protocol tunnel through a Rekey message.

[0013] As a possible implementation manner, the above-mentioned modification of the security protocol tunnel between the first network device and the second network device includes one or more of the following: deleting the association relationship between the security protocol tunnel and the service instance, and adding the association relationship between the security protocol tunnel and the service instance.

[0014] For example, in response to a request to delete a secure tunnel, the first network device may send a message to the second network device instructing the deletion of the secure protocol tunnel between the first and second network devices. For another example, in response to a request to delete the association between a secure tunnel and a service instance, the first network device may send a message to the second network device instructing the deletion of the association between a target secure tunnel and a target service instance. For another example, in response to a request to add an association between a secure tunnel and a service instance, the first network device may send a message to the second network device instructing the addition of an association between a target secure tunnel and a service instance.

[0015] This enables more flexible secure tunnel sharing. For example, network devices can negotiate with other network devices at any time regarding secure tunnel management based on actual needs. This includes adding or deleting secure tunnels on demand, as well as adding or deleting associations between secure tunnels and service instances. This on-demand adjustment supports the on-demand allocation of system computing, storage, IP address, and other resources, enabling more efficient resource allocation.

[0016] As a possible implementation, the third message is used to indicate the deletion of the association between the security protocol tunnel and the service instance between the first network device and the second network device. The third message carries a first message, and the first message includes an INFORMATIONAL message. For example, the third message can indicate the deletion of the security protocol tunnel between the first network device and the second network device, or the deletion of the association between the security protocol tunnel and the service instance, via a DELETE payload carried in the INFORMATIONAL message. Based on this, on-demand deletion of security tunnels or on-demand deletion of the association between security tunnels and service instances can be supported in different communication scenarios, thereby achieving on-demand allocation of system computing, storage, IP address, and other resources.

[0017] As a possible implementation, the third message is used to indicate the association between the newly added security protocol tunnel and the service instance, wherein the third message carries a second message, and the second message includes a CREATE_CHILD_SA message, an INFORMATIONAL message, or an IKE_SA_INIT message. For example, the third message can indicate the association between the newly added security protocol tunnel and the service instance through a NOTIFY payload carried in a CREATE_CHILD_SA message or an INFORMATIONAL message, or a NOTIFY payload carried in an IKE_SA_INIT message. Based on this, it is possible to support the on-demand association between newly added security tunnels and service instances in different communication scenarios, thereby realizing on-demand allocation of system computing, storage, IP address and other resources.

[0018] As a possible implementation, the above method also includes: the first network device sends a fourth message to the second network device, wherein the fourth message is used to indicate that the first network device has the ability to associate a security protocol tunnel with a business instance; the first network device receives a fifth message from the second network device, wherein the fifth message is used to indicate that the second network device has the ability to associate a security protocol tunnel with a business instance. Based on this, it is convenient for both communicating parties to understand whether each other has the ability to associate a security protocol tunnel with a business instance, so as to decide whether to negotiate the business instance corresponding to the security tunnel based on each other's capabilities, and avoid the problem that when one party (such as the second network device) does not have the ability to associate a security protocol tunnel with a business instance, the party (such as the first network device) that has the ability to associate a security protocol tunnel with a business instance sends business instance negotiation information to the second network device, which may cause the receiving party to process it incorrectly. As an example, the fourth message and the first message can be the same message.

[0019] As a possible implementation, the fourth message carries a third message, where the third message includes an IKE_SA_INIT message, an IKE_AUTH message, a CREATE_CHILD_SA message, and an INFORMATIONAL message. For example, the fourth message can inform the second network device whether the first network device has the ability to associate a service instance with a secure protocol tunnel through the NOTIFY payload carried in the IKE_SA_INIT message, the NOTIFY payload carried in the IKE_AUTH message, the NOTIFY payload carried in the CREATE_CHILD_SA message, or the NOTIFY payload carried in the INFORMATIONAL message. Based on this, notification of service instance negotiation capabilities can be supported in different communication scenarios to support the selection of subsequent communication strategies.

[0020] As a possible implementation manner, the first network device may communicate with the second network device based on the IKEv2 protocol.

[0021] As an example, the security protocol tunnel may include an IPsec tunnel.

[0022] Of course, this application does not limit the communication protocol. In some scenarios, the first network device can also communicate with the second network device based on other protocols to implement the solution provided by this application. In addition, the security protocol tunnel between the first network device and the second network device can also be a security tunnel based on other protocols.

[0023] In a second aspect, a data transmission method is provided, which can be applied to a first network device. The method may include: the first network device sends a data packet carrying business data to a second network device through a first security protocol tunnel, wherein the data packet includes an identifier of a first business instance corresponding to the business data, and the first security protocol tunnel has an association relationship with the first business instance.

[0024] The solution provided in the second aspect above is that the sender of the data message can transmit business data related to the business instance through a security protocol tunnel that is associated with the business instance, and carry the identifier of the business instance corresponding to the business data in the data message, so that the receiver of the data message can verify subsequent data messages based on the identifier of the business instance carried in the data message, and select a matching security policy to parse the data message, so as to support the efficient, reliable and orderly transmission of business data based on the shared security protocol tunnel solution.

[0025] As a possible implementation, the identifier of the first service instance is located in one or more of the following fields of the data packet: an unencrypted Internet Protocol version (IPv4) header, an encrypted IPv4 header, an unencrypted IPv6 header or an IPv6 extension header, or an encrypted IPv6 header or an extension header. This allows the carrying of service instance identifiers in various communication scenarios, enabling efficient, reliable, and orderly transmission of subsequent service data.

[0026] As a possible implementation, before the first network device sends a data packet to the second network device through the first security protocol tunnel, the method further includes: the first network device encrypting the service data based on the security policy corresponding to the first service instance at the tunnel interface of the first security protocol tunnel, and then encapsulating the encrypted data into a data packet. This ensures secure and reliable transmission of the service data.

[0027] As a possible implementation, the first network device can communicate with the second network device based on the IKEv2 protocol. As an example, the security protocol tunnel can include an IPsec tunnel. Of course, this application does not limit the communication protocol. In some scenarios, the first network device can also communicate with the second network device based on other protocols to implement the solution provided by this application. Furthermore, the security protocol tunnel between the first network device and the second network device can also be a security tunnel based on other protocols.

[0028] In a third aspect, a method for creating a security protocol tunnel is provided, which can be applied to a second network device. The method may include: first, the second network device receives a first message from the first network device, wherein the first message is used to indicate the creation of a security protocol tunnel between the first network device and the second network device, and the first message includes first information, wherein the first information is used to indicate a service instance of the first network device; then, the second network device sends a second message to the first network device, wherein the second message is a response of the second network device to the first message, and the second message carries second information, wherein the second information is used to indicate a service instance determined by the second network device based on the first information; finally, the second network device completes the creation of the security protocol tunnel with the first network device according to the first message, and associates the security protocol tunnel with the service instance indicated by the second information.

[0029] As an example, one or more security protocol tunnels may be established between the first network device and the second network device. Any security protocol tunnel between the first network device and the second network device may be established based on the above method and associated with the corresponding service instance.

[0030] The solution provided in the third aspect above is that the second network device can support multiple operators it serves to share the security protocol tunnel between the second network device and other network devices (such as the first network device), and can establish and manage the association between the security tunnel and the business instance to support business isolation even when the security tunnel is shared by multiple operators. Based on this, it can also save system computing, storage, IP address and other resources, reduce customer operation and maintenance costs, and facilitate the selection of security tunnels and smooth identification and analysis of the receiving end during subsequent data transmission between network devices.

[0031] As a possible implementation, the method further includes: the second network device receiving a third message from the first network device, wherein the third message is used to instruct modification of the security protocol tunnel between the first network device and the second network device; and the second network device modifying one or more security protocol tunnels between the first network device and the second network device based on the third message. This enables more flexible security tunnel sharing. For example, network devices can negotiate with other network devices regarding security tunnel management at any time based on actual needs, including modifying security tunnels on demand. This on-demand adjustment supports on-demand allocation of system computing, storage, IP address, and other resources, achieving more efficient resource allocation.

[0032] As a possible implementation, the method further includes: the second network device updating, based on an instruction from the first network device, a key for a service instance associated with the security protocol tunnel between the first and second network devices. This allows for more secure and reliable secure tunnel data transmission by updating the key for the service instance. For example, the first network device may instruct the second network device to update the key for a service instance associated with a security protocol tunnel using a Rekey message.

[0033] As a possible implementation, modifying the security protocol tunnel between the first network device and the second network device may include one or more of the following: deleting the association between the security protocol tunnel and the service instance, or adding a new association between the security protocol tunnel and the service instance. This allows for more flexible security tunnel sharing. For example, network devices can negotiate with other network devices at any time regarding security tunnel management based on actual needs, including adding or deleting security tunnels and adding / deleting associations between security tunnels and service instances on demand. This on-demand adjustment supports on-demand allocation of system computing, storage, IP address, and other resources, achieving more efficient resource allocation.

[0034] As a possible implementation, the third message is used to indicate the deletion of the association between the security protocol tunnel and the service instance between the first network device and the second network device. The third message carries the first message, and the first message includes an INFORMATIONAL message. For example, the third message can indicate the deletion of the security protocol tunnel between the first network device and the second network device, or the deletion of the association between the security protocol tunnel and the service instance, via the DELETE payload carried in the INFORMATIONAL message. Based on this, on-demand deletion of security tunnels or on-demand deletion of the association between security tunnels and service instances can be supported in different communication scenarios to achieve on-demand allocation of system computing, storage, IP address and other resources.

[0035] As a possible implementation method, the third message is used to indicate the association between the newly added security protocol tunnel and the service instance, wherein the third message carries the second message, and the second message includes a CREATE_CHILD_SA message, an INFORMATIONAL message, or an IKE_SA_INIT message. For example, the third message can indicate the association between the newly added security protocol tunnel and the service instance through a NOTIFY payload carried in a CREATE_CHILD_SA message or an INFORMATIONAL message, or a NOTIFY payload carried in an IKE_SA_INIT message. Based on this, it is possible to support the on-demand association between newly added security tunnels and service instances in different communication scenarios, so as to realize the on-demand allocation of system computing, storage, IP address and other resources.

[0036] As a possible implementation, the method further includes: the second network device receives a fourth message from the first network device, wherein the fourth message is used to indicate that the first network device has the ability to associate a security protocol tunnel with a service instance; and the second network device sends a fifth message to the first network device, wherein the fifth message is used to indicate that the second network device has the ability to associate the security protocol tunnel with the service instance. Based on this, it is convenient for both communicating parties to understand whether each other has the ability to associate a security protocol tunnel with a service instance, so as to decide whether to subsequently negotiate the service instance corresponding to the security tunnel based on each other's capabilities, thereby avoiding the problem that when one party (such as the second network device) does not have the ability to associate a security protocol tunnel with a service instance, the party (such as the first network device) that has the ability to associate a security protocol tunnel with a service instance sends service instance negotiation information to the second network device, which may cause the receiving party to process it incorrectly.

[0037] As a possible implementation, the fifth message carries a third message, where the third message includes an IKE_SA_INIT message, an IKE_AUTH message, a CREATE_CHILD_SA message, and an INFORMATIONAL message. For example, the fifth message can inform the second network device whether the first network device has the ability to associate a service instance with a security protocol tunnel through the NOTIFY payload carried in the IKE_SA_INIT message, the NOTIFY payload carried in the IKE_AUTH message, the NOTIFY payload carried in the CREATE_CHILD_SA message, or the NOTIFY payload carried in the INFORMATIONAL message. Based on this, notification of service instance negotiation capabilities can be supported in different communication scenarios to support the selection of subsequent communication strategies.

[0038] As a possible implementation manner, the second network device may communicate with the first network device based on the IKEv2 protocol.

[0039] As an example, the security protocol tunnel may include an IPsec tunnel.

[0040] Of course, this application does not limit the communication protocol. In some scenarios, the second network device can also communicate with the first network device based on other protocols to implement the solution provided by this application. In addition, the secure protocol tunnel between the second network device and the first network device can also be a secure tunnel based on other protocols.

[0041] In a fourth aspect, a data transmission method is provided, which can be applied to a second network device. The method may include: first, the second network device receives a data packet sent by the first network device through a first security protocol tunnel, wherein the data packet includes business data and an identifier of a first business instance corresponding to the business data, and the first security protocol tunnel is one of one or more security protocol tunnels between the first network device and the second network device, and the first security protocol tunnel has an association with the first business instance; then, the second network device determines the security policy of the data packet based on the identifier of the first business instance; finally, the second network device parses the data packet according to the determined security policy to obtain the business data.

[0042] In the solution provided in the fourth aspect above, the sender of the data message (such as the first network device) can transmit business data related to the business instance through a security protocol tunnel that is associated with the business instance, and carry the identifier of the business instance corresponding to the business data in the data message. The receiving end of the data message (such as the second network device) can select a matching security policy based on the identifier of the business instance carried in the data message to parse the data message, so as to support the efficient, reliable and orderly transmission of business data based on the shared security protocol tunnel solution.

[0043] As one possible implementation, the identifier of the first service instance is located in one or more of the following fields of the data packet: an unencrypted IPv4 header, an encrypted IPv4 header, an unencrypted IPv6 header or an IPv6 extension header, or an encrypted IPv6 header or an extension header. This allows for the carrying of service instance identifiers in various communication scenarios, ensuring efficient, reliable, and orderly transmission of subsequent service data.

[0044] As one possible implementation, the second network device parsing the data packet to obtain the service data includes: the second network device parsing the data packet to obtain the service data based on the security policy corresponding to the first service instance. This ensures secure and reliable transmission of the service data and successful data parsing.

[0045] As a possible implementation, the second network device can communicate with the first network device based on the IKEv2 protocol. As an example, the security protocol tunnel can include an IPsec tunnel. Of course, this application does not limit the communication protocol. In some scenarios, the second network device can also communicate with the first network device based on other protocols to implement the solution provided by this application. Furthermore, the security protocol tunnel between the first network device and the second network device can also be a security tunnel based on other protocols.

[0046] In a fifth aspect, a network device is provided, which may include: a transceiver for sending and receiving signals; a memory for storing computer program instructions and data; and a processor for executing the computer program instructions to support the network device to implement the method described in any possible implementation method of the first aspect, the second aspect, the third aspect or the fourth aspect.

[0047] In a sixth aspect, a communication system is provided, comprising: a first network device and a second network device, wherein the first network device is used to implement the method described in any possible implementation of the first aspect or the second aspect, and the second network device is used to implement the method described in any possible implementation of the third aspect or the fourth aspect.

[0048] In the seventh aspect, a computer-readable storage medium is provided, on which computer program instructions are stored. When the computer program instructions are executed by a processor, the method in any possible implementation of the first aspect, the second aspect, the third aspect or the fourth aspect is implemented.

[0049] In an eighth aspect, a computer program product comprising instructions is provided, which, when executed on a computer, enables the computer to implement a method in any possible implementation of the first, second, third or fourth aspects.

[0050] In a ninth aspect, a chip system is provided, comprising a processing circuit and a storage medium storing computer program instructions; when the computer program instructions are executed by the processor, the method of any possible implementation of the first, second, third, or fourth aspects is implemented. The chip system may be composed of a chip alone or may include a chip and other discrete components. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] FIG1 is a schematic diagram of a system architecture provided by an embodiment of the present application;

[0052] FIG2 is a schematic diagram of conventional data transmission based on a secure tunnel;

[0053] FIG3A is a schematic diagram of data transmission based on a secure tunnel provided in an embodiment of the present application;

[0054] FIG3B is a schematic diagram of a message encryption process provided in an embodiment of the present application;

[0055] FIG3C is a schematic diagram of another message encryption process provided in an embodiment of the present application;

[0056] FIG4 is a schematic diagram of the hardware structure of a network device provided in an embodiment of the present application;

[0057] FIG5 is a schematic diagram of a process of data transmission between network devices provided in an embodiment of the present application;

[0058] FIG6 is a diagram illustrating an example of a message for capability negotiation according to an embodiment of the present application;

[0059] FIG7 is a second example of a message for capability negotiation provided in an embodiment of the present application;

[0060] FIG8 is a diagram illustrating an example of a message for carrying service instance negotiation information according to an embodiment of the present application;

[0061] FIG9 is a second example of a message for carrying service instance negotiation information provided in an embodiment of the present application;

[0062] FIG10 is a third example of a message for carrying service instance negotiation information provided in an embodiment of the present application;

[0063] FIG11 is a fourth example of a message for carrying service instance negotiation information provided in an embodiment of the present application;

[0064] FIG12 is a fifth example of a message for carrying service instance negotiation information provided in an embodiment of the present application;

[0065] FIG13 is a sixth example of a message for carrying service instance negotiation information provided in an embodiment of the present application;

[0066] FIG14 is a flow chart of a data transmission method under a secure tunnel sharing mechanism provided in an embodiment of the present application;

[0067] FIG15A is a schematic diagram of decryption of a message provided in an embodiment of the present application;

[0068] FIG15B is a schematic diagram of decryption of another message provided in an embodiment of the present application;

[0069] FIG16 is a diagram illustrating an example of a message for modifying a secure tunnel according to an embodiment of the present application;

[0070] FIG17 is a schematic diagram of a specific interaction between a security tunnel and a service instance provided in an embodiment of the present application. DETAILED DESCRIPTION

[0071] The technical solutions in the embodiments of the present application will be described below in conjunction with the accompanying drawings in the embodiments of the present application. In the description of the embodiments of the present application, unless otherwise specified, " / " means or, for example, A / B can mean A or B; "and / or" in this article is merely a description of the association relationship of associated objects, indicating that three relationships can exist, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of the present application, "multiple" means two or more than two.

[0072] Hereinafter, the terms "first," "second," and so on are used solely to distinguish different descriptive objects and have no limiting effect on the position, order, priority, quantity, or content of the described objects. For example, if the described object is a "field," the ordinal number preceding the "field" in "first field" and "second field" does not define the position or order of the "fields." "First" and "second" do not define whether the modified "fields" are in the same message, nor do they restrict the order of the "first field" and "second field." For another example, if the described object is a "level," the ordinal number preceding the "level" in "first level" and "second level" does not define the priority of the "levels." For another example, the number of described objects is not limited by the ordinal number and can be one or more. For example, in the case of "first device," the number of "devices" can be one or more. Furthermore, the objects modified by different prefixes can be the same or different. For example, if the described object is a "device," the "first device" and "second device" can be the same type of device or different types of devices. For another example, if the described object is "information," the "first information" and "second information" can be information of the same content or different contents. In short, the use of prefixes such as ordinal numbers to distinguish the described objects in the embodiments of the present application does not constitute a restriction on the described objects. For the statement of the described objects, please refer to the description in the context of the claims or embodiments, and no unnecessary restrictions should be constituted due to the use of such prefixes.

[0073] Furthermore, in the embodiments of the present application, "connection" may be a direct connection or an indirect connection; in addition, it may refer to an electrical connection or a communication connection; for example, the connection between two electrical components A and B may refer to a direct connection between A and B, or may refer to an indirect connection between A and B through other electrical components or connection media, or may refer to an indirect connection between A and B through other communication devices or communication media, as long as communication between A and B can be achieved.

[0074] At present, in the application scenario of wireless base stations, as shown in Figure 1, secure communication between the base station and the core network can be achieved by establishing a secure protocol channel between the base station and the security gateway (SeGW) to carry collaborative services between base stations, where the core network may include the local area network (LAN), SeGW, mobility management entity (MME) / authentication management function (AMF), signaling gateway (SGW) / user plane function (UPF), etc. shown in Figure 1.

[0075] With 3GPP's support for establishing direct secure tunnels between base stations, direct secure tunnels, such as direct IPsec tunnels (hereinafter referred to as "IPsec tunnels"), can be established between base stations to reduce traffic load on security gateways and minimize latency between base stations. As shown in Figure 1, secure transmission between base stations 1 and 2 can utilize not only the secure protocol channel between the base stations and the core network's security gateway (SeGW), but also the secure tunnel between base stations 1 and 2.

[0076] In multi-operator base station scenarios, such as when a base station serves multiple operators simultaneously, or in RAN Sharing scenarios where multiple operators share the same base station, different operators typically use different Virtual Formats (VRFs), due to the need for transmission and data isolation between operators. Each VRF requires its own secure tunnel. To achieve transmission and data isolation between operators, four inter-site secure tunnels must be established between base station 1 and base station 2, based on operator granularity. Similarly, multiple secure tunnels must be established between base station 1 and other base stations, and between base station 2 and other base stations to ensure isolation between different operators.

[0077] We know that IPsec resources are limited. For example, the hardware of the IPsec board is limited. For example, in some examples, the Child SA specification of the entire board is 512, which means that a base station can have 512 neighboring stations. If based on the conventional inter-station security tunnel establishment mechanism, there are a total of 4 operators, and 4 security tunnels are established between base station 1 and the others, for example, base station 1 needs to establish a total of 512*4=2048 security tunnels with other base stations. Therefore, based on the conventional inter-station security tunnel establishment mechanism, the specifications of the inter-station security tunnels will increase dramatically. The essence of this problem is that the security tunnel cannot be shared as a public channel for all operators, which greatly wastes base station resources. In other words, the key to solving the problem of the sharp increase in the specifications of the above-mentioned security tunnels is to improve the utilization rate of the security tunnels through security tunnel sharing when the number of base station security tunnels is limited.

[0078] Among them, the key to establishing a secure tunnel lies in negotiating the security parameters used to protect the secure tunnel and the security parameters used to protect business data. Taking the secure tunnel as an IPSec tunnel as an example, when establishing the IPSec tunnel, the negotiation of IKE SA and Child SA is the focus, wherein IKE SA is a security association (SA) negotiated based on the Internet Key Exchange (IKE) protocol and used for security protection such as encryption of IKE messages. Child SA is an SA negotiated based on the IKE protocol and used for security protection of specific services. Since the main usage scenario of the IKE protocol is IPsec, Child SA is sometimes also called IPsec SA (collectively referred to as "Child SA" in the following embodiments). IKE SA is a set of security parameters used to protect the IPSec tunnel, and Child SA is mainly used to protect the security parameters of user data. Among them, in the above negotiation process, IKE SA is the basis of Child SA, because the establishment of Child SA requires the use of a series of keys after the establishment of IKE SA.

[0079] Currently, mainstream configuration of IKE SAs and Child SAs is often based on protocol standards such as RFC7296 and RFC4301. These protocols do not support sharing of secure tunnels between base stations. Furthermore, the Traffic Selector for Child SAs in these protocols only defines the scope of the flow of interest (for example, using source and destination address ranges to describe the flows to be encrypted), without defining other dimensions, such as virtual private network (VPN) granularity. Therefore, to avoid the inability to isolate and distinguish multiple service instances when address conflicts arise between multiple service instances (a common scenario), each service instance requires a separate IKE SA and Child SA. This means that a single IKE SA + Child SA combination cannot provide multiplexing and sharing for multiple service instances, even within a single operator. In this scenario, as shown in Figure 2, if there are N (where N is a positive integer greater than 1) inner service instances, base station 1 and base station 2 must provide N local IKE addresses, N IKE SAs, and N Child SAs. The service instances may be virtual routing and forwarding (VRF) 1, VRF2, and VRF3 as shown in Figure 2. In some cases, service instances are also referred to as "VRF instances." VRFs are created on physical devices through logical partitioning. Each instance is isolated at the routing level, enabling data or service isolation. Each VRF has independent interfaces, routing tables, and routing protocol processes. In other words, current protocols cannot support the sharing of secure tunnels between base stations, both in terms of protocol functionality and the prescribed communication process.

[0080] In order to solve the problem of a sharp increase in the specifications of inter-station security tunnels in the network in conventional technologies, an embodiment of the present application provides a method for sharing a security protocol tunnel, which can support multiple operators to share multiple security tunnels between network devices, and the multiple security tunnels are available to any operator served by the first network device and the second network device. As shown in Figure 3A, the data of any operator between base station 1 and base station 2 can be transmitted through security tunnel 1, where security tunnel 1 is provided with encryption and other security protections by IKE1. In other words, regardless of the data transmission requirements of any operator served by the first network device and the second network device, the first network device can complete the data transmission through any security tunnel between the first network device and the second network device. Based on this, the problem of a sharp increase in the specifications of inter-station security tunnels can be solved, system computing, storage, IP address and other resources can be saved, customer operation and maintenance costs can be reduced, while improving the utilization rate of security tunnels and ensuring that the business runs more reliably and efficiently.

[0081] In some embodiments, in order to solve the problem in conventional technologies that different business instances require an independent IKE SA and a Child SA to support, resulting in the inability of the security tunnel to provide reuse and sharing for multiple business instances, resulting in the still low utilization rate of the security tunnel, the sharing method of the security protocol tunnel provided in the embodiment of the present application can also achieve the effect of providing reuse and sharing for multiple business instances by associating a Child SA with one or more business instances. Based on this, the network device does not need to establish an independent IKE SA and Child SA for each business instance, thereby further reducing the number of inter-station security tunnels, saving system computing, storage, IP address and other resources, reducing customer operation and maintenance costs, and further improving the utilization rate of the security tunnel, and ensuring that the business runs more reliably and efficiently.

[0082] Taking the RFC4301 protocol standard as an example, the standard defines two databases: a security policy database (SPD) and a security association database (SAD). The SPD describes which traffic can be encrypted, and the SAD describes how to encrypt data packets. The SPD and SAD are in a one-to-one correspondence. When the control plane protocol IKE completes the negotiation of the correspondence between a service instance and a secure tunnel, an SPD and SAD will be added to the secure tunnel, and the SPD and SAD will be mapped to each other. Thus, when the control plane protocol completes the negotiation of the correspondence between multiple service instances and secure tunnels, a mapping relationship between multiple SPD entries and one SAD entry will be obtained.

[0083] Based on this, the core of the embodiment of the present application is that multiple business instances share one Child SA. Since each business instance has its own complete and independent address and routing space (such as spatial isolation achieved through VRF), the SPD should belong to the VPN level, and the SAD should belong to the system level. Among them, from the system perspective, as shown in Figure 3B, the SPD entries corresponding to the business instances of multiple business data (Figure 3B uses plaintext 1, plaintext 2 and plaintext 3 as examples) (Figure 3B uses VPN1SPD, VPN2 SPD, VPN3 SPD as examples) can be mapped to one SAD entry of the system. From the perspective of the VPN instance, as shown in Figure 3C, the SPD entry (Figure 3C uses VPN2 SPD as an example) corresponding to the business instance of a business data (Figure 3C uses plaintext 2 as an example) can be mapped to one SAD entry of the system.

[0084] It should be noted that in some scenarios, a service instance can also be a VPN instance.

[0085] The network device described in the embodiment of the present application may be the base station in the above example, such as a macro base station, a micro base station (also known as a "small station"), a distributed unit-control unit (DU-CU), etc., wherein the DU-CU is a device deployed in a wireless access network that enables terminal devices to perform wireless communications. In addition, the above base station may also be a wireless controller in a cloud radio access network (CRAN) scenario, or a relay station, access point, vehicle-mounted device, wearable device, or a network device in a future evolved public land mobile network (PLMN) network.

[0086] In some examples, the base station may be an Ng-eNB, a gNB, or a transmission / reception point (TRP). It may also be a base station defined by the 3rd Generation Partnership Project (3GPP), such as an eNB or an e-NodeB.

[0087] In addition, when an eNB connects to the NR core network, the next generation core (NGC), or the 5G core network (5GC), the eNB can also be called an eLTE eNB. Specifically, an eLTE eNB is an LTE base station device that has evolved from the eNB and can directly connect to the 5G CN. An eLTE eNB is also a base station device in NR.

[0088] In some examples, the network devices described in the embodiments of the present application may also include network devices of other types, functions, and structures, such as wireless terminals (WTs), access points (APs), access controllers (ACs), or other network devices capable of communicating with terminal devices and core networks. The embodiments of the present application do not specifically limit this.

[0089] Please refer to Figure 4, which shows a schematic diagram of the hardware structure of a network device. As shown in Figure 4, the network device may include a processor 401, a communication circuit 402, a memory 403, and at least one communication interface (Figure 4 is merely an example of including a communication interface 404).

[0090] The processor 401 may be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of the program of the present application.

[0091] Communication link 402 may include a pathway for transmitting information between the aforementioned components.

[0092] The communication interface 404 uses any transceiver or other device for communicating with other devices or communication networks, such as Ethernet, RAN, WLAN, etc.

[0093] In an embodiment of the present application, the communication line 402 and the communication interface 404 can be used to support the creation / modification / deletion of secure tunnels between a network device and other network devices (such as a first network device and a second network device), negotiation of the association between the secure tunnel and the business instance (such as adding / deleting / updating keys, etc.), transmission of business data, etc.

[0094] The memory 403 may be a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (RAM) or other type of dynamic storage device that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, an optical disc storage (including a compact disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory may exist independently and be connected to the processor via a communication line 402. The memory may also be integrated with the processor.

[0095] Memory 403 is used to store computer-executable instructions for executing the solution of the present application. Memory 403 can store instructions for implementing two modular functions: sending instructions, receiving instructions, and processing instructions, and is controlled by processor 401 for execution. Processor 401 is used to execute the computer-executable instructions stored in memory 403, thereby implementing the methods provided in the following embodiments of the present application. The memory 403 shown in FIG4 is merely a schematic diagram, and the memory may also include other functional instructions, which are not limited by the present invention.

[0096] Optionally, the computer-executable instructions in this application may also be referred to as application code, which is not specifically limited in this application.

[0097] In a specific implementation, as an embodiment, the processor 401 may include one or more CPUs, such as CPU0 and CPU1 in FIG. 4 .

[0098] It should be noted that FIG4 is only an example of a network device and does not limit the specific structure of the network device. For example, the network device may also include other functional modules.

[0099] The following will describe in detail the security protocol tunnel sharing method provided in the embodiments of the present application with reference to the accompanying drawings.

[0100] As a possible implementation method, when creating a security tunnel, the network device may associate the security tunnel with one or more service instances, so that one security tunnel can provide multiplexing and sharing for multiple service instances.

[0101] For example, as a possible implementation method, the network device can associate a Child SA with multiple service instances when creating a Child SA, that is, when conducting Child SA negotiation, so that the combination of an IKE SA and a Child SA can provide multiplexing and sharing effects for multiple service instances. Based on this, when transmitting data corresponding to multiple service instances, the same combination of Child SA and IKE SA can be used. In addition, in order to accurately distinguish data with the same IP address for different service instances, after completing the IPsec processing for the data, the network device can also carry service instance information in the message after IPsec processing, so that the opposite network device can identify the service instance to which the data belongs.

[0102] Of course, the embodiments of the present application do not limit the number of service instances corresponding to a Child SA. For example, a Child SA can also be associated with a service instance, but Child SAs associated with different service instances can use the same IKE SA. Based on this, when transmitting data corresponding to different service instances, different Child SAs can be used, but the same IKE SA is used. For example, when performing IPsec processing, a network device can respectively assign Child SAs corresponding to multiple data. The peer network device can use the traditional IPsec processing process to identify the service instance to which the data belongs based on the serial peripheral interface (SPI) value field of the SA in the message.

[0103] Based on the above implementation method, network devices do not need to establish independent IKE SAs and Child SAs for each service instance. Therefore, the number of inter-station security tunnels can be further reduced, saving system computing, storage, IP address and other resources, reducing customer operation and maintenance costs, and further improving the utilization of security tunnels, thereby ensuring more reliable and efficient service operation.

[0104] Since different network devices have different capabilities regarding service instance negotiation, for example, some network devices have the capability to associate a service instance with a secure protocol tunnel, while some network devices do not have the capability to associate a service instance with a secure protocol tunnel, when one party does not support it, the supporting party sending service instance negotiation information to the non-supporting party may cause processing errors on the receiving party. To avoid such problems, in some embodiments, network devices (such as a first network device and a second network device) may conduct capability negotiation in advance so that both parties can understand whether each other has the capability to associate a service instance with a secure protocol tunnel.

[0105] For example, the first network device may send a message to the second network device indicating that the first network device has the ability to associate a security protocol tunnel with a service instance, and upon receiving the message from the second network device indicating that the second network device has the ability to associate a security protocol tunnel with a service instance, negotiate with the second network device the service instance corresponding to the security tunnel.

[0106] As an example, please refer to Figure 5, which shows a schematic diagram of a process for data transmission between network devices provided in an embodiment of the present application. As shown in Figure 5, the first network device and the second network device can complete capability negotiation based on the process provided in S501, and complete the association of one or more secure tunnels and service instances between the network devices based on the process provided in S502:

[0107] S501: A first network device performs capability negotiation with a second network device.

[0108] In some embodiments, the first network device and the second network device may perform separate capability negotiation before creating the Child SA, so that both parties can understand whether the other party has the capability of associating a service instance with a security protocol tunnel.

[0109] The first network device and the second network device may perform capability negotiation through, but not limited to, any of the following messages: an IKE_SA_INIT message, an IKE_AUTH message, a CREATE_CHILD_SA message, and an INFORMATIONAL message.

[0110] As an example, the first network device and the second network device can perform capability negotiation during the IKE_SA_INIT exchange phase. For example, the party that has the capability of associating a service instance with a security protocol tunnel can carry a new NOTIFY payload in the IKE_SA_INIT message to inform the other party that it has the capability of associating a service instance with a security protocol tunnel. If the receiving party also has the capability of associating a service instance with a security protocol tunnel, the NOTIFY payload can be carried in the response message. Based on this, the sending end can carry the service instance negotiation information when subsequently negotiating to create a Child SA. If the receiving party does not have the capability of associating a service instance with a security protocol tunnel, the NOTIFY payload can be ignored and not carried in the response message, or a reply such as NO_PROPOSAL_CHOSEN or other error response can be made. Based on this, the sending end will not carry the service instance negotiation information when subsequently negotiating to create a Child SA.

[0111] Taking the first network device as having the capability of associating a service instance with a security protocol tunnel as an example, the IKE_SA_INIT message sent by the first network device to the second network device may be as follows:

[0112] In this example, SUPPORT_VPN_INSTANCE indicates that the local end has the capability to associate a service instance with a security protocol tunnel.

[0113] Taking the case where the second network device does not have the capability of associating a service instance with a security protocol tunnel as an example, the IKE_SA_INIT message that the second network device replies to the first network device may be as follows:

[0114] In this example, the second network device does not have the ability to associate a service instance with a secure protocol tunnel. Therefore, the response message it sends to the first network device does not carry a NOTIFY payload of the SUPPORT_VPN_INSTANCE type. Based on this, the first network device can understand from the absence of the NOTIFY payload of the SUPPORT_VPN_INSTANCE type in the response message that the second network device does not have the ability to associate a service instance with a secure protocol tunnel. It can then choose not to create an IKE SA and notify the termination of the session, or continue to create an IKE SA and subsequently negotiate a Child SA without carrying the service instance negotiation information.

[0115] For example, when initially establishing an IKE SA, the first network device and the second network device can negotiate algorithms, exchange key materials, and use a NOTIFY payload through an IKE_SA_INIT message, where the NOTIFY payload can carry some additional information, such as information used to characterize whether the local end has the ability to associate a security protocol tunnel with a service instance.

[0116] As an example, the Notify Message Type used in the NOTIFY payload to carry information indicating whether the local end has the capability to associate a service instance with a secure protocol tunnel can be as shown in Figure 6. A Notify Message Type field of SUPPORT_VPN_INSTANCE indicates that the local end has the capability to associate a service instance with a secure protocol tunnel. The value X of SUPPORT_VPN_INSTANCE can be any unoccupied available value within the standard range of IKEv2 NOTIFY values, such as 16444. The receiving end can determine whether the sending end has the capability to associate a service instance with a secure protocol tunnel based on the specific value of the Notify Message Type field.

[0117] Of course, in some embodiments, the receiving end may also determine whether the sending end has the ability to associate a security protocol tunnel with a business instance based on whether the Notify Message Type field is included in the NOTIFY payload. For example, if the Notify Message Type field is included in the NOTIFY payload, the receiving end may consider that the sending end has the ability to associate a security protocol tunnel with a business instance. If the Notify Message Type field is not included in the NOTIFY payload, the receiving end may consider that the sending end does not have the ability to associate a security protocol tunnel with a business instance.

[0118] As an example, the NOTIFY payload may also carry the Supported VPN Nums field, shown in Figure 7, which indicates the number of associated service instances supported by a Child SA, i.e., the maximum number of supported service instances. As an example, the Supported VPN Nums field shown in Figure 7 can be an optional 4-byte field. As an example, if the local end does not limit the number, the Supported VPN Nums field can be all 0s, all Fs, or not carry this field, without specific restrictions.

[0119] As an example, the first network device and the second network device can perform capability negotiation in the IKE_AUTH or CREATE_CHILD_SA stage. For example, the party with the ability to associate a service instance with a security protocol tunnel can carry a new NOTIFY payload in the IKE_AUTH or CREATE_CHILD_SA message to inform the other party that it has the ability to associate a service instance with a security protocol tunnel. If the receiving party also has the ability to associate a service instance with a security protocol tunnel, it can also carry the NOTIFY payload in the response message. Based on this, the sending end can carry the service instance negotiation information when subsequently negotiating to create a Child SA; if the receiving party does not have the ability to associate a service instance with a security protocol tunnel, it can ignore the NOTIFY payload and not carry the NOTIFY payload in the response message, or reply such as NO_PROPOSAL_CHOSEN or other error responses. Based on this, the sending end will not carry the service instance negotiation information when subsequently negotiating to create a Child SA.

[0120] For the process of capability negotiation between the first network device and the second network device through the IKE_AUTH message in the IKE_AUTH phase, through the CREATE_CHILD_SA message in the CREATE_CHILD_SA phase, or through the INFORMATIONAL message, and the related introduction of the NOTIFY payload used to inform the other end that the local end has the ability to associate a security protocol tunnel with a service instance, please refer to the related introduction of capability negotiation between the first network device and the second network device in the IKE_SA_INIT exchange phase above, which will not be repeated here.

[0121] Of course, explicit capability negotiation may not be performed between network devices (such as between the first network device and the second network device). For example, in some embodiments, when either the first network device or the second network device does not have the capability to associate a service instance with a security protocol tunnel, it may inform the other end that it does not have the capability to associate a service instance with a security protocol tunnel by replying with a NOTIFY payload of the TS_UNACCEPTABLE type or other error response. This method is also called implicit capability negotiation. Based on this, the other end device can create a Child SA in a conventional manner. This application does not specifically limit the specific timing and specific method for network devices to conduct capability negotiation.

[0122] For example, using the TS_VPNV4_ADDR_RANGE type Traffic Selector in the CREATE_CHILD_SA message to create a Child SA, if the second network device does not have the ability to associate a service instance with a security protocol tunnel, the reply message may be as follows:

[0123] In this example, the second network device informs the first network device that it does not have the ability to associate a service instance with a security protocol tunnel by carrying a NOTIFY payload of the TS_UNACCEPTABLE type in the CREATE_CHILD_SA message. Based on this, the first network device can know that the second network device does not have the ability to associate a service instance with a security protocol tunnel, and can therefore not carry the service instance negotiation information when subsequently negotiating to create a Child SA.

[0124] After completing S501, if both the first network device and the second network device have the capability of associating the service instance with a security protocol tunnel, proceed to S502:

[0125] S502: The first network device negotiates with the second network device about a service instance corresponding to the secure tunnel.

[0126] In some embodiments, a first network device may include service instance negotiation information, such as a service instance of the first network device, in a message sent to a second network device to instruct the second network device to create a secure tunnel between the first and second network devices. Upon receiving a response message from the second network device, the first network device may complete the creation of the secure tunnel based on the response message and simultaneously associate the created secure tunnel with the service instance of the first network device and the service instance of the second network device (such as the service instance indicated in the response message). The service instance indicated in the response message is determined by the second network device based on the service instance negotiation information.

[0127] In some examples, the first network device and the second network device can negotiate and determine a service instance corresponding to any of the one or more secure tunnels based on the Internet Key Exchange Version 2 (IKEv2) protocol. For example, the first network device and the second network device can negotiate and determine the service instance corresponding to the secure tunnel by carrying service instance negotiation information in any one or more of the following messages: an IKE_AUTH message and a CREATE_CHILD_SA message.

[0128] The IKE_AUTH message can be used to negotiate the creation of the first Child SA, and the CREATE_CHILD_SA message can be used to negotiate the creation of the second and subsequent Child SAs. For example, when creating a Child SA, the first network device and the second network device can negotiate which traffic on both ends of the IPsec network can use the Child SA based on the IP address, protocol, and port.

[0129] In some embodiments, the first network device and the second network device may include service instance negotiation information in an IKE_AUTH message to negotiate and determine the service instance corresponding to the secure tunnel. That is, the first network device and the second network device may also negotiate, through the IKE_AUTH message, which service instance traffic at both ends of the IPsec network can use the Child SA.

[0130] The IKE_AUTH message may carry the service instance negotiation information through any one or more of the following fields: an extension field (such as an extension header), a special field, a reserved field, an IP address field, and a TTL field.

[0131] As an example, the first network device and the second network device can define a new traffic selector (TS) payload in the IKE_AUTH message, such as extending the Traffic Selector to carry service instance negotiation information. The form of the service instance negotiation information in the Traffic Selector can include but is not limited to any form such as numbers and strings, and is not specifically limited. In addition, the Traffic Selector can carry the service instance negotiation information alone, or it can carry both the service instance negotiation information and other information (such as IP address, protocol, port, etc.).

[0132] As shown in Figure 8, a TS payload can contain multiple Traffic Selectors. The information in the Traffic Selector can be used to indicate to the IPsec peer which traffic requires IPsec processing. As an example, the Traffic Selectors for conventional TS Types TS_IPV4_ADDR_RANGE (value 7) and TS_IPV6_ADDR_RANGE (value 8) might be as shown in Figure 9.

[0133] As an example, a Traffic Selector carrying service instance negotiation information may be as shown in Figure 10. In the Traffic Selector format shown in Figure 10, the TS Type is TS_VPNV4_ADDR_RANGE or TS_VPNV6_ADDR_RANGE. This Traffic Selector differs from the Traffic Selector TS Type shown in Figure 9, which has the TS Type of TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE. This Traffic Selector also includes a VPN ID field, which is used to carry service instance negotiation information. As an example, the VPN ID field can be identification information (e.g., an ID) of the service instance.

[0134] As an example, a traffic selector carrying service instance negotiation information may also be shown in Figure 11. In the Traffic Selector format shown in Figure 11, the TS Type is TS_VPN. This Traffic Selector differs from the Traffic Selector TS Types TS_IPV4_ADDR_RANGE and TS_IPV6_ADDR_RANGE shown in Figure 9 in that it has a new VPN ID field, which is used to carry service instance negotiation information. As an example, the VPN ID field can be identification information (e.g., an ID) of the service instance.

[0135] In some embodiments, the first network device and the second network device can include service instance negotiation information in a CREATE_CHILD_SA message to negotiate and determine the service instance corresponding to the secure tunnel. That is, the first network device and the second network device can also negotiate, through the CREATE_CHILD_SA message, which service instances on both ends of the IPsec network can use the Child SA.

[0136] As an example, using the TS_VPNV4_ADDR_RANGE type Traffic Selector in the CREATE_CHILD_SA message to carry service instance negotiation information, the message may be as follows:

[0137] In the above message exchange example, TSi stands for Traffic Selector-initiator, and TSr stands for Traffic Selector-responder. Both TSi and TSr are expressions agreed upon in RFC 7296 of the IKEv2 protocol. TSi represents traffic sent from or received by the Initiator, and TSr represents traffic received by or sent from the Responder.

[0138] For example, two operators share base stations 1 and 2. Assume that operator 1 uses VRF1 as the service instance and the corresponding VPN ID is 1. Assume that operator 2 uses VRF2 as the service instance and the corresponding VPN ID is 2. Operators 1 and 2 use the same IP address range. For example, the address range used on base station 1 is 10.1.1.0–10.1.1.255, and the address range used on base station 2 is 11.1.1.0–11.1.1.255. Base station 1 (Initiator) and base station 2 (Responder) use the IKEv2 protocol. When negotiating the creation of a Child SA in the CREATE_CHILD_SA process, a Child SA can be associated with a service instance through the following message:

[0139] For example, the TS payload in this example is as follows:

[0140] In this TS payload example, two TS_VPNV4_ADDR_RANGE type Traffic Selectors are used. One Traffic Selector indicates that the traffic from the Initiator to the Responder belonging to the VPN instance "VRF1" with a source IPv4 address range of "10.1.1.0 to 10.1.1.255" and a destination IPv4 address range of "11.1.1.0 to 11.1.1.255" and the traffic from the Responder to the Initiator belonging to the VPN instance "VRF1" with a source IPv4 address range of "11.1.1.0 to 11.1.1.255" and a destination IPv4 address range of "10.1.1.0 to 10.1.1.255" are of interest. The other Traffic Selector indicates that the traffic from the Initiator to the Responder belonging to the VPN instance "VRF1" with a source IPv4 address range of "11.1.1.0 to 11.1.1.255" and a destination IPv4 address range of "10.1.1.0 to 10.1.1.255" are of interest. The Selector indicates that the traffic from the Initiator to the Responder within VPN instance VRF2, with a source IPv4 address range of 10.1.1.0 to 10.1.1.255 and a destination IPv4 address range of 11.1.1.0 to 11.1.1.255, and the traffic from the Responder to the Initiator within VPN instance VRF1, with a source IPv4 address range of 11.1.1.0 to 11.1.1.255 and a destination IPv4 address range of 10.1.1.0 to 10.1.1.255, are the flows of interest. These flows require this Child SA.

[0141] In some embodiments, the first network device and the second network device can carry service instance negotiation information in a newly added NOTIFY payload to negotiate and determine the service instance corresponding to the secure tunnel. That is, the first network device and the second network device can also negotiate which service instance traffic at both ends of IPsec can use the Child SA through the newly added NOTIFY payload. The form of the service instance negotiation information in the NOTIFY payload can include but is not limited to any form such as numbers and strings, and is not specifically limited. In addition, the NOTIFY payload can carry service instance negotiation information alone, or it can carry both service instance negotiation information and other information (such as IP address, protocol, port, etc.).

[0142] As an example, a NOTIFY payload carrying service instance negotiation information may be as shown in Figure 12. In the NOTIFY payload format shown in Figure 12, the Notify Message Type field is VPN_BINDING, and the value Q of VPN_BINDING can be any unoccupied available value within the IKEv2 NOTIFY standard range, such as 16448. The NOTIFY payload format shown in Figure 12 also includes a VPN ID field, which is used to carry service instance negotiation information. For example, the VPN ID field can be identification information (e.g., an ID) of the service instance.

[0143] Taking the VPN_BINDING type NOTIFY payload carried in the CREATE_CHILD_SA message as an example, the message carrying service instance negotiation information and indicating the association between the Child SA to be created and certain service instances specified in the NOTIFY payload may be as follows:

[0144] It can be understood that VPN is a stand-alone concept. Generally, when creating a VPN on a device, a VPN name in string format is created for it, and the VPN name is used as the VPN identifier in the device. However, the embodiment of the present application relies on the use of IPsec SA based on business instance negotiation, and the IPsec message needs to carry business instance information. Therefore, it is necessary to complete the mapping of business instances and VPN ID values ​​between multiple devices. In some embodiments, in order to ensure the consistency of the mapping between business instances and VPN IDs, the mapping of business instances and VPN IDs can be performed through configuration or interaction between devices.

[0145] As an example, an administrator may configure mappings between specified service instances and VPN IDs on different network devices to ensure that the mappings are the same across all network devices.

[0146] For example, you can create a mapping between a service instance and a VPN ID based on the VPN name as follows:

[0147] [device1]vpn <vpn-name>.

[0148] In this example, <vpn-name>The field is the business name that the administrator needs to enter.

[0149] For example, you can specify the corresponding VPN ID when creating a VPN based on the following example:

[0150] [device1]vpn <vpn-name> <vpn-id>.

[0151] In this example, <vpn-name>This is the business name that the administrator needs to enter. <vpn-id>Field <vpn-name>The corresponding VPN ID, <vpn-id>This field can be an integer value, which allows administrators to specify the same VPN ID for VPNs with the same VPN name on different network devices.

[0152] For example, an administrator can use the following command line to create two VPNs on device1 and device2, respectively. The VPN named "VRF1" has a VPN ID of 1 on both devices, and the VPN named "VRF2" has a VPN ID of 2 on both devices:

[0153] [device1]vpn VRF1 1;

[0154] [device1]vpn VRF2 2;

[0155] [device2]vpn VRF1 1;

[0156] [device2]vpn VRF2 2.

[0157] As another example, network devices may interact based on the IKEv2 protocol, adding negotiation or notification regarding mapping between service instances and VPN IDs.

[0158] For example, a NOTIFY payload carrying service instance negotiation information may also carry a newly added VPN_ID_MAPPING type, where the VPN_ID_MAPPING type is used to inform the peer of the mapping relationship between the service instance name (VPN Name) and ID included in the message. For example, a NOTIFY payload carrying the VPN_ID_MAPPING type may be as shown in Figure 13 , where the Notify Message Type field shown in Figure 13 is VPN_ID_MAPPING, indicating that the message includes a mapping relationship between the service instance name (VPN Name) and ID. The VPN_ID_MAPPING value G can be any available value within the IKEv2 NOTIFY range defined by the IANA organization, such as 16453. The VPN ID field shown in Figure 13 is used to carry service instance negotiation information. For example, the VPN ID field can be identification information (e.g., ID) of the service instance, and the VPN Name field represents the name of the service instance.

[0159] Taking the example of the first network device and the second network device notifying the other end of the mapping relationship between the name (VPN Name) and ID of the local service instance in the IKE_SA_INIT message, the IKE_SA_INIT message may be as follows:

[0160] In some examples of this application, a security tunnel can correspond to multiple service instances. For example, through negotiation, a Child SA can be associated with multiple service instances, and a combination of a Child SA and an IKE SA can provide services for multiple service instances. Based on this example, the number of SAs can be minimized, thereby minimizing the number of SAs, saving system computing / storage / IP address resources, reducing customer operation and maintenance costs, and improving SA utilization.

[0161] Of course, in other examples of this application, a security tunnel may also correspond to only one business instance. For example, through negotiation, a Child SA can be associated with a business instance, a Child SA can provide services for a business instance, and multiple Child SAs that provide services for multiple different business instances can share an IKE SA. Although this cannot reduce the number of SAs to a minimum, it can reduce the number of IKE SAs (such as to 1), so it can still reduce the number of SAs to a certain extent, save system computing / storage / IP address and other resources, reduce customer operation and maintenance costs, and improve SA utilization. In addition, in this example, the network device does not need to modify the IPsec data plane and can directly reuse the traditional IPsec protocol process and format.

[0162] For example, assume that carrier 1 uses VRF1 as the service instance, corresponding to VPN ID 1. Carrier 1 uses the address range 10.1.1.0–10.1.1.255 on base station 1 and the address range 11.1.1.0–11.1.1.255 on base station 2. Device 1 (Initiator) and device 2 (Responder) negotiate the creation of a Child SA using the IKEv2 protocol during the CREATE_CHILD_SA process. The following message associates a Child SA with a service instance:

[0163] In this example, the value of the VPN ID field is 1, representing "VRF1". That is, based on this message, the Child SA can be associated with a service instance VRF1.

[0164] It can be understood that based on the above-mentioned capability negotiation process provided by the embodiment of the present application, network devices can understand each other's capabilities, such as whether they have the ability to associate a business instance with a secure protocol tunnel, so that both parties can decide whether to subsequently negotiate the business instance corresponding to the secure tunnel based on each other's capabilities. Based on this, it can be avoided that when one party (such as the second network device) does not have the ability to associate a business instance with a secure protocol tunnel, the party (such as the first network device) that has the ability to associate a business instance with a secure protocol tunnel sends business instance negotiation information to the second network device, which may cause the receiving party to process it incorrectly.

[0165] Furthermore, when both network devices have the ability to associate a secure protocol tunnel with a service instance, based on the above-mentioned service instance negotiation process provided in the embodiment of the present application, multiple operators are supported to share the same secure tunnel between network devices. For example, the same secure tunnel is available to any operator served by the first network device and the second network device. In other words, regardless of any data transmission requirements of any operator served by the first network device and the second network device, the first network device can complete the data transmission through any secure tunnel between the first network device and the second network device. In addition, an association relationship between a secure tunnel and a service instance can be established between network devices, and service isolation can be achieved while sharing hardware resources. This not only solves the problem of a sharp increase in the specifications of secure tunnels between stations, saves system computing, storage, IP address and other resources, reduces customer operation and maintenance costs, and improves the utilization rate of secure tunnels, but also facilitates the selection of secure tunnels and the smooth identification and parsing of the receiving end during subsequent data transmission between network devices, ensuring more reliable and efficient operation of services.

[0166] Based on the service instance negotiation process between network devices provided in the above-mentioned embodiments of the present application, when there is a need for data transmission between network devices, the network devices can perform IPsec processing on traffic under different service instances based on the Child SA. In conventional technology, because the SPIs of different Child SAs are completely different, it is sufficient to encapsulate messages solely by relying on the SPI. However, in the embodiments of the present application, because multiple service instances may reuse the same Child SA, but different service instances each have different policies, it is necessary to add an identifier to the message to identify the service instance so that the data plane can distinguish which service instance the message (such as an Encapsulation Security Payload Protocol (ESP) message or an Authentication Header Protocol (AH) message) belongs to.

[0167] As an example, please refer to FIG. 14 , which shows a flow chart of a data transmission method under a secure tunnel sharing mechanism provided in an embodiment of the present application. As shown in FIG. 14 , the method may include S1401 to S1404:

[0168] S1401: A first network device receives a transmission request for transmitting service data.

[0169] The transmission request may be initiated by any operator served by the first network device, and the transmission request may correspond to any service instance without specific limitation.

[0170] S1402: In response to the first transmission request, the first network device sends a data message to the second network device through the first security protocol tunnel, where the data message includes service data and an identifier of a first service instance corresponding to the service data.

[0171] There are one or more secure tunnels between the first network device and the second network device, and the first security protocol tunnel is one of the one or more secure tunnels. The identifier of the first service instance is, for example, the ID of the first service instance.

[0172] As a possible implementation manner, the first network device may determine a security tunnel associated with the first service instance from the one or more security tunnels based on the association relationship between the security tunnel and the service instance, such as the first security protocol tunnel.

[0173] The aforementioned association between secure tunnels and service instances represents the service instances corresponding to each secure tunnel. This association may be determined based on a negotiation between the first network device and the second network device. The method and specific process for negotiating the service instances corresponding to the secure tunnels between the first network device and the second network device can be found in the above description and will not be further elaborated here.

[0174] As an example, the first network device can encrypt the business data at the tunnel interface of the first security protocol tunnel based on the security policy corresponding to the first business instance, encapsulate the data into a data message, and then send the data message to the second network device through the first security protocol tunnel. The security policy corresponding to the first business instance can be pre-set in the first network device. For example, the first network device can be pre-set with security policies corresponding to one or more security tunnels. The first network device can determine the security policy corresponding to the first business instance based on the identifier of the first business instance in the data message. Alternatively, the security policy corresponding to the first business instance can be generated by the first network device and the second network device, such as when the first network device and the second network device negotiate the correspondence between the security tunnel and the business instance.

[0175] As an example, a data message such as an IPsec message may include, but is not limited to, a plaintext IPv4 message before encryption, a plaintext IPv6 message before encryption, an encrypted ciphertext IPv4 message, an encrypted ciphertext IPv6 message, an ESP message, an AH message, etc. Correspondingly, the identifier of the first service instance may be carried in one or more of the following: a plaintext IPv4 header before encryption (i.e., an unencrypted IPv4 header), a plaintext IPv6 header before encryption (i.e., an unencrypted IPv6 header), a plaintext IPv4 extension field before encryption (e.g., an unencrypted IPv4 extension header), a plaintext IPv6 extension field before encryption (e.g., an unencrypted IPv6 extension header), an encrypted ciphertext IPv4 header (i.e., an encrypted IPv4 header), an encrypted ciphertext IPv6 header (i.e., an encrypted IPv6 header), an encrypted ciphertext IPv4 extension field (e.g., an encrypted IPv4 extension header), an encrypted ciphertext IPv6 extension field (e.g., an encrypted IPv6 extension header), etc.

[0176] As described above, the essence of Child SA multiplexing technology is to map multiple SPDs to a security association database (SAD). Based on this, when a Child SA is shared by multiple service instances, the first network device can indicate the specific SPD mapped to the SAD of the second network device by carrying the identifier of the service instance in the data packet. As an example, the first network device can encrypt the service data at the tunnel interface of the first security protocol tunnel based on the SPD and SAD (i.e., the security policy) corresponding to the first service instance, encapsulate the data into a data packet, and then send the data packet to the second network device through the first security protocol tunnel.

[0177] As an example, please refer to Figure 15A, which shows a schematic diagram of the encryption process of a data message provided by an embodiment of the present application. Wherein, (a) in Figure 15A shows a process in which conventional plaintext business data is securely protected and encrypted based on SPD and SAD at the tunnel interface of a secure tunnel, and is ultimately forwarded to a target device in ciphertext form. (b) in Figure 15A shows a process in which plaintext business data of multiple different business instances provided by an embodiment of the present application (as shown in Figure 15A, plaintext 1 and plaintext 2) are securely protected and encrypted based on SPD and SAD at the tunnel interface of a secure tunnel, and ultimately are forwarded to a target device in ciphertext form. Wherein, the MUX shown in (b) in Figure 15A is a multiplexer, and the MUX can add the identifier of the business instance therein during the message encryption process.

[0178] It should be noted that the present application does not limit the specific encapsulation mode of the data message. For example, the encapsulation mode of the data message may include but is not limited to a tunnel mode or a transport mode.

[0179] Among them, tunnel mode means that the user's entire IP data packet is involved in encryption and authentication, such as being used to calculate the AH or ESP header. The AH or ESP header and the ESP-encrypted service data are encapsulated in a new IP data packet. As an example, for tunnel mode, a secure tunnel usually needs to first encrypt and authenticate the service data, then create a new IP header and add the encrypted IP data packet therein. Transport mode means that only the payload of the IP data packet is encrypted and authenticated, and then added to a new IP header. As an example, for transport mode, a secure tunnel usually needs to first encrypt and authenticate the payload in the service data, then create a new IP header and add the encrypted payload therein. For an introduction to the specific encapsulation mode of the data message, please refer to conventional technology and will not be described in detail here.

[0180] As an example, the identifier of the first business instance can be carried in but not limited to any one of the following: the IPv4 header of the plaintext IPv4 message of the first mode, the IPv6 header of the plaintext IPv4 message of the first mode, the IPv4 header of the ciphertext IPv4 message of the first mode, the IPv4 header of the ciphertext IPv6 message of the first mode, the IPv4 header of the ciphertext IPv6 message of the second mode, and the IPv6 of the ciphertext IPv6 message of the second mode.

[0181] It should be noted that the present application does not limit the specific encryption mode of the data message. As a possible example, the secure tunnel can encrypt the plaintext business data and the identifier of the first business instance together; correspondingly, after receiving the encrypted data message, the second network device can rely on the SPI mapping Child SA in the header of the data message (such as ESP message, AH message, etc.) to perform decryption processing, and then map the plaintext business data to the corresponding business instance for subsequent processing based on the identifier of the first business instance in the plaintext data message. As another possible example, the first network device can encrypt the plaintext business data and encapsulate it together with the identifier of the first business instance to obtain a data message; correspondingly, after receiving the data message, the second network device can rely on the SPI mapping Child SA in the header of the data message (such as ESP message, AH message, etc.) to perform decryption processing, and then map the plaintext business data to the corresponding business instance for subsequent processing based on the identifier of the first business instance in the ciphertext data message.

[0182] It should be noted that the embodiments of the present application do not specifically limit the IP version of the ciphertext data message and the plaintext IP version, and the two can be the same or different. As an example, the ciphertext data message described in the embodiments of the present application can be an IPv4 message or an IPv6 message.

[0183] As an example, taking the encapsulation mode of the data message as tunnel mode, the message format carrying the identifier of the first service instance in the optional field of the IPv4 header of the plaintext IPv4 message may be as follows:

[0184] ________________________************************************

[0185] |IP Header|ESP / AH Header|IPv4 Header|Option:VPNID|PAYLOAD|

[0186] _______________________************************************

[0187] In this example, "-" represents a non-encrypted field, "*" represents an encrypted field, and the identifier of the first service instance is located in the Option field.

[0188] As an example, taking the encapsulation mode of the data message as tunnel mode, the message format carrying the identifier of the first service instance in the TTL field of the IPv4 header of the plaintext IPv4 message may be as follows:

[0189] __________________________***********************************

[0190] |IP Header|ESP / AH Header|IPv4 Header(TTL:VPNID)|PAYLOAD|

[0191] ___________________________***********************************

[0192] In this example, "-" represents a non-encrypted field, "*" represents an encrypted field, and the identifier of the first service instance is located in the TTL field.

[0193] As an example, taking the encapsulation mode of the data message as tunnel mode, the message format carrying the identifier of the first service instance in the destination address extension field of the plaintext IPv6 message may be as follows:

[0194] _______________________************************************************

[0195] |IP Header|ESP / AH Header|IPv6 Header|Destination Extension:VPNID|PAYLOAD|

[0196] _________________________*************************************************

[0197] In this example, "-" represents a non-encrypted field, "*" represents an encrypted field, and the identifier of the first service instance is located in the Destination Extension field.

[0198] As an example, taking the encapsulation mode of the data message as tunnel mode, the message format carrying the identifier of the first service instance in the flow label field of the plaintext IPv6 message may be as follows:

[0199] ___________________________****************************************

[0200] |IP Header|ESP / AH Header|IPv6 Header(Flow Lable:VPNID)|PAYLOAD|

[0201] ____________________________****************************************

[0202] In this example, "-" represents a non-encrypted field, "*" represents an encrypted field, and the identifier of the first service instance is located in the Flow Lable field of the IPv6 Header.

[0203] As an example, taking the encapsulation mode of the data message as tunnel mode, the message format carrying the identifier of the first service instance in the optional field of the IPv4 header of the ciphertext IPv4 message may be as follows:

[0204] The message format is as follows: ("-" is a non-encrypted field, "*" is an encrypted field)

[0205] _______________________________________***********

[0206] |IPv4 Header|Option:VPNID|ESP / AH Header|PAYLOAD|

[0207] _____________________________________***********

[0208] In this example, "-" represents a non-encrypted field, "*" represents an encrypted field, and the identifier of the first service instance is located in the Option field.

[0209] As an example, taking the encapsulation mode of the data message as tunnel mode, the message format carrying the identifier of the first service instance in the destination address extension field of the ciphertext IPv6 message may be as follows:

[0210] _______________________________________________________***********

[0211] |IPv6 Header|Destination Extension:VPNID|ESP / AH Header|PAYLOAD|

[0212] _________________________________________________________***********

[0213] In this example, "-" represents a non-encrypted field, "*" represents an encrypted field, and the identifier of the first service instance is located in the Destination Extension field.

[0214] As an example, taking the encapsulation mode of the data message as transport mode, the message format carrying the identifier of the first service instance in the optional field of the IPv4 header of the ciphertext IPv4 message may be as follows:

[0215] ____________________________________________***********

[0216] |IPv4 Header|Option:VPNID|ESP / AH Header|PAYLOAD|

[0217] _____________________________________***********

[0218] In this example, "-" represents a non-encrypted field, "*" represents an encrypted field, and the identifier of the first service instance is located in the Option field.

[0219] As an example, taking the transport mode as an example, the message format carrying the identifier of the first service instance in the destination address extension field of the ciphertext IPv6 message may be as follows:

[0220] __________________________________________________***********

[0221] |IPv6 Header|Destination Extension:VPNID|ESP / AH Header|PAYLOAD|

[0222] ____________________________________________________***********

[0223] In this example, "-" represents a non-encrypted field, "*" represents an encrypted field, and the identifier of the first service instance is located in the Destination Extension field.

[0224] S1403: The second network device determines a security policy for the data message based on the identifier of the first service instance.

[0225] As a possible implementation, the second network device may match a security policy corresponding to the first service instance from multiple security policies based on the first service instance in the data packet. For example, the second network device may have pre-configured security policies corresponding to one or more security tunnels. The second network device may match the security policy corresponding to the first service instance based on the identifier of the first service instance in the data packet. If a match is found, the second network device may decrypt the data packet based on the matched security policy. If a match is not found, the second network device may terminate processing of the data packet.

[0226] As mentioned above, the essence of Child SA multiplexing technology is to map multiple SPDs to a security association database SAD. Based on this, when Child SA is shared by multiple service instances, the second network device can determine the specific SPD used for decryption based on the identifier of the service instance carried in the data message.

[0227] As an example, please refer to Figure 15B, which shows a schematic diagram of the decryption process of a data message provided by an embodiment of the present application. Figure 15B (a) shows the process of a conventional secure tunnel interface performing secret encryption based on SPD and SAD, and Figure 15B (b) shows the process of the secure tunnel interface provided by an embodiment of the present application selecting a matching SPD for decryption based on the identifiers of the service instances carried in each of multiple data messages (such as ciphertext 1 and ciphertext 2 shown in Figure 15B). The DEMUX shown in Figure 15B (b) is a demultiplexer, and the DEMUX can obtain the identifiers of the service instances therein during the ciphertext decryption process.

[0228] S1404: The second network device parses the data message according to the determined security policy to obtain service data.

[0229] As a possible implementation manner, the second network device may decrypt the data packet based on the security policy corresponding to the first service instance to obtain service data.

[0230] In some embodiments, the network device may also accept modification or deletion of the secure tunnel, and the network device may also accept modification (such as addition or deletion) of the service instance corresponding to the secure tunnel.

[0231] For example, in response to a request to delete a secure tunnel, the first network device may send a message to the second network device instructing the deletion of the secure protocol tunnel between the first network device and the second network device. For another example, in response to a request to delete the association between a secure tunnel and a service instance, the first network device may send a message to the second network device instructing the deletion of the association between a target secure tunnel and a target service instance. For another example, in response to a request to add an association between a secure tunnel and a service instance, the first network device may send a message to the second network device instructing the addition of an association between a target secure tunnel and a service instance.

[0232] As an example, in response to a request to delete a Child SA, the first network device may send an INFORMATIONAL message to the second network device, where the INFORMATIONAL message carries a DELETE payload for notifying the second network device of the Child SA to be deleted.

[0233] For example, an INFORMATIONAL message might look like this:

[0234] In this example, D represents a DELETE payload, which may carry the SPI value of the Child SA to be deleted. The first network device and the second network device may delete the corresponding Child SA based on the SPI value.

[0235] As an example, in response to a request to delete a service instance associated with a Child SA, the first network device may add a NOTIFY payload of the OPERATE_VPN_INSTANCE type to notify the peer device via this NOTIFY payload that the associated service instance needs to be deleted. For example, the network device may send a NOTIFY payload to the peer device via an INFORMATIONAL exchange message to indicate to the peer device that the service instance corresponding to the Child SA needs to be deleted.

[0236] For example, a network device notifies the peer end of the need to delete a service instance through the newly added NOTIFY payload type. The message for deleting a service instance corresponding to a Child SA may be as follows:

[0237] In this example, N(OPERATE_VPN_INSTANCEa), N(OPERATE_VPN_INSTANCEb), and D(spi1, spi2, spi3) are as follows:

[0238] In this example, when the SPI in the NOTIFY payload has a corresponding Notify(OPERATE_VPN_INSTANCE) payload, it means that the entire Child SA does not need to be completely deleted, but the association between the Child SA indicated by the Notify payload and a certain service instance needs to be deleted, such as spi1 and spi2 in this example. When the SPI in the NOTIFY payload cannot find a corresponding Notify(OPERATE_VPN_INSTANCE) payload, it means that the entire Child SA is completely deleted, such as spi3 in this example. Based on this, it is ultimately possible to delete the association between the Child SA corresponding to spi1 and vpn1 and vpn2, delete the association between the Child SA corresponding to spi2 and vpn2 and vpn3, and completely delete the Child SA corresponding to spi3.

[0239] As an example, in response to a request to modify the service instance corresponding to a Child SA, as a possible implementation method, the network device can create a new Child SA separately. In the new Child SA, in addition to associating the interested flows of the existing service instance, it also adds the interested flows corresponding to the new service instance, and then deletes the old Child SA separately.

[0240] For example, a message for modifying a service instance corresponding to a Child SA may be as follows:

[0241] Alternatively, as a possible implementation manner, the network device may add an interested flow corresponding to the associated new service instance through a CREATE_CHILD_SA message during the CREATE_CHILD_SA phase.

[0242] Alternatively, as a possible implementation manner, the network device may use a rekey function to create a new interested flow corresponding to the new service instance in the new Child SA during the rekey process.

[0243] For example, a message for modifying a service instance corresponding to a Child SA may be as follows:

[0244] Alternatively, as a possible implementation, a network device may add a new NOTIFY payload type, using which the peer device may be notified that it needs to modify (e.g., add or delete) an associated service instance. For example, the network device may send a new NOTIFY payload to the peer device via an INFORMATIONAL exchange message to indicate to the peer device that it needs to add or delete an associated service instance in an already created Child SA.

[0245] For example, the NOTIFY payload may be as shown in Figure 16, where the Notify Message Type field shown in Figure 16 may be OPERATE_VPN_INSTANCE, and the value Z of OPERATE_VPN_INSTANCE may be any unoccupied available value within the standard range of values ​​in IKEv2 NOTIFY, such as 16447. The Operation Flag field shown in Figure 16 indicates whether the operation is to add or delete an association, for example, 1 indicates adding an association, and 2 indicates deleting an association. The VPNs field exists only when the Operation Flag field is "Delete Association" and indicates that the association between the SA indicated by the SPI and the service instance indicated by this field needs to be deleted.

[0246] For example, a network device notifies the peer end of a newly associated service instance by adding a new NOTIFY payload type. The message for adding a service instance corresponding to a Child SA may be as follows:

[0247] For example, the NOTIFY payload in this example might look like this:

[0248] In this NOTIFY payload example, the TS payload carrying the TS_VPNV4_ADDR_RANGE type Traffic Selector indicates that the traffic sent from the Initiator to the Responder and belonging to VPN instance "VRF3" with a source IPv4 address range of "10.1.1.0 to 10.1.1.255" and a destination IPv4 address range of "11.1.1.0 to 11.1.1.255" and the traffic sent from the Responder to the Initiator and belonging to VPN instance "VRF3" with a source IPv4 address range of "11.1.1.0 to 11.1.1.255" and a destination IPv4 address range of "10.1.1.0 to 10.1.1.255" are interesting flows. These interesting flows need to use this Child SA.

[0249] As an example, please refer to Figure 17, which shows a specific interaction diagram of the association relationship between a secure tunnel and a business instance provided by an embodiment of the present application. As shown in Figure 17, message 1 and message 2 carry the policies of VPN1 and VPN2, and after completion, an IKE SA and Child are generated. SA, but two different TS policies are negotiated, corresponding to VPN1 and VPN2 respectively; message 3 shown in Figure 17 represents the sending of ESP messages between VPNs and the encryption and decryption of messages, where the ESP message carries VPN1 or VPN2, and the SPI is the SPI negotiated based on messages 1 and 2; messages 4 and 5 shown in Figure 17 represent the addition of a VPN3 and the negotiation of related information about VPN3. After the negotiation, the two parties can encrypt or decrypt messages about VPN1, VPN2, and VPN3 based on message 6 shown in Figure 17; when there is a need to delete the service instance corresponding to the secure tunnel, the two parties can negotiate the service instances to be deleted, such as VPN1 and VPN12, through messages 7 and 8 (such as Delete messages) shown in Figure 17; finally, as shown in message 9 in Figure 17, encryption or decryption of messages can be achieved based only on the remaining VPN3.

[0250] In some embodiments, the network device may also accept a key update (also referred to as "rekey") for a service instance associated with a security tunnel. For example, in response to a request to update the key for a service instance, the first network device may send a message to the second network device instructing the second network device to update the key for a service instance associated with a security protocol tunnel.

[0251] As an example, in response to a request to update a key of a Child SA, as a possible implementation, the first network device may use a Traffic Selector of the TS_VPNV4_ADDR_RANGE type to update the key of the Child SA when creating the Child SA. The Rekey message for updating the key may be as follows:

[0252] Alternatively, as another possible implementation, the first network device may use a NOTIFY payload of the VPN_BINDING type to update the key of the Child SA when creating the Child SA. The message for updating the key may be as follows:

[0253] After the first network device and the second network device complete the key update, the old Child SA may be deleted according to the process specified in the IKEv2 protocol.

[0254] It is understood that by supporting the deletion of secure tunnels and the modification of the association between secure tunnels and service instances (such as adding or deleting them), network devices in the embodiments of the present application can achieve more flexible secure tunnel sharing. For example, network devices can negotiate with other network devices at any time regarding the management of secure tunnels based on actual needs, including adding or deleting secure tunnels on demand, and adding / deleting the association between secure tunnels and service instances on demand. This supports on-demand allocation of system computing, storage, IP address and other resources through on-demand adjustments, achieving more scientific resource allocation.

[0255] It should be understood that the various schemes of the embodiments of the present application can be reasonably combined and used, and the explanations or descriptions of the various terms appearing in the embodiments can be referenced or explained with each other in the various embodiments, without limitation to this.

[0256] It should also be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0257] It is understandable that, in order to implement the functions of any of the above-mentioned embodiments, the network device (such as the first network device or the second network device) includes a hardware structure and / or software module corresponding to the execution of each function. Those skilled in the art should easily appreciate that, in combination with the units and algorithm steps of each example described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0258] The embodiments of the present application can divide the network device into functional modules. For example, each functional module can be divided according to each function, or two or more functions can be integrated into one processing module. The above-mentioned integrated modules can be implemented in the form of hardware or software functional modules. It should be noted that the division of modules in the embodiments of the present application is schematic and is only a logical functional division. In actual implementation, other division methods may be used.

[0259] It should also be understood that the various modules in a network device can be implemented in software and / or hardware, without specific limitation. In other words, the network device is presented in the form of functional modules. "Modules" here can refer to application-specific integrated circuits (ASICs), circuits, processors and memories that execute one or more software or firmware programs, integrated logic circuits, and / or other devices that can provide the aforementioned functions.

[0260] In an optional manner, when data transmission is implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is implemented in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that includes one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a digital video disk (DVD)), or a semiconductor medium (e.g., a solid state disk (SSD)).

[0261] The steps of the method or algorithm described in conjunction with the embodiments of the present application can be implemented in hardware or by executing software instructions by a processor. The software instructions can be composed of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM) memory, registers, hard disk, mobile hard disk, compact disc read-only memory (CD-ROM) or any other form of storage medium known in the art. An exemplary storage medium is coupled to a processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be an integral part of the processor. The processor and the storage medium can be located in an application specific integrated circuit (ASIC). In addition, the ASIC can be located in a network device. Of course, the processor and the storage medium can also exist as discrete components.

[0262] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. < / vpn-name>

Claims

1. A method for creating a security protocol tunnel, characterized in that: Applied to a first network device, the method comprises: Sending a first message containing first information to a second network device, where the first message is used to instruct the creation of a security protocol tunnel between the first network device and the second network device, and the first information is used to indicate a service instance of the first network device; receiving a second message from the second network device, where the second message is a response of the second network device to the first message, and the second message carries second information, where the second information is used to indicate a service instance determined by the second network device based on the first information; The security protocol tunnel is created according to the second message and the second network device, and the security protocol tunnel is associated with the service instance indicated by the second information.

2. The method according to claim 1, characterized in that The method further comprises: Sending a third message to the second network device, where the third message is used to instruct modification of a security protocol tunnel between the first network device and the second network device; Modify one or more security protocol tunnels between the first network device and the second network device.

3. The method according to claim 2, characterized in that The modifying of the security protocol tunnel between the first network device and the second network device includes one or more of the following: deleting the association relationship between the security protocol tunnel and the service instance, and adding the association relationship between the security protocol tunnel and the service instance.

4. The method according to claim 3, characterized in that The third message is used to indicate deletion of the association relationship between the security protocol tunnel and the service instance between the first network device and the second network device. The third message carries a first message, and the first message includes an INFORMATIONAL message.

5. The method according to claim 3, characterized in that: The third message is used to indicate the newly added association relationship between the security protocol tunnel and the service instance, and the third message carries a second message, and the second message includes a CREATE_CHILD_SA message, an INFORMATIONAL message, or an IKE_SA_INIT message.

6. The method according to any one of claims 1 to 5, characterized in that The method further comprises: Sending a fourth message to the second network device, where the fourth message is used to indicate that the first network device has the ability to associate a service instance with a security protocol tunnel; A fifth message is received from the second network device, where the fifth message is used to indicate that the second network device has the ability to associate the service instance with a security protocol tunnel.

7. The method according to claim 6, characterized in that The fourth message carries a third message, and the third message includes an IKE_SA_INIT message, an IKE_AUTH message, a CREATE_CHILD_SA message, and an INFORMATIONAL message.

8. A data transmission method, characterized in that: Applied to a first network device, the method comprises: A data message carrying service data is sent to a second network device through a first security protocol tunnel, wherein the data message includes an identifier of a first service instance corresponding to the service data, and the first security protocol tunnel is associated with the first service instance.

9. The method according to claim 8, characterized in that The identifier of the first service instance is located in one or more of the following fields of the data message: an unencrypted IPv4 header, an encrypted IPv4 header, an unencrypted IPv6 header or an IPv6 extension header, an encrypted IPv6 header or an extension header.

10. The method according to claim 8 or 9, characterized in that: Before sending the data message to the second network device through the first security protocol tunnel, the method further includes: At the tunnel interface of the first security protocol tunnel, the service data is encrypted based on the security policy corresponding to the first service instance and then encapsulated into the data message.

11. The method according to any one of claims 8 to 10, characterized in that: The security protocol tunnel includes an IPsec tunnel.

12. A method for creating a secure protocol tunnel, characterized in that: Applied to the second network device, the method comprises: receiving a first message from a first network device, where the first message is used to instruct the creation of a security protocol tunnel between the first network device and the second network device, and the first message includes first information, where the first information is used to indicate a service instance of the first network device; Sending a second message to the first network device, where the second message is a response of the second network device to the first message, and the second message carries second information, where the second information is used to indicate a service instance determined by the second network device based on the first information; The security protocol tunnel is created according to the first message and the first network device, and the security protocol tunnel is associated with the service instance indicated by the second information.

13. The method according to claim 12, characterized in that The method further comprises: receiving a third message from the first network device, wherein the third message is used to instruct modification of a security protocol tunnel between the first network device and the second network device; One or more security protocol tunnels between the first network device and the second network device are modified based on the third message.

14. The method according to claim 13, characterized in that The modifying of the security protocol tunnel between the first network device and the second network device includes one or more of the following: deleting the association relationship between the security protocol tunnel and the service instance, and adding the association relationship between the security protocol tunnel and the service instance.

15. The method according to claim 14, characterized in that The third message is used to indicate deletion of the association relationship between the security protocol tunnel and the service instance between the first network device and the second network device. The third message carries a first message, and the first message includes an INFORMATIONAL message.

16. The method according to claim 14, characterized in that The third message is used to indicate the newly added association relationship between the security protocol tunnel and the service instance, and the third message carries a second message, and the second message includes a CREATE_CHILD_SA message, an INFORMATIONAL message, or an IKE_SA_INIT message.

17. The method according to any one of claims 12 to 16, characterized in that: The method further comprises: receiving a fourth message from the first network device, wherein the fourth message is used to indicate that the first network device has the ability to associate a service instance with a security protocol tunnel; A fifth message is sent to the first network device, where the fifth message is used to indicate that the second network device has the ability to associate the service instance with a security protocol tunnel.

18. The method according to claim 17, characterized in that The fifth message carries a third message, and the third message includes an IKE_SA_INIT message, an IKE_AUTH message, a CREATE_CHILD_SA message, and an INFORMATIONAL message.

19. A data transmission method, characterized in that: Applied to the second network device, the method comprises: Receiving a data message sent by a first network device through a first security protocol tunnel, the data message including service data and an identifier of a first service instance corresponding to the service data, the first security protocol tunnel being one of one or more security protocol tunnels between the first network device and the second network device, and the first security protocol tunnel being associated with the first service instance; Determining a security protocol policy for the data message based on an identifier of the first service instance; The data message is parsed according to the security protocol policy to obtain the business data.

20. The method according to claim 19, characterized in that The identifier of the first service instance is located in one or more of the following fields of the data message: an unencrypted IPv4 header, an encrypted IPv4 header, an unencrypted IPv6 header or an IPv6 extension header, an encrypted IPv6 header or an extension header.

21. The method according to claim 19 or 20, characterized in that The parsing the data message to obtain the service data includes: The data message is parsed based on the security protocol policy corresponding to the first service instance to obtain the service data.

22. The method according to any one of claims 19 to 21, characterized in that The security protocol tunnel includes an IPsec tunnel.

23. A communication system, characterized in that: The communication system comprises a first network device and a second network device, wherein the first network device is used to implement the method as described in any one of claims 1-7 or 8-11, and the second network device is used to implement the method as described in any one of claims 12-18 or 19-22.

24. A network device, characterized in that: The network equipment includes: A transceiver, used for sending and receiving signals; a memory for storing computer program instructions; A processor, configured to execute the computer program instructions to support the network device to implement the method as described in any one of claims 1-11 or 12-22.

25. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer program instructions, and when the computer program instructions are executed by the processing circuit, the method according to any one of claims 1-11 or 12-22 is implemented.

26. A computer program product comprising instructions, characterized in that When the computer program product is run on a computer, the computer is caused to execute the method according to any one of claims 1 to 11 or 12 to 22.

27. A chip system, characterized in that: The chip system includes a processing circuit and a storage medium, wherein the storage medium stores computer program instructions; when the computer program instructions are executed by the processing circuit, the method as described in any one of claims 1-11 or 12-22 is implemented.

Images