Security protocol tunnel sharing method, device and system

Abstract

Disclosed are a method, device and system for sharing a security protocol tunnel, which relate to the technical field of communications, can share the same security tunnel through a plurality of service instances, and ensure more reliable and efficient operation of services while improving the utilization rate of the security tunnel. In the application, the network equipment supports a plurality of operators to share the same security tunnel among the network equipment, and the network equipment can support service isolation under the condition that the security tunnel is shared by the plurality of operators by establishing and managing the association relationship between the security tunnel and the service instance, so that the service isolation can still be realized on the basis of the above. In addition, system computing, storage, IP address and other resources can be saved, the client operation and maintenance cost is reduced, and safety tunnel selection and smooth identification and analysis of a receiving end during subsequent data transmission between network devices are facilitated.

Description

Technical Field

[0001] This application relates to the field of communication technologies, and in particular, to a method, device, and system for sharing a secure protocol tunnel. Background Art

[0002] As the current 3rd generation partnership project (3GPP) already supports secure self-establishment through the X2 / Xn interface, such as directly establishing a secure protocol tunnel (hereinafter referred to as "secure tunnel") between two base stations, such as an Internet Protocol Security (IPsec) tunnel. Among them, in the scenario of multi-operator base stations, such as the scenario where a base station serves multiple operators simultaneously, due to the need for transmission isolation and data isolation between operators, different operators usually adopt different virtual routing and forwarding (VRF), and different VRFs require separate secure tunnels.

[0003] However, due to the resource limitations of IPsec, the secure tunnels that a base station can establish are usually limited. Based on this, in the case where the number of secure tunnels of the base station is limited, how to improve the utilization rate of secure tunnels in the multi-operator base station scenario is a problem that needs to be solved. Summary of the Invention

[0004] This application provides a method, device, and system for sharing a secure protocol tunnel, which can share the same secure tunnel through multiple service instances, while improving the utilization rate of the secure tunnel, ensuring that the service runs more reliably and efficiently.

[0005] To achieve the above object, this application adopts the following technical solutions:

[0006] In a first aspect, a method for creating a secure protocol tunnel is provided. This method is applied to a first network device and may include: First, the first network device sends a first message containing first information to the second network device, where the first message is used to indicate the creation of a secure protocol tunnel between the first network device and the second network device, and the first information is used to indicate the service instance of the first network device; Then, the first network device receives a second message from the second network device, where the second message is a response from 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 secure protocol tunnel with the second network device according to the second message, and associates the secure 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.

[0007] As an example, one or more secure protocol tunnels can be established between the first network device and the second network device. For any secure protocol tunnel between the first network device and the second network device, it can be established based on the above method and associated with the corresponding service instance.

[0008] In the solution provided in the first aspect above, the first network device can support multiple operators it serves to share the secure protocol tunnel between the first network device and other network devices (such as the second network device), and can support service isolation even when the secure tunnel is shared by multiple operators by establishing and managing the association relationship between the secure tunnel and the service instance. Based on this, system computing, storage, IP addresses and other resources can also be saved, the customer operation and maintenance cost can be reduced, and it is convenient for the selection of the secure tunnel during subsequent data transmission between network devices and the smooth identification and parsing at the receiving end.

[0009] As a possible implementation manner, the above method further includes: the first network device sends a third message to the second network device, where the third message is used to indicate modifying the secure protocol tunnel between the first network device and the second network device; the first network device modifies one or more secure protocol tunnels between the first network device and the second network device. Based on this, more flexible secure tunnel sharing can be achieved. For example, the network device can negotiate with other network devices about the management of the secure tunnel at any time according to actual needs, including modifying the secure tunnel as needed, and supporting on-demand allocation of system computing, storage, IP addresses and other resources through on-demand adjustment, so as to achieve more scientific resource allocation.

[0010] As a possible implementation manner, the above method further includes: the first network device instructs the second network device to update the key of the service instance associated with the secure protocol tunnel between the first network device and the second network device. For example, the first network device can respond to a request to update the key of the service instance and instruct the second network device to update the key of a certain service instance associated with a certain secure 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 can instruct the second network device to update the key of a certain service instance associated with a certain secure protocol tunnel through a Rekey message.

[0011] As a possible implementation manner, the above modification of the secure 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 secure protocol tunnel and the service instance, and adding a new association relationship between the secure protocol tunnel and the service instance.

[0012] For example, in response to a request to delete a security tunnel, the first network device may send a message to the second network device to indicate the deletion of the security 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 security tunnel and a service instance, the first network device may send a message to the second network device to indicate the deletion of the association between the target security tunnel and the target service instance. For yet another example, in response to a request to add the association between a security tunnel and a service instance, the first network device may send a message to the second network device to indicate the addition of the association between the target security tunnel and the service instance.

[0013] Based on this, more flexible sharing of security tunnels can be achieved. For example, a network device can negotiate with other network devices about the management of security tunnels at any time according to actual needs, including adding or deleting security tunnels as needed, adding / deleting the association between a security tunnel and a service instance as needed, and supporting the on-demand allocation of system computing, storage, IP addresses and other resources by means of on-demand adjustment, so as to achieve more scientific resource allocation.

[0014] As a possible implementation, the above-mentioned 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 may indicate the deletion of the security protocol tunnel between the first network device and the second network device, or indicate the deletion of the association between the security protocol tunnel and the service instance, through the DELETE payload carried in the INFORMATIONAL message. Based on this, it is possible to support the on-demand deletion of a security tunnel or the on-demand deletion of the association between a security tunnel and a service instance in different communication scenarios, so as to achieve the on-demand allocation of system computing, storage, IP addresses and other resources.

[0015] As a possible implementation, the above-mentioned third message is used to indicate the addition of the association between a security protocol tunnel and a service instance. 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 may indicate the addition of the association between a security protocol tunnel and a service instance through the CREATE_CHILD_SA message, the NOTIFY payload carried in the INFORMATIONAL message, the NOTIFY payload carried in the IKE_SA_INIT message, etc. Based on this, it is possible to support the on-demand addition of the association between a security tunnel and a service instance in different communication scenarios, so as to achieve the on-demand allocation of system computing, storage, IP addresses and other resources.

[0016] As a possible implementation manner, the above method further includes: a first network device sending a fourth message to a second network device, where 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; the first network device receiving a fifth message from the second network device, where the fifth message is used to indicate that the second network device has the ability to associate a security protocol tunnel with a service instance. Based on this, it is convenient for both communication parties to understand whether they have the ability to associate a security protocol tunnel with a service instance, so as to decide whether to negotiate the service instance corresponding to the security tunnel based on their respective 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 service instance, the party with the ability to associate a security protocol tunnel with a service instance (such as the first network device) sending service instance negotiation information to the second network device may cause processing errors at the receiving end. As an example, the fourth message and the first message may be the same message.

[0017] As a possible implementation manner, the above fourth message carries a third message, where the third message includes IKE_SA_INIT message, IKE_AUTH message, CREATE_CHILD_SA message, INFORMATIONAL message. For example, the fourth message can inform the second network device whether the first network device has the ability to associate a security protocol tunnel with a service instance 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, it is possible to support the notification of service instance negotiation capabilities in different communication scenarios to support the selection of subsequent communication strategies.

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

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

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

[0021] Second aspect, a data transmission method is provided. This method can be applied to a first network device and may include: The first network device sends a data packet carrying service data to a second network device through a first secure protocol tunnel, where the data packet includes an identifier of a first service instance corresponding to the service data, and the first secure protocol tunnel has an association relationship with the first service instance.

[0022] For the solution provided in the second aspect above, the transmitting end of the data packet can transmit service data related to a service instance through a secure protocol tunnel associated with the service instance, and carry the identifier of the service instance corresponding to the service data in the data packet, so that the receiving end of the data packet can perform subsequent verification of the data packet based on the identifier of the service instance carried in the data packet, and select a matching security policy to parse the data packet, so as to support the efficient, reliable, and orderly transmission of service data based on the shared secure protocol tunnel solution.

[0023] 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: unencrypted Internet Protocol version (IPv) 4 header, encrypted IPv4 header, unencrypted IPv6 header or IPv6 extension header, encrypted IPv6 header or extension header. Based on this, it is possible to support the carrying of service instance identifiers in different communication scenarios to support the efficient, reliable, and orderly transmission of subsequent service data.

[0024] As a possible implementation, before the first network device sends a data packet to the second network device through the first secure protocol tunnel, the method further includes: The first network device encrypts the service data based on the security policy corresponding to the first service instance at the tunnel interface of the first secure protocol tunnel and encapsulates it into a data packet. Based on this, the secure and reliable transmission of service data can be ensured.

[0025] As a possible implementation, the first network device can communicate with the second network device based on the IKEv2 protocol. As an example, the secure protocol tunnel may include an IPsec tunnel. Of course, the present 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 in the present application. Moreover, the secure protocol tunnel between the first network device and the second network device can also be a secure tunnel based on other protocols.

[0026] In a third aspect, a method for creating a secure protocol tunnel is provided. This method can be applied to a second network device and may include: First, the second network device receives a first message from a first network device. The first message is used to indicate the creation of a secure protocol tunnel between the first network device and the second network device. The first message includes first information, where the first information is used to indicate the service instance of the first network device. Then, the second network device sends a second message to the first network device. 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 the service instance determined by the second network device based on the first information. Finally, the second network device completes the creation of the secure protocol tunnel with the first network device according to the first message and associates the secure protocol tunnel with the service instance indicated by the second information.

[0027] As an example, one or more secure protocol tunnels can be established between the first network device and the second network device. For any secure protocol tunnel between the first network device and the second network device, it can be established based on the above method and associated with the corresponding service instance.

[0028] For the solution provided in the above third aspect, the second network device can support multiple operators it serves to share the secure protocol tunnel between the second network device and other network devices (such as the first network device), and can support service isolation even when the secure tunnel is shared by multiple operators by establishing and managing the association relationship between the secure tunnel and the service instance. Based on this, system computing, storage, IP addresses, and other resources can also be saved, the customer operation and maintenance cost can be reduced, and it is convenient for the selection of the secure tunnel during subsequent data transmission between network devices and the successful identification and parsing at the receiving end.

[0029] As a possible implementation manner, the above method further includes: The second network device receives a third message from the first network device, where the third message is used to indicate modifying the secure protocol tunnel between the first network device and the second network device; The second network device modifies one or more secure protocol tunnels between the first network device and the second network device based on the third message. Based on this, more flexible secure tunnel sharing can be achieved. For example, network devices can negotiate with other network devices about the management of secure tunnels at any time according to actual needs, including modifying secure tunnels as needed, and support on-demand allocation of system computing, storage, IP addresses, and other resources through on-demand adjustment, so as to achieve more scientific resource allocation.

[0030] As a possible implementation, the above method further includes: The second network device updates the key of the service instance associated with the security protocol tunnel between the first network device and the second network device according to the indication of the first network device. 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 can indicate to the second network device to update the key of a certain service instance associated with a certain security protocol tunnel through a Rekey message.

[0031] As a possible implementation, modifying 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, adding a new association relationship between the security protocol tunnel and the service instance. Based on this, more flexible sharing of secure tunnels can be achieved. For example, a network device can negotiate with other network devices about the management of secure tunnels at any time according to actual needs, including adding or deleting secure tunnels as needed, adding / deleting the association relationship between the secure tunnel and the service instance as needed, and supporting the on-demand allocation of system computing, storage, IP addresses and other resources by adjusting as needed, so as to achieve more scientific resource allocation.

[0032] As a possible implementation, the above third message is used to indicate deleting the association relationship between the security protocol tunnel and the service instance between the first network device and the second network device, and the third message carries a first message, and the first message includes an INFORMATIONAL message. For example, the third message can indicate deleting the security protocol tunnel between the first network device and the second network device through the DELETE payload carried in the INFORMATIONAL message, or indicate deleting the association relationship between the security protocol tunnel and the service instance. Based on this, it is possible to support deleting a secure tunnel or deleting the association relationship between the secure tunnel and the service instance on demand in different communication scenarios, so as to achieve on-demand allocation of system computing, storage, IP addresses and other resources.

[0033] As a possible implementation, the above third message is used to indicate adding a new association relationship between the security protocol tunnel and the service instance, where 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 adding a new association relationship between the security protocol tunnel and the service instance through the NOTIFY payload carried in the CREATE_CHILD_SA message, the INFORMATIONAL message, the NOTIFY payload carried in the IKE_SA_INIT message, etc. Based on this, it is possible to support adding a new association relationship between the secure tunnel and the service instance on demand in different communication scenarios, so as to achieve on-demand allocation of system computing, storage, IP addresses and other resources.

[0034] As a possible implementation manner, the above method further includes: The second network device receives a fourth message from the first network device, where 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; The second network device sends a fifth message to the first network device, where 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 can be convenient for both communication parties to understand whether they have the ability to associate a security protocol tunnel with a service instance, so as to decide whether to negotiate the service instance corresponding to the security tunnel subsequently based on their respective 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 service instance, the party with the ability to associate a security protocol tunnel with a service instance (such as the first network device) sending service instance negotiation information to the second network device may cause processing errors at the receiving side.

[0035] As a possible implementation manner, the above fifth message carries a third message, where the third message includes IKE_SA_INIT message, IKE_AUTH message, CREATE_CHILD_SA message, and INFORMATIONAL message. For example, the fifth message can inform the second network device whether the first network device has the ability to associate a security protocol tunnel with a service instance 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, it can support the notification of service instance negotiation capabilities in different communication scenarios to support the selection of subsequent communication strategies.

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

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

[0038] Of course, the present 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 the present application. Also, the security protocol tunnel between the second network device and the first network device can also be a security tunnel based on other protocols.

[0039] Fourthly, 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 a first network device through a first secure protocol tunnel. The data packet includes service data and an identifier of a first service instance corresponding to the service data. The first secure protocol tunnel is one of one or more secure protocol tunnels between the first network device and the second network device, and the first secure protocol tunnel has an association relationship with the first service instance. Then, the second network device determines a security policy for the data packet based on the identifier of the first service instance. Finally, the second network device parses the data packet according to the determined security policy to obtain the service data.

[0040] For the solution provided in the fourth aspect above, the sender of the data packet (such as the first network device) can transmit service data related to a service instance through a secure protocol tunnel associated with the service instance, and carry the identifier of the service instance corresponding to the service data in the data packet. The receiver of the data packet (such as the second network device) can select a matching security policy based on the identifier of the service instance carried in the data packet to parse the data packet, so as to support the efficient, reliable and orderly transmission of service data based on the shared secure protocol tunnel solution.

[0041] 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: unencrypted IPv4 header, encrypted IPv4 header, unencrypted IPv6 header or IPv6 extension header, encrypted IPv6 header or extension header. Based on this, it is possible to support the carrying of service instance identifiers in different communication scenarios to support the efficient, reliable and orderly transmission of subsequent service data.

[0042] As a possible implementation, the second network device parses the data packet to obtain the service data, including: the second network device parses the data packet based on the security policy corresponding to the first service instance to obtain the service data. Based on this, it is possible to ensure the secure and reliable transmission of service data and the successful parsing of data.

[0043] As a possible implementation, the second network device can communicate with the first network device based on the IKEv2 protocol. As an example, the secure protocol tunnel may include an IPsec tunnel. Of course, the present 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 in the present application. Moreover, the secure protocol tunnel between the first network device and the second network device can also be a secure tunnel based on other protocols.

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

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

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

[0047] In an eighth aspect, a computer program product containing instructions is provided. When the computer program product runs on a computer, the computer is enabled to implement the method described in any possible implementation manner of the first aspect, the second aspect, the third aspect, or the fourth aspect.

[0048] In a ninth aspect, a chip system is provided. The chip system includes a processing circuit and a storage medium, and computer program instructions are stored in the storage medium; when the computer program instructions are executed by the processor, the method described in any possible implementation manner of the first aspect, the second aspect, the third aspect, or the fourth aspect is implemented. The chip system may be composed of chips or may include chips and other discrete devices. Description of the Drawings

[0049] Figure 1 It is a schematic diagram of a system architecture provided by an embodiment of the present application;

[0050] Figure 2 It is a schematic diagram of conventional data transmission based on a secure tunnel;

[0051] Figure 3A It is a schematic diagram of data transmission based on a secure tunnel provided by an embodiment of the present application;

[0052] Figure 3B It is a schematic diagram of the encryption process of a message provided by an embodiment of the present application;

[0053] Figure 3C It is another schematic diagram of the encryption process of a message provided by an embodiment of the present application;

[0054] Figure 4 Schematic diagram of the hardware structure of a network device provided by an embodiment of the present application;

[0055] Figure 5 Schematic diagram of the process of data transmission between network devices provided by an embodiment of the present application;

[0056] Figure 6 Message example for capability negotiation provided by an embodiment of the present application Figure 1 ;

[0057] Figure 7 Message example for capability negotiation provided by an embodiment of the present application Figure 2 ;

[0058] Figure 8 Message example for carrying service instance negotiation information provided by an embodiment of the present application Figure 1 ;

[0059] Figure 9 Message example for carrying service instance negotiation information provided by an embodiment of the present application Figure 2 ;

[0060] Figure 10 Message example diagram for carrying service instance negotiation information provided by an embodiment of the present application - Figure 3

[0061] Figure 11 Message example for carrying service instance negotiation information provided by an embodiment of the present application Figure 4 ;

[0062] Figure 12 Message example for carrying service instance negotiation information provided by an embodiment of the present application Figure 5 ;

[0063] Figure 13 Message example for carrying service instance negotiation information provided by an embodiment of the present application Figure 6 ;

[0064] Figure 14 Flowchart of a data transmission method under a secure tunnel sharing mechanism provided by an embodiment of the present application;

[0065] Figure 15A Schematic diagram of the decryption of a message provided by an embodiment of the present application

[0066] Figure 15B Another schematic diagram of the decryption of a message provided by an embodiment of the present application

[0067] Figure 16 Message example diagram for modifying a secure tunnel provided by an embodiment of the present application;

[0068] Figure 17 This is a specific interaction schematic diagram of the association relationship between a security tunnel and a service instance provided by an embodiment of the present application. Detailed implementation manners

[0069] Next, the technical solutions in the embodiments of the present application will be described with reference to the accompanying drawings in the embodiments of the present application. Among them, in the description of the embodiments of the present application, unless otherwise specified, " / " means "or". For example, A / B may represent A or B; herein, "and / or" is only a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B may represent: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of the present application, "a plurality of" means two or more than two.

[0070] Hereinafter, terms such as "first" and "second" are only used to distinguish different described objects, and do not limit the position, order, priority, quantity or content of the described objects. For example, if the described object is "field", the ordinal numbers before "field" in "the first field" and "the second field" do not limit the position or order between the "fields", and "first" and "second" do not limit whether the "fields" they modify are in the same message, nor do they limit the order of the "first field" and the "second field". Again, if the described object is "level", the ordinal numbers before "level" in "the first level" and "the second level" do not limit the priority between the "levels". Again, the quantity of the described object is not limited by the ordinal number and can be one or more. Taking "the first device" as an example, the quantity of "device" can be one or more. In addition, the objects modified by different prefixes can be the same or different. For example, if the described object is "device", then "the first device" and "the second device" can be devices of the same type or different types. Again, if the described object is "information", then "the first information" and "the second information" can be information of the same content or different content. In short, the use of ordinal numbers and other prefixes for distinguishing described objects in the embodiments of the present application does not constitute a limitation on the described objects, and the description of the described objects refers to the description in the claims or the context of the embodiments, and should not constitute an unnecessary limitation due to the use of such prefixes.

[0071] In addition, in the embodiments of the present application, "connection" can be a direct connection or an indirect connection; in addition, it can refer to an electrical connection or a communication connection; for example, when two electrical components A and B are connected, it can mean that A is directly connected to B, or it can mean that A and B are indirectly connected through other electrical components or connection media, or it can mean that A and B are indirectly connected through other communication devices or communication media, as long as communication can be carried out between A and B.

[0072] Currently, in the application scenarios of wireless base stations, such as Figure 1 shown, the 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 the collaborative services between the base stations. The core network may include Figure 1 the local area network (LAN), SeGW, mobility management entity (MME) / authentication management function (AMF), signal gateway (SGW) / user plane function (UPF), etc. shown.

[0073] With the 3GPP's support for directly establishing a secure tunnel between base stations, in order to reduce the traffic load of the security gateway and the latency between base stations, a secure tunnel can be directly established between base stations, such as a Direct IPsec tunnel (hereinafter referred to as "IPsec tunnel"). As Figure 1 shown, the secure transmission between base station 1 and base station 2 can be achieved not only by relying on the secure protocol channel between the base station and the security gateway (SeGW) of the core network, but also by relying on the secure tunnel between base station 1 and base station 2.

[0074] In the scenario of multi-operator base stations, such as the scenario where a base station serves multiple operators simultaneously, that is, in the RAN Sharing scenario where multiple operators share the same base station, since transmission isolation and data isolation are required between operators, different operators usually adopt different VRFs, and different VRFs require separate secure tunnels. In order to perform transmission isolation and data isolation between operators, 4 inter-station secure tunnels need to be established between base station 1 and base station 2 according to the operator granularity. Similarly, multiple secure tunnels also need to be established between base station 1 and other base stations, and multiple secure tunnels also need to be established between base station 2 and other base stations to meet the isolation between different operators.

[0075] As we know, the resources of IPsec are limited. For example, the single-board hardware of IPsec is limited. In some examples, the Child SA specification of the entire single 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, taking a total of 4 operators as an example, and assuming that 4 security tunnels are established between Base Station 1 and other stations, Base Station 1 needs to establish 512 * 4 = 2048 security tunnels with other base stations. Therefore, based on the conventional inter-station security tunnel establishment mechanism, it will lead to a sharp increase in the inter-station security tunnel specification. The essence of this problem is that the security tunnel cannot be used as a common pipeline to provide sharing for all operators, which greatly wastes the resources of the base station. That is to say, the key to solving the problem of the sharp increase in the above-mentioned security tunnel specification lies in improving the utilization rate of the security tunnel through security tunnel sharing under the condition that the number specification of the base station security tunnel is limited.

[0076] Among them, the key to establishing a security tunnel lies in negotiating the security parameters for protecting the security tunnel and the security parameters for protecting service data. Taking the security tunnel as an IPSec tunnel as an example, when establishing an IPSec tunnel, the negotiation of IKE SA and Child SA is the key point. Among them, IKE SA is a security association (SA) used for encrypting and other security protections of IKE messages negotiated based on the internet key exchange (IKE) protocol. Child SA is an SA used for specific service security protection negotiated based on the IKE protocol. Since the main usage scenario of the IKE protocol is IPsec, Child SA is sometimes also called IPsec SA (collectively referred to as "ChildSA" in the following embodiments). IKE SA is a set of security parameters used to protect the IPSec tunnel, and Child SA is mainly used for security parameters to protect user data. Among them, in the above negotiation process, IKE SA is the basis of Child SA because the establishment of Child SA requires a series of keys after the establishment of IKE SA.

[0077] Currently, the mainstream configurations of IKE SA and Child SA are often based on protocol standards such as RFC7296 and RFC4301. The above-mentioned protocols do not support the sharing of secure tunnels between base stations, and in the Traffic Selector related to Child SA in the protocols, only the range of interesting traffic is defined (for example, the range of source addresses and destination addresses is defined to describe the traffic that needs to be encrypted), and other dimensions are not defined, such as the granularity of virtual private network (VPN). Therefore, in order to avoid the problem that multiple service instances cannot be isolated and distinguished when there are address conflicts (where address conflicts are a relatively common scenario), each different service instance requires an independent IKE SA and a Child SA to support, that is, a combination of one IKE SA + Child SA cannot provide multiplexing and sharing for multiple service instances, not even within a single operator. In this case, as Figure 2 shown, if there are N (N is a positive integer greater than 1) inner-layer service instances, then N local IKE addresses, N IKE SAs, and N Child SAs need to be provided between base station 1 and base station 2. Among them, the service instance can be Figure 2 the virtual routing and forwarding (VRF) 1, VRF2, and VRF3 shown. In some cases, the service instance is also called a "VRF instance". Among them, VRF is an instance created on a physical device and obtained by logically partitioning the physical device. Each instance is isolated at the routing level, and based on this, data or services can be isolated. Each VRF has independent interfaces, routing tables, and routing protocol processes, etc. That is to say, the current protocol does not support the sharing of secure tunnels between base stations in terms of both protocol functions and the specified communication process.

[0078] In order to solve the problem of the sharp increase in the specifications of inter-station secure tunnels in the conventional technology, the embodiments of the present application provide a method for sharing a secure protocol tunnel. This method can support multiple operators to share multiple secure tunnels between network devices, and these multiple secure tunnels are available to any operator served by the first network device and the second network device. As Figure 3AAs shown in the figure, 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 security protection such as encryption by IKE1. That is to say, no matter which operator the first network device and the second network device serve and there is a data transmission requirement, the first network device can complete data transmission through any security tunnel between it and the second network device. Based on this, the problem of the sharp increase in the specifications of inter-station security tunnels can be solved, resources such as system computing, storage, and IP addresses can be saved, the operation and maintenance costs of customers can be reduced, the utilization rate of security tunnels can be improved at the same time, and the business can be ensured to run more reliably and efficiently.

[0079] In some embodiments, in order to solve the problem in the conventional technology that since each different service instance requires an independent IKE SA and a Child SA to support, the security tunnel cannot provide multiplexing and sharing for multiple service instances, resulting in a still low utilization rate of the security tunnel, the method for sharing a security protocol tunnel provided by the embodiments of the present application can also associate a Child SA with one or more service instances, so as to achieve the effect that a combination of an IKE SA and a Child SA can provide multiplexing and sharing for multiple service instances. Based on this, the network device does not need to establish independent IKE SAs and Child SAs for each service instance, so the number of inter-station security tunnels can be further reduced, resources such as system computing, storage, and IP addresses can be saved, the operation and maintenance costs of customers can be reduced, the utilization rate of security tunnels can be further improved at the same time, and the business can be ensured to run more reliably and efficiently.

[0080] Taking the RFC4301 protocol standard as an example, two databases are defined in this standard, namely a security policy database (SPD) that maps a security association database (SAD). Among them, SPD describes which traffic can be encrypted, and SAD describes how to encrypt data packets. 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 security tunnel, 1 SPD and SAD will be newly added under this security tunnel, and SPD and SAD will map to each other. In this way, when the control plane protocol completes the negotiation of the correspondence between multiple service instances and security tunnels, the mapping relationship of multiple SPD entries and 1 SAD entry will be obtained.

[0081] Based on this, the core of the embodiments of the present application is that multiple service instances share 1 Child SA. Since each service instance has its own complete and independent address and routing space (such as space isolation is achieved through VRF), SPD should belong to the VPN level, and SAD should belong to the system level. From the perspective of the system, such asFigure 3B As shown, the SPD entries corresponding to the service instances of multiple service data ( Figure 3B taking plaintext 1, plaintext 2, and plaintext 3 as examples) can be mapped to 1 SAD entry of the system. From the perspective of the VPN instance, as Figure 3B shown, the SPD entry corresponding to the service instance of a service data ( Figure 3C taking plaintext 2 as an example) can be mapped to 1 SAD entry of the system. Figure 3C taking VPN2 SPD as an example) Figure 3C It should be noted that in some scenarios, the service instance can also be a VPN instance.

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

[0083] Among them, the network device described in the embodiments of the present application may be the base station in the above examples, such as: macro base station, micro base station (also known as "small station"), distribute unit-control unit (DU-CU), etc. Among them, DU-CU is a device deployed in the radio access network that can perform wireless communication with terminal devices. In addition, the above base station may also be a radio controller in the cloud radio access network (CRAN) scenario, or a relay station, access point, vehicle-mounted device, wearable device, or network device in the future evolved public land mobile network (PLMN) network, etc.

[0084] In some examples, the base station may be an Ng-eNB, gNB, or transmission / reception point (TRP). It may also be a base station defined by the 3rd generation partnership project (3GPP). For example, eNB or e-NodeB, etc.

[0085] In addition, when the eNB accesses the core network of NR or the next generation core network (NGC) or the 5G core network (5GC), the eNB can also be called an eLTE eNB. Specifically, the eLTE eNB is an LTE base station device evolved on the basis of the eNB, which can be directly connected to the 5G CN, and the eLTE eNB also belongs to the base station device in NR.

[0086] In some examples, the network device described in the embodiments of the present application may also include other types, functions, and structures of network devices, such as wireless terminals (WTs), access points (APs), access controllers (ACs), or other network devices with the ability to communicate with terminal devices and the core network. The embodiments of the present application do not make specific limitations.

[0087] Please refer to Figure 4 , Figure 4 which shows a schematic diagram of the hardware structure of a network device. As Figure 4 shown, the network device may include a processor 401, a communication line 402, a memory 403, and at least one communication interface ( Figure 4 only for example, the communication interface 404 is used for illustration).

[0088] 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 solution of the present application.

[0089] The communication line 402 may include a path for transmitting information between the above components.

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

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

[0092] The memory 403 can be a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM) or other types of dynamic storage devices that can store information and instructions, or can also be an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM), or other optical disc storage, optical disc storage (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), magnetic disk storage media, or other magnetic storage devices, or any other medium that can be used to carry or store the 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 can exist independently and be connected to the processor through the communication line 402. The memory can also be integrated with the processor.

[0093] Among them, the memory 403 is used to store computer-executable instructions for executing the solution of this application. Among them, the memory 403 can store instructions for implementing two modular functions: sending instructions, receiving instructions, and processing instructions, and is controlled by the processor 401 to execute. The processor 401 is used to execute the computer-executable instructions stored in the memory 403, so as to implement the method provided in the following embodiments of this application. Figure 4 The memory 403 shown in is only a schematic diagram, and this memory can also include other functionalized instructions. In this regard, the present invention does not make any limitations thereto.

[0094] Optionally, the computer-executable instructions in this application can also be referred to as application code, and this application does not make specific limitations thereto.

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

[0096] It should be noted that Figure 4 only as an example of a network device, does not limit the specific structure of the network device. For example, the network device can also include other functional modules.

[0097] Hereinafter, the method for sharing a secure protocol tunnel provided in the embodiments of this application will be specifically introduced in conjunction with the accompanying drawings.

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

[0099] For example, as a possible implementation, when creating a Child SA, that is, during Child SA negotiation, a network device may associate one Child SA with multiple service instances, so that a combination of one IKE SA and one Child SA can provide multiplexing and sharing 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. Also, 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 may also carry service instance information in the packet after IPsec processing, so that the peer network device can identify the service instance to which the data belongs.

[0100] Of course, the embodiments of this application do not limit the number of service instances corresponding to one Child SA either. For example, one Child SA may also be associated with one service instance, but the Child SAs associated with different service instances may 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. Exemplarily, when performing IPsec processing, the network device may respectively use multiple Child SAs corresponding to multiple data, and the peer network device can identify the service instance to which the data belongs based on the serial peripheral interface (SPI) value field of the SA in the packet using the traditional IPsec processing process.

[0101] Based on the above implementation, the network device does not need to establish independent IKE SAs and Child SAs for each service instance. Therefore, the number of inter-station secure tunnels can be further reduced, saving system resources such as computing, storage, and IP addresses, reducing customer operation and maintenance costs, while further improving the utilization rate of secure tunnels, and ensuring that services run more reliably and efficiently.

[0102] Since different network devices have different capabilities for service instance negotiation. For example, some network devices have the ability to associate a security protocol tunnel with a service instance, while some do not. When one party does not support it, sending service instance negotiation information from the supporting party to the non-supporting party may cause processing errors at the receiving end. To avoid such problems, in some embodiments, network devices (such as between a first network device and a second network device) can perform capability negotiation in advance so that both parties can understand whether they have the ability to associate a security protocol tunnel with a service instance.

[0103] For example, the first network device can 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 negotiate the service instance corresponding to the security tunnel with the second network device when receiving a 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.

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

[0105] S501: The first network device and the second network device perform capability negotiation.

[0106] In some embodiments, the first network device and the second network device can perform separate capability negotiation before creating a Child SA so that both parties can understand whether they have the ability to associate a security protocol tunnel with a service instance.

[0107] Among them, the first network device and the second network device can perform capability negotiation through any one of the following messages, but not limited to: IKE_SA_INIT message, IKE_AUTH message, CREATE_CHILD_SA message, INFORMATIONAL message.

[0108] As an example, the first network device and the second network device can negotiate capabilities during the IKE_SA_INIT exchange phase. For example, the party with the ability to support the security protocol tunnel associated with the service instance can inform the peer of its ability to support the security protocol tunnel associated with the service instance by carrying a newly added NOTIFY payload in the IKE_SA_INIT message. If the receiving party also has the ability to support the security protocol tunnel associated with the service instance, it can also carry this NOTIFY payload in the response message. Based on this, the sending party can carry service instance negotiation information when negotiating and creating a Child SA later. If the receiving party does not have the ability to support the security protocol tunnel associated with the service instance, it can ignore this NOTIFY payload and not carry this NOTIFY payload in the response message, or reply with responses such as NO_PROPOSAL_CHOSEN or other error responses. Based on this, the sending party will not carry service instance negotiation information when negotiating and creating a Child SA later.

[0109] Taking the example that the first network device has the ability to support the security protocol tunnel associated with the service instance, the IKE_SA_INIT message sent by the first network device to the second network device may be as follows:

[0110]

[0111] Among them, in this example, SUPPORT_VPN_INSTANCE can represent the ability of the local end to support the security protocol tunnel associated with the service instance.

[0112] Taking the example that the second network device does not have the ability to support the security protocol tunnel associated with the service instance, the IKE_SA_INIT message replied by the second network device to the first network device may be as follows:

[0113]

[0114] Among them, in this example, the second network device does not have the ability to support the security protocol tunnel associated with the service instance. Therefore, the response message it replies to the first network device does not carry the NOTIFY payload of the SUPPORT_VPN_INSTANCE type. Based on this, the first network device can know that the second network device does not have the ability to support the security protocol tunnel associated with the service instance according to the fact that the response message does not carry the NOTIFY payload of the SUPPORT_VPN_INSTANCE type. Then it can either not create an IKE SA and notify the termination of the session, or continue to create an IKE SA and not carry service instance negotiation information when negotiating and creating a Child SA later.

[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 NOTIFY payloads through IKE_SA_INIT messages. 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 information used to carry in the NOTIFY payload to characterize whether the local end has the ability to associate a security protocol tunnel with a service instance can be as Figure 6 shown in the Notify Message Type. When the Notify Message Type field is SUPPORT_VPN_INSTANCE, it can characterize that the local end has the ability to associate a security protocol tunnel with a service instance. The value X of SUPPORT_VPN_INSTANCE can be any available value that is not occupied within the IKEv2 NOTIFY standard range, such as 16444. The receiving end can determine whether the sending end has the ability to associate a security protocol tunnel with a service instance based on the specific value of the Notify Message Type field.

[0117] Of course, in some embodiments, the receiving end can also determine whether the sending end has the ability to associate a security protocol tunnel with a service instance based on whether the NOTIFY payload includes the NotifyMessage Type field. For example, if the NOTIFY payload includes the Notify Message Type field, the receiving end can consider that the sending end has the ability to associate a security protocol tunnel with a service instance; if the NOTIFY payload does not include the Notify Message Type field, the receiving end can consider that the sending end does not have the ability to associate a security protocol tunnel with a service instance.

[0118] As an example, the NOTIFY payload can also carry Figure 7 the Supported VPN Nums shown, which is used to characterize the number of service instances that a Child SA supports associating with, that is, the maximum number of supported service instances. As an example, Figure 7 the Supported VPN Nums shown can be an optional field with a length of 4 bytes. As an example, if the local end does not limit the quantity, the value of Supported VPN Nums can be all 0 or all F or not carry this field, without specific limitation.

[0119] As an example, the first network device and the second network device can negotiate capabilities during the IKE_AUTH or CREATE_CHILD_SA phase. For example, the party with the capability of the service instance associated security protocol tunnel can inform the peer of its capability of the service instance associated security protocol tunnel by carrying a newly added NOTIFY payload in the IKE_AUTH or CREATE_CHILD_SA message. If the receiving party also has the capability of the service instance associated security protocol tunnel, it can also carry this NOTIFY payload in the response message. Based on this, the sending party can carry service instance negotiation information when negotiating to create a Child SA subsequently. If the receiving party does not have the capability of the service instance associated security protocol tunnel, it can ignore this NOTIFY payload and not carry this NOTIFY payload in the response message, or reply with NO_PROPOSAL_CHOSEN or other error responses. Based on this, the sending party will not carry service instance negotiation information when negotiating to create a Child SA subsequently.

[0120] Regarding the process of the first network device and the second network device negotiating capabilities through IKE_AUTH messages during the IKE_AUTH phase, through CREATE_CHILD_SA messages during the CREATE_CHILD_SA phase, or through INFORMATIONAL messages, as well as the relevant introduction of the NOTIFY payload used to inform the peer of the capability of the service instance associated security protocol tunnel at the local end, reference can be made to the relevant introduction of the first network device and the second network device negotiating capabilities during the IKE_SA_INIT exchange phase in the above text, 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 of the service instance associated security protocol tunnel, it can inform the other end of its lack of the capability of the service instance associated security protocol tunnel by replying with a NOTIFY payload of the TS_UNACCEPTABLE type or other error responses. This method is also called implicit capability negotiation. Based on this, the other end device can create a Child SA in a conventional manner. The present application does not make specific limitations on the specific timing and specific method of network devices negotiating capabilities.

[0122] Taking the example of creating a Child SA by using a TrafficSelector of the TS_VPNV4_ADDR_RANGE type in a CREATE_CHILD_SA message, when the second network device does not have the capability of the service instance associated security protocol tunnel, the message it replies with may be as follows:

[0123]

[0124] Among them, in this example, the second network device notifies the first network device that it does not have the ability to associate a security protocol tunnel with a service instance by carrying a NOTIFY payload of type TS_UNACCEPTABLE 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 security protocol tunnel with a service instance, and thus may not carry service instance negotiation information when negotiating to create a Child SA later.

[0125] After completing S501, if both the first network device and the second network device have the ability to associate a security protocol tunnel with a service instance, continue to execute S502:

[0126] S502: The first network device and the second network device negotiate the service instance corresponding to the security tunnel.

[0127] In some embodiments, the first network device may carry service instance negotiation information in a message sent to the second network device for instructing to create a security tunnel between the first network device and the second network device, such as carrying the service instance of the first network device, and after receiving a response message from the second network device, complete the creation of the security tunnel according to the response message, and at the same time associate the created security 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 by the response message). Among them, the service instance indicated by the response message is determined by the second network device based on the service instance negotiation information.

[0128] In some examples, the first network device and the second network device may negotiate and determine the service instance corresponding to any security tunnel among one or more security tunnels based on the Internet Key Exchange version 2 (IKEv2) protocol. For example, the first network device and the second network device may carry service instance negotiation information in any one or more of the following messages to negotiate and determine the service instance corresponding to the security tunnel: IKE_AUTH message, CREATE_CHILD_SA message.

[0129] Among them, the IKE_AUTH message can be used for negotiation to create the first Child SA, and the CREATE_CHILD_SA message can be used for negotiation to create the second and subsequent Child SAs. For example, when creating a Child SA, the first network device and the second network device may negotiate which traffic at both ends of the IPsec can use this Child SA based on the IP address, protocol, and port.

[0130] In some embodiments, the first network device and the second network device may carry service instance negotiation information in the IKE_AUTH message to negotiate and determine the service instance corresponding to the security 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 can use the Child SA.

[0131] Among them, the IKE_AUTH message may carry service instance negotiation information through any one or more of the following fields: extension fields (such as extension headers), special fields, reserved fields, IP address fields, TTL fields.

[0132] As an example, the first network device and the second network device can carry service instance negotiation information by defining a new traffic selector (TS) payload in the IKE_AUTH message, such as the way of extending the Traffic Selector. Among them, the form of the service instance negotiation information in the Traffic Selector may include but is not limited to any way such as numbers, strings, etc., without specific limitation. In addition, the Traffic Selector may carry the service instance negotiation information alone, or may carry both the service instance negotiation information and other information (such as IP address, protocol, port, etc.).

[0133] Such as Figure 8 As shown, a TS payload may contain multiple Traffic Selectors, and the information in the Traffic Selector can be used to indicate to the IPsec peer which traffic needs to be processed by IPsec. As an example, the conventional Traffic Selectors with TSType of TS_IPV4_ADDR_RANGE (value is 7) and TS_IPV6_ADDR_RANGE (value is 8) may be as Figure 9 shown.

[0134] As an example, the Traffic Selector carrying the service instance negotiation information may be as Figure 10 shown, where Figure 10 in the Traffic Selector of the format shown, the TS Type is TS_VPNV4_ADDR_RANGE or TS_VPNV6_ADDR_RANGE, and this Traffic Selector compared to Figure 9The Traffic Selector TS Types shown as TS_IPV4_ADDR_RANGE and TS_IPV6_ADDR_RANGE are different, and a VPN ID field is newly added, where the VPN ID field is used to carry service instance negotiation information. As an example, the VPN ID field can be the identification information (such as ID) of the service instance.

[0135] As an example, the Traffic Selector carrying service instance negotiation information may also be as Figure 11 shown, where Figure 11 in the Traffic Selector of the format shown, the TS Type is TS_VPN. This Traffic Selector is different from the Traffic Selector with TS Types of TS_IPV4_ADDR_RANGE and TS_IPV6_ADDR_RANGE shown Figure 9 and a VPN ID field is newly added, where the VPN ID field is used to carry service instance negotiation information. As an example, the VPN ID field can be the identification information (such as ID) of the service instance.

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

[0137] As an example, taking the case of carrying service instance negotiation information by using the Traffic Selector of the TS_VPNV4_ADDR_RANGE type in the CREATE_CHILD_SA message, the message may be as shown below:

[0138]

[0139] Among them, in the above message interaction example, TSi represents Traffic Selector-initiator, TSr represents Traffic Selector-responder. Both TSi and TSr are the expressions defined in RFC 7296 of the IKEv2 protocol. TSi represents the traffic sent from the Initiator (sender) or received by the Initiator, and TSr represents the traffic received by the Responder (receiver) or sent from the Responder.

[0140] Taking the sharing and use of Base Station 1 and Base Station 2 by two operators as an example, assume that Operator 1 uses VRF1 as a service instance with a corresponding VPN ID of 1, and Operator 2 uses VRF2 as a service instance with a corresponding VPN ID of 2. Operators 1 and 2 use the same IP address range. For example, the address range used on the side of Base Station 1 is 10.1.1.0–10.1.1.255, and the address range used on the side of Base Station 2 is 11.1.1.0–11.1.1.255. Based on the IKEv2 protocol, when Base Station 1 (Initiator) and Base Station 2 (Responder) negotiate and create a Child SA in the CREATE_CHILD_SA process, a Child SA can be associated with a service instance through the following message:

[0141]

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

[0143]

[0144]

[0145] Among them, in this example of the TS payload, two TrafficSelectors of the TS_VPNV4_ADDR_RANGE type are used. One TrafficSelector 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" is the interesting traffic. The other TrafficSelector indicates that the traffic from the Initiator to the Responder belonging to the 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 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" is the interesting traffic. The above interesting traffic needs to use this Child SA.

[0146] In some embodiments, the first network device and the second network device may carry service instance negotiation information in an added NOTIFY payload to negotiate and determine the service instance corresponding to the security tunnel. That is, the first network device and the second network device may also negotiate through the added NOTIFY payload which service instance traffic at both ends of the IPsec can use this Child SA. Among them, the form of the service instance negotiation information in the NOTIFY payload may include but is not limited to any way such as numbers, strings, etc., and no specific limitation is made. In addition, the NOTIFY payload may carry the service instance negotiation information alone, or may carry both the service instance negotiation information and other information (such as IP addresses, protocols, ports, etc.).

[0147] As an example, the NOTIFY payload carrying the service instance negotiation information may be as Figure 12 shown, where Figure 12In the NOTIFY payload in the format shown, the Notify Message Type field is VPN_BINDING, and the value Q of VPN_BINDING can be any available value within the standard range of IKEv2 NOTIFY that is not occupied, such as 16448; and Figure 12 The NOTIFY payload in the format shown has a new VPN ID field, where the VPN ID field is used to carry service instance negotiation information. As an example, the VPN ID field can be the identification information (such as ID) of the service instance.

[0148] Taking the example of carrying a NOTIFY payload of VPN_BINDING type in the CREATE_CHILD_SA message, a message carrying service instance negotiation information, indicating the Child SA to be created, and associated with certain service instances specified in this NOTIFY payload may be as follows:

[0149]

[0150] It can be understood that VPN is a single-device 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 identifier of the VPN within the device. However, the embodiments of this application rely on using IPsec SA based on service instance negotiation, and service instance information needs to be carried in the IPsec packet. Therefore, it is necessary to complete the mapping of service instances and VPN ID values among multiple devices. In some embodiments, to ensure the consistency of the mapping between service instances and VPN IDs, the mapping between service instances and VPN IDs can be performed through configuration methods or device-to-device interactions, etc.

[0151] As an example, an administrator can configure the mapping of specified service instances and VPN IDs on different network devices to ensure the same mapping among network devices.

[0152] For example, based on the following example, the mapping of service instances and VPN IDs can be created based on the VPN name:

[0153] [device1]vpn <vpn-name>。

[0154] Among them, in this example, <vpn-name>The field is the business name that the administrator needs to input.

[0155] For another example, based on the following example, when creating a VPN, its corresponding VPN ID can be specified at the same time:

[0156] [device1]vpn <vpn-name> <vpn-id>。

[0157] Among them, in this example, <vpn-name>This is the business name that the administrator needs to enter. <vpn-id>The field is <vpn-name>The corresponding VPN ID, <vpn-id>The field can be a value in integer format. Based on this, the administrator can specify the same VPN ID for VPNs with the same VPN name on different network devices.

[0158] For example, the administrator can use the following command lines to create two VPNs on two devices, device1 and device2 respectively. For the VPN with the name "VRF1", its VPN ID is 1 on both devices, and for the VPN with the name "VRF2", its VPN ID is 2 on both devices:

[0159] [device1] vpn VRF1 1;

[0160] [device1] vpn VRF2 2;

[0161] [device2] vpn VRF1 1;

[0162] [device2] vpn VRF2 2.

[0163] As another example, network devices can interact based on the IKEv2 protocol to increase the negotiation or notification of the mapping between service instances and VPN IDs.

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

[0165] Taking the example of the first network device and the second network device notifying the peer 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:

[0166]

[0167]

[0168] Among them, in some examples of this application, one security tunnel can correspond to multiple service instances. For example, through negotiation, one Child SA can be associated with multiple service instances. The combination of one Child SA and IKE SA can serve multiple service instances. Based on this example, the number of SAs can be minimized, so the number of SAs can be reduced to the greatest extent, system computing / storage / IP address and other resources can be saved, customer operation and maintenance costs can be reduced, and SA utilization can be improved.

[0169] Of course, in other examples of this application, one security tunnel can also correspond to only one service instance. For example, through negotiation, one Child SA can be associated with one service instance. One Child SA can serve one service instance, and multiple Child SAs serving multiple different service instances can share one IKE SA. Although the number of SAs cannot be minimized in this way, the number of IKE SAs can be reduced (such as reduced to 1). Therefore, 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. Moreover, 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.

[0170] For example, assume that Operator 1 uses VRF1 as the service instance, corresponding to VPN ID 1. The address range used by Operator 1 on the side of Base Station 1 is 10.1.1.0–10.1.1.255, and the address range used on the side of Base Station 2 is 11.1.1.0–11.1.1.255. When Device 1 (Initiator) and Device 2 (Responder) negotiate to create a Child SA in the CREATE_CHILD_SA process based on the IKEv2 protocol, one Child SA can be associated with one service instance through the following message:

[0171]

[0172] Among them, in this example, the value of the VPN ID field is 1, representing "VRF1", that is, based on this message, the association between the Child SA and one service instance VRF1 can be realized.

[0173] It can be understood that based on the above-mentioned capability negotiation process provided by the embodiments of the present application, network devices can understand each other's capabilities, such as whether they have the ability to associate a service instance with a secure protocol tunnel, so that both parties can decide whether to negotiate the service 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 service instance with a secure protocol tunnel, the party with the ability to associate a service instance with a secure protocol tunnel (such as the first network device) sending service instance negotiation information to the second network device may cause problems in the processing of the receiving party.

[0174] Moreover, when both network devices have the ability to associate a service instance with a secure protocol tunnel, based on the above-mentioned service instance negotiation process provided by the embodiments of the present application, it is supported that multiple operators share the same secure tunnel between network devices. For example, the same secure tunnel is available for any operator served by the first network device and the second network device. That is to say, regardless of whether there is a data transmission requirement for any operator served by the first network device and the second network device, the first network device can complete data transmission through any secure tunnel between it and the second network device. In addition, the network devices can establish an association relationship between the secure tunnel and the service instance, and achieve service isolation under the condition of hardware resource sharing. This can not only solve the problem of the sharp increase in the secure tunnel specifications between stations, save system computing, storage, IP addresses and other resources, reduce the customer operation and maintenance cost, and improve the utilization rate of the secure tunnel, but also facilitate the selection of the secure tunnel during subsequent data transmission between network devices and the smooth identification and parsing at the receiving end, ensuring that the service runs more reliably and efficiently.

[0175] Based on the service instance negotiation process between network devices provided by the above embodiments of the present application, when there is a data transmission requirement between network devices, the network device can perform IPsec processing on the traffic under different service instances based on the Child SA. In the conventional technology, since the SPIs of different Child SAs are completely different, the packet can be encapsulated only relying on the SPI. However, in the embodiments of the present application, since multiple service instances may reuse the same Child SA, but different service instances have different policies respectively, an identifier needs to be added to the packet to identify the service instance, so that the data plane can distinguish which service instance the packet (such as an encapsulation security payload protocol (ESP) packet or an authentication header protocol (AH) packet) belongs to.

[0176] As an example, please refer to Figure 14 , Figure 14 The flowchart of a data transmission method provided by an embodiment of the present application under a secure tunnel sharing mechanism is shown. As Figure 14 shown, the method may include S1401 - S1404:

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

[0178] Among them, 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.

[0179] S1402: In response to the first transmission request, the first network device sends a data packet to the second network device through the first secure protocol tunnel. The data packet includes service data and an identifier of the first service instance corresponding to the service data.

[0180] Among them, there is one or more secure tunnels between the first network device and the second network device, and the first secure protocol tunnel is one of these one or more secure tunnels. The identifier of the first service instance is such as the ID of the first service instance.

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

[0182] Among them, the above - mentioned association relationship between the secure tunnel and the service instance represents the service instances corresponding to each secure tunnel. This association relationship may be determined based on the negotiation between the first network device and the second network device. For the method and specific process of the first network device and the second network device negotiating the service instance corresponding to the secure tunnel, reference can be made to the introduction in the above text, which will not be elaborated here.

[0183] As an example, the first network device may encrypt the service data at the tunnel interface of the first secure protocol tunnel based on the security policy corresponding to the first service instance, and then encapsulate it into a data packet, and then send the data packet to the second network device through the first secure protocol tunnel. Among them, the security policy corresponding to the first service instance may be pre - set in the first network device. For example, one or more security policies corresponding to the secure tunnels may be pre - set in the first network device, and the first network device may determine the security policy corresponding to the first service instance from them based on the identifier of the first service instance in the data packet. Or, the security policy corresponding to the first service instance may be generated by the first network device and the second network device. For example, the first network device and the second network device may generate it when negotiating the corresponding relationship between the secure tunnel and the service instance.

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

[0185] As described above, the essence of the Child SA multiplexing technology is that multiple SPDs map to one 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 by the SAD to 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., security policy) corresponding to the first service instance, encapsulate it into a data packet, and then send the data packet to the second network device through the first security protocol tunnel.

[0186] As an example, please refer to Figure 15A , Figure 15A which shows a schematic diagram of the encryption process of a data packet provided by an embodiment of the present application. As shown in Figure 15A (a) therein shows the process of secure protection and encryption of conventional plaintext service data at the tunnel interface of a secure tunnel based on SPD and SAD, and finally forwarding it to the target device in ciphertext form. As shown in Figure 15A (b) therein shows the process of secure protection and encryption of plaintext service data of multiple different service instances (such as Figure 15A plaintext 1 and plaintext 2 shown) at the tunnel interface of the secure tunnel based on SPD and SAD respectively, and finally forwarding it to the target device in ciphertext form. Among them, Figure 15A the MUX shown in (b) therein is a multiplexer, and the MUX can add the identifier of the service instance during the process of packet encryption.

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

[0188] Among them, the tunnel mode means that the entire IP data packet of the user participates in encryption and authentication. For example, it is all used to calculate the AH or ESP header, and the AH or ESP header and the ESP-encrypted service data are encapsulated in a new IP data packet. As an example, for the tunnel mode, the secure tunnel usually needs to encrypt and authenticate the service data first, and then create a new IP header and add the encrypted IP data packet therein. The 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 the transport mode, the secure tunnel usually needs to encrypt and authenticate the payload in the service data first, and then create a new IP header and add the encrypted payload therein. For the relevant introduction to the specific encapsulation mode of the data packet, reference can be made to the conventional technology and will not be elaborated here.

[0189] As an example, the identifier of the first service instance can be carried in, but is not limited to, any one of the following: the IPv4 header of the plaintext IPv4 packet in the first mode, the IPv6 header of the plaintext IPv4 packet in the first mode, the IPv4 header of the ciphertext IPv4 packet in the first mode, the IPv4 header of the ciphertext IPv6 packet in the first mode, the IPv4 header of the ciphertext IPv6 packet in the second mode, the IPv6 of the ciphertext IPv6 packet in the second mode.

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

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

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

[0193] ---------------------------------************************************

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

[0195] ---------------------------------************************************

[0196] Among them, 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.

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

[0198] --------------------------------*************************************

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

[0200] --------------------------------*************************************

[0201] Among them, 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.

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

[0203] ---------------------************************************************

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

[0205] --------------------------*******************************************

[0206] Among them, 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.

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

[0208] ----------------------------*****************************************

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

[0210] -----------------------------****************************************

[0211] Among them, 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.

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

[0213] The packet format is as follows: ("-" represents an unencrypted field, "*" represents an encrypted field)

[0214] ---------------------------------------------------******************

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

[0216] ----------------------------------------------***********************

[0217] Among them, in this example, "-" represents an unencrypted field, "*" represents an encrypted field, and the identifier of the first service instance is located in the Option field.

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

[0219] ---------------------------------------------------------************

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

[0221] ------------------------------------------------------***************

[0222] Among them, in this example, "-" represents an unencrypted field, "*" represents an encrypted field, and the identifier of the first service instance is located in the Destination Extension field.

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

[0224] ----------------------------------------------***********************

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

[0226] -------------------------------------------**************************

[0227] Among them, 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.

[0228] As an example, taking the encapsulation mode of the data packet as the transport mode, the format of the packet carrying the identifier of the first service instance in the destination address extension field of the encrypted IPv6 packet may be as follows:

[0229] ------------------------------------------------------***************

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

[0231] -----------------------------------------------------****************

[0232] Among them, 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.

[0233] S1403: The second network device determines the security policy of the data packet based on the identifier of the first service instance.

[0234] As a possible implementation, the second network device may match the security policy corresponding to the first service instance from multiple security policies according to the first service instance in the data packet. For example, one or more security policies corresponding to security tunnels may be preset in the second network device. 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 data packet may be decrypted based on the matched security policy. If no match is found, the processing of the data packet may be terminated.

[0235] As described above, the essence of the Child SA multiplexing technology is that multiple SPDs map to one security association database SAD. Based on this, when a Child SA is shared by multiple service instances, the second network device may determine the specific SPD used during decryption according to the identifier of the service instance carried in the data packet.

[0236] As an example, please refer to Figure 15B , Figure 15B which shows a schematic diagram of the decryption process of a data packet provided by an embodiment of the present application. Among them Figure 15B (a) shows the process of secreting the tunnel interface of a conventional security tunnel based on SPD and SAD, Figure 15B (b) shows the process of decrypting the tunnel interface of the security tunnel provided by the embodiment of the present application by selecting a matching SPD based on the identifiers of the service instances carried in multiple data packets (such as Figure 15B the ciphertext 1 and ciphertext 2 shown). Among them, Figure 15B the DEMUX shown in (b) is a demultiplexer, and the DEMUX can obtain the identifier of the service instance during the process of decrypting the ciphertext.

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

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

[0239] In some embodiments, the network device may also accept modifications or deletions of security tunnels, and the network device may also accept modifications (such as addition or deletion) of the service instances corresponding to the security tunnels.

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

[0241] As an example, in response to a request to delete a certain 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.

[0242] For example, the INFORMATIONAL message may be as follows:

[0243]

[0244] Among them, in this example, D represents the 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 this SPI value.

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

[0246] Taking the network device's notification to the peer end of the need to delete an associated service instance by adding a NOTIFY payload type as an example, the message for deleting a service instance corresponding to a certain Child SA may be as follows:

[0247]

[0248] Among them, N(OPERATE_VPN_INSTANCEa, N(OPERATE_VPN_INSTANCEb, and D(spi1, spi2, spi3) in this example are as follows:

[0249]

[0250] Among them, in this example, when the SPI in the NOTIFY payload has a corresponding Notify(OPERATE_VPN_INSTANCE) payload, it means that it is not necessary to completely delete the entire Child SA, but it is necessary to delete the association relationship between the Child SA indicated by the Notify payload and a certain service instance, 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 to completely delete the entire Child SA, such as spi3 in this example. Based on this, finally, it is possible to delete the association relationships between the Child SA corresponding to spi1 and vpn1 and vpn2, delete the association relationships between the Child SA corresponding to spi2 and vpn2 and vpn3, and completely delete the Child SA corresponding to spi3.

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

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

[0253]

[0254] Alternatively, as a possible implementation, the network device can add the interesting flows corresponding to the new service instance through the CREATE_CHILD_SA message in the CREATE_CHILD_SA phase.

[0255] Alternatively, as a possible implementation, the network device can borrow the update key (Rekey) function to add the interesting flows corresponding to the new service instance when creating a new Child SA during Rekey.

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

[0257]

[0258] Alternatively, as a possible implementation, the network device can add a new NOTIFY payload type, and use this NOTIFY payload to inform the peer that a certain service instance needs to be modified (such as added or deleted). For example, the network device can send the newly added NOTIFY payload to the peer device through an INFORMATIONAL exchange message, indicating to the peer device that it is necessary to add or delete an associated service instance in the already created Child SA.

[0259] For example, the NOTIFY payload may be as Figure 16 shown, where Figure 16 the shown Notify Message Type field can be OPERATE_VPN_INSTANCE, and the value Z of OPERATE_VPN_INSTANCE can be any available value within the IKEv2 NOTIFY standard range that is not occupied, such as 16447; Figure 16 the shown Operation Flag field indicates whether it is an operation to add an association or delete an association. For example, 1 indicates adding an association, and 2 indicates deleting an association; the VPNs field only exists when the OperationFlag field is "delete association", and this field indicates that it is necessary to delete the association between the SA indicated by the SPI and the service instance indicated by this field.

[0260] Taking the network device's use of the newly added NOTIFY payload type to inform the peer that a certain service instance needs to be newly associated as an example, the message used to add the service instance corresponding to a certain Child SA may be as follows:

[0261]

[0262] For example, the specific NOTIFY payload in this example may be as follows:

[0263]

[0264] Among them, in this NOTIFY payload example, the TS payload carrying the TrafficSelector of the TS_VPNV4_ADDR_RANGE type can indicate that the source IPv4 address range belonging to the VPN instance "VRF3" from the Initiator to the Responder is "10.1.1.0 to 10.1.1.255" and the destination IPv4 address range is "11.1.1.0 to 11.1.1.255", and the traffic from the Responder to the Initiator belonging to the VPN instance "VRF3" with the source IPv4 address range of "11.1.1.0 to 11.1.1.255" and the destination IPv4 address range of "10.1.1.0 to 10.1.1.255" is the interesting traffic, and the above-mentioned interesting traffic needs to use this Child SA.

[0265] As an example, please refer to Figure 17 , Figure 17 which shows a specific interaction schematic diagram of the association relationship between a security tunnel and a service instance provided by an embodiment of the present application. As shown in Figure 17 Message 1 and Message 2 carried the policies of VPN1 and VPN2. After completion, an IKE SA and a Child SA were generated, but two different TS policies were negotiated, corresponding to VPN1 and VPN2 respectively; Figure 17 Message 3 shown represents the sending of ESP packets between VPNs and the encryption and decryption of the packets. The ESP packet carries VPN1 or VPN2, and the SPI is the SPI negotiated based on Message 1 and Message 2; Figure 17 Message 4 and Message 5 shown represent the addition of a new VPN3 and the negotiation of relevant information of VPN3. After the negotiation, both parties can perform encryption or decryption of the packets of VPN1, VPN2, and VPN3 based on Figure 17 Message 6 shown; when there is a need to delete the service instance corresponding to the security tunnel, both parties can negotiate the service instances to be deleted, such as VPN1 and VPN12, through Figure 17 Message 7 and Message 8 shown (such as the Delete message); finally, as shown in Figure 17 Message 9 in, it is possible to achieve encryption or decryption of packets only based on the remaining VPN3.

[0266] In some embodiments, the network device can also accept the update of the key of a service instance corresponding to a certain security tunnel (also known as "Rekey"). For example, the first network device can, in response to a request to update the key of a service instance, send a packet to the second network device to indicate the update of the key of a service instance associated with a certain security protocol tunnel.

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

[0268]

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

[0270]

[0271] Among them, after the first network device and the second network device complete the key update, the old Child SA may be deleted according to the procedure specified in the IKEv2 protocol.

[0272] It can be understood that by supporting the deletion of the security tunnel and the modification of the association relationship between the security tunnel and the service instance (such as addition or deletion, etc.) among the network devices described in the embodiments of the present application, more flexible sharing of the security tunnel can be achieved. For example, the network device can negotiate with other network devices about the management of the security tunnel at any time according to actual needs, including adding or deleting the security tunnel as needed, adding / deleting the association relationship between the security tunnel and the service instance as needed, and supporting the on-demand allocation of system computing, storage, IP addresses and other resources by means of on-demand adjustment, so as to achieve more scientific resource allocation.

[0273] It should be understood that the various solutions in the embodiments of the present application can be combined reasonably, and the explanations or descriptions of the various terms appearing in the embodiments can be referred to or explained mutually in the various embodiments, which is not limited herein.

[0274] It should also be understood that in various embodiments of the present application, the magnitudes of the sequence numbers of the above processes do not mean the order of execution, and the order of execution of each process should be determined by its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

[0275] It can be understood that, in order to implement the functions of any of the above embodiments, a network device (such as the first network device or the second network device) includes the corresponding hardware structures and / or software modules for executing various functions. Those skilled in the art should easily realize that, for the units and algorithm steps of each example described in combination with the embodiments disclosed in this application, this application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a certain function is executed in the way of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods for each specific application to implement the described function, but such implementation should not be considered to exceed the scope of this application.

[0276] The embodiments of this application can perform a division of functional modules on the network device. For example, each functional module can be divided corresponding to each function, or two or more functions can be integrated into one processing module. The above integrated modules can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the embodiments of this application is illustrative, only a logical functional division, and there can be other division methods in actual implementation.

[0277] It should also be understood that each module in the network device can be implemented in the form of software and / or hardware, and no specific limitation is made thereto. In other words, the network device is presented in the form of functional modules. Here, the "module" can refer to an application-specific integrated circuit ASIC, a circuit, a processor and a memory that execute one or more software or firmware programs, an integrated logic circuit, and / or other devices that can provide the above functions.

[0278] In an alternative approach, when data transmission is implemented using software, it can be realized in the form of a computer program product, wholly or partly. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in the embodiments of this application are realized wholly or partly. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. 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 wired means (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless means (such as infrared, wireless, microwave, etc.). 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 integrated available media. The available medium can be a magnetic medium (such as a floppy disk, hard disk, magnetic tape), an optical medium (such as a digital video disk (DVD)), or a semiconductor medium (such as a solid state disk (SSD)), etc.

[0279] The steps of the methods or algorithms described in connection with the embodiments of the present application may be implemented in hardware or by a processor executing software instructions. The software instructions may be composed of corresponding software modules, and the software modules may be stored in a random access memory (RAM), flash memory, read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM) memory, register, hard disk, removable hard disk, compact disc read-only memory (CD-ROM), or any other form of storage medium well-known in the art. An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium may also be a component of the processor. The processor and the storage medium may be located in an application specific integrated circuit (ASIC). Additionally, the ASIC may be located in a network device. Of course, the processor and the storage medium may also exist as discrete components.

[0280] Through the description of the above embodiments, those skilled in the art can clearly understand that for the convenience and brevity of description, only the above division of each functional module is used as an example. In actual applications, the above functions may be allocated to different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. < / vpn-name>

Claims

1. A method for creating a secure protocol tunnel, characterized in that, applied to a first network device, the method includes: sending a first message containing first information to a second network device, the first message being used to indicate the creation of a secure protocol tunnel between the first network device and the second network device, and the first information being used to indicate the service instance of the first network device; receiving a second message from the second network device, the second message being a response of the second network device to the first message, and the second message carrying second information, the second information being used to indicate the service instance determined by the second network device based on the first information; completing the creation of the secure protocol tunnel with the second network device according to the second message, and associating the secure protocol tunnel with the service instance indicated by the second information.

2. The method according to claim 1, characterized in that, the method further includes: sending a third message to the second network device, the third message being used to indicate modifying the secure protocol tunnel between the first network device and the second network device; modifying one or more secure protocol tunnels between the first network device and the second network device.

3. The method according to claim 2, characterized in that, the modifying the secure 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 secure protocol tunnel and the service instance, adding a new association relationship between the secure protocol tunnel and the service instance.

4. The method according to claim 3, characterized in that, the third message is used to indicate deleting the association relationship between the secure protocol tunnel and the service instance between the first network device and the second network device, and 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 adding a new association relationship between the secure 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-5, characterized in that, the method further includes: sending a fourth message to the second network device, the fourth message being used to indicate that the first network device has the ability to associate a secure protocol tunnel with a service instance; receiving a fifth message from the second network device, the fifth message being used to indicate that the second network device has the ability to associate a secure protocol tunnel with the service instance.

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, an INFORMATIONAL message.

8. A data transmission method, characterized in that, Applied to a first network device, the method includes: Sending a data packet carrying service data to a second network device through a first secure protocol tunnel, where the data packet includes an identifier of a first service instance corresponding to the service data, and the first secure protocol tunnel has an association relationship with the first service instance.

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

10. The method according to claim 8 or 9, wherein, before sending the data packet to the second network device through the first secure protocol tunnel, the method further includes: At the tunnel interface of the first secure protocol tunnel, encrypting the service data based on the security policy corresponding to the first service instance and encapsulating it into the data packet.

11. The method according to any one of claims 8-10, wherein, the secure protocol tunnel includes an IPsec tunnel.

12. A method for creating a secure protocol tunnel, wherein, Applied to a second network device, the method includes: Receiving a first packet from a first network device, the first packet is used to indicate creating a secure protocol tunnel between the first network device and the second network device, the first packet includes first information, and the first information is used to indicate the service instance of the first network device; Sending a second packet to the first network device, the second packet is a response of the second network device to the first packet, and the second packet carries second information, and the second information is used to indicate the service instance determined by the second network device based on the first information; Completing the creation of the secure protocol tunnel with the first network device according to the first packet and associating the secure protocol tunnel with the service instance indicated by the second information.

13. The method according to claim 12, wherein, the method further includes: Receiving a third packet from the first network device, the third packet is used to indicate modifying the secure protocol tunnel between the first network device and the second network device; Modifying one or more secure protocol tunnels between the first network device and the second network device based on the third packet.

14. The method according to claim 13, wherein, modifying the secure 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 secure protocol tunnel and the service instance, adding a new association relationship between the secure protocol tunnel and the service instance.

15. The method according to claim 14, wherein, The third message is used to indicate deleting 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.

16. The method according to claim 14, wherein, the third message is used to indicate adding the association between the security protocol tunnel and the service instance. 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-16, wherein, the method further includes: receiving a fourth message from the first network device, where 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; sending a fifth message to the first network device, where 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.

18. The method according to claim 17, wherein, 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, wherein, applied to a second network device, the method includes: receiving a data packet sent by a first network device through a first security protocol tunnel. The data packet includes service data and an identifier of a first service instance corresponding to the service data. 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 service instance; determining a security protocol policy for the data packet based on the identifier of the first service instance; parsing the data packet according to the security protocol policy to obtain the service data.

20. The method according to claim 19, wherein, 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 IPv6 extension header, an encrypted IPv6 header or extension header.

21. The method according to claim 19 or 20, wherein, the parsing the data packet to obtain the service data includes: parsing the data packet 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-21, wherein, the security protocol tunnel includes an IPsec tunnel.

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

24. A network device, characterized in that, the network device includes: a transceiver for transmitting and receiving signals; a memory for storing computer program instructions; a processor for executing the computer program instructions to support the network device in implementing the method described in any one of claims 1-11 or 12-22.

25. A computer-readable storage medium, characterized in that, computer program instructions are stored on the computer-readable storage medium, and when the computer program instructions are executed by a processing circuit, the method described in any one of claims 1-11 or 12-22 is implemented.

26. A computer program product containing instructions, characterized in that, when the computer program product runs on a computer, the computer is caused to execute the method described in any one of claims 1-11 or 12-22.

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

Images