CN116980150A

CN116980150A - Message transmission method and related equipment

Info

Publication number: CN116980150A
Application number: CN202210434246.4A
Authority: CN
Inventors: 史玉林; 韩涛; 任广涛; 赵凤华
Original assignee: Beijing Huawei Digital Technologies Co Ltd
Current assignee: Beijing Huawei Digital Technologies Co Ltd
Priority date: 2022-04-24
Filing date: 2022-04-24
Publication date: 2023-10-31

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

Message transmission method and related equipment

Technical Field

The present application relates to the field of communications, and in particular, to a method for transmitting a message and related devices.

Background

The internet security protocol (Internet Protocol Security, IPSec) is a set of protocols used to provide interoperable, high-quality, encryption-based security services for internet protocol version four (Internet Protocol version, IPv 4) and internet protocol version six (Internet Protocol Version, IPv 6). The security services provided by IPSec are provided at the internet protocol (Internet Protocol, IP) layer. IPSec provides protection in a standard manner for the IP layer and all protocols carried on the IP layer. One or more paths between a pair of hosts, between a pair of security gateways, between a security gateway and a host may be protected using IPsec.

IPSec supports a tunnel mode and a transport mode, in which the entire IP packet to be protected is encapsulated in a new IP packet as a payload of the new packet, and then a new IP header is added externally. In transport mode, only transport layer data is used to compute an authentication optional extension header (Authentication option header, AH) or encapsulated security payload header, the AH or encapsulated security payload header and encrypted transport layer data are placed after the original IP header. The transmission mode of AH will verify the IP header, while the transmission mode of the encapsulated security payload will not protect both the IP header and the extension header before the encapsulation of the security payload header.

With the rapid development of IPv6+ services, new transmission plane encryption requirements emerge. Whereas IPsec is a one-to-one (P2P) encrypted tunnel. Aiming at many-to-one, many-to-many, one-to-many and other scenes, the face encryption service can be realized only by establishing a FULL MESH IPsec Tunnel mode, the deployment mode is complex, and the network overhead is high.

Disclosure of Invention

The application provides a message transmission method and related equipment. In the application, the target message comprises a sender identifier, and the sender identifier is used for indicating the 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, the ordered transmission of the message can be realized without a complex deployment mode, and the network overhead is reduced.

The first aspect of the present application provides a message transmission method, in which: 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.

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.

In a possible implementation manner of the first aspect, the target message further includes a thread identifier, where 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.

In this possible implementation manner, the target message may include a thread identifier (window id), where the window id is used to indicate an identifier of a thread that processes the target message in a device that receives the target message, that is, an id of a heterogeneous processor core. Assuming that the same data stream of 5-tuple in the packet message is called a stream, multiple target messages can be respectively distributed to multiple processor cores for processing through different window ids, the problem of insufficient processing capacity of a single heterogeneous processor core aiming at a large bandwidth flow can be solved, and the processing efficiency of the target messages is improved.

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

In the possible implementation manner, a specific existence manner of the sender identifier and/or the thread identifier is provided, when the sender identifier and/or the thread identifier is included in the security load encapsulation header (Encapsulating Security Payload, ESP), the sender identifier and/or the thread identifier are carried under the standard encapsulation format, so that the equipment for receiving the target message can be more conveniently docked with the network equipment, and the feasibility of the scheme is improved.

In a possible implementation manner of the first aspect, the destination optional extension header DOH is included in the target packet, and the sender identifier and/or the thread identifier are included in the DOH.

In this possible implementation manner, a specific existence manner of the sender identifier and/or the thread identifier is provided, the target optional extension header (Destination option header, DOH) is processed at the end node, and the end node can be used as an encryption tunnel end node without additional tunnel information indication encryption, thereby improving the feasibility of the scheme.

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

In the possible implementation manner, a specific existence manner of the sender identifier and/or the thread identifier is provided, so that the feasibility of the scheme is improved.

In a possible implementation manner of the first aspect, the target packet includes a sequence number, where the sequence number, the sender identifier, and/or the thread identifier are used together to form an IV value, where the IV value is used to encrypt the packet.

In this possible implementation, it is assumed that the target message includes a sequence number (sequence number), a sender identifier (sender id), and a thread identifier (window id). For an encryption algorithm requiring the IV to ensure encryption security, the IV can be obtained by converting a sender id I window id I sequence number combination. Therefore, the IV does not need to be carried in a clear text in the message payload, and the cost required by message encapsulation can be reduced.

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

In this possible implementation, alternatively, the AN and the SPI may integrally form a security parameter indication function, taking 2 bits, and 00/01/10/11 is used for a lightweight update mechanism in the case that the SA updates other parameters except the key. Only the key is indicated by the AN, and the control plane is not required to carry out SA new construction and dismantling processing, so that the load of the control plane of the whole network is reduced, and the network overhead is saved.

The second aspect of the present application provides a method for transmitting a message, where the method includes: 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.

In the application, a network device receives a target message, wherein the target message comprises a sender identifier, and the sender identifier is used for indicating the identity information of the device for sending the target message. Therefore, aiming at the scenes of many-to-one, many-to-many, one-to-many and the like, the network 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.

In a possible implementation manner of the second aspect, the target message further includes a thread identifier, where 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.

In a possible implementation manner of the second aspect, the target packet includes a security load encapsulation header ESP, where the ESP includes the sender identifier and/or the thread identifier.

In a possible implementation manner of the second aspect, the destination optional extension header DOH is included in the target packet, and the sender identifier and/or the thread identifier are included in the DOH.

In a possible implementation manner of the second aspect, 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.

In a possible implementation manner of the second aspect, the target packet includes a sequence number, where the sequence number, the sender identifier, and/or the thread identifier are used together to form an IV value, where the IV value is used to encrypt the packet.

In this possible implementation, it is assumed that the target message includes a sequence number (sequence number), a sender identifier (sender id), and a thread identifier (window id). For an encryption algorithm requiring the IV to ensure encryption security, the IV can be obtained by converting a sender id I window id I sequence number combination. Therefore, the plaintext is not required to carry IV in the payload of the message, and the cost required by message encapsulation can be reduced.

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

A third aspect of the application provides a network device comprising at least one processor, a memory and a communication interface. The processor is coupled with the memory and the communication interface. The memory is used for storing instructions, the processor is used for executing the instructions, and the communication interface is used for communicating with other network devices under the control of the processor. The instructions, when executed by a processor, cause the network device to perform the method of the first aspect or any of the possible implementations of the first aspect, or cause the network device to perform the method of the second aspect or any of the possible implementations of the second aspect.

A fourth aspect of the application provides a computer readable storage medium storing a program for causing a network device to perform the method of the first aspect or any possible implementation of the first aspect or causing the network device to perform the method of the second aspect or any possible implementation of the second aspect.

A fifth aspect of the application provides a computer program product storing one or more computer-executable instructions which, when executed by the processor, perform the method of any one of the possible implementations of the first aspect or the first aspect, or the method of any one of the possible implementations of the second aspect or the second aspect.

A sixth aspect of the application provides a chip comprising a processor and a communication interface, the processor being coupled to the communication interface, the processor being for reading instructions to perform the method of any one of the above-described first aspect or any one of the possible implementations of the first aspect, or the processor being for reading instructions to perform the method of any one of the above-described second aspect or any one of the possible implementations of the second aspect.

A seventh aspect of the present application is a network system comprising a network device on which the method according to the first aspect or any one of the possible implementations of the first aspect is performed, or on which the method according to the second aspect or any one of the possible implementations of the second aspect is performed.

Drawings

Fig. 1 is a schematic diagram of an application scenario of a message transmission method provided by the present application;

fig. 2 is a schematic diagram of another application scenario of a message transmission method provided by the present application;

fig. 3 is a schematic diagram of another application scenario of a message transmission method provided by the present application;

fig. 4 is a schematic flow chart of a message transmission method provided by the present application;

FIG. 5 is a schematic diagram of a target message according to the present application;

FIG. 6 is a schematic diagram of an ESP standard head provided by the present application;

FIG. 7 is a schematic illustration of an ESP extension head provided by the present application;

FIG. 8 is another schematic diagram of a target message according to the present application;

FIG. 9 is a schematic diagram of a DOH header provided by the present application;

FIG. 10 is a flow chart of an encryption scheme provided by the present application;

FIG. 11 is a flowchart of an encryption method according to the present application;

FIG. 12 is a flow chart of a decryption method according to the present application;

FIG. 13 is a flow chart of another decryption method according to the present application;

FIG. 14 is a schematic diagram of another playback resistant principle provided by the present application;

fig. 15 is a schematic diagram of a network device according to the present application;

fig. 16 is another schematic diagram of a network device according to the present application;

fig. 17 is another schematic diagram of a network device according to the present application.

Detailed Description

Examples provided by the present application will now be described with reference to the accompanying drawings, it being apparent that the examples described are only some, but not all, examples of the application. As one of ordinary skill in the art can appreciate, with the development of technology and the appearance of new scenes, the technical scheme provided by the application is also applicable to similar technical problems.

The terms first, second and the like in the description and in the claims and in the above-described figures, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the examples described herein may be implemented in sequences other than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

The "and/or" in the present application is merely an association relationship describing the association object, and indicates that three relationships may exist, for example, a and/or B may indicate: there are three cases, a alone, a and B together, and B alone, wherein a, B may be singular or plural. Also, in the description of the present application, unless otherwise indicated, "a plurality" means two or more than two. "at least one of" or the like means any combination of these items, including any combination of single item(s) or plural items(s). For example, at least one (one) of a, b, or c may represent: a, b, c, a-b, a-c, b-c, or a-b-c, wherein a, b, c may be single or plural.

In order to solve the problems in the above-mentioned scheme, the present application provides a message transmission method and related equipment. In the application, the target message comprises a sender identifier, and the sender identifier is used for indicating the 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, the ordered transmission of the message can be realized without a complex deployment mode, and the network overhead is reduced.

The application scenario of the message transmission method provided by the application is first described below.

Fig. 1 is a schematic diagram of an application scenario of a message transmission method provided by the present application.

In the present application, as shown in fig. 1, a network system to which the message transmission method provided by the present application is applied mainly comprises a client network node and a LAN network. The LAN network mainly carries the forwarding of IP packet messages of the client network nodes through PE equipment. In the present application, it is understood that the destination of the IP packet is not fixed, and the specific destination is not limited herein. As shown in fig. 1, it is assumed that an IP packet message sent from the client network node a is addressed to the client network node C for a certain period of time. In other time periods, the IP packet message sent from the client network node a is sent to the client network node B, and specifically, to which destination is determined by the destination MAC or the destination IP in the IP packet message.

Fig. 2 is a schematic diagram of another application scenario of a message transmission method provided by the present application.

In the present application, as shown in fig. 2, PE1, PE2 and PE3 respectively establish a forwarding relationship. Alternatively, the forwarding relationship may be established by creating an MPLS tunnel through multiprotocol label switching (Multiprotocol Label Switching, MPLS)/label distribution protocol (Label Distribution Protocol, LDP) protocol, or by forming a routing forwarding relationship through border gateway protocol (Border Gateway Protocol, BGP)/interior gateway protocol (Interior Gateway Protocol, IGP) routing, or the controller issues a forwarding policy to form a forwarding tunnel, such as SRV6 policy, or may be established through other protocols. The establishment of the forwarding relationship is not particularly limited in the present application, as long as the MP2P forwarding relationship can be formed among PE1, PE2, and PE 3.

Fig. 3 is a schematic diagram of another application scenario of a message transmission method provided by the present application.

In the present application, as shown in fig. 3, PE1, PE3, and PE4 establish a multicast forwarding relationship, PE2, PE3, and PE4 establish a multicast forwarding relationship, and the establishment of the forwarding relationship may be through a PIM protocol, an MPVPN, or the like, and the establishment of the forwarding relationship is not limited in the present application, as long as a multicast forwarding relationship can be formed among PE1, PE2, and PE 3.

In the application, as shown in fig. 3, the multicast source nodes of the PE1 and the PE2 form mutual protection, so as to ensure the network reliability of multicast service. PE1, PE2, PE3 and PE4 form a multicast encryption group, so that the transmission safety of multicast data in a network is ensured. PE1 and PE2 use sender identification for the same multicast channel to identify different multicast sources, if two different multicast sources are protected from each other, the system can assign the two multicast sources to be different sender ids. The following table illustrates the mapping relationship between keys, multicast sources, and Multi-core.

TABLE 1

In the application, PE4 or PE3 can establish a multicast sequence number anti-replay checking mechanism. The message encapsulation format, encryption and decryption flow are described below.

The message transmission method provided by the application is introduced based on the application scenarios described in fig. 1 to 3.

Fig. 4 is a flow chart of a message transmission method according to the present application, and one method 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 the application, the network equipment can receive the packet message and further confirm whether the packet message needs to be encrypted or not. This process is exemplarily described below in conjunction with fig. 2.

In the present application, as shown in fig. 2, PE1 and PE3 may establish an encryption security association (security association, SA) relationship, and PE2 and PE3 may also establish an encryption SA relationship, and a forwarding mechanism between PE2 and PE3 is similar to a forwarding mechanism between PE1 and PE3, and a detailed description of the forwarding mechanism between PE1 and PE3 is described below.

In the present application, it is assumed that the client network node a sends out a packet message, and the destination is the client network node C. PE1 (network device) receives a packet message from a client network node a. And the PE1 confirms whether the packet message from the client network node A matches the encryption stream selector rule according to the SA relationship formed between the PE1 and the PE3, and if so, the encryption processing of the packet message is carried out. If the encryption stream selector rule is not matched, the encryption processing of the packet message is not performed.

103. The network equipment A encrypts the packet to generate a target message.

In the application, the target message comprises a sender identifier (sender id), and the sender identifier is used for indicating the identity information of the network equipment.

For example, as shown in fig. 2, if PE3 receives a target packet forwarded by PE1, the sender identifier included in the target packet may indicate the identity information of PE 1. If PE3 receives the target message forwarded by PE2, the sender identifier included in the target message can indicate the identity information of PE 2.

104. The network equipment B receives the target message;

105. the network device B decrypts the target message.

In the present application, the target message mentioned in the above method example may further include a thread identifier, where 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.

In the application, the network device can generate the target message through different encryption modes, and when different encryption modes are adopted, the positions of the sender identifier and the thread identifier in the target message are different, and the specific implementation mode is described in detail in the following examples.

Mode one: the packet message is encrypted and integrity processed using the ESP header.

Fig. 5 is a schematic diagram of a target message provided in the present application.

Referring to fig. 5, fig. 5 shows a packing format of an ESP header encrypted IPv6 packet, and the ESP header is used to indicate the packet encryption and integrity functions. The ESP header may use a standard encapsulation format or use an extended encapsulation header format, among other formats.

In the present application, the sender identification and/or thread identification may be included in the ESP header in fig. 5. Alternatively, the sender identifier and/or the thread identifier may be contained in any field in the ESP header, and the specific containing location is not limited in the present application.

Fig. 6 is a schematic diagram of an ESP standard header provided by the present application.

As shown in fig. 6, fig. 6 shows an ESP standard encapsulation format, which has Next header=50, wherein the ESP Header contains various parameters such as SPI, sequence Number, etc. In order to identify the identity of the device sending the target message by the target message, optionally, a sender identification may be added to the ESP header.

Fig. 7 is a schematic diagram of an ESP extension head provided by the present application.

As shown in fig. 7, fig. 7 shows another ESP standard encapsulation format, where Next header=144, and the determined value of the Next Header needs to be allocated by an internet number allocation organization (Internet Assigned Numbers Authority, IANA). Wherein the ESP extension head may comprise:

(1)SPI||S||AN。

in the application, the length of the SPI S AN field is 4octets. The SPI is a security parameter indicator, and occupies 28bits. Alternatively, the ESP extension header may include a sender identification (sender id), and/or a thread identification (window id), assuming that the ESP extension header may include a sender id and a window id, S is a sender id and a window id enable indicator bit, occupying 2 bits. Illustratively, 00 may represent that sender id and window id are not enabled, 01 may represent that only window id is enabled, 10 may represent that only sender id is enabled, and 11 may represent that both sender id and window id are enabled. Alternatively, other enabling manners may be provided, and are not limited herein.

In the application, alternatively, the AN and SPI can integrally form a security parameter indication function, and occupy 2 bits, 00/01/10/11 is used for a lightweight update mechanism under the condition that the SA updates other parameters except the secret key, the secret key is indicated only by the AN, and the control plane is not required to carry out new construction and dismantling processing of the SA so as to reduce the load of the control plane of the whole network.

(2)Sender id||window id。

In the application, the sender id occupies 2 bytes, the window id occupies 2 bytes, the sender id is used for indicating a plurality of sender ids of a receiver, the window id is used for indicating heterogeneous processor core ids, and if the same data stream of 5-tuple in the packet message is called a stream, the window id can solve the problem of insufficient processing capacity of a single heterogeneous processor core in a large bandwidth flow. Optionally, the ESP extension header may include a sender id, and/or a window id, i.e., the ESP extension header may include only a sender id, the ESP may include only a window id, and the ESP may include both a sender id and a window id, which is not limited herein.

(3)Sequence Number。

In the application, the Sequence Number is used for identifying the Sequence Number sent by the message and is used for the message anti-replay function, and occupies 4 bytes or 8 bytes. Optionally, for an encryption algorithm requiring an IV to ensure encryption security, for example, AES-GCM, the IV is converted through a sender id I window id I sequence number combination, and the IV is not carried in a message payload in a clear text, so that the additional encapsulation cost of the message is reduced.

(4)Timestamp。

In the present application, timestamp can be used in the playback-resistant mode, i.e., the playback-resistant capability based on a Timestamp, accounting for 4 bytes. Alternatively, the coding format may be in accordance with IEEE 1588v2 format, and may support 4s playback resistance at maximum. The Timestamp needs the sender and the receiver group to realize NTP time synchronization, and the NTP time synchronization can use the controller as a server, or can select one of the sender and the receiver group as the NTP server for synchronization.

In the application, the relation between the key, the network element and the core id in the actual data encryption process is shown in the following table 2.

	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

Mode two: the DOH header is used to encrypt and integrity process the packet message.

Fig. 8 is another schematic diagram of a target message provided in the present application.

Referring to fig. 8, fig. 8 shows a DOH header for encrypting an IPv6 packet, where the DOH header is used to indicate the message encryption and integrity functions. Optionally, the sender identification, and/or the thread identification may be carried by an optional TLV in the DOH.

Fig. 9 is a schematic diagram of a DOH head according to the present application.

Referring to fig. 9, fig. 9 shows a DOH encapsulation format carrying an encrypted ESP standard or an extended header, wherein the format of the encrypted ESP standard or the extended header is similar to the formats shown in fig. 6 and fig. 7, and details thereof will not be described herein. Furthermore, optional TLV definitions in DOH consider current network device compatibility. The DOH extension header may contain the following parameters:

(1)Option Type。

In the application, the Option Type occupies 8 bits, wherein the two higher bits are 00' b, which means that if the equipment does not know the Option Type, the Option TLV needs to be ignored, and the rest of message content is continuously processed.

(2)Option Data Len。

In the present application, the Option Data Len occupies 8 bits, representing the length of the Option Data portion of this Option TLV.

(3)Opt.DATA。

In the present application, the opt.data may include ESP standard or extension header information. The format of the ESP standard or the extension header is similar to the format shown in fig. 6 and 7, and detailed description thereof will be omitted herein.

In the present application, the step 103 mentioned in the corresponding method example of fig. 4 has a plurality of specific implementations, which will be described in detail in the following examples.

For example, as shown in fig. 2, when the PE1 (network device) encrypts the IPv6 packet, the PE1 receives the original IPv6 packet, and determines whether the original IPv6 packet needs to be encrypted based on the trafic selector. If encryption is not needed, forwarding is carried out according to the normal message forwarding flow. If encryption is needed, an encryption packaging mode is selected according to SA negotiation information.

Encryption mode one: the packet message is encrypted and integrity processed using the ESP header.

In the present application, the network device may optionally encrypt and integrity process the packet using the ESP header, and the process is exemplarily described below.

Fig. 10 is a flowchart of an encryption method provided by the present application.

Referring to fig. 10, in the present application, the PE1 (network device) generates ESP header information according to an ESP standard encapsulation format (e.g., fig. 6) or according to an ESP extension encapsulation format (e.g., fig. 7). The PE1 inserts the format of the generated ESP extension header into the IPv6 original packet message according to the format shown in fig. 5, and defines an encapsulation security load tail padding, padding length according to the 8-byte alignment requirement of the payload part of the IPv6 packet message, and records the original IPv6 extension header Next header. And encrypting or calculating the integrity of the original IPv6 packet message according to the encryption algorithm, the KEY and the message encryption length appointed by the SA. If the message requires integrity protection, an integrity value is calculated and an integrity check value (the Integrity Check Value, ICV) value is appended to the message tail. The Next Header value of the original Ipv6 packet is modified to the ESP Header type value. Recalculate and update IPv6 standard header portion field: IPv6 payload length. And sending the message.

Encryption mode II: the DOH header is used to encrypt and integrity process the packet message.

In the present application, optionally, the network device may use the DOH header to encrypt and integrity process the packet, and the processing procedure is exemplarily described below.

Fig. 11 is a flowchart of an encryption method provided by the present application.

Referring to fig. 11, in the present application, ESP header information is generated according to an ESP standard encapsulation format (fig. 6) or an ESP extension encapsulation format (fig. 7). The DOH message format is generated according to fig. 9 and inserted into the IPv6 original packet message according to the format in fig. 8. According to the 8 byte alignment requirement of the payload part of the Ipv6 packet, defining the encapsulation security payload tail, the payload length, and recording the original Ipv6 extension header Next header. And encrypting or calculating the integrity of the original IPv6 packet message according to the encryption algorithm, the KEY and the message encryption length appointed by the SA. If the message needs integrity protection, calculating an integrity value and attaching an ICV value to the tail of the message. The DOH next header value is modified to be No next header (59). Recalculate and update IPv6 standard header portion field: IPv6 payload length. And sending the message.

In the present application, the step 105 mentioned in the corresponding method example of fig. 4 has a plurality of specific implementations, which will be elaborated in the following examples.

Illustratively, as shown in fig. 2, the target message is received when the target message is decrypted by the pe3 (network device). And determining the boundary Next header=50/144 of the ESP head through the type value of the ESP head in the target message, and decrypting the target message in a decryption mode if the boundary Next header=50/144 of the ESP head is the same as the target message. If not, go to the next step. And analyzing opt.type in DOH to determine a type=DOH optional encryption Type value. If yes, decrypting the target message in a second decryption mode. If not, forwarding is carried out according to the normal message forwarding flow. Two decryption modes are described in detail below.

Decryption mode one: and decrypting the target message through the ESP header.

Fig. 12 is a flowchart of a decryption method according to the present application.

Referring to fig. 12, in the present application, the relevant information is parsed according to the ESP standard package format (fig. 6) or the ESP extended package format (fig. 7). And performing anti-replay processing by using the sender id window id sequence Number. And carrying out integrity calculation on the message by using the KEY and a corresponding algorithm. And verifying whether the ICV value attached to the message is consistent with the calculation integrity value, and if not, discarding the message. And (5) decrypting the message by using the KEY and a corresponding algorithm. And according to the SA attribute, if the message carries the Timestamp anti-replay Loose capability, obtaining the Timestamp and the local time in the message payload to carry out replay judgment. The original Ipv6 packet message related Next Header value is modified to the Next Header in the encapsulation security payload trailer. The message strips ICV tail, package safety load tail and ESP head, and anti-replay Timestamp related information. Recalculate and update IPv6 standard header portion field: IPv6 payload length. And sending the decrypted message.

Fig. 13 is a flowchart of another decryption method according to the present application.

Referring to fig. 13, in the present application, the optional header is extended by DOH to decrypt the IPv6 packet. The relevant information is parsed according to the ESP standard encapsulation format (fig. 6) or the ESP extended encapsulation format (fig. 7). And performing anti-replay processing by using the sender id window id sequence Number. And carrying out integrity calculation on the message by using the KEY and a corresponding algorithm. And according to the SA attribute, if the message carries the Timestamp anti-replay Loose capability, obtaining the Timestamp and the local time in the message payload to carry out replay judgment. And verifying whether the ICV value attached to the message is consistent with the calculation integrity value, and if not, discarding the message. And (5) decrypting the message by using the KEY and a corresponding algorithm. The message strips ICV tail, package safety load tail and ESP head, and anti-replay Timestamp related information. Judging whether the number of DOH option TLVs is 0, and if the number of DOH option TLVs is 0, stripping DOH. Modify the corresponding extension Header Next Header = Next Header in the encapsulation security payload tail. Recalculate and update IPv6 standard header portion field: IPv6 payload length. And sending the decrypted message.

In the present application, optionally, the target packet may include a sequence Number (sequence Number), and the sequence Number, the sender identifier, and/or the thread identifier may together form an IV value, where the IV value may be used to encrypt the packet.

In the present application, it is assumed that the target message includes a sequence number, a sender identifier, and a thread identifier. For an encryption algorithm requiring IV to ensure encryption security, for example, AES-GCM, IV can be converted through a sender id I window id I sequence number combination, and the IV is not carried in a message payload in a plaintext, so that the cost required by message encapsulation is reduced. It will be appreciated that other encryption algorithms may be used to encrypt the packet message, and is not limited in this particular context. This process is specifically described below with an example.

Fig. 14 is a schematic diagram of another playback resistant principle provided by the present application.

Referring to fig. 14, in the present application, for the same SA, a plurality of sequence Number state spaces are established based on { SPI S AN window }. And searching a corresponding sequence Number state space by using { SPI S AN sender id window id } carried in the received encrypted message, performing anti-replay inspection according to the set anti-replay window size, if the inspection is passed, performing the next processing of the message, and if the inspection is not passed, directly discarding the message.

The principle of anti-replay inspection is as follows:

packet_sequence_number < = current_sequence_number, check failed;

packet_sequence_number > current_sequence_number & & packet_sequence_number < = current_sequence_number+window_anti_replay, check pass;

packet_sequence_number > current_sequence_number &packet_sequence_number > current_sequence_number+window_anti_replay, and the check is failed.

Updating the counter of the corresponding sequence Number state space.

The Sequence Number space is updated or deleted with the SA negotiation state.

The foregoing examples provide different embodiments of a message transmission method, and the following provides a network loss device 20, as shown in fig. 15, where the network device 20 is configured to execute the message transmission method related to the foregoing examples, and the executing steps and the corresponding beneficial effects are specifically understood with reference to the foregoing corresponding examples, which are not described herein in detail, and include:

A receiving unit 201, configured to receive a packet;

the processing unit 202 is configured to:

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.

In a possible implementation manner, the target message further includes a thread identifier, where 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.

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

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

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

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

In a possible implementation manner, the target message includes a sequence number, where the sequence number, the sender identifier, and/or the thread identifier are used together to form an IV value, and the IV value is used to encrypt the packet message.

In a possible implementation manner, the target message includes AN SPI and AN, where the SPI and the AN are used together to indicate the security parameter.

It should be noted that, since the content of information interaction, execution process and the like between the modules of the network device 20 is based on the same concept as the method example of the present application, the execution steps thereof are consistent with the details of the method steps described above, and reference may be made to the description at the method example described above.

The foregoing examples provide different embodiments of a network device 20, and the following provides a network loss device 30, as shown in fig. 16, where the network device 30 is configured to perform the packet transmission method related to the foregoing examples, and the performing steps and the corresponding beneficial effects are specifically understood with reference to the foregoing corresponding examples, which are not described herein in detail, and include:

a receiving unit 301, configured to receive a target packet, where the target packet includes a sender identifier, where the sender identifier is used to indicate identity information of a device that sends the target packet;

a processing unit 302, configured to decrypt the target message.

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

It should be noted that, since the content of information interaction, execution process and the like between the modules of the network device 30 is based on the same concept as the method example of the present application, the execution steps thereof are consistent with the details of the method steps described above, and reference may be made to the description at the method example described above.

It should be noted that, because the content of information interaction and execution process between the modules of the apparatus 30 provided in the foregoing embodiment is based on the same concept as the method embodiment of the present application, the technical effects brought by the content are the same as the method embodiment of the present application, and the specific content may be referred to the description in the foregoing illustrated method embodiment of the present application, which is not repeated herein.

Referring to fig. 17, a schematic structural diagram of a network device is provided in the present application, where the network device 40 includes: processor 402, communication interface 403, memory 401. Optionally, a bus 404 may be included. Wherein the communication interface 403, the processor 402 and the memory 401 may be interconnected by a bus 404; bus 404 may be a peripheral component interconnect standard (Peripheral Component Interconnect, PCI) bus, or an extended industry standard architecture (extended industry standard architecture, EISA) bus, among others. The buses may be classified as address buses, data buses, control buses, etc. For ease of illustration, only one thick line is shown in fig. 17, but not only one bus or one type of bus. The network device 40 may implement the functionality of any of the network devices in the examples shown in fig. 15 or 16. Processor 402 and communication interface 403 may perform the operations corresponding to the network devices in the method examples described above.

The following describes the components of the network device in detail with reference to fig. 17:

wherein the memory 401 may be a volatile memory (RAM), such as a random-access memory (RAM); or a nonvolatile memory (non-volatile memory), such as a read-only memory (ROM), a flash memory (flash memory), a hard disk (HDD) or a Solid State Drive (SSD); or a combination of the above-mentioned types of memories for storing program code, configuration files, or other content that may implement the methods of the present application.

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

The communication interface 403 is used to communicate with other network devices.

The processor 402 may perform operations performed by any one of the foregoing network devices in the examples shown in fig. 15 or 16, and detailed descriptions thereof are omitted herein.

It should be noted that, since the content of information interaction, execution process and the like between the modules of the network device 40 is based on the same concept as the method example of the present application, the execution steps thereof are consistent with the details of the method steps described above, and reference may be made to the description at the method example described above.

The present application provides a chip comprising a processor and a communication interface, the processor being coupled to the communication interface, the processor being configured to read instructions to perform operations performed by a network device in the embodiments described above with reference to figures 15 to 17.

The present application provides a network system comprising the network device described in the embodiments described above with reference to fig. 15 to 17.

It will be clear to those skilled in the art that for convenience and brevity of description, specific working procedures of the above-described systems, apparatuses and units may refer to corresponding procedures in the foregoing examples, and are not repeated herein.

In the examples provided herein, it should be understood that the disclosed systems, apparatuses, and methods may be implemented in other ways. For example, the apparatus examples described above are merely illustrative, e.g., the division of the elements is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple elements or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the object of this example.

In addition, each functional unit in each example of the present application may be integrated in one processing unit, each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.

The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be embodied in essence or a part contributing to the prior art or all or part of the technical solution in the form of a software product stored in a storage medium, including several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in the examples of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a read-only memory (ROM), a random access memory (RAM, random access memory), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

While the foregoing embodiments have been described in some detail for purposes of clarity of understanding, it will be appreciated that various embodiments of the application may be practiced otherwise than as specifically described, and that no limitations are intended to the scope of the application, except as may be modified, practiced with respect to any combination, modification, equivalent replacement, or improvement made within the spirit or principles of the application. The above examples are only for illustrating the technical solution of the present application, and are not limiting; although the application has been described in detail with reference to the foregoing examples, it will be appreciated by those of ordinary skill in the art that: the technical scheme recorded in each example can be modified or part of technical features in the technical scheme can be replaced equivalently; such modifications and substitutions do not depart from the essence of the corresponding technical solutions from the scope of the various exemplary technical solutions of the present application.

Claims

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:

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:

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;

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:

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:

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.