CN116980150A - Message transmission method and related equipment - Google Patents

Abstract

The application provides a message transmission method and related equipment. In the application, after the network equipment confirms that the received packet message needs to be encrypted, the network equipment encrypts the packet message to generate the target message. The network equipment encrypts the packet message to generate a target message, wherein the target message comprises a sender identifier, and the sender identifier is used for indicating identity information of the network equipment. Therefore, aiming at the scenes of many-to-one, many-to-many, one-to-many and the like, the equipment for receiving the target message can know the source of the target message according to the sender identification, can realize the ordered transmission of the service message without a complex deployment mode, and reduces the network overhead.

Description

A message transmission method and related equipment

Technical field

The present application relates to the field of communications, in particular to a message transmission method and related equipment.

Background technique

Internet Protocol Security (IPSec) is used to provide interoperable, high-quality, IP-based security protocols for Internet Protocol version 4 (IPv4) and Internet Protocol Version 6 (IPv6). A set of protocols for cryptographic security services. The security services provided by IPSec are provided at the Internet Protocol (IP) layer. IPSec provides protection for the IP layer and all protocols carried on the IP layer in a standard way. IPsec can be used to protect one or more paths between a pair of hosts, a pair of security gateways, or a security gateway and a host.

IPSec supports tunnel mode and transmission mode. In tunnel mode, the entire IP data packet that needs to be protected is encapsulated in a new IP packet as the payload of the new packet, and then a new IP header is added to the outside. In transport mode, only the transport layer data is used to calculate the Authentication option header (AH) or encapsulating security payload header. The AH or encapsulating security payload header and the encrypted transport layer data are placed behind the original IP header. . The AH transmission mode will verify the IP header, while the transmission mode of encapsulating the security payload will not protect the IP header and extension header before the encapsulated security payload header.

With the rapid development of IPv6+ services, new transmission plane encryption requirements have emerged. IPsec is a one-to-one (peer-to-peer, P2P) encrypted tunnel. For many-to-one, many-to-many, and one-to-many scenarios, face-to-face encryption services can only be implemented by establishing a FULLMESH IPsec Tunnel. The deployment method is complex and the network overhead is large.

Contents of the invention

This application provides a message transmission method and related equipment. In this application, the target message includes a sender identifier, and the sender identifier is used to indicate the identity information of the network device. Therefore, for scenarios such as many-to-one, many-to-many, and one-to-many, the device receiving the target message can know the source of the target message based on the sender identification, and the ordering of the messages can be achieved without the need for complicated deployment methods. transmission, reducing network overhead.

The first aspect of this application provides a message transmission method. In the method: a network device receives a group message; the network device confirms that the group message needs to be encrypted; the network device encrypts the group message to generate The target message includes a sender identifier, and the sender identifier is used to indicate the identity information of the network device.

In this application, after the network device confirms that the received packet message needs to be encrypted, the network device encrypts the packet message to generate a target message. The network device encrypts the packet message to generate a target message. The target message includes a sender identifier, and the sender identifier is used to indicate the identity information of the network device. Therefore, for scenarios such as many-to-one, many-to-many, and one-to-many, the device receiving the target message can know the source of the target message based on the sender ID, and can achieve valid service packets without complicated deployment methods. sequential transmission, reducing network overhead.

In a possible implementation of the first aspect, the target message further includes a thread identifier, and the thread identifier is used to indicate the identifier of the thread that processes the target message in the device that receives the target message. .

In this possible implementation, the target message may include a thread identifier (window id). The window id is used to indicate the identifier of the thread that processes the target message in the device that receives the target message, that is, the ID of the heterogeneous processor core. . Assuming that the same 5-tuple data flow in a packet packet is called a flow, multiple target packets can be allocated to multiple processor cores through different window IDs, which can solve the problem of a single heterogeneous processor for a large-bandwidth traffic It solves the problem of insufficient processing capacity of the core and improves the processing efficiency of target packets.

In a possible implementation manner of the first aspect, the target message includes a security payload encapsulation header ESP, and the ESP includes the sender identification and/or the thread identification.

This possible implementation provides a specific way for the sender identification and/or thread identification to exist. When the security payload encapsulation header (Encapsulating Security Payload, ESP) includes the sender identification and/or the thread identification, in the standard The encapsulation format carries the sender identification and/or thread identification, which makes it easier for the device receiving the target message to connect with the network device, improving the achievability of the solution.

In a possible implementation manner of the first aspect, the target message includes a destination optional extension header DOH, and the DOH includes the sender identification and/or the thread identification.

This possible implementation provides a specific way for the sender identification and/or thread identification to exist. The destination optional extension header (Destination option header, DOH) is processed at the end node and does not require additional tunnel information. Indicates the encryption end point and can itself be used as the end node of the encryption tunnel, which improves the achievability of the solution.

In a possible implementation of the first aspect, the DOH includes the sender identification and/or the thread identification, including: the optional type length value TLV of the DOH includes the sender identification. and/or the thread ID.

This possible implementation method provides a specific existence method of the sender identification and/or the thread identification, which improves the realizability of the solution.

In a possible implementation of the first aspect, the target message includes a sequence number, and the sequence number, the sender identification and/or the thread identification are jointly used to form an IV value, and the IV The value is used to encrypt the packet message.

In this possible implementation, it is assumed that the target message includes a sequence number, a sender ID, and a thread ID (window ID). For encryption algorithms that require IV to ensure encryption security, the IV can be converted through the sender id||window id||sequence number combination. Therefore, there is no need to carry the IV in clear text in the message payload, which can reduce the overhead required for message encapsulation.

In a possible implementation manner of the first aspect, the target message includes SPI and AN, and the SPI and AN are jointly used to indicate security parameters.

In this possible implementation, optionally, AN and SPI can form a security parameter indication function as a whole, occupying 2 bits, 00/01/10/11 is used for light SA parameters except key update when other parameters remain unchanged. Magnitude update mechanism. Only the key needs to be indicated through the AN, and the control plane does not need to create or remove SAs, so as to reduce the control plane load of the entire network and save network overhead.

A second aspect of the present application provides a message transmission method. The method includes: a network device receives a target message, the target message includes a sender identifier, and the sender identifier is used to instruct sending of the target message. The identity information of the device sending the message; the network device decrypts the target message.

In this application, the network device receives the target message, where the target message includes a sender identifier, and the sender identifier is used to indicate the identity information of the device that sent the target message. Therefore, for many-to-one, many-to-many, and one-to-many scenarios, the network device that receives the target message can know the source of the target message based on the sender ID, and the service message can be authenticated without complicated deployment methods. Orderly transmission reduces network overhead.

In a possible implementation of the second aspect, the target message further includes a thread identifier, and the thread identifier is used to indicate the identifier of the thread that processes the target message in the device that receives the target message. .

In this possible implementation, the target message may include a thread identifier (window id). The window id is used to indicate the identifier of the thread that processes the target message in the device that receives the target message, that is, the ID of the heterogeneous processor core. . Assuming that the same 5-tuple data flow in a packet packet is called a flow, multiple target packets can be allocated to multiple processor cores through different window IDs, which can solve the problem of a single heterogeneous processor for a large-bandwidth traffic It solves the problem of insufficient processing capacity of the core and improves the processing efficiency of target packets.

In a possible implementation manner of the second aspect, the target message includes a security payload encapsulation header ESP, and the ESP includes the sender identification and/or the thread identification.

This possible implementation method provides a specific existence method of the sender identification and/or the thread identification, which improves the realizability of the solution.

In a possible implementation manner of the second aspect, the target message includes a destination optional extension header DOH, and the DOH includes the sender identification and/or the thread identification.

This possible implementation method provides a specific existence method of the sender identification and/or the thread identification, which improves the realizability of the solution.

In a possible implementation of the second aspect, the DOH includes the sender identification and/or the thread identification, including: the optional TLV of the DOH includes the sender identification and/or The thread identifier.

This possible implementation method provides a specific existence method of the sender identification and/or the thread identification, which improves the realizability of the solution.

In a possible implementation of the second aspect, the target message includes a sequence number, and the sequence number, the sender identification and/or the thread identification are jointly used to form an IV value, and the IV The value is used to encrypt the packet message.

In this possible implementation, it is assumed that the target message includes a sequence number, a sender ID, and a thread ID (window ID). For encryption algorithms that require IV to ensure encryption security, the IV can be converted through the sender id||window id||sequence number combination. Therefore, there is no need to carry the IV in plain text in the message payload, which can reduce the overhead required for message encapsulation.

In a possible implementation manner of the second aspect, the target message includes SPI and AN, and the SPI and AN are jointly used to indicate security parameters.

In this possible implementation, optionally, AN and SPI can form a security parameter indication function as a whole, occupying 2 bits, 00/01/10/11 is used for light SA parameters except key update when other parameters remain unchanged. Magnitude update mechanism. Only the key needs to be indicated through the AN, and the control plane does not need to create or remove SAs, so as to reduce the control plane load of the entire network and save network overhead.

A third aspect of the present application provides a network device, which includes at least one processor, a memory, and a communication interface. The processor is coupled to memory and communication interfaces. The memory is used to store instructions, the processor is used to execute the instructions, and the communication interface is used to communicate with other network devices under the control of the processor. When executed by the processor, the instruction causes the network device to perform the above-mentioned first aspect or the method in any possible implementation of the first aspect, or causes the network device to perform the above-mentioned second aspect or the method of the second aspect. Methods in any possible implementation.

The fourth aspect of the present application provides a computer-readable storage medium that stores a program that causes the network device to execute the method in the above-mentioned first aspect or any possible implementation of the first aspect, or , causing the network device to execute the method in the above second aspect or any possible implementation of the second aspect.

The fifth aspect of the present application provides a computer program product that stores one or more computer-executable instructions. When the computer-executable instructions are executed by the processor, the processor executes the above-mentioned first aspect or any of the first aspects. A method of a possible implementation, or the processor executes the method of the above second aspect or any possible implementation of the second aspect.

A sixth aspect of the present application provides a chip. The chip includes a processor and a communication interface. The processor is coupled to the communication interface. The processor is configured to read instructions to execute the above first aspect or any one of the first aspects. A method in a possible implementation manner, or the processor is used to read instructions to execute the above second aspect or the method in any possible implementation manner of the second aspect.

A seventh aspect of the present application is a network system. The network system includes a network device. The network device can execute the method described in the above-mentioned first aspect or any possible implementation of the first aspect, or the network device can execute the above-mentioned method. The method described in the second aspect or any possible implementation manner of the second aspect.

Description of the drawings

Figure 1 is a schematic diagram of an application scenario of a message transmission method provided by this application;

Figure 2 is a schematic diagram of another application scenario of a message transmission method provided by this application;

Figure 3 is a schematic diagram of another application scenario of a message transmission method provided by this application;

Figure 4 is a schematic flow chart of a message transmission method provided by this application;

Figure 5 is a schematic diagram of a target message provided by this application;

Figure 6 is a schematic diagram of an ESP standard header provided by this application;

Figure 7 is a schematic diagram of an ESP extension header provided by this application;

Figure 8 is another schematic diagram of a target message provided by this application;

Figure 9 is a schematic diagram of a DOH head provided by the present application;

Figure 10 is a flow chart of an encryption method provided by this application;

Figure 11 is another flow chart of an encryption method provided by this application;

Figure 12 is a flow chart of a decryption method provided by this application;

Figure 13 is another flow chart of another decryption method provided by this application;

Figure 14 is a schematic diagram of another anti-replay principle provided by this application;

Figure 15 is a schematic diagram of a network device provided by this application;

Figure 16 is another schematic diagram of a network device provided by this application;

Figure 17 is another schematic diagram of a network device provided by this application.

Detailed ways

The examples provided in this application are described below in conjunction with the accompanying drawings. Obviously, the described examples are only examples of a part of this application, not all examples. Persons of ordinary skill in the art know that with the development of technology and the emergence of new scenarios, the technical solutions provided in this application are also applicable to similar technical problems.

The terms "first", "second", etc. in the description and claims of this application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It is to be understood that data so used are interchangeable under appropriate circumstances so that the examples described herein can be practiced in sequences other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, e.g., a process, method, system, product, or apparatus that encompasses a series of steps or units and need not be limited to those explicitly listed. Those steps or elements may instead include other steps or elements not expressly listed or inherent to the process, method, product or apparatus.

"And/or" in this application is just an association relationship describing related objects, indicating that there can be three relationships, for example, A and/or B, which can mean: A exists alone, A and B exist simultaneously, and they exist alone. In the three cases of B, A and B can be singular or plural. Furthermore, in the description of this application, unless otherwise specified, "plurality" means two or more than two. "At least one of the following" or similar expressions thereof refers to any combination of these items, including any combination of a single item (items) or a plurality of items (items). For example, at least one of a, b, or c can mean: a, b, c, a-b, a-c, b-c, or a-b-c, where a, b, c can be single or multiple .

Internet Protocol Security (IPSec) is used to provide interoperable, high-quality, IP-based security protocols for Internet Protocol version 4 (IPv4) and Internet Protocol Version 6 (IPv6). A set of protocols for cryptographic security services. The security services provided by IPSec are provided at the Internet Protocol (IP) layer. IPSec provides protection for the IP layer and all protocols carried on the IP layer in a standard way. IPsec can be used to protect one or more paths between a pair of hosts, a pair of security gateways, or a security gateway and a host.

IPSec supports tunnel mode and transmission mode. In tunnel mode, the entire IP data packet that needs to be protected is encapsulated in a new IP packet as the payload of the new packet, and then a new IP header is added to the outside. In transport mode, only the transport layer data is used to calculate the Authentication option header (AH) or encapsulating security payload header. The AH or encapsulating security payload header and the encrypted transport layer data are placed behind the original IP header. . The AH transmission mode will verify the IP header, while the transmission mode of encapsulating the security payload will not protect the IP header and extension header before the encapsulated security payload header.

With the rapid development of IPv6+ services, new transmission plane encryption requirements have emerged. IPsec is a one-to-one (peer-to-peer, P2P) encrypted tunnel. For many-to-one, many-to-many, and one-to-many scenarios, face-to-face encryption services can only be implemented by establishing a FULLMESH IPsec Tunnel. The deployment method is complex and the network overhead is large.

In order to solve the problems existing in the above solution, this application provides a message transmission method and related equipment. In this application, the target message includes a sender identifier, and the sender identifier is used to indicate the identity information of the network device. Therefore, for scenarios such as many-to-one, many-to-many, and one-to-many, the device receiving the target message can know the source of the target message based on the sender identification, and the ordering of the messages can be achieved without the need for complicated deployment methods. transmission, reducing network overhead.

The following first introduces the application scenario of a message transmission method provided by this application.

Figure 1 is a schematic diagram of an application scenario of a message transmission method provided by this application.

In this application, as shown in Figure 1, the network system using the message transmission method provided by this application is mainly composed of customer network nodes and a LAN network. The LAN network mainly carries the forwarding of IP packets of customer network nodes through PE equipment. In this application, it can be understood that the destination of the IP packet message is not fixed, and the specific destination is not limited here. As shown in Figure 1, assume that within a certain period of time, the IP packets sent from customer network node A are sent to customer network node C. In other time periods, IP packets sent from customer network node A are sent to customer network node B. The specific destination is determined by the destination MAC or destination IP in the IP packet.

Figure 2 is a schematic diagram of another application scenario of a message transmission method provided by this application.

In this application, as shown in Figure 2, PE1, PE2 and PE3 establish forwarding relationships respectively. Optionally, the forwarding relationship can be established through the Multiprotocol Label Switching (MPLS)/Label Distribution Protocol (LDP) protocol to build an MPLS tunnel, or through the Border Gateway Protocol (BorderGateway Protocol, BGP)/internal Gateway Protocol (Interior Gateway Protocol, IGP) routing forms a routing and forwarding relationship, or the controller issues a forwarding policy to form a forwarding tunnel, such as SRV6 policy, or a forwarding relationship can be established through other protocols. The establishment of the forwarding relationship is not specifically limited in this application, as long as an MP2P forwarding relationship can be formed between PE1, PE2, and PE3.

Figure 3 is a schematic diagram of another application scenario of a message transmission method provided by this application.

In this application, as shown in Figure 3, PE1 establishes a multicast forwarding relationship with PE3 and PE4, and PE2 establishes a multicast forwarding relationship with PE3 and PE4. The forwarding relationship can be established through the PIM protocol, MVPPN, etc. The forwarding relationship is established in this application. There are no restrictions in the application, as long as a multicast forwarding relationship can be formed between PE1, PE2, and PE3.

In this application, as shown in Figure 3, the multicast source nodes of PE1 and PE2 form mutual protection to ensure network reliability of multicast services. PE1, PE2, PE3, and PE4 form a multicast encryption group to ensure the security of multicast data transmission on the network. PE1 and PE2 use sender IDs for the same multicast channel to identify different multicast sources. If two different multicast sources protect each other, the system can assign different sender IDs to the two multicast sources. The following Table 1 illustrates the mapping relationship between Key, multicast source and Multi-core.

Table 1

In this application, PE4 or PE3 can establish a multicast sequence number anti-replay check mechanism. The message encapsulation format, encryption and decryption process will be explained below.

Based on the application scenarios described in Figures 1 to 3, the message transmission method provided by this application is introduced.

Figure 4 is a schematic flowchart of a message transmission method provided by this application. An example of the message transmission method includes steps 101 to 105.

101. Network device A receives the packet message.

102. Network device A confirms that the packet message needs to be encrypted.

In this application, the network device can receive the group message and then confirm whether the group message needs to be encrypted. This process is exemplarily explained below with reference to Figure 2.

In this application, as shown in Figure 2, PE1 and PE3 can establish an encrypted security association (SA) relationship, and PE2 and PE3 can also establish an encrypted SA relationship. The forwarding mechanism between PE2 and PE3 is the same as that between PE1 and PE3. The forwarding mechanism between PE1 and PE3 is similar. The forwarding mechanism between PE1 and PE3 is described in detail below.

In this application, it is assumed that customer network node A sends a packet message and the destination is customer network node C. PE1 (network device) receives the packet message from customer network node A. Based on the SA relationship formed between PE1 and PE3, PE1 confirms whether the packet packet from customer network node A matches the encrypted flow selector rule. If it matches the encrypted flow selector rule, the packet packet is encrypted. If the encrypted flow selector rule does not match, the packet packet will not be encrypted.

103. Network device A encrypts the packet message to generate a target message.

In this application, the target message includes a sender ID, and the sender ID is used to indicate the identity information of the network device.

For example, as shown in Figure 2, if PE3 receives a target message forwarded by PE1, the sender identifier included in the target message can indicate the identity information of PE1. If PE3 receives the target packet forwarded by PE2, the sender ID included in the target packet can indicate PE2's identity information.

104. Network device B receives the target message;

105. Network device B decrypts the target message.

In this application, after the network device confirms that the received packet message needs to be encrypted, the network device encrypts the packet message to generate a target message. The network device encrypts the packet message to generate a target message. The target message includes a sender identifier, and the sender identifier is used to indicate the identity information of the network device. Therefore, for scenarios such as many-to-one, many-to-many, and one-to-many, the device receiving the target message can know the source of the target message based on the sender ID, and can achieve valid service packets without complicated deployment methods. sequential transmission, reducing network overhead.

In this application, the target message mentioned in the above method example may also include a thread identifier, which is used to indicate the identifier of the thread that processes the target message in the device that receives the target message.

In this application, the network device can generate the target message through different encryption methods. When using different encryption methods, the positions of the sender identification and the thread identification in the target message are different. The specific implementation method will be in the following example. Elaborate.

Method 1: Use the ESP header to encrypt and integrity process the packet message.

Figure 5 is a schematic diagram of a target message provided by this application.

Please refer to Figure 5. Figure 5 shows an encapsulation format of an ESP header encrypted IPv6 packet message, using the ESP header to indicate the message encryption and integrity functions. Among them, the ESP header can use the standard encapsulation format or the extended encapsulation header format.

In this application, the ESP header in Figure 5 may include the sender identification and/or the thread identification. Optionally, the sender identification and/or thread identification may be included in any field in the ESP header, and the specific inclusion location is not limited in this application.

Figure 6 is a schematic diagram of an ESP standard header provided by this application.

As shown in Figure 6, Figure 6 shows an ESP standard encapsulation format with Next Header=50, in which the ESP header contains SPI, Sequence Number and other parameters. In order to identify the identity of the device sending the target packet through the target packet, optionally, the sender identifier can be added to the ESP header.

Figure 7 is a schematic diagram of an ESP extension header provided by this application.

As shown in Figure 7, Figure 7 shows another ESP standard encapsulation format, with Next Header=144, and the determined value of Next Header needs to be allocated by the Internet Assigned Numbers Authority (IANA). Among them, the ESP extension header can contain:

(1)SPI||S||AN.

In this application, the length of the SPI||S||AN field is 4octets. Among them, SPI is the security parameter indicator, occupying 28 bits. Optionally, the ESP extension header can include the sender ID (sender id), and/or the thread ID (windowid). It is assumed that the ESP extension header can include the sender id and window id, and S is the sender id and window id enable indication bit. , occupying 2bit. For example, 00 can indicate that sender ID and window ID are not enabled, 01 can indicate that only window ID is enabled, 10 can indicate that only sender ID is enabled, and 11 can indicate that both sender ID and window ID are enabled. Optionally, other enabling methods can also be set, which are not limited here.

In this application, optionally, AN and SPI can form a security parameter indication function as a whole, occupying 2 bits, 00/01/10/11 is used for lightweight update mechanism of SA when other parameters except key update remain unchanged. , only the key needs to be indicated through the AN, and the control plane does not need to perform SA creation and teardown processing, so as to reduce the control plane load of the entire network.

(2)Sender id||window id.

In this application, the sender id occupies 2 bytes, and the window id occupies 2 bytes. The sender id is used to indicate multiple sender IDs of a receiver, and the window id is used to indicate the heterogeneous processor core ID. If the packet message contains The same 5-tuple data stream is called a stream, and window ID can solve the problem of insufficient processing power of a single heterogeneous processor core in a large-bandwidth traffic. Optionally, the ESP extension header can include sender id, and/or window id, that is, the ESP extension header can only include sender id, ESP can also include only window id, and ESP can also include both sender id and window id. Specifically, this is There are no restrictions anywhere.

(3)Sequence Number.

In this application, Sequence Number is used to identify the sequence number of message transmission and is used for the message anti-replay function, occupying 4 bytes or 8 bytes. Optional, for encryption algorithms that require IV to ensure encryption security, such as AES-GCM, the IV is converted through the sender id||window id||sequence number combination and is not carried in clear text in the message payload, reducing additional packaging of the message overhead.

(4)Timestamp.

In this application, Timestamp can be used in the anti-replay loose mode, that is, the anti-replay capability based on timestamp, which occupies 4 bytes. Optionally, the encoding format can be in accordance with the IEEE 1588v2 format, which can support up to 4s anti-replay capability. Timestamp requires the sender and receiver groups to implement NTP time synchronization. NTP time synchronization can use the controller as the server, or you can select one of the sender and receiver groups as the NTP server for synchronization.

In this application, the relationship between key, network element and core ID in the actual data encryption process is shown in Table 2 below.

Key Network element Multi-Core P2P unicast SPI||S||AN <-1:1-> Sender ID <-1:N-> Window id MP2P LAN SPI||S||AN <-1:N-> Sender ID <-1:N-> Window id

Table 2

Method 2: Use the DOH header to encrypt and integrity process the packet message.

Figure 8 is another schematic diagram of a target message provided by this application.

Please refer to Figure 8. Figure 8 shows an encapsulation format of a DOH header encrypted IPv6 packet message, using the DOH header to indicate the message encryption and integrity functions. Optionally, the sender identification and/or thread identification can be carried through the optional TLV in the DOH.

Figure 9 is a schematic diagram of a DOH head provided by this application.

Please refer to Figure 9. Figure 9 shows a DOH encapsulation format carrying an encrypted ESP standard or extension header. The format of the encrypted ESP standard or extension header is similar to the formats shown in Figures 6 and 7 above. The details are not mentioned here. To elaborate. In addition, the optional TLV definition in DOH considers the compatibility of existing network equipment. The DOH extension header can contain the following parameters:

(1)Option Type.

In this application, Option Type occupies 8 bits, of which the two highest bits are 00’b, which means that if the device does not recognize this option Type, it needs to ignore this option TLV and continue to process the remaining message content.

(2)Option Data Len.

In this application, Option Data Len occupies 8 bits and represents the length of the option DATA part of this option TLV.

(3)Opt.DATA.

In this application, Opt.DATA can include ESP standard or extended header information. Among them, the format of the ESP standard or extension header is similar to the format shown in Figure 6 and Figure 7 above, and the details will not be described here.

In this application, step 103 mentioned in the method example corresponding to Figure 4 has a variety of specific implementation methods, and the specific implementation methods will be elaborated in the following examples.

For example, as shown in Figure 2, when PE1 (network device) encrypts IPv6 packets, PE1 receives the original IPv6 packets and determines whether the original IPv6 packets need to be encrypted based on the traffic selector. If encryption is not required, forward the message according to the normal message forwarding process. If encryption is required, select the encryption encapsulation method based on SA negotiation information.

Encryption method 1: Use the ESP header to encrypt and integrity process the packet message.

In this application, optionally, the network device can use the ESP header to perform encryption and integrity processing on the packet message. The following is an example of this processing process.

Figure 10 is a flow chart of an encryption method provided by this application.

Please refer to Figure 10. In this application, PE1 (network equipment) generates ESP header information according to the ESP standard encapsulation format (as shown in Figure 6), or according to the ESP extended encapsulation format (as shown in Figure 7). PE1 will generate the ESP extension header format and insert it into the original IPv6 packet message according to the format shown in Figure 5. According to the 8-byte alignment requirement of the payload part of the Ipv6 packet message, define the encapsulation security payload tail padding, padding length, and record the original IPv6 Extension headerNext header. Encrypt or calculate the integrity of the original IPv6 packet message according to the encryption algorithm, KEY, and message encryption length specified by the SA. If the message requires integrity protection, calculate the integrity value and attach the Integrity Check Value (ICV) value to the end of the message. Modify the Next Header value of the original IPv6 packet message to the ESP header type value. Recalculate and update the IPv6 standard header field: IPv6 payload length. Send message.

Encryption method two: Use the DOH header to encrypt and integrity process the packet message.

In this application, optionally, the network device can use the DOH header to perform encryption and integrity processing on the packet message. The following is an example of this processing process.

Figure 11 is a flow chart of an encryption method provided by this application.

Please refer to Figure 11. In this application, ESP header information is generated according to the ESP standard encapsulation format (Figure 6) or the ESP extended encapsulation format (Figure 7). Generate the DOH message format according to Figure 9, and insert it into the IPv6 original packet message according to the format in Figure 8. According to the 8-byte alignment requirement of the payload part of the IPv6 packet message, define the encapsulation security payload tail padding, padding length, and record the original IPv6 extension header Next header. Encrypt or calculate the integrity of the original IPv6 packet message according to the encryption algorithm, KEY, and message encryption length specified by the SA. If the message requires integrity protection, calculate the integrity value and attach the ICV value to the end of the message. Modify the DOH next header value to No next header (59). Recalculate and update the IPv6 standard header field: IPv6 payload length. Send message.

In this application, step 105 mentioned in the method example corresponding to Figure 4 has a variety of specific implementation methods, and the specific implementation methods will be elaborated in the following examples.

For example, as shown in Figure 2, when PE3 (network device) decrypts the target packet, it receives the target packet. Determine the ESP header boundary Next Header=50/144 based on the type value of the ESP header in the target packet. If so, decrypt the target packet through decryption. If not, go to the next step. Parse opt.Type in DOH and determine Type=DOH optional encryption type value. If so, decrypt the target message through decryption method 2. If not, forward the packet according to the normal packet forwarding process. The two decryption methods are described in detail below.

Decryption method one: Decrypt the target message through the ESP header.

Figure 12 is a flow chart of a decryption method provided by this application.

Please refer to Figure 12. In this application, relevant information is parsed according to the ESP standard encapsulation format (Figure 6) or the ESP extended encapsulation format (Figure 7). Use sender id||window id||sequence Number for anti-replay processing. Use KEY and the corresponding algorithm to calculate the integrity of the message. Verify whether the ICV value attached to the packet is consistent with the calculated integrity value. If not, discard the packet. Use KEY and the corresponding algorithm to decrypt and calculate the message. According to the SA attribute, if the packet carries the timestamp anti-replay Loose capability, the Timestamp and local time in the packet payload are obtained for replay judgment. Modify the Next Header value related to the original IPv6 packet to the Next Header in the encapsulated security payload tail. The message strips off the ICV trailer, encapsulates the security payload trailer and ESP header, and anti-replay Timestamp related information. Recalculate and update the IPv6 standard header field: IPv6 payload length. Send the decrypted message.

Figure 13 is a flow chart of another decryption method provided by this application.

Please refer to Figure 13. In this application, the IPv6 packet message is decrypted through the DOH extension optional header. The relevant information is parsed according to the ESP standard encapsulation format (Figure 6) or the ESP extended encapsulation format (Figure 7). Use sender id||window id||sequence Number for anti-replay processing. Use KEY and the corresponding algorithm to calculate the integrity of the message. According to the SA attribute, if the packet carries the timestamp anti-replay Loose capability, the Timestamp and local time in the packet payload are obtained for replay judgment. Verify whether the ICV value attached to the packet is consistent with the calculated integrity value. If not, discard the packet. Use KEY and the corresponding algorithm to decrypt and calculate the message. The message strips off the ICV trailer, encapsulates the security payload trailer and ESP header, and anti-replay Timestamp related information. Determine whether the number of DOH option TLVs is 0. If it is 0, DOH needs to be stripped. Modify the corresponding extension header Next Header = Encapsulate the Next Header in the security payload tail. Recalculate and update the IPv6 standard header field: IPv6 payload length. Send the decrypted message.

In this application, optionally, the target message may include a sequence number, and the sequence number, sender identifier, and/or thread identifier may together constitute an IV value, and the IV value may be used to encrypt the packet message.

In this application, it is assumed that the target message includes a sequence number, sender identification and thread identification. For encryption algorithms that require IV to ensure encryption security, such as AES-GCM, IV can be converted through the sender id | overhead. It can be understood that other encryption algorithms can also be used to encrypt packet messages, and the details are not limited here. This process is introduced in detail below with an example.

Figure 14 is a schematic diagram of another anti-replay principle provided by this application.

Please refer to Figure 14. In this application, for the same SA, multiple sequence number state spaces are established based on {SPI||S||AN||sender id||windowid}. For the received encrypted message, use {SPI||S||AN||sender id||window id} carried in the message to find the corresponding sequence number state space, and proceed according to the set anti-replay window window_anti_replay size Anti-replay check. If the check passes, the packet will be processed in the next step. If the check fails, the packet will be discarded directly.

The principle of anti-replay check is as follows:

packet_Sequence_Number<=Current_Sequence_Number, the check fails;

packet_Sequence_Number>Current_Sequence_Number&&packet_Sequence_Number<=Current_Sequence_Number+window_anti_replay, check passed;

packet_Sequence_Number>Current_Sequence_Number&&packet_Sequence_Number>Current_Sequence_Number+window_anti_replay, the check fails.

Update the counter of the corresponding sequence Number state space.

The Sequence Number space is updated or deleted according to the SA negotiation status.

In this application, after the network device confirms that the received packet message needs to be encrypted, the network device encrypts the packet message to generate a target message. The network device encrypts the packet message to generate a target message. The target message includes a sender identifier, and the sender identifier is used to indicate the identity information of the network device. Therefore, for scenarios such as many-to-one, many-to-many, and one-to-many, the device receiving the target message can know the source of the target message based on the sender ID, and can achieve valid service packets without complicated deployment methods. sequential transmission, reducing network overhead.

The above examples provide different implementations of a message transmission method. The following provides a network device 20, as shown in Figure 15. The network device 20 is used to perform the message transmission method involved in the above examples. Please refer to the corresponding examples above to understand the execution steps and corresponding beneficial effects, which will not be repeated here, including:

The receiving unit 201 is used to receive packet messages;

The processing unit 202 is used for:

Confirm that the packet message needs to be encrypted;

The packet message is encrypted to generate a target message, where the target message includes a sender identification, and the sender identification is used to indicate the identity information of the network device.

In a possible implementation manner, the target message further includes a thread identifier, and the thread identifier is used to indicate the identifier of a thread that processes the target message in the device that receives the target message.

In a possible implementation manner, the target message includes a security payload encapsulation header ESP, and the ESP includes the sender identification and/or the thread identification.

In a possible implementation manner, the target message includes a destination optional extension header DOH, and the DOH includes the sender identification and/or the thread identification.

In a possible implementation, the DOH includes the sender identification and/or the thread identification, including:

The optional type length value TLV of the DOH includes the sender identification and/or the thread identification.

In a possible implementation, the target message includes a sequence number, the sequence number, the sender identification and/or the thread identification are jointly used to form an IV value, and the IV value is used to The packet message is encrypted.

In a possible implementation manner, the target message includes SPI and AN, and the SPI and AN are jointly used to indicate security parameters.

It should be noted that the information interaction, execution process, etc. between the modules of the network device 20 are based on the same concept as the method examples of this application, and the execution steps are consistent with the details of the above method steps. Please refer to the above method examples. description of the location.

The above examples provide different implementations of a network device 20. The following provides a network device 30, as shown in Figure 16. The network device 30 is used to execute the message transmission method involved in the above examples. The execution Please refer to the corresponding examples above to understand the specific steps and corresponding beneficial effects, which will not be repeated here, including:

The receiving unit 301 is configured to receive a target message, where the target message includes a sender identification, and the sender identification is used to indicate the identity information of the device that sends the target message;

The processing unit 302 is used to decrypt the target message.

In a possible implementation manner, the target message further includes a thread identifier, and the thread identifier is used to indicate the identifier of a thread that processes the target message in the device that receives the target message.

In a possible implementation manner, the target message includes a security payload encapsulation header ESP, and the ESP includes the sender identification and/or the thread identification.

In a possible implementation manner, the target message includes a destination optional extension header DOH, and the DOH includes the sender identification and/or the thread identification.

In a possible implementation, the DOH includes the sender identification and/or the thread identification, including:

The optional TLV of the DOH includes the sender identification and/or the thread identification.

In a possible implementation, the target message includes a sequence number, the sequence number, the sender identification and/or the thread identification are jointly used to form an IV value, and the IV value is used to The packet message is encrypted.

In a possible implementation manner, the target message includes SPI and AN, and the SPI and AN are jointly used to indicate security parameters.

It should be noted that the information interaction and execution process between the modules of the network device 30 are based on the same concept as the method examples of this application, and the execution steps are consistent with the details of the above method steps. Please refer to the above method examples. description of the location.

It should be noted that the information interaction, execution process, and other contents between the modules of the device 30 provided in the above embodiments are based on the same concept as the method embodiments of the present application, and the technical effects they bring are the same as those of the method embodiments of the present invention. , for specific details, please refer to the descriptions in the method embodiments shown above in this application, and will not be described again here.

Referring to FIG. 17 , a schematic structural diagram of a network device is provided for this application. The network device 40 includes: a processor 402 , a communication interface 403 , and a memory 401 . Optionally, bus 404 may be included. Among them, the communication interface 403, the processor 402 and the memory 401 can be connected to each other through the bus 404; the bus 404 can be a peripheral component interconnect standard (Peripheral Component Interconnect, PCI) bus or an extended industry standard architecture (extended industry standard architecture, EISA) bus. wait. The bus can be divided into address bus, data bus, control bus, etc. For ease of presentation, only one thick line is used in Figure 17, but it does not mean that there is only one bus or one type of bus. The network device 40 can implement the functions of any network device in the examples shown in FIG. 15 or FIG. 16 . The processor 402 and the communication interface 403 can perform corresponding operations of the network device in the above method examples.

The following is a detailed introduction to each component of the network equipment in conjunction with Figure 17:

The memory 401 may be a volatile memory (volatile memory), such as a random-access memory (RAM); or a non-volatile memory (non-volatile memory), such as a read-only memory (read-only memory). memory (ROM), flash memory (flash memory), hard disk drive (HDD) or solid-state drive (SSD); or a combination of the above types of memories, used to store data that can implement the method of the present application. Program code, configuration files, or other content.

The processor 402 is the control center of the controller, which may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or may be configured to implement the examples provided in this application. One or more integrated circuits, such as one or more digital signal processors (DSP), or one or more field programmable gate arrays (FPGA).

Communication interface 403 is used to communicate with other network devices.

The processor 402 can perform operations performed by any of the network devices in the examples shown in FIG. 15 or FIG. 16 , and details will not be described again here.

It should be noted that the information interaction, execution process, etc. between the modules of the network device 40 are based on the same concept as the method examples of this application, and the execution steps are consistent with the details of the above method steps. Please refer to the above method examples. description of the location.

This application provides a chip. The chip includes a processor and a communication interface. The processor is coupled to the communication interface. The processor is used to read instructions and execute the network in the embodiments described in Figures 15 to 17. The operation performed by the device.

The present application provides a network system, which includes the network device described in the embodiments described in FIGS. 15 to 17 .

Those skilled in the art can clearly understand that for the convenience and simplicity of description, the specific working processes of the systems, devices and units described above can be referred to the corresponding processes in the foregoing examples, and will not be described again here.

Among the several examples provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device examples described above are only illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or may be Integrated into another system, or some features can be ignored, or not implemented. On the other hand, the coupling or direct coupling or communication connection between each other shown or discussed may be through some interfaces, and the indirect coupling or communication connection of the devices or units may be in electrical, mechanical or other forms.

The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or they may be distributed to multiple network units. You can select some or all of the units according to actual needs to achieve the purpose of this example.

In addition, each functional unit in each example of this application can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above integrated units can be implemented in the form of hardware or software functional units.

If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it may be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or contributes to the existing technology, or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium , including several instructions to cause a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in each example of this application. The aforementioned storage media include: U disk, mobile hard disk, read-only memory (ROM, read-only memory), random access memory (RAM, random access memory), magnetic disk or optical disk and other media that can store program code.

The above-mentioned specific implementations further describe the purpose, technical solutions and beneficial effects of the present invention in detail. It should be understood that different examples can be combined, and the above are only specific implementations of the present invention. It is not intended to limit the protection scope of the present invention. Any combination, modification, equivalent substitution, improvement, etc. made within the spirit and principles of the present invention shall be included in the protection scope of the present invention. As mentioned above, the above examples are only used to illustrate the technical solution of the present application, but not to limit it; although the present application has been described in detail with reference to the foregoing examples, those of ordinary skill in the art should understand that they can still modify the foregoing examples. The recorded technical solutions may be modified, or some of the technical features thereof may be equivalently substituted; however, these modifications or substitutions shall not cause the essence of the corresponding technical solutions to depart from the scope of the exemplary technical solutions of this application.

Claims (31)

1. A method for transmitting a message, comprising:

the network equipment receives the packet message;

the network equipment confirms that the packet message needs to be encrypted;

the network equipment encrypts the packet message to generate a target message, wherein the target message comprises a sender identifier, and the sender identifier is used for indicating the identity information of the network equipment.

2. The method according to claim 1, wherein the target message further includes a thread identifier, and the thread identifier is used to indicate an identifier of a thread that processes the target message in a device that receives the target message.

3. The message transmission method according to claim 2, wherein the target message includes a security load encapsulation header ESP, and the ESP includes the sender identifier and/or the thread identifier.

4. The message transmission method according to claim 2, wherein the destination message includes a destination optional extension header DOH, and the DOH includes the sender identifier and/or the thread identifier.

5. The method according to claim 4, wherein the DOH includes the sender identifier and/or the thread identifier, and the method includes:

the optional type length value TLV of the DOH includes the sender identification and/or the thread identification.

6. The method according to any one of claims 1 to 5, wherein the target message includes a sequence number, and wherein the sequence number, the sender identifier and/or the thread identifier are used together to form an IV value, and wherein the IV value is used to encrypt the packet message.

7. The method according to any one of claims 1 to 6, wherein the target message includes AN SPI and AN, and the SPI and the AN are used together to indicate a security parameter.

8. A method for transmitting a message, comprising:

the network equipment receives a target message, wherein the target message comprises a sender identifier, and the sender identifier is used for indicating the identity information of equipment for sending the target message;

the network device decrypts the target message.

9. The method according to claim 8, wherein the target message further includes a thread identifier, and the thread identifier is used to indicate an identifier of a thread that processes the target message in a device that receives the target message.

10. The message transmission method according to claim 9, wherein the target message includes a security load encapsulation header ESP, and the ESP includes the sender identifier and/or the thread identifier.

11. The method according to claim 9, wherein the destination message includes a destination optional extension header DOH, and the DOH includes the sender identifier and/or the thread identifier.

12. The method for transmitting a message according to claim 11, wherein the DOH includes the sender identifier and/or the thread identifier, including:

the optional TLV of the DOH includes the sender identification and/or the thread identification.

13. The method according to any of claims 8 to 12, wherein the target message comprises a sequence number, and wherein the sequence number, the sender identification and/or the thread identification are used together to form an IV value, and wherein the IV value is used to encrypt the packet message.

14. The method according to any one of claims 8 to 13, wherein the target message includes AN SPI and AN, and the SPI and the AN are used together to indicate security parameters.

15. A network device, comprising:

a receiving unit, configured to receive a packet;

the processing unit is used for:

confirming that the packet message needs to be encrypted;

and encrypting the packet message to generate a target message, wherein the target message comprises a sender identifier, and the sender identifier is used for indicating the identity information of the network equipment.

16. The network device of claim 15, wherein the target message further comprises a thread identification, the thread identification indicating an identification of a thread processing the target message in the device receiving the target message.

17. Network device according to claim 16, characterized in that the target message comprises a security load encapsulation header ESP, which ESP comprises the sender identification and/or the thread identification.

18. Network device according to claim 16, characterized in that the destination optional extension header DOH is included in the destination message, and the sender identification and/or the thread identification is included in the DOH.

19. Network device according to claim 18, characterized in that said sender identification and/or said thread identification are included in said DOH, comprising:

the optional type length value TLV of the DOH includes the sender identification and/or the thread identification.

20. The network device according to any of claims 15 to 19, wherein the target message comprises a sequence number, the sender identification and/or the thread identification being used together to form an IV value, the IV value being used to encrypt the packet message.

21. A network device according to any one of claims 15 to 20, wherein the target message includes AN SPI and AN, which are used together to indicate security parameters.

22. A network device, comprising:

the receiving unit is used for receiving a target message, wherein the target message comprises a sender identifier, and the sender identifier is used for indicating the identity information of equipment for sending the target message;

and the processing unit is used for decrypting the target message.

23. The network device of claim 22, wherein the target message further comprises a thread identification, the thread identification indicating an identification of a thread processing the target message in the device receiving the target message.

24. Network device according to claim 23, characterized in that the target message comprises a security load encapsulation header ESP, which ESP comprises the sender identification and/or the thread identification.

25. The network device according to claim 23, wherein the destination optional extension header DOH is included in the destination message, and wherein the sender identifier and/or the thread identifier is included in the DOH.

26. Network device according to claim 25, characterized in that said sender identification and/or said thread identification are included in said DOH, comprising:

the optional TLV of the DOH includes the sender identification and/or the thread identification.

27. The network device according to any of claims 22 to 26, wherein the target message comprises a sequence number, the sender identification and/or the thread identification being used together to form an IV value, the IV value being used to encrypt the packet message.

28. A network device according to any one of claims 22 to 27, wherein the target message includes AN SPI and AN, which are used together to indicate security parameters.

29. A network device, comprising:

a processor and a memory;

the processor is configured to execute instructions stored in the memory such that the method of any one of claims 1 to 7 is performed or such that the method of any one of claims 8 to 14 is performed.

30. A computer readable storage medium storing a computer program, characterized in that the computer program, when executed on a computer or processor, causes the method of any one of claims 1 to 7 to be performed or causes the method of any one of claims 8 to 14 to be performed.

31. A computer program product, characterized in that it when run on a computer or processor causes the method of any one of claims 1 to 7 to be performed or causes the method of any one of claims 8 to 14 to be performed.