Forwarding proof obtaining method and device and forwarding proof verification method and device

Abstract

The embodiment of the invention provides a forwarding certificate obtaining method and device and a forwarding certificate verification method and device, the forwarding certificate is obtained by combining the position of a forwarding node on a forwarding path and the identity of the forwarding node, and position binding of the forwarding certificate is achieved. The forwarding proof is not only related to the identity of the forwarding node, but also related to the position of the forwarding node on the forwarding path. The correct forwarding proof can be calculated by the correct node when the data message is forwarded to the correct position on the forwarding path, so that the forwarding proof and the real forwarding condition of the data message are strongly bound. If nodes in a path are skipped or redundant unspecified nodes are passed in the forwarding process, the identities of the nodes are not corresponding to the positions of the nodes any more, so that the forwarding proof obtained based on the identities of the nodes and the positions of the nodes cannot pass verification, and the credibility of the forwarding proof is improved.

Description

[0001] This application claims priority to Chinese patent application No. 202310784326.7 filed on June 28, 2023, and entitled “Verification Method for Message Forwarding Path Locking and Order-Preserving Forwarding”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of network technology, and in particular to a method for obtaining a forwarding certificate, and a method and device for verifying a forwarding certificate. Background Art

[0003] Forwarding proof refers to a type of data generated during the process of forwarding data messages to verify the forwarding status of data messages. Forwarding proof helps reduce the probability of data messages being tampered with or forged during the forwarding process, thereby improving the transmission security of data messages.

[0004] Currently, if a data packet is not forwarded hop by hop along the specified path, but skips nodes in the forwarding path, or passes through redundant unspecified nodes, the forwarding proof obtained in this scenario can still be verified with a certain probability, which shows that the credibility of the forwarding proof is insufficient. Summary of the invention

[0005] The embodiment of the present application provides a method for obtaining a forwarding certificate, a method for verifying a forwarding certificate, and a device, which can improve the credibility of the forwarding certificate. The technical solution is as follows.

[0006] In a first aspect, a method for obtaining a forwarding proof is provided, the method comprising: a first forwarding node obtains a first data packet, the forwarding path of the first data packet includes at least two forwarding nodes, and the at least two forwarding nodes include a first forwarding node; the first forwarding node obtains location information of the first forwarding node and identity information of the first forwarding node, the location information of the first forwarding node indicates a first position of the first forwarding node on the forwarding path, and the identity information of the first forwarding node indicates the identity of the first forwarding node; the first forwarding node obtains a first forwarding proof based on the location information of the first forwarding node and the identity information of the first forwarding node, the first forwarding proof being used to prove that the first forwarding node is at the first position on the forwarding path.

[0007] Based on the method provided in the first aspect, since the forwarding proof is obtained by combining the position of the forwarding node on the forwarding path and the identity of the forwarding node, the position binding of the forwarding proof is achieved. That is, the forwarding proof is not only related to the identity of the forwarding node, but also to the position of the forwarding node on the forwarding path. Therefore, the correct forwarding proof can be calculated by the correct node when the data message is forwarded to the correct position on the forwarding path, so that the forwarding proof and the actual forwarding situation of the data message are strongly bound. For example, if a node in the path is skipped during the forwarding process, or an extra unspecified node is passed, the identity of the node and the position of the node will no longer correspond to each other. Therefore, the forwarding proof obtained based on the identity of the node and the position of the node cannot be verified, thereby improving the credibility of the forwarding proof.

[0008] In some possible implementations, at least two forwarding nodes also include a second forwarding node, the second forwarding node is an upstream node of the first forwarding node in the forwarding path, and the first forwarding node obtains a first forwarding proof based on location information of the first forwarding node and identity information of the first forwarding node, including: the first forwarding node obtains the first forwarding proof based on the location information of the first forwarding node, the identity information of the first forwarding node, the location information of the second forwarding node, and the identity information of the second forwarding node, the location information of the second forwarding node indicates a second position of the second forwarding node on the forwarding path, and the identity information of the second forwarding node indicates the identity of the second forwarding node.

[0009] Since the forwarding proof is obtained based on the positions and identities of multiple forwarding nodes, the forwarding proof obtained can verify whether multiple nodes are in the corresponding positions on the forwarding path at one time, and use the advantages of batch processing to improve the overall verification performance of the forwarding path, saving the time of calculating and verifying the proof. In addition, this method makes the time spent on obtaining the forwarding proof almost not increase linearly with the increase in the number of nodes in the forwarding path, so it is more suitable for large-scale networking and improves scalability.

[0010] In some possible implementations, the second forwarding node includes at least one node from the first forwarding node on the forwarding path to the previous forwarding node of the first forwarding node on the forwarding path. For example, the second forwarding node includes each node from the first forwarding node on the forwarding path to the previous forwarding node of the first forwarding node on the forwarding path.

[0011] By combining the position and identity of each node in the forwarding path from the head node to the previous node of the current node to obtain the forwarding proof, the position and identity of each node that the message has passed on the forwarding path can be verified at one time, reducing the time and computing costs, improving the efficiency of verification, and making the verification more complete.

[0012] In some possible implementations, after the first forwarding node obtains the first forwarding proof based on the location information of the first forwarding node and the identity information of the first forwarding node, the method further includes: the first forwarding node verifies the first forwarding proof based on the vector commitment, the location information of the first forwarding node, the identity information of the first forwarding node, the location information of the second forwarding node, and the identity information of the second forwarding node, the vector commitment indicating the correspondence between the locations of at least two forwarding nodes and the identities of the at least two forwarding nodes.

[0013] By verifying the forwarding proofs related to multiple nodes based on vector commitment, it is possible to verify at one time whether multiple nodes are in the corresponding correct position in the forwarding path, without having to verify the forwarding proof of each node separately, thereby reducing the number of verifications required for the entire forwarding path and speeding up the verification. At the same time, the scope of verification covers the location and identity of multiple nodes, and also achieves more comprehensive verification.

[0014] In some possible implementations, after the first forwarding node obtains the first forwarding proof based on the location information of the first forwarding node and the identity information of the first forwarding node, the method also includes: the first forwarding node obtains the second data packet based on the first data packet and the first forwarding proof, the first data packet includes payload data, and the second data packet includes the first forwarding proof and the payload data; the first forwarding node sends the second data packet to a third forwarding node, and the third forwarding node is the next node of the first forwarding node on the forwarding path.

[0015] Since the forwarding proof of this node is carried in the data message transmitted from this node to the next node, it is convenient for the next node to verify the source of the data based on the forwarding proof of this node, thereby improving network security. If an attacker hijacks and / or diverts the data message from this node to a device controlled by the attacker and then transfers it back to the downstream node of this node in the forwarding path, the downstream node of this node can identify the problem with the data source based on the failure of verifying the forwarding proof, thereby reducing the risk of further transmission of the attack message.

[0016] In some possible implementations, the first data packet also includes a second forwarding proof, and the first forwarding node obtains the second data packet based on the first data packet and the first forwarding proof, including: the first forwarding node uses the first forwarding proof to replace the second forwarding proof in the first data packet to obtain the second data packet; or, the first forwarding node adds the first forwarding proof to the first data packet to obtain the second data packet.

[0017] By replacing the forwarding proof of the previous hop with the forwarding proof of this node, the message does not need to store the forwarding proof of each node that has passed, thereby avoiding the increase in the number of message bytes occupied by the proof as the number of nodes increases, saving message space. In addition, since the data message only needs to carry the proof of one node during the forwarding process, instead of carrying the proof of multiple nodes, the network resources required for the transmission of proofs are saved.

[0018] In some possible implementations, the second data message further includes a vector commitment indicating a correspondence between a position of the first forwarding node and an identity of the first forwarding node and a correspondence between a position of the second forwarding node and an identity of the second forwarding node.

[0019] By carrying the vector commitment in the data message transmitted from this node to the next node, the next node can verify the source of the data based on the vector commitment, thereby improving network security.

[0020] In some possible implementations, the second data packet includes an Internet Protocol version 6 (IPv6) extension header, and the IPv6 extension header includes a first forwarding proof and a vector commitment, so that it is suitable for scenarios such as IPv6 networks and provides a function of verifying the source of data based on the forwarding proof in the IPv6 network.

[0021] In some possible implementations, the second data packet includes a network service packet header NSH, the NSH includes a metadata field, the metadata field includes a first forwarding proof and a vector commitment, so that it is suitable for scenarios such as business function chains, and is convenient for verifying whether the data packets are forwarded in sequence in the order specified by the business function chain.

[0022] In some possible implementations, the second data packet includes a multi-protocol label switching MPLS header, and the MPLS header includes a first forwarding proof and a vector commitment, so that it is suitable for scenarios such as MPLS protocol communication, and provides a mechanism for verifying the source of data in the MPLS network, so as to facilitate verification of whether the data packets are forwarded in the order specified by the MPLS tunnel.

[0023] In some possible implementations, the second data packet includes a virtualized extended local area network VxLAN header, and the VxLAN header includes a first forwarding proof and a vector commitment, so that it is suitable for scenarios such as virtualized networks based on the VxLAN protocol or cross-data center interconnections, and provides the function of verifying the source of data in the VxLAN tunnel, which facilitates verification of whether the data packets are forwarded in the order specified by the VxLAN tunnel.

[0024] In some possible implementations, the second data packet includes an Internet Protocol security IPsec header, and the IPsec header includes a first forwarding proof and a vector commitment, so that it is suitable for scenarios such as a virtual private network (VPN) or secure communication based on the IPSec protocol, and provides the ability to verify the source of data in the IPSec tunnel, facilitating verification of whether the data packets are forwarded in sequence in the order specified by the IPSec tunnel.

[0025] In some possible implementations, the IPv6 extension header includes a segment routing header SRH, the SRH includes a first type-length-value TLV and a second TLV, the first TLV of the SRH includes a first forwarding proof, and the second TLV of the SRH includes a vector commitment. The IPv6 extension header includes an application-aware network APN message header, the APN message header includes an application-aware network identifier APN ID, and the APNID includes a first forwarding proof and a vector commitment; or, the IPv6 extension header includes a destination option header DOH, the DOH includes a first TLV and a second TLV, the first TLV of the DOH includes a first forwarding proof, and the second TLV of the DOH includes a vector commitment. The IPv6 extension header includes a hop-by-hop option header HBH, the HBH includes a first TLV and a second TLV, the first TLV of the HBH includes a first forwarding proof, and the second TLV of the HBH includes a vector commitment.

[0026] The above methods provide multiple ways to carry forwarding proofs in IPv6 networks, matching more application scenarios.

[0027] In some possible implementations, the first data packet includes a first encrypted routing table entry, and the first forwarding node sends a second data packet to a third forwarding node, including: the first forwarding node uses the key of the first forwarding node to decrypt the first encrypted routing table entry to obtain the identifier of the third forwarding node; the first forwarding node sends the second data packet to the third forwarding node based on the identifier of the third forwarding node; or, the first forwarding node uses the key of the first forwarding node to decrypt the first encrypted routing table entry to obtain the output interface of the first forwarding node; the first forwarding node sends the second data packet based on the output interface of the first forwarding node, and the output interface of the first forwarding node is used to communicate with the third forwarding node.

[0028] Since the identity of the next forwarding node can only be obtained by decrypting the key of this node, the confidentiality of the identity of the next forwarding node is improved. Without the key of a node, the attacker cannot know the next hop node of the node, making it impossible for the attacker to calculate the forwarding proof in advance through the known location and identity of the node, increasing the difficulty of cracking the forwarding proof and further improving network security. Moreover, when the attacker tries to skip a node and directly forward the data to the subsequent node of the node, since the attacker cannot obtain the key of the node, it is impossible to decrypt the identity of the subsequent node, so that the illegal forwarding of the data will be stagnant, which has the effect of passive interception.

[0029] In some possible implementations, the second data packet includes a second encrypted routing table entry, which is encrypted based on the key of the third forwarding node, and the second encrypted routing table entry is used to indicate a sub-forwarding path from the third forwarding node to the fifth forwarding node included in the forwarding path.

[0030] Since the information of the subsequent path of the next node is encrypted based on the key of the next node, the current node cannot know in advance the identity of any subsequent node after the next hop because it does not have the key of the next node. This method makes the structure of the routing table similar to an onion that is peeled off layer by layer. Each layer (a node) can only know the information of the next layer (the next node), but cannot know the information of nodes at a deeper level, thereby achieving path hiding and reducing the possibility of attackers calculating forwarding proofs in advance during transmission, making it impossible for attackers to obtain complete path and identity information from the beginning and calculate forwarding proofs in advance.

[0031] In some possible implementations, the second encrypted routing table entry includes at least one of a node identification ciphertext or an output interface ciphertext, the node identification ciphertext is a ciphertext obtained by encrypting the identification of the fifth forwarding node based on the key of the third forwarding node, the output interface ciphertext is a ciphertext obtained by encrypting the identification of the output interface of the third forwarding node based on the key of the third forwarding node, and the output interface of the third forwarding node is used to communicate with the fifth forwarding node.

[0032] In some possible implementations, the first data packet includes a second forwarding proof, and the first forwarding node obtains the first data packet, including: the first forwarding node receives the first data packet from a second forwarding node, and the second forwarding node is an upstream node of the first forwarding node in the forwarding path; the method also includes: the first forwarding node verifies the second forwarding proof based on a vector commitment, identity information of the second forwarding node, and location information of the second forwarding node, the vector commitment indicating a correspondence between the location of the first forwarding node and the identity of the first forwarding node and a correspondence between the location of the second forwarding node and the identity of the second forwarding node.

[0033] In some possible implementations, the first forwarding node verifies the second forwarding proof based on the vector commitment, the identity information of the second forwarding node, and the location information of the second forwarding node, including: the first forwarding node verifies the second forwarding proof based on the vector commitment, the identity information of the second forwarding node, the location information of the second forwarding node, the identity information of the fourth forwarding node, and the location information of the fourth forwarding node, the fourth forwarding node including at least one node from the head node on the forwarding path to the previous forwarding node of the second forwarding node on the forwarding path.

[0034] By verifying the forwarding proof of the previous hop node based on vector commitment, it is possible to confirm whether the location and identity of the previous hop node correspond, reducing the risk of incorrect data sources. In addition, since the verification of each node is based on the verification of the previous hop, it is equivalent to forming a continuous verification chain, thereby reducing the probability of any hop node in the forwarding path disguising, deceiving or tampering with the data packet, and improving the security of the network.

[0035] In some possible implementations, after the first forwarding node verifies the second forwarding proof based on the vector commitment, the identity information of the second forwarding node, and the location information of the second forwarding node, the method further includes: in response to determining that the second forwarding proof fails the verification, the first forwarding node discards the first data packet or outputs an alarm message; in response to determining that the second forwarding proof passes the verification, the first forwarding node forwards the first data packet.

[0036] By discarding data packets that fail the verification, it prevents the packets with problematic data sources from being further transmitted from this node to the next node, thereby quickly preventing the further spread of data packets with problematic data sources, reducing the probability of unauthorized data access and tampering, reducing the possibility of network attacks, and improving network security. By outputting alarm information, it is convenient for the management plane or control plane to be informed of the failure of verification in a timely manner, reducing the risk of network attacks.

[0037] In some possible implementations, the vector commitment includes at least one of a KZG polynomial commitment, a fast Reed-Solomon interactive algebra FRI commitment, a succinct non-interactive argument of knowledge SNARK proof, an RSA accumulator, a FC function commitment, a Pedersen commitment, a Merkle Tree commitment, or a Walker Tree commitment.

[0038] Since KZG polynomial commitment has a constant time computational complexity when calculating commitment and opening proof, and is almost unaffected by the amount of committed information, it avoids the superlinear growth of the verification time of the forwarding proof as the number of nodes in the forwarding path increases, making the verification time of the forwarding proof as short as possible.

[0039] In some possible implementations, after the first forwarding node obtains the first forwarding proof based on the location information of the first forwarding node and the identity information of the first forwarding node, the method further includes: the first forwarding node sends the first forwarding proof to the verification node.

[0040] By transmitting the forwarding proof to the verification node, it is convenient for the verification node to verify the forwarding proof in real time during the message forwarding process.

[0041] In some possible implementations, the message header in the first data message includes a trusted path identifier, and the trusted path identifier is used to indicate obtaining a forwarding proof, and the first forwarding node obtains the first forwarding proof based on the location information of the first forwarding node and the identity information of the first forwarding node, including: the first forwarding node obtains the first forwarding proof based on the location information of the first forwarding node and the identity information of the first forwarding node in response to identifying the trusted path identifier in the first data message.

[0042] In some possible implementations, the message header in the first data message includes an IPv6 basic header, the destination address field of the IPv6 basic header includes a segment identifier SID of the first forwarding node, and the SID of the first forwarding node includes a trusted path identifier.

[0043] By including a trusted path identifier in the message header of a data message, the forwarding node is supported to decide whether to generate a forwarding proof based on the presence or absence of the identifier. This eliminates the need to generate a forwarding proof for each data message, and eliminates the need to pre-configure on the forwarding node which messages need to generate a forwarding proof. This simplifies the configuration process and reduces configuration complexity.

[0044] In some possible implementations, the SID of the first forwarding node includes a function field, which includes a trusted path identifier; or the SID of the first forwarding node includes a parameter field, which includes a trusted path identifier.

[0045] Since the trusted path identifier is carried in the SID, it is more suitable for SRv6 scenarios. For example, the SID carried in the SRv6 encapsulation can be reused. There is no need to add additional fields or message headers to the message to carry the trusted path identifier, which helps to simplify the message format and reduce the overhead of transmitting messages.

[0046] In some possible implementations, the identity information of the first forwarding node includes an address, a certificate, a public key, a segment identifier SID, a multi-protocol label switching MPLS label, an access control token token, a router identifier router ID or a host name.

[0047] By using publicly verifiable identity information to calculate and verify forwarding proofs, the difficulty of obtaining identity information is reduced, thereby reducing the complexity of calculating and verifying forwarding proofs based on identity information.

[0048] In some possible implementations, the identity information of the first forwarding node includes at least one item of identity information encrypted based on a key of the first forwarding node.

[0049] By using encrypted identity information to calculate or verify the forwarding proof, the security and privacy of the calculation and verification of the forwarding proof are further improved due to the higher security and privacy of the identity information.

[0050] In some possible implementations, the identity information obtained by encryption based on the key of the first forwarding node includes at least one of a signature, a message authentication code MAC tag, a zero-knowledge NIZK proof, or a Sigma protocol proof.

[0051] By using NIZK proof as identity information to calculate forwarding proof and verify forwarding proof, the true identity of the forwarding node can be hidden, reducing the probability of the true identity of the forwarding node being leaked. At the same time, it supports the verification of NIZK proof as identity information, thereby further reducing the probability of forwarding proof being tampered with and forged, and enhancing the security and credibility of forwarding proof.

[0052] In some possible implementations, the forwarding path includes a service function chain, and at least one forwarding node includes a service function SF node in the service function chain; or, the forwarding path includes a segment list path, and at least two forwarding nodes include segment routing SR endpoints in the segment list path; the forwarding path includes a label switching path, and at least two forwarding nodes include a label switching router LSR in the label switching path.

[0053] Through the above method, it supports application in scenarios such as service function chain, SRv6 and MPLS that require data packets to be forwarded in a certain order.

[0054] In a second aspect, a method for verifying a forwarding proof is provided, the method comprising: a verification node obtains a vector commitment, identity information of a first forwarding node, location information of the first forwarding node, and a first forwarding proof, the location information of the first forwarding node indicating a first position of the first forwarding node on a forwarding path, the forwarding path comprising at least two forwarding nodes, the at least two forwarding nodes including the first forwarding node, the identity information of the first forwarding node being used to indicate the identity of the first forwarding node, the vector commitment indicating a correspondence between the position of the first forwarding node and the identity of the first forwarding node, the first forwarding proof being used to prove that the first forwarding node is at the first position on the forwarding path; the verification node verifies the first forwarding proof based on the vector commitment, the identity information of the first forwarding node, and the location information of the first forwarding node.

[0055] Since the forwarding proof is verified by combining the vector commitment, the position of the forwarding node on the forwarding path, and the identity of the forwarding node, if a node in the path is skipped or an extra unspecified node is passed during the forwarding process, the identity of the node and the position of the node will no longer correspond to each other. Therefore, the forwarding proof obtained based on the identity of the node and the position of the node cannot be verified.

[0056] In some possible implementations, at least two forwarding nodes also include a second forwarding node, the second forwarding node is an upstream node of the first forwarding node included in the forwarding path, and the verification node verifies the first forwarding proof based on the vector commitment, the identity information of the first forwarding node, and the location information of the first forwarding node, including: the verification node verifies the first forwarding proof based on the vector commitment, the location information of the first forwarding node, the identity information of the first forwarding node, the location information of the second forwarding node, and the identity information of the second forwarding node, and the vector commitment also indicates the correspondence between the location of the second forwarding node and the identity of the second forwarding node.

[0057] Since the forwarding proof is based on the location of multiple forwarding nodes and the identity authentication forwarding proof of multiple forwarding nodes, it is possible to verify whether multiple nodes are in the corresponding position on the forwarding path at one time, and use the advantages of batch processing to improve the overall verification performance of the forwarding path, saving the time of calculating proof and verifying proof. In addition, this method makes the time spent on verifying the forwarding proof almost not increase linearly with the increase in the number of nodes in the forwarding path, so it is more suitable for large-scale networking and improves scalability.

[0058] According to a third aspect, a method for verifying a forwarding proof is provided, the method comprising: a controller obtaining identity information of a first forwarding node, location information of the first forwarding node, identity information of a second forwarding node and location information of the second forwarding node, the identity information of the first forwarding node being used to indicate the identity of the first forwarding node, the location information of the first forwarding node being used to indicate the location of the first forwarding node on a forwarding path, the identity information of the second forwarding node being used to indicate the identity of the second forwarding node, the location information of the second forwarding node being used to indicate the location of the second forwarding node on a forwarding path, the forwarding path comprising the first forwarding node and the second forwarding node; the controller obtaining a vector commitment based on the identity information of the first forwarding node, the location information of the first forwarding node, the identity information of the second forwarding node and the location information of the second forwarding node, the vector commitment indicating a correspondence between the location of the first forwarding node and the identity of the first forwarding node and a correspondence between the location of the second forwarding node and the identity of the second forwarding node, the vector commitment being used to verify the forwarding proof.

[0059] Since the vector commitment is obtained based on the identity information of the forwarding node and the location information of the forwarding node, the vector commitment is related to both the identity information and the location information of the forwarding node. The vector commitment can reflect the correspondence between the location information and the identity information of the forwarding node on the forwarding path. Therefore, when verifying the forwarding proof based on the vector commitment, the identity information, location information and forwarding proof must correspond to each other to pass the verification. The forwarding proof obtained when the identity information and location information do not correspond will cause the verification to fail. In addition, since the vector commitment itself is in the form of ciphertext, the identity information and location information of the forwarding node contained therein cannot be directly obtained through the vector commitment itself, and it is also difficult to decrypt or reverse the vector commitment to obtain the identity information and location information of the forwarding node, thereby hiding the identity information and location information of the forwarding node on the forwarding path, thereby improving the privacy and confidentiality of the identity information and location information of the forwarding node.

[0060] In some possible implementations, after the controller obtains the vector commitment based on the identity information of at least two forwarding nodes and the location information of at least two forwarding nodes, the method further includes: the controller sends the vector commitment to the first forwarding node, the second forwarding node, or the verification node; or, the controller saves the correspondence between the identifier of the forwarding path and the vector commitment to a database.

[0061] By sending the vector commitment to the forwarding node and the verification node or saving it in a database, the forwarding node and the verification node can obtain the vector commitment and use the vector commitment to verify the forwarding proof.

[0062] In a fourth aspect, a device for obtaining a forwarding proof is provided, which is arranged at a first forwarding node and includes: an obtaining unit, used to obtain a first data packet, the forwarding path of the first data packet includes at least two forwarding nodes, and the at least two forwarding nodes include a first forwarding node; obtaining location information of the first forwarding node and identity information of the first forwarding node, the location information of the first forwarding node indicating a first position of the first forwarding node on the forwarding path, and the identity information of the first forwarding node indicating the identity of the first forwarding node; a processing unit, used to obtain a first forwarding proof based on the location information of the first forwarding node and the identity information of the first forwarding node, the first forwarding proof being used to prove that the first forwarding node is at the first position on the forwarding path.

[0063] In some possible implementations, at least two forwarding nodes also include a second forwarding node, which is an upstream node of the first forwarding node in the forwarding path, and a processing unit is used to obtain a first forwarding proof based on location information of the first forwarding node, identity information of the first forwarding node, location information of the second forwarding node, and identity information of the second forwarding node, the location information of the second forwarding node indicates a second position of the second forwarding node on the forwarding path, and the identity information of the second forwarding node indicates the identity of the second forwarding node.

[0064] In some possible implementations, the second forwarding node includes at least one node from the first forwarding node on the forwarding path to the previous forwarding node of the first forwarding node on the forwarding path.

[0065] In some possible implementations, the device also includes: a verification unit, configured to verify the first forwarding proof based on a vector commitment, location information of the first forwarding node, identity information of the first forwarding node, location information of the second forwarding node, and identity information of the second forwarding node, wherein the vector commitment indicates a correspondence between locations of at least two forwarding nodes and identities of at least two forwarding nodes.

[0066] In some possible implementations, the acquisition unit is also used by the first forwarding node to obtain a second data packet based on the first data packet and the first forwarding proof, the first data packet includes payload data, and the second data packet includes the first forwarding proof and the payload data; the device also includes: a sending unit, used to send the second data packet, and the third forwarding node is the next node of the first forwarding node on the forwarding path.

[0067] In some possible implementations, the first data packet also includes a second forwarding proof, and the acquisition unit is used to use the first forwarding proof to replace the second forwarding proof in the first data packet to obtain the second data packet; or, add the first forwarding proof to the first data packet to obtain the second data packet.

[0068] In some possible implementations, the second data message further includes a vector commitment indicating a correspondence between a position of the first forwarding node and an identity of the first forwarding node and a correspondence between a position of the second forwarding node and an identity of the second forwarding node.

[0069] In some possible implementations, the second data packet includes an Internet Protocol version 6 (IPv6) extension header, and the IPv6 extension header includes a first forwarding proof and a vector commitment; or,

[0070] The second data packet includes a network service header NSH, the NSH includes a metadata field, and the metadata field includes a first forwarding proof and a vector commitment; or,

[0071] The second data packet includes a multi-protocol label switching MPLS header, and the MPLS header includes a first forwarding proof and a vector commitment; or,

[0072] The second data message includes a virtualized extended local area network VxLAN header, and the VxLAN header includes a first forwarding proof and a vector commitment; or,

[0073] The second data packet includes an Internet Protocol security IPsec header, and the IPsec header includes a first forwarding proof and a vector commitment.

[0074] In some possible implementations, the IPv6 extension header includes a segment routing header SRH, the SRH includes a first type-length-value TLV and a second TLV, the first TLV of the SRH includes a first forwarding proof, and the second TLV of the SRH includes a vector commitment; or

[0075] The IPv6 extension header includes an application-aware network APN message header, the APN message header includes an application-aware network identifier APNID, and the APN ID includes a first forwarding proof and a vector commitment; or,

[0076] The IPv6 extension header includes a destination option header DOH, the DOH includes a first TLV and a second TLV, the first TLV of the DOH includes a first forwarding proof, and the second TLV of the DOH includes a vector commitment; or,

[0077] The IPv6 extension header includes a hop-by-hop options header HBH, the HBH includes a first TLV and a second TLV, the first TLV of the HBH includes a first forwarding proof, and the second TLV of the HBH includes a vector commitment; or.

[0078] In some possible implementations, the first data message includes a first encrypted routing table entry, and a sending unit is used to decrypt the first encrypted routing table entry using a key of the first forwarding node to obtain an identifier of a third forwarding node; the first forwarding node sends a second data message to the third forwarding node based on the identifier of the third forwarding node; or, the first encrypted routing table entry is decrypted using the key of the first forwarding node to obtain an output interface of the first forwarding node; the first forwarding node sends the second data message based on the output interface of the first forwarding node, and the output interface of the first forwarding node is used to communicate with the third forwarding node.

[0079] In some possible implementations, the second data packet includes a second encrypted routing table entry, which is encrypted based on the key of the third forwarding node, and the second encrypted routing table entry is used to indicate a sub-forwarding path from the third forwarding node to the fifth forwarding node included in the forwarding path.

[0080] In some possible implementations, the second encrypted routing table entry includes at least one of a node identification ciphertext or an output interface ciphertext, the node identification ciphertext is a ciphertext obtained by encrypting the identification of the fifth forwarding node based on the key of the third forwarding node, the output interface ciphertext is a ciphertext obtained by encrypting the identification of the output interface of the third forwarding node based on the key of the third forwarding node, and the output interface of the third forwarding node is used to communicate with the fifth forwarding node.

[0081] In some possible implementations, the first data packet includes a second forwarding proof, and the acquisition unit is used to receive the first data packet from a second forwarding node, where the second forwarding node is an upstream node of the first forwarding node in the forwarding path; the processing unit is also used to verify the second forwarding proof based on a vector commitment, identity information of the second forwarding node, and position information of the second forwarding node, the vector commitment indicating a correspondence between the position of the first forwarding node and the identity of the first forwarding node and a correspondence between the position of the second forwarding node and the identity of the second forwarding node.

[0082] In some possible implementations, the processing unit is configured to verify the second forwarding proof based on the vector commitment, the identity information of the second forwarding node, the location information of the second forwarding node, the identity information of the fourth forwarding node, and the location information of the fourth forwarding node, where the fourth forwarding node includes at least one node from the head node on the forwarding path to the previous forwarding node of the second forwarding node on the forwarding path.

[0083] In some possible implementations, the processing unit is further used to discard the first data packet or output an alarm message in response to determining that the second forwarding proof fails verification; in response to determining that the second forwarding proof passes verification, instruct the sending unit to forward the first data packet.

[0084] In some possible implementations, the vector commitment includes at least one of a KZG polynomial commitment, a fast Reed-Solomon interactive algebra FRI commitment, a succinct non-interactive argument of knowledge SNARK proof, an RSA accumulator, a FC function commitment, a Pedersen commitment, a Merkle Tree commitment, or a Walker Tree commitment.

[0085] In some possible implementations, the apparatus further includes: a sending unit, configured to send a first forwarding certificate to a verification node.

[0086] In some possible implementations, the message header in the first data message includes a trusted path identifier, and the trusted path identifier is used to indicate obtaining a forwarding certificate. The processing unit is used to obtain a first forwarding certificate based on location information of a first forwarding node and identity information of the first forwarding node in response to identifying the trusted path identifier in the first data message.

[0087] In some possible implementations, the message header in the first data message includes an IPv6 basic header, the destination address field of the IPv6 basic header includes a segment identifier SID of the first forwarding node, and the SID of the first forwarding node includes a trusted path identifier.

[0088] In some possible implementations, the SID of the first forwarding node includes a function field, and the function field includes a trusted path identifier; or,

[0089] The SID of the first forwarding node includes a parameter field, and the parameter field includes a trusted path identifier.

[0090] In some possible implementations, the identity information of the first forwarding node includes at least one of an address, a certificate, a public key, a segment identifier SID, a multi-protocol label switching MPLS label, an access control token token, a router identifier router ID, a host name, or identity information encrypted based on a key of the first forwarding node.

[0091] In some possible implementations, the identity information obtained by encryption based on the key of the first forwarding node includes at least one of a signature, a message authentication code MAC tag, a zero-knowledge NIZK proof, or a Sigma protocol proof.

[0092] In some possible implementations, the forwarding path includes a service function chain, and the at least one forwarding node includes a service function SF node in the service function chain; or,

[0093] The forwarding path includes a segment list path, and at least two forwarding nodes include segment routing SR endpoints in the segment list path;

[0094] The forwarding path includes a label switching path, and the at least two forwarding nodes include a label switching router LSR in the label switching path.

[0095] In a fifth aspect, a forwarding proof verification device is provided, the device comprising:

[0096] an acquisition unit, configured to acquire a vector commitment, identity information of a first forwarding node, location information of the first forwarding node, and a first forwarding proof, wherein the location information of the first forwarding node indicates a first location of the first forwarding node on a forwarding path, the forwarding path includes at least two forwarding nodes, the at least two forwarding nodes include the first forwarding node, the identity information of the first forwarding node is used to indicate an identity of the first forwarding node, the vector commitment indicates a corresponding relationship between the location of the first forwarding node and the identity of the first forwarding node, and the first forwarding proof is used to prove that the first forwarding node is at the first location on the forwarding path;

[0097] A verification unit is used to verify the first forwarding proof based on the vector commitment, the identity information of the first forwarding node, and the location information of the first forwarding node.

[0098] In some possible implementations, at least two forwarding nodes also include a second forwarding node, where the second forwarding node is an upstream node of the first forwarding node included in the forwarding path, and the verification unit is used to verify the first forwarding proof based on the vector commitment, the location information of the first forwarding node, the identity information of the first forwarding node, the location information of the second forwarding node, and the identity information of the second forwarding node, and the vector commitment also indicates the correspondence between the location of the second forwarding node and the identity of the second forwarding node.

[0099] In a sixth aspect, a forwarding proof verification device is provided, the device comprising:

[0100] an acquisition unit, for obtaining identity information of a first forwarding node, location information of the first forwarding node, identity information of a second forwarding node, and location information of the second forwarding node, wherein the identity information of the first forwarding node is used to indicate the identity of the first forwarding node, the location information of the first forwarding node is used to indicate the location of the first forwarding node on a forwarding path, the identity information of the second forwarding node is used to indicate the identity of the second forwarding node, and the location information of the second forwarding node is used to indicate the location of the second forwarding node on the forwarding path, and the forwarding path includes the first forwarding node and the second forwarding node;

[0101] A processing unit is used to obtain a vector commitment based on the identity information of the first forwarding node, the position information of the first forwarding node, the identity information of the second forwarding node, and the position information of the second forwarding node, the vector commitment indicating the correspondence between the position of the first forwarding node and the identity of the first forwarding node and the correspondence between the position of the second forwarding node and the identity of the second forwarding node, and the vector commitment is used to verify the forwarding proof.

[0102] In some possible implementations, the device further includes: a sending unit, configured to control the controller to send the vector commitment to the first forwarding node, the second forwarding node, or the verification node; or a saving unit, configured to save the correspondence between the identifier of the forwarding path and the vector commitment to a database.

[0103] In a seventh aspect, a computing device is provided, the computing device comprising a processor, the processor being coupled to a memory, the memory storing at least one computer program instruction, the at least one computer program instruction being loaded and executed by the processor, so that the computing device performs the method provided in the first aspect or any optional manner of the first aspect, and the network interface is used to receive or send a message. The specific details of the computing device provided in the seventh aspect can be found in the first aspect or any optional manner of the first aspect, and will not be repeated here.

[0104] In an eighth aspect, a computing device is provided, the computing device comprising a processor, the processor being coupled to a memory, the memory storing at least one computer program instruction, the at least one computer program instruction being loaded and executed by the processor, so that the computing device implements the method provided in the second aspect or any optional manner of the second aspect. The specific details of the computing device provided in the eighth aspect can be found in the second aspect or any optional manner of the second aspect, and will not be repeated here.

[0105] In a ninth aspect, a computing device is provided, the computing device comprising a processor, the processor being coupled to a memory, the memory storing at least one computer program instruction, the at least one computer program instruction being loaded and executed by the processor, so that the computing device implements the method provided in the third aspect or any optional manner of the third aspect. The specific details of the computing device provided in the ninth aspect can be found in the third aspect or any optional manner of the third aspect, and will not be repeated here.

[0106] In a tenth aspect, a computer-readable storage medium is provided, wherein at least one instruction is stored in the storage medium. When the instruction is executed on a computer, the computer executes the method provided in the first aspect or any optional manner of the first aspect.

[0107] In the eleventh aspect, a computer-readable storage medium is provided, wherein at least one instruction is stored in the storage medium. When the instruction is executed on a computer, the computer executes the method provided in the second aspect or any optional manner of the second aspect.

[0108] In the twelfth aspect, a computer-readable storage medium is provided, wherein the storage medium stores at least one instruction, and when the instruction is executed on a computer, the computer executes the method provided in the third aspect or any optional manner of the third aspect.

[0109] In the thirteenth aspect, a computer program product is provided, which includes one or more computer program instructions. When the computer program instructions are loaded and executed by a computer, the computer executes the method provided by the first aspect or any optional method of the first aspect.

[0110] In a fourteenth aspect, a computer program product is provided, which includes one or more computer program instructions. When the computer program instructions are loaded and executed by a computer, the computer executes the method provided by the second aspect or any optional manner of the second aspect.

[0111] In the fifteenth aspect, a computer program product is provided, which includes one or more computer program instructions. When the computer program instructions are loaded and executed by a computer, the computer executes the method provided by the third aspect or any optional method of the third aspect.

[0112] In the sixteenth aspect, a chip is provided, comprising a memory and a processor, wherein the memory is used to store computer instructions, and the processor is used to call and run the computer instructions from the memory to execute the method in the above-mentioned first aspect and any possible implementation of the first aspect.

[0113] In the seventeenth aspect, a chip is provided, comprising a memory and a processor, wherein the memory is used to store computer instructions, and the processor is used to call and run the computer instructions from the memory to execute the method in the above-mentioned second aspect and any possible implementation of the second aspect.

[0114] In the eighteenth aspect, a chip is provided, comprising a memory and a processor, wherein the memory is used to store computer instructions, and the processor is used to call and run the computer instructions from the memory to execute the method in the above-mentioned third aspect and any possible implementation of the third aspect.

[0115] In the nineteenth aspect, a network system is provided, which includes the apparatus of the fourth aspect, the apparatus of the fifth aspect and the apparatus of the sixth aspect.

[0116] In the twentieth aspect, a network system is provided, which includes the apparatus of the seventh aspect, the apparatus of the eighth aspect and the apparatus of the ninth aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0117] Figure 1 This is a schematic diagram of a verification scenario of forwarding proof in a real-time verification mode provided by an embodiment of the present application;

[0118] Figure 2 It is a schematic diagram of a method for obtaining and verifying a forwarding certificate in a real-time verification mode provided by an embodiment of the present application;

[0119] Figure 3 This is a schematic diagram of a verification scenario of forwarding proof in an on-path verification mode provided by an embodiment of the present application;

[0120] Figure 4 It is a schematic diagram of a method for obtaining and verifying a forwarding certificate in a path-by-path verification mode provided by an embodiment of the present application;

[0121] Figure 5 This is a schematic diagram of a verification scenario of forwarding proof in an endpoint verification mode provided by an embodiment of the present application;

[0122] Figure 6 It is a schematic diagram of a method for obtaining and verifying a forwarding certificate in an end point verification mode provided by an embodiment of the present application;

[0123] Figure 7 This is a schematic diagram of a business function chain scenario provided by an embodiment of the present application;

[0124] Figure 8 This is a schematic diagram of a message encapsulation format in a service function chain scenario provided by an embodiment of the present application;

[0125] Fig. 9 This is a schematic diagram of a verification scenario of a forwarding certificate in a path-by-path verification mode in a business function chain scenario provided by an embodiment of the present application;

[0126] Fig.10 This is a schematic diagram of a message encapsulation format in an SRv6 scenario provided in an embodiment of the present application;

[0127] Fig.11 It is a schematic diagram of a method for obtaining and verifying a forwarding certificate in a path-by-path verification mode in an SRv6 scenario provided by an embodiment of the present application;

[0128] Fig.12 This is a schematic diagram of a verification scenario of a forwarding certificate in an endpoint verification mode in an SRv6 scenario provided by an embodiment of the present application;

[0129] Fig.13It is a structural diagram of a device for obtaining a forwarding certificate provided in an embodiment of the present application;

[0130] Fig.14 It is a structural diagram of a verification device for forwarding proof provided in an embodiment of the present application;

[0131] Fig.15 It is a structural diagram of a verification device for forwarding proof provided in an embodiment of the present application;

[0132] Fig.16 It is a structural diagram of a computing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0133] In order to make the objectives, technical solutions and advantages of the present application clearer, the implementation methods of the present application will be further described in detail below with reference to the accompanying drawings.

[0134] The following is an example of an application scenario of the embodiment of the present application.

[0135] In the routing security scenario, existing network attacks include route hijacking, route injection, and traffic detour. Route hijacking refers to the attacker hijacking and / or diverting network traffic to a network device or autonomous system (AS) controlled by the attacker out of subjective malice, and then monitoring, tampering, or intercepting it. Route hijacking is often called prefix hijacking or Internet Protocol (IP) hijacking. Another possible non-subjective malicious cause of route hijacking is network misconfiguration. Route injection refers to inputting forged routing information into network devices such as routers, so that the forged routing information spreads throughout the network. An attacker can change the routing path of the network through route injection, causing traffic to be redirected to a path controlled by the attacker. Traffic detour refers to an attacker tampering with the configuration of network devices to detour traffic from the expected path, causing traffic to be redirected to a path specified by the attacker. This attack can be used to bypass security measures or implement specific network attacks.

[0136] Regardless of whether it is out of subjective malice or non-malice, the main goal of the trusted path mechanism (also called secure routing mechanism or path validation mechanism) is to solve the problem of network attacks, ensure that data packets can and can only be forwarded hop by hop according to the forwarding path planned by the network controller or terminal, and provide publicly verifiable forwarding proof. The trusted path mechanism is a key supporting technology to ensure routing security at all levels of the Internet and to realize cutting-edge architectures and applications in the network field, including path-aware networking (PAN) and application-aware networking (APN). The current trusted path mechanism has certain limitations in security. As a result, routing security issues are still an international open network security problem.

[0137] A complete trusted path mechanism includes two technical parts: path locking mechanism and path verification mechanism. Path locking, also known as path binding, refers to a mechanism that can ensure that data packets are forwarded along a certain forwarding path. Path verification refers to a mechanism that can verify whether data packets are forwarded along a specified forwarding path.

[0138] If a non-cryptographic traversal proof is used to implement path locking, for example, the head node adds a field with an initial value to the header of the data message, and then each forwarding node passed by adds the identity information of the forwarding node to the message, that is, the identity information of all forwarding nodes is used as a forwarding proof. Since the forwarding proof has no strong binding relationship with the position of the forwarding node on the forwarding path, it is impossible to generate a forwarding proof with strong position binding. For example, it is impossible to achieve that only the node at the i-th position on the forwarding path can generate the i-th proof, resulting in poor credibility of the forwarding proof, and it is very easy to forge and tamper with the forwarding proof. For example, if the data message is not forwarded hop by hop along the specified path, but skips the nodes in the forwarding path, or passes through redundant unspecified nodes, the forwarding proof obtained in this scenario can still pass the verification with a certain probability, which shows that the credibility of the forwarding proof is insufficient. Moreover, even if the data message carries the proof of all nodes on this path, since the proof is independent of the position of the forwarding node on the forwarding path, it cannot be guaranteed that the data is definitely forwarded along this path. For example, the traversal proof may be added by a device outside the forwarding path after the message forwarding is completed. In other words, there is no strong binding relationship between the forwarding proof and the actual message forwarding situation, which results in data messages being forwarded arbitrarily and then being given a forged traversal proof, and the traversal proof obtained at the end point is unreliable.

[0139] If path locking is achieved by using cryptographic traversal credentials, for example, each forwarding node establishes a key pair with the controller, and then each routing node uses cryptography to generate an identity-bound certificate, and then passes the certificate. Although the problem of counterfeiting has been slightly improved, the position of the forwarding node on the forwarding path is not considered when obtaining the forwarding certificate, and a forwarding certificate with strong position binding cannot be generated, resulting in the same problem as the non-cryptographic traversal proof method: the forwarding certificate is disconnected from the actual forwarding situation of the data message, and there is no strong binding relationship. The data message can be forwarded arbitrarily and then colluded with the forwarding node, and a forged traversal certificate is added to the tail node, resulting in the traversal certificate obtained from the tail node being unreliable. During the transit process, it cannot be guaranteed that the forwarding will be forwarded according to the specified forwarding path.

[0140] In view of this, in order to solve the problem of poor credibility of the proof due to the irrelevance of the forwarding proof to the position of the forwarding node on the forwarding path in the path locking mechanism, in some embodiments of the present application, the forwarding proof is obtained and verified by combining the position of the forwarding node on the forwarding path and the identity of the forwarding node, thereby realizing the position binding of the forwarding proof. That is, the forwarding proof is no longer only related to the identity of the forwarding node, but also to the position of the forwarding node on the forwarding path, so that the correct forwarding proof can be calculated by the correct node when the data message is forwarded to the correct position on the forwarding path, so that the forwarding proof and the actual forwarding situation of the data message have strong binding, and the forwarding proof has public verifiability that is difficult to tamper with.

[0141] The correctness of the position means that the position of each forwarding node in the forwarding path that the data message actually passes through during the forwarding process is the same as the expected position of each forwarding node in the selected forwarding path.

[0142] The correctness of the forwarding proof means that the forwarding proof obtained based on the identity of the node and the position of the node can be verified under the condition that the identity of the node and the position of the node correspond to each other. For example, the forwarding proof p_i calculated by node i at position i in the forwarding path is correct, and the forwarding proof p_i can be verified, i is a positive integer, i is less than or equal to N, N represents the total number of forwarding nodes in the forwarding path, and N is a positive integer greater than or equal to 2. If the condition that the identity of the node and the position of the node do not correspond to each other is not met, the forwarding proof obtained based on the identity of the node and the position of the node cannot be verified. For example, if a node in the path is skipped or an extra unspecified node is passed during the forwarding process, the identity of the node and the position of the node will no longer correspond to each other, so the forwarding proof obtained based on the identity of the node and the position of the node cannot be verified.

[0143] For example, if the selected forwarding path is forwarding node A→forwarding node B→forwarding node C→forwarding node D, the correct position of forwarding node A is 1, the correct position of forwarding node B is 2, the correct position of forwarding node C is 3, and the correct position of forwarding node D is 4. If the data message is indeed forwarded hop by hop along the path, the forwarding proof 1 obtained based on at least one of the identity of forwarding node A and the correct position of forwarding node A (1), the identity of forwarding node B and the correct position of forwarding node B (2), the identity of forwarding node C and the correct position of forwarding node C (3), or the identity of forwarding node D and the correct position of forwarding node D (4) is correct and can pass the verification. If forwarding node C is skipped during the forwarding process, the actual forwarding path 2 is forwarding node A→forwarding node B→forwarding node D. Taking forwarding node D as an example, forwarding node D obtains forwarding proof 2 based on position (3) and identity (D). Since the position (3) and identity (D) on which forwarding proof 2 is based do not match, forwarding proof 2 cannot pass the verification based on vector commitment. For another example, in the case of passing through an extra unspecified node, an extra node e is added to forwarding path 1, and the actual forwarding path 2 is forwarding node A→forwarding node B→forwarding node C→forwarding node E→forwarding node D. If the position (5) and identity (D) of forwarding node D on forwarding path 2 are used to calculate forwarding proof 2, and the commitment generated at the beginning is used for verification, because the position (5) and identity (D) on which forwarding proof 2 is based do not match, forwarding proof 2 cannot pass verification.

[0144] For the sake of simplicity, the embodiments of the present application will use i to represent the specific position of the node on the forwarding path, N represents the number of forwarding nodes included in the forwarding path, r_i represents the identity information of the node at position i on the forwarding path, p_i represents the forwarding proof generated by the node at position i on the forwarding path, C represents commitment, P represents the forwarding path, B represents a section in the forwarding path, that is, a set of at least two nodes in the forwarding path, OP (opening proof) represents the forwarding proof related to a single forwarding node (hereinafter referred to as a single-point forwarding proof). MP (multi proof) represents the forwarding proof related to multiple forwarding nodes (hereinafter referred to as a multi-point forwarding proof). In addition, the form of "forwarding node + underscore + position" is used to simplify the representation of specific nodes on the forwarding path, such as forwarding node_i represents the forwarding node at position i on the forwarding path. The form of "OP+underscore+position" is used to simplify the representation of the single-point forwarding proof obtained by the node, such as OP_i represents the single-point forwarding proof obtained by the forwarding node at position i on the forwarding path. The form of "MP+underscore+position" is used to simplify the representation of the multi-point forwarding proof obtained by the node, such as MP_i represents the multi-point forwarding proof obtained by the forwarding node at position i on the forwarding path.

[0145] In one possible implementation, after forwarding node_i obtains the data message, forwarding node_i obtains the location information of forwarding node_i and the identity information of forwarding node_i; forwarding node_i obtains forwarding proof r_i based on the location information of forwarding node_i and the identity information of forwarding node_i, and forwarding proof r_i is used to prove that forwarding node_i is at position i on the forwarding path.

[0146] The identity information of the forwarding node_i indicates the identity of the forwarding node_i. The identity information of the forwarding node_i is, for example, the identifier of the forwarding node_i. The position information of the forwarding node_i indicates the position i of the forwarding node_i on the forwarding path of the data message. The position information of the forwarding node_i is, for example, the sequence number of the forwarding node_i. The position information can be optionally expressed in the form of a positive integer, such as the position information of the head node is 1, the position information of the second forwarding node is 2, the position information of the third forwarding node is 3, and so on.

[0147] Optionally, the size order of the position information of different forwarding nodes indicates the front and back order of the forwarding nodes on the forwarding path. For example, the smaller the position information of the forwarding node, the closer the position of the forwarding node is to the upstream of the forwarding path, and the larger the position information of the forwarding node, the closer the position of the forwarding node is to the downstream of the forwarding path. Exemplarily, the forwarding path includes n nodes, n is a positive integer greater than or equal to 2, the position information of the first node (head node) on the forwarding path is 1, the position information of the i-th node on the forwarding path is i, and the position information of the n-th node (tail node) on the forwarding path is n.

[0148] In one possible implementation, the forwarding proof is obtained and verified based on the vector commitment technology. Since the vector commitment has the property of order preservation, that is, the information m_i of the commitment and the open proof must be bound to the position i, the acquisition and verification of the forwarding proof with position binding can be achieved.

[0149] Vector commitment is a cryptographic technique used to prove the correctness of the value and position of each piece of information in a set of ordered information (such as a vector, array, or list containing at least two elements), while supporting the hiding of the information, usually without exposing the original content of the information. Specifically, vector commitment allows each piece of information in a set of ordered information to be committed and generate a corresponding proof, which other participants can verify to confirm the integrity of the ordered information.

[0150] Vector commitment mainly includes three functions: commit function, open function and verify function.

[0151] The commitment function means that entity A secretly selects N sequential information M = (m_1, m_2, ..., m_N) at one time, then calculates a commitment based on information M and makes the commitment public. The commitment contains the sequential relationship between information M and the N information inside information M, but the outside world cannot infer the plaintext of the N information through the commitment, nor can it infer the corresponding position of each information in the N information through the commitment. Usually, after calculating the commitment based on information M, entity A can no longer modify information M.

[0152] The open function is used to obtain proof to prove the information at a specific location. Specifically, entity A calculates the opening proof (OP) and makes it public, thereby proving that the information promised at a certain location i is m_i. The open function includes a single-point open function and a batch open function.

[0153] The single-point opening function means that entity A calculates a single-point opening proof (OP_i) for a single position i. Through the single-point opening proof, it can be proved that the information at position i is m_i;

[0154] The batch open function means that entity A calculates a multi-point open proof (multiproof, MP_B) at one time. The multi-point open proof is used to prove that the set formed by multiple information m_i is B, where each m_i is at its corresponding position i. Through the multi-point open proof, information at multiple positions can be verified at the same time.

[0155] Verification means that the verifier uses commitment and open proof to verify that the object that entity A initially committed or selected is indeed information M. Verification includes single-point verification and batch verification.

[0156] Single-point verification refers to the single-point opening proof (OP_i). The verifier can use the commitment, the single-point opening proof OP_i and the corresponding m_i to verify whether the information at a certain position i is consistent with the declaration of the single-point opening proof.

[0157] Batch verification refers to the multi-point open proof. The verifier can use commitment C, multi-point open proof MP_B and set B to verify whether the information at multiple locations is consistent with the declaration of the open proof.

[0158] In an optional implementation of the present application, the node device responsible for routing (such as a controller or user device) is used as entity A, and information M is used to represent the trusted path P = (r_1, r_2, ... r_i ..., r_N), each piece of information m_i in the information M represents the identity r_i of the forwarding node_i, and a set B is used to represent a certain section of the trusted path. A commitment is obtained based on a commitment function, a forwarding proof is obtained based on an open function, and verification of the forwarding proof is implemented based on a verification function.

[0159] In one possible implementation, a forwarding certificate related to a single forwarding node is obtained based on a single-point opening function, and the forwarding certificate related to the single forwarding node is verified based on a single-point verification function, thereby implementing verification of the certificate of a single node. In another possible implementation, a forwarding certificate related to multiple forwarding nodes is verified based on a batch verification function. A forwarding certificate related to multiple forwarding nodes is obtained based on a multi-point opening function, thereby verifying multiple nodes of the path at one time.

[0160] By using vector commitment to verify forwarding proof, the benefits achieved include at least the following aspects.

[0161] First, it helps verify that data is forwarded in the order specified by the forwarding path.

[0162] Specifically, the vector commitment itself has position binding, that is, it can reflect the binding relationship between the value of the information and the position of the information in the vector. Therefore, the vector commitment is obtained based on the identity information of the forwarding node and the position information of the forwarding node, so that the vector commitment is related to both the identity information and the position information of the forwarding node. The vector commitment can reflect the correspondence between the position information and the identity information of the forwarding node on the forwarding path. Therefore, when verifying the forwarding proof based on the vector commitment, the identity information, position information and forwarding proof must correspond to each other to pass the verification. The forwarding proof obtained when the identity information and position information do not correspond will cause the verification to fail. In other words, only the node i at the correct position i can calculate the correct forwarding proof p_i, which cannot be forged by others.

[0163] Second, it helps to hide the path. Since the vector commitment itself is in the form of ciphertext, the identity information and location information of the forwarding node contained in it cannot be directly obtained through the vector commitment itself, and it is also difficult to decrypt or reverse the vector commitment to obtain the identity information and location information of the forwarding node, thereby hiding the identity information and location information of the forwarding node on the forwarding path, thereby improving the privacy and confidentiality of the identity information and location information of the forwarding node.

[0164] Third, reduce the time to obtain commitments and verify commitments, and improve the efficiency of obtaining commitments and verifying commitments. If a single-point commitment method is used, the location of each node and the identity of each node need to be committed one by one. If the forwarding path includes n nodes, it will take n times the time to obtain and verify the commitment. By using the vector commitment method, a forwarding path containing at least two nodes (equivalent to a vector) can be committed at one time. If the forwarding path includes n nodes, it may only take log n or a constant time to obtain and verify the commitment, thereby reducing the risk of the amount of committed data growing superlinearly with the increase in the number of nodes in the forwarding path. The process of obtaining and verifying commitments can be completed more quickly, which can greatly improve efficiency and is more suitable for situations where a large number of nodes are included in the forwarding path. In addition, the single-point commitment method cannot bind the identity information and location information of the forwarding node, and other methods are needed to achieve location binding, such as using a list to record location information. Vector commitment has the ability to bind locations, and can directly bind multiple identity information with corresponding location information, thereby simplifying the verification process.

[0165] The three functions of commitment, opening and verification listed above are only examples of several functions that can be used to obtain and verify forwarding proofs. In another possible implementation, other types of functions in vector commitment are used to obtain and verify forwarding proofs, for example, using the evidence creation function (create witness, which is equivalent to the opening function) to obtain forwarding proofs, using the verification calculation function (verify eval, which is equivalent to the verification function) to obtain forwarding proofs, using the batch creation evidence function (create witness batch, which is equivalent to the batch opening function) to obtain multi-point forwarding proofs, and using batch verification calculation (verify eval batch, which is equivalent to the batch verification function) to verify multi-point forwarding proofs.

[0166] If necessary, the embodiment of the present application may optionally support the forwarding node to verify the source of the received data message based on the vector commitment and the forwarding proof, thereby achieving the correctness of the source of the data message to a certain extent. In a possible implementation, the data message carries the forwarding proof during the forwarding process along the way. When the forwarding node_i receives the data message_i, the forwarding node_i verifies the forwarding proof carried by the data message_i based on the vector commitment.

[0167] The method of verifying the source of the data message based on vector commitment and forwarding proof specifically includes the following implementation methods.

[0168] Method 1 for verifying the source of a data message: verify the single-point forwarding proof (OP) based on the location information of a single forwarding node and the identity information of a single forwarding node. For example, the data message received by forwarding node_i carries the single-point forwarding proof related to forwarding node_k. Forwarding node_i verifies the single-point forwarding proof of forwarding node_k based on the vector commitment, the identity information of forwarding node_k and the location information of forwarding node_k. Forwarding node_k is the upstream node of forwarding node_i in the forwarding path. The single-point forwarding proof of forwarding node_k is used to prove that node_k forwards the data message at position k on the forwarding path. The single-point forwarding proof of forwarding node_k is obtained based on the position k and the identity information of forwarding node_k, and k is a positive integer less than or equal to i.

[0169] Optionally, the forwarding node verifies the single-point forwarding proof of the previous hop node, thereby verifying the correctness of the previous hop. For example, the data message received by forwarding node_i carries the single-point forwarding proof generated by the previous hop node (node_i-1) of forwarding node i, and the single-point forwarding proof is used to prove that node_i-1 forwards the data message at position i-1 on the forwarding path. Forwarding node_i verifies the single-point forwarding proof carried by the data message based on the vector commitment, the identity information of node_i-1, and the location information of node_i-1. Similarly, each hop node is responsible for verifying the single-point forwarding proof of the previous hop node.

[0170] By having each hop node be responsible for verifying the single-point forwarding proof of the previous hop node, the benefits achieved include but are not limited to the following aspects.

[0171] First, further reduce the probability of deception and tampering. Specifically, since the verification of each node is based on the verification of the previous hop, it is equivalent to forming a continuous verification chain. Once a node is verified as deceptive, the subsequent nodes can immediately stop forwarding, thereby reducing the probability of any hop node in the forwarding path disguising, deceiving or tampering with the data packet, and improving the security of the network.

[0172] Second, verify the integrity of the path. Since the single-point forwarding proof of each hop is verified by the next hop, the risk of missing the proof of a node in the forwarding path is reduced, and each hop node on the entire forwarding path can be gradually verified to be in the correct position with almost no jumps or interruptions.

[0173] Third, privacy protection: Since the identity information and location information of other nodes other than the previous hop node are not needed to verify the single-point forwarding proof of the previous hop node, the identity information and location information of each hop node only need to be exposed to the next hop node, and do not need to be exposed to other nodes other than the next hop node. This protects the privacy of the node to a certain extent and reduces the risk of identity information and location information leakage.

[0174] Fourth, the correctness of the node's location can be verified. Since the forwarding proof of each forwarding node is obtained based on identity information and location information, by verifying the single-point forwarding proof of each node, it is possible to verify whether the node forwards the data message at the correct location on the path.

[0175] Method 2 for verifying the source of a data message: verifying a multi-point forwarding proof (MP) based on the location information of at least two forwarding nodes and the identity information of at least two forwarding nodes. For example, a data message received by forwarding node_i carries a multi-point forwarding proof related to forwarding node_k and forwarding node_m. Forwarding node_i verifies the multi-point forwarding proof related to forwarding node_k and forwarding node_m based on vector commitment, identity information of forwarding node_k, location information of forwarding node_k, identity information of forwarding node_m, and location information of forwarding node_m. Forwarding node_k is an upstream node of forwarding node_i in the forwarding path, and forwarding node_m is an upstream node of forwarding node_k in the forwarding path. The multi-point forwarding proof is used to prove that forwarding node_k forwards a data message at position k on the forwarding path, and forwarding node_m forwards a data message at position m on the forwarding path. The multi-point forwarding proof is obtained based on position k, identity information of forwarding node_k, position m, and identity information of forwarding node_m, where k is a positive integer less than or equal to i, and m is a positive integer less than or equal to k.

[0176] By verifying the multi-point forwarding proof (MP) based on the location information and identity information of multiple forwarding nodes, the benefits achieved include but are not limited to the following aspects.

[0177] First, efficiency is improved: compared with each node verifying a single-point forwarding proof individually, a multi-point forwarding proof can verify the forwarding proofs of multiple nodes at one time, using the advantages of batch processing to improve the overall verification performance of the forwarding path, saving the time for calculating and verifying proofs.

[0178] Second, reduce the number of verifications: By verifying the forwarding proofs of multiple nodes, the number of actual verifications can be reduced. For example, for m nodes on the forwarding path, it is necessary to perform m verifications when verifying the single-point forwarding proof of each node; by verifying the multi-point forwarding proof with m nodes, m nodes can be verified at one time, and the number of verifications can be reduced to 1, thereby reducing the number of verifications required to be performed on the entire forwarding path and speeding up the verification.

[0179] Third, better scalability: Compared with the single-point forwarding proof method, the multi-point forwarding proof method will hardly increase the time cost of calculating and verifying the proof linearly with the increase in the number of nodes in the forwarding path. Therefore, even if the forwarding path contains more nodes that need to be verified, it will hardly lead to a significant increase in the verification cost. Because the verification process has the efficiency advantage of batch processing, the overall performance can still be maintained at a high level.

[0180] Fourth, integrate the verification results of multiple nodes. Similar to the effect of single-point forwarding proof, the verification results of multiple nodes on the forwarding path can be integrated so that the scope of verification covers the location and identity of each node on the entire forwarding path, thereby fully verifying the entire forwarding path.

[0181] In a possible implementation, the forwarding proof carried by the data message is verified based on the location information of each node that the data message has passed on the forwarding path and the identity information of each node. For example, the data message received by the forwarding node _i carries a multi-point forwarding proof, which is obtained based on the identity information of each node from the head node to the previous node _i-1 on the forwarding path and the location information of each node from the head node to the previous node _i-1. The forwarding node _i verifies the multi-point forwarding proof carried by the data message based on the vector commitment, the identity information of each node from the head node to the previous node _i-1, and the location information of each node from the head node to the previous node _i-1. By combining the location and identity of each forwarding node that the data message passes through for verification, the benefits achieved include but are not limited to the following aspects.

[0182] First, from the perspective of verifying the source of the path, node _i is allowed to verify the upper half of the path that the data message has passed, including the position and identity of each node from the head node to the previous node _i-1, further reducing the probability of data messages passing through untrusted nodes being verified and the probability of data messages not passing through nodes on the trusted path being verified.

[0183] Second, in terms of efficiency improvement, the forwarding proof of each node that the message has passed on the forwarding path can be verified at one time, without having to verify the forwarding proof of each node that has passed separately, thereby taking advantage of batch processing to improve the overall verification performance, reducing time and computing costs, and improving verification efficiency.

[0184] Third, from the perspective of integrity verification, every node that the message has passed through on the forwarding path has been verified, without missing a single node, so the verification is more complete. If any node before node_i in the forwarding path is deleted or replaced, node_i will fail the verification of the multi-point forwarding proof during the verification of the multi-point forwarding proof because the multi-point forwarding proof no longer matches the identity and location of the deleted or replaced node, thereby further reducing the risk of data tampering or fraudulent forwarding.

[0185] Using the identity information and location information of each hop node in the forwarding path for verification is only an example. In other implementations of the present application, it is supported to trace and verify nodes within a certain range before the current node on the forwarding path. The verifier can flexibly specify the required traceability range according to actual needs, and different nodes can be responsible for verifying different parts of the forwarding path, thereby providing a more flexible and adjustable traceability capability. The following is an example of verifying the two-hop or three-hop nodes before the forwarding node.

[0186] In another possible implementation, forwarding node_i verifies the forwarding proof based on the vector commitment, the identity information of the two-hop nodes before forwarding node_i in the forwarding path, and the location information of the two-hop nodes before forwarding node_i, thereby supporting the tracing and verification of the correctness of the two-hop nodes before the current node. For example, the third node verifies the forwarding proof received by the third node based on the vector commitment, the identity information of the first node, the location information of the first node, the identity information of the second node, and the location information of the second node; the fifth node verifies the forwarding proof received by the fifth node based on the vector commitment, the identity information of the third node, the location information of the third node, the identity information of the fourth node, and the location information of the fourth node.

[0187] In another possible implementation, forwarding node_i verifies the forwarding proof based on the identity information of the three-hop nodes before forwarding node_i in the forwarding path, the location information of the three-hop nodes before forwarding node_i, and the vector commitment, thereby supporting the tracing and verification of the correctness of the three-hop nodes before this node. For example, the fourth node verifies the forwarding proof received by the fourth node based on the identity information of the first node, the location information of the first node, the identity information of the second node, the location information of the second node, the identity information of the third node, the location information of the third node, and the vector commitment; the seventh node verifies the forwarding proof received by the seventh node based on the identity information of the fourth node, the location information of the fourth node, the identity information of the fifth node, the location information of the fifth node, the identity information of the sixth node, the location information of the sixth node, and the vector commitment.

[0188] In one possible implementation, during the forwarding process of the data message, each forwarding node verifies the forwarding proof hop by hop in real time; in another possible implementation, when the data message is forwarded to the tail node, the tail node verifies once that the data message has indeed and only passed through each forwarding node on the forwarding path in sequence.

[0189] In one possible implementation, in response to determining that the forwarding proof carried by the data message fails verification, the forwarding node discards the received data message. By discarding the data message whose forwarding proof fails verification, it helps to block the further transmission of data with illegal sources and improve network security. Specifically, if the forwarding node finds that the forwarding proof carried by the data message fails verification, that is, the source of the proof data may have problems, such as the data message skips a node in the path or passes through an extra unspecified node before forwarding to this node, the forwarding node discards the data message, thereby avoiding the data message with problematic source from being further transmitted from this node to the next node, thereby quickly preventing the data message with problematic source from being further propagated, reducing the probability of unauthorized data access and tampering, reducing the possibility of network attacks, and improving network security.

[0190] In one possible implementation, in response to determining that the forwarding proof carried by the data message fails to pass the verification, the forwarding node outputs an alarm message, and the alarm message is used to indicate that the forwarding proof fails to pass the verification. In one possible implementation, the forwarding node notifies the alarm message to the network management system (Network Management System, NMS), the element management system (Element Management System, EMS) or the controller through the management plane protocol. For example, the forwarding node sends a network configuration protocol (Network Configuration Protocol, NETCOF) message to the controller, the NETCOF message includes the alarm information, and the NETCOF message indicates that the forwarding proof fails to pass the verification. For another example, the forwarding node sends a simple network management protocol (Simple Network Management Protocol, SNMP) message to the controller, the SNMP message includes the alarm information, and the SNMP message indicates that the forwarding proof fails to pass the verification. For another example, the forwarding node sends an alarm message indicating that the forwarding proof fails to pass the verification to the controller based on telemetry. For another example, the forwarding node sends an alarm message indicating that the forwarding proof fails to pass the verification to the controller based on the representational state transfer principle (Representational State Transfer, RESTful). For another example, the forwarding node sends information indicating that the forwarding certificate fails to pass the verification to the controller in the form of a log based on the log management protocol. For example, the forwarding node sends a system log (System Logging Protocol, Syslog) protocol message to the controller, and the Syslog protocol message includes an alarm message indicating that the forwarding certificate fails to pass the verification. Syslog is a standard UNIX system log management protocol for sending log information generated by a device or application to a remote server. In one possible implementation, the forwarding node outputs the alarm information in the form of an alarm notification. The alarm notification can be sent by SMS, email, instant messaging tools, etc., so that the administrator or network security team receives it in time and takes corresponding countermeasures. In another possible implementation, the forwarding node outputs the alarm information in the form of log recording. For example, the forwarding node_i records the information of the data message_i that failed the verification in the system log. In another possible implementation, the forwarding node_i sends an alarm message to the controller. The controller provides a visual display of the alarm information so that the administrator can quickly find the problem and take measures.

[0191] In a possible implementation, in response to determining that the forwarding proof carried by the data packet passes verification, the forwarding node further forwards the received data packet.

[0192] If necessary, the embodiments of the present application may choose to support a method based on KZG polynomial commitment (kate-zaverucha-goldberg polynomial commitment), obtaining and verifying commitments based on the identity information of the forwarding node and the location information of the forwarding node, thereby further reducing the time for obtaining commitments, improving the efficiency of obtaining commitments, and avoiding the superlinear growth of the verification time of the forwarding proof as the number of nodes in the forwarding path increases, so that the verification time of the forwarding proof is as short as possible.

[0193] KZG polynomial commitment is a specific construction method of a vector commitment mechanism with better characteristics. Polynomial commitment is the ability to commit to N points (such as N identity information) on a polynomial curve at one time, and prove and verify that 1 or N points (such as N identity information) are on this polynomial in constant time, and the amount of data committed and the amount of data for each forwarding proof are both constants O(1). In the polynomial commitment, the information m_i is converted into a point form (x_i, y_i) and saved, that is, the information M is converted into <(x_1, y_1), (x_, 2, y_2), ..., (x_N, y_N)>, x_i = i, y_i = m_i. x_i represents the location information of the forwarding node, for example, x_i is a subscript (usually an integer 1, 2, 3 ..., that is, x_i = i), and y_i represents the identity information of the forwarding node. KZG polynomial commitment can achieve that the commitment calculation time of entity A to commit to N pieces of information at one time, the time for others to calculate single or multiple open proofs, and the time for others to verify N pieces of information at one time are all sublinear time (actually constant time).

[0194] Commitments are obtained and verified by using the KZG polynomial commitment method. Since KZG polynomial commitment has a constant time computational complexity when calculating commitments and opening proofs, and is almost unaffected by the number of committed information N, this means that no matter how much the amount of information increases, the time required for commitment calculation and opening proof calculation is constant time, thereby achieving constant time proof calculation and verification time, and a constant size of additional proof data size, which is independent of the number of nodes N contained in the path. In other words, the time required to obtain the commitment and the time required to verify the commitment remain constant, and the amount of data for forwarding the proof remains constant. The time required to obtain the commitment, the time required to verify the commitment, and the amount of data for forwarding the proof will not increase with the increase in the length of the forwarding path. In the case of complex networking and the forwarding path including a large number of nodes, commitments can still be obtained and verified quickly, thereby greatly improving the efficiency of obtaining and verifying commitments.

[0195] The implementation details of the KZG polynomial commitment are described in detail in the embodiments. The KZG polynomial commitment is only one possible implementation method for obtaining vector commitments, which can not only achieve the effect of forwarding proof and position binding, but also has the advantage of high efficiency. Vector commitments obtained by other methods can also achieve the effect of forwarding proof and position binding.

[0196] In some other possible implementations, a fast Reed-Solomon interactive (FRI) commitment method is used to obtain and verify commitments based on the identity information of the forwarding node and the location information of the forwarding node. FRI commitment is a commitment mechanism used to verify the integrity of polynomials in interactive proof systems. It can quickly verify whether a polynomial satisfies a set of constraints without calculating the entire polynomial item by item. FRI commitment is based on Reed-Solomon coding and interactive proof protocols. By constructing multiple small-scale Reed-Solomon codes and related proofs, the complexity of verifying polynomials is greatly reduced.

[0197] In some other possible implementations, a succinct non-interactive argument of knowledge (SNARK) commitment is used to obtain and verify commitments based on the identity information of the forwarding node and the location information of the forwarding node. SNARK commitment is a protocol for proving the correctness of a computation and that the inputs held by one party satisfy certain conditions. SNARK proofs are non-interactive, meaning that the prover does not need to interact with the verifier, but only needs to generate a proof and send it to the verifier. SNARK proofs are compact, the proof size is small, and the verification time is relatively short.

[0198] In some other possible implementations, based on the identity information and location information of the forwarding node, a scalable transparent arguments of knowledge (STARK) commitment method is used to obtain a forwarding proof or a vector commitment; or a STARK commitment method is used to verify the forwarding proof based on the vector commitment. STARK is a zero-knowledge proof technology. STARK does not require a trusted third party to set up and start, so it is more decentralized and distributed, reducing the impact of single point failures on obtaining forwarding proofs or vector commitments, and also has higher security. In addition, STARK is post-quantum secure, so the use of STARK helps to improve the ability of forwarding proofs to resist quantum computing attacks, and is more reliable in protecting the security of forwarding proofs and identity information. In addition, the amount of data of the forwarding proof generated based on STARK is relatively small, which means that the proof can be transmitted with less storage space, and it also has advantages in verification efficiency, such as the next-hop forwarding node or verification node can verify the validity of the forwarding proof in a relatively short time.

[0199] In some other possible implementations, based on the identity information of the forwarding node and the location information of the forwarding node, the forwarding proof or vector commitment is obtained by using the Bulletproof method; or the forwarding proof is verified based on the vector commitment by using the Bulletproof method. Bulletproof is a zero-knowledge proof technology. Bulletproof is a cryptographic primitive used in zero-knowledge proof to prove that a value satisfies a certain relationship without providing additional proof information. Bulletproof also does not require a trusted third party to set up and start, so it is more decentralized and distributed, reducing the impact of single point failures on obtaining forwarding proofs or vector commitments, and also has higher security.

[0200] In some other possible implementations, an RSA accumulator is used to obtain and verify commitments based on the identity information of the forwarding node and the location information of the forwarding node. An RSA accumulator is a data structure used to accumulate the elements of a set into an accumulator so as to subsequently verify whether an element belongs to the set. Based on the RSA addition homomorphic property, an RSA accumulator can verify whether a specific element is contained in an accumulator without disclosing the elements of the set.

[0201] In some other possible implementations, FC function commitment is adopted to obtain commitment and verify commitment based on the identity information of the forwarding node and the location information of the forwarding node. FC function commitment is a commitment mechanism that is used to bind the input with the calculation result of the function so that the calculation result can be verified without exposing the input. FC function commitment can be implemented by combining the zero-knowledge proof system and the commitment mechanism. It can be used to protect computer privacy and verify the correctness of the calculation result.

[0202] In some other possible implementations, Pedersen commitment is used to obtain and verify commitments based on the identity information of the forwarding node and the location information of the forwarding node. Pedersen commitment is a commitment mechanism used to commit a value or vector to a hidden value. Pedersen commitment is based on the discrete logarithm problem, so that only the committer who knows the hidden value can verify the correctness of the commitment without revealing the actual value.

[0203] In some other possible implementations, a merkle tree commitment is used to obtain and verify commitments based on the identity information of the forwarding node and the location information of the forwarding node. Merkle tree commitment is a commitment mechanism that is used to bind multiple elements in a set into a tree structure. The Merkle tree combines elements level by level through a hash function and generates a root hash, which is a commitment to the entire tree. In the verification phase, you only need to know some elements in the set and the hash values ​​on the relevant paths to verify whether the elements belong to the tree.

[0204] In some other possible implementations, a Verkle tree commitment is used to obtain and verify commitments based on the identity information of the forwarding node and the location information of the forwarding node. Verkle tree commitment is a commitment mechanism that is used to bind multiple elements in a set into a non-binary tree structure. The Verkle tree commits the path from the root node to the leaf node in the tree through polynomial commitments and aggregates multiple paths. In the verification phase, it is only necessary to know certain elements in the set and the polynomial commitments on the relevant paths to verify whether the elements belong to the tree.

[0205] In some other possible implementations, the source of the data message is verified based on an aggregatable signature. For example, the data message contains a digital signature. This signature can be the signature of the previous hop node_i-1, or it can be the aggregated signature of all nodes_1 to node_i-1 in the upper half. The characteristic of the aggregated signature is that the aggregation result of an infinite number of signatures is the same length as one signature. It is known that the Public Key Infrastructure (PKI) exists, that is, the public identity of the node is known, and node_i can verify the correctness of this signature.

[0206] In some other possible implementations, the source of the data message is verified based on a symmetric key message authentication code (MAC) tag: for example, the data message includes a MAC tag, and node_i can verify the correctness of the MAC tag.

[0207] If necessary, the embodiment of the present application may optionally support path hiding based on an encrypted routing table.

[0208] For example, the path hiding property means that node_i can only know the address of the next node_i+1 of node_i on the forwarding path to determine where to forward the next hop. It is difficult for node_i to know the address of each node from node_i+2 to the last node_N on the forwarding path.

[0209] The encrypted routing table is used to guide the data message to be forwarded hop by hop along the specified forwarding path. The content of the encrypted routing table is in the form of ciphertext. In order to distinguish the description of the encrypted routing table as a whole from the part of the encrypted routing table corresponding to a single forwarding node, the part of the encrypted routing table corresponding to a single forwarding node is referred to as an encrypted routing table item below. An encrypted routing table includes at least one encrypted routing table item.

[0210] In some possible implementations, the encrypted routing table entry corresponding to node_i on the forwarding path in the encrypted routing table is encrypted based on the key of node_i. The encrypted routing table entry corresponding to node_i is used to guide node_i to forward the data message to the next node_i+1 of node_i on the forwarding path. The encrypted routing table entry corresponding to node_i is, for example, encrypted based on the symmetric key of node_i, or encrypted based on the private key of node_i.

[0211] In some possible implementations, the encrypted routing table entry includes a node identification ciphertext. For example, the encrypted routing table entry corresponding to node_i includes a ciphertext obtained by encrypting the identification of node_i+1 based on the key of node_i.

[0212] For example, in the scenario of an IP network, the encrypted routing table entry corresponding to node_i includes the ciphertext obtained by encrypting the IP address of node_i+1 based on the key of node_i. In the scenario of an Internet Protocol version 4 (IPv4) network, the encrypted routing table entry corresponding to node_i includes the ciphertext obtained by encrypting the IPv4 address of node_i+1 based on the key of node_i. In the scenario of an Internet Protocol version 6 (IPv6) network, the encrypted routing table entry corresponding to node_i includes the ciphertext obtained by encrypting the IPv6 address of node_i+1 based on the key of node_i.

[0213] For example, in a Segment Routing over IPv6 (SRv6) network scenario, the encrypted routing table entry corresponding to node_i includes a ciphertext obtained by encrypting the SID of node_i+1 based on the key of node_i.

[0214] For example, in a Multi-Protocol Label Switching (MPLS) network scenario, the encrypted routing table entry corresponding to node_i includes a ciphertext obtained by encrypting the MPLS label of node_i+1 based on the key of node_i.

[0215] For example, in a layer 2 forwarding scenario, the address ciphertext of node_i+1 is a ciphertext obtained by encrypting the media access control (MAC) address of node_i+1 based on the key of node_i.

[0216] In some possible implementations, the encrypted routing table includes the identification ciphertext of each node in the forwarding path. Optionally, the encrypted routing table items in the encrypted routing table are arranged in sequence according to the order of each node in the forwarding path. For example, the encrypted routing table items in the encrypted routing table are arranged in sequence from front to back in the forwarding path (arranged in positive order). The last table item in the encrypted routing table includes the node identification ciphertext of the tail node, the second to last table item in the encrypted routing table includes the node identification ciphertext of the second to last node, and so on. The first table item in the encrypted routing table includes the node identification ciphertext of the head node. For another example, the encrypted routing table items in the encrypted routing table are arranged in sequence from back to front in the forwarding path (arranged in reverse order).

[0217] Taking the node identifier as the address as an example, for a forwarding path including N nodes, starting from the previous hop node N-1 of the tail node, the address of the tail node N is encrypted using the secret key of node N-1; then, the address of node N-1 is added to the ciphertext of the address of the tail node N, and the address of node N-1 is encrypted using the secret key of node N-2, and so on, until the identifier of the second node is encrypted using the secret key of the head node of the forwarding path.

[0218] Since the encrypted routing table entry corresponding to node _i in the encrypted routing table includes the ciphertext obtained by encrypting the identifier of node _i+1 based on the key of node _i, the structure of the routing table is similar to an onion peeled off layer by layer. Specifically, in the encrypted routing table, each node can only decrypt the table entry corresponding to the node in the encrypted routing table based on the key of the node. Therefore, the node only knows the identifier of the next hop of the node based on the encrypted routing table, and cannot know in advance the identifier of any node subsequent to the next hop. Each node decrypts according to its own key to obtain the address of the next hop. This hop-by-hop decryption process is like peeling off the layers of an onion. Each layer can only know the information of the next layer, but cannot know the identifier of the node at a deeper level. In this way, path confidentiality can be achieved under the premise of completing the message forwarding task. The benefits of path confidentiality include but are not limited to the following aspects.

[0219] First, reduce the probability of calculating the forwarding proof in advance before forwarding. Considering that if the forwarding path or routing table is public, the attacker may calculate the forwarding proof in advance based on the known location and identity information, thereby compromising the security of the data. By using an encrypted routing table, the identity of each hop node in the complete path is hidden. During the transmission process, the node identity is gradually revealed hop by hop. In the forwarding process of each hop, only the identity of the next hop is known, and the identity of the subsequent node cannot be known in advance. This reduces the possibility of the attacker calculating the forwarding proof in advance during the transmission process, making it impossible for the attacker to obtain the complete path and identity information from the beginning and calculate the forwarding proof in advance.

[0220] Second, after the data is diverted by the malicious attacker, it will not be known where it will be forwarded, and the illegal forwarding of the data will stagnate, which will have the effect of passive interception. Specifically, when the attacker tries to skip a certain node and directly forward the data to the subsequent node, the attacker cannot obtain the key of the node, so it is impossible to decrypt the address of the subsequent node. Therefore, the attacker will not know which node to forward the data to, and cannot correctly calculate the forwarding proof. For example, the forwarding path includes forwarding node A→forwarding node B→forwarding node C→forwarding node D. The attacker diverts the data message that should have been received by forwarding node B to forwarding node B', but forwarding node B' does not have the key of forwarding node B, so forwarding node B' cannot decrypt the identifier of forwarding node C based on the encrypted routing table carried in the data message, and forwarding node B' cannot forward the data message to forwarding node C. It is also difficult for forwarding node C to calculate the correct forwarding proof, so that the forwarding proof carried by the data message cannot be verified and the forwarding stops. In this way, the macro observer can observe that the data message stops forwarding at node b', achieving a passive interception effect, and timely discovering and preventing malicious behavior.

[0221] Third, after the attacker redirects the data to skip a section of nodes in the trusted path, it cannot be transferred back to the subsequent nodes of the trusted path, pretending that the data has never left the trusted path. Specifically, even if the attacker forwards the data to a node on an untrusted path, due to the lack of the key of the subsequent node and the correct forwarding proof, the attacker cannot continue to forward the data to the subsequent nodes of the trusted path, nor can he calculate the correct forwarding proof.

[0222] In some possible implementations, a portion of the routing table items in the encrypted routing table are in an encrypted state, and the portion of the routing table items includes the ciphertext of the identification of the node located downstream of node_i in the forwarding path; another portion of the routing table items are in a decrypted state, and the portion of the routing table items includes the plaintext of the identification of the node located upstream of node_i in the forwarding path. For example, in the encrypted routing table carried in the data message received by node_i, the routing table items corresponding to each node from node_1 to node_i-1 are in a decrypted state, the routing table item corresponding to node_1 includes the identification of node_1, the routing table item corresponding to node_2 includes the identification of node_2, and so on, the routing table item corresponding to node_i-1 includes the identification of node_i-1; the routing table items corresponding to each node from node_i to node_N are in an encrypted state. In this way, a complete forwarding path is divided into two sections. The first half of the path that the message has traveled (corresponding to the routing table entries corresponding to each node from node_1 to node_i-1) is open to node_i, so that node_i can verify the forwarding proof based on the identifier of each node in the first half of the path, and the second half of the path that the message has not traveled (corresponding to the routing table entries corresponding to each node from node_i+1 to node_N) is kept confidential to node_i, so as to maintain the confidentiality of the path. In particular, since the forwarding path of the data message is relatively confidential before forwarding, the risk of the data message being ambushed in advance is reduced, as well as the risk of the data message being diverted in the first half of the path that has been traveled and then skipping some nodes to return to the second half of the trusted path.

[0223] In some possible implementations, the encrypted routing table uses a key-value pair format, where the key (index keyword based on which the table lookup is based) is the location information of the node, and the value (the search result corresponding to the index) is the identity information of the node.

[0224] In some possible implementations, when single-point forwarding proof is adopted, when a data message is transmitted to node _i, the format of the encrypted routing table carried by the data message is as shown in the following table.

[0225] Identity information of node r_i-1 T: ciphertext encrypted by the secret key of node r_i (including the address information or identity information of node r_i+1)

[0226] In some possible implementations, when multi-point forwarding proof is adopted, when the data message is transmitted to node _i, the format of the encrypted routing table carried by the data message is as shown in the following table.

[0227] T: ciphertext encrypted by the secret key of node r_i (including the address information or identity information of node r_i+1)

[0228] Then, node r_i obtains the identity information of each node from node_1 to node r_i-1 through other channels other than the data message.

[0229] In some other possible implementations, the encrypted routing table entry corresponding to node_i includes the outbound interface ciphertext of node_i+1. The outbound interface ciphertext of node_i+1 is the ciphertext obtained by encrypting the identifier of the designated outbound interface of node_i based on the key of node_i, and the designated outbound interface of node_i is the interface in node_i that communicates with node_i+1. For example, for a forwarding path including N nodes, starting from the previous hop node_N-1 of the tail node, the identifier of the outbound interface on node_N-1 for communicating with the tail node is encrypted using the secret key of node_N-1; then, the identifier of the outbound interface on node_N-2 for communicating with node_N-1 is encrypted using the secret key of node_N-2, and the ciphertext of the outbound interface of node_N-2 is added to the ciphertext of the outbound interface of node_N-1, and so on, until the identifier of the outbound interface on the head node for communicating with the second node is encrypted using the secret key of the head node of the forwarding path. In this way, the forwarding node only knows how to forward the message to the next node, without knowing the information of any nodes after the next node in advance, thereby protecting the path confidentiality while completing the forwarding task.

[0230] In some possible implementations, the controller generates an encrypted routing table. For example, before forwarding a data message, the controller and each node in the forwarding path distribute symmetric keys in advance. For example, the controller sends the symmetric key of the head node to the head node, sends the symmetric key of the second forwarding node to the second forwarding node, and so on, sends the symmetric key corresponding to node_i to node_i. Then, the controller encrypts the identifier of node_i+1 based on the symmetric key of node_i, and obtains the identifier ciphertext of node_i+1. The identifier ciphertext of node_i+1 is the encrypted routing table item corresponding to node_i. The controller adds the identifier ciphertext of node_i+1 to the routing table, and repeats the encryption steps to obtain an encrypted routing table. In the data message forwarding stage, each forwarding node decrypts the routing table item corresponding to the node based on the symmetric key received from the controller to obtain the identifier of the next node.

[0231] In some possible implementations, in the process of generating an encrypted routing table, a network controller is not used, and the encrypted routing table is generated by exchanging keys between forwarding nodes to distribute the keys. For example, the key distribution is performed between node_i and the previous hop node_i-1 or the next hop node_i+1, and then the subsequent process is the same as the process of generating an encrypted routing table by the controller.

[0232] In some other possible implementations, the encrypted routing table is not used to achieve path hiding. In some embodiments, the entire path is disclosed in advance at the control plane or service plane, etc., and although the security is reduced, it is still available. In other words, the three technical effects of the effect of binding the forwarding proof with the location, the correctness of the source of the data message, and the efficiency of obtaining and verifying the commitment are not necessarily bound to the encrypted routing table. When the forwarding path is disclosed, the three technical effects of binding the forwarding proof with the location, the correctness of the source of the data message, and the efficiency of obtaining and verifying the commitment can still be achieved to a certain extent by obtaining the forwarding proof based on the location, verifying the source of the data message based on the vector commitment, KZG polynomial commitment or other methods.

[0233] The following is an example of identity information that can be used to obtain or verify a forwarding certificate.

[0234] In some possible implementations, the identity information of the forwarding node is publicly verifiable identity information. By using publicly verifiable identity information to calculate and verify the forwarding proof, the difficulty of obtaining the identity information is reduced, thereby reducing the complexity of calculating and verifying the forwarding proof based on the identity information. In some other possible implementations, the identity information of the forwarding node_i is a publicly verifiable and unforgeable identity proof that can only be calculated by the forwarding node_i and can be verified by multiple parties. Exemplarily, the identity information of the forwarding node_i includes identity information encrypted based on the key of the forwarding node_i. Optionally, the identity information encrypted based on the key of the forwarding node_i is identity information encrypted based on the symmetric key of the forwarding node_i; or, the identity information encrypted based on the key of the forwarding node_i is identity information encrypted based on the private key of the forwarding node_i. By using the encrypted identity information to calculate the forwarding proof or verify the forwarding proof, the security and privacy of the calculation and verification of the forwarding proof are further improved due to the higher security and privacy of the identity information.

[0235] Exemplarily, the identity information of the forwarding node_i includes the address of the forwarding node_i. The address used as the identity information of the forwarding node_i is optionally the IP address of the forwarding node_i. For example, the address used as the identity information of the forwarding node_i is the Internet Protocol version 4 (internet protocol version 4, IPv4) address of the forwarding node_i or the Internet Protocol version 6 (internet protocol version 6, IPv6) address of the forwarding node_i. Alternatively, the address used as the identity information of the forwarding node_i is the MAC address of the forwarding node_i.

[0236] Exemplarily, the identity information of forwarding node_i includes the segment ID (SID) of forwarding node_i. SID is an identifier used in SRv6 (Segment Routing over IPv6) network, which is used to define a certain function or instruction in the network. SID is in the form of an IPv6 address with 128 bits. By using SID as identity information to calculate forwarding proof and verify forwarding proof, it is more suitable for SRv6 network scenarios. While achieving path binding, the SID carried in the SRv6 encapsulation can be reused, and there is no need to add additional fields in the message to carry identity information, which helps to simplify the message format and reduce the overhead of transmitting messages.

[0237] Exemplarily, the identity information of forwarding node_i includes a multi-protocol label switching (MPLS) label of forwarding node_i. The MPLS label is a short and fixed-length connection identifier used to replace IP forwarding in an MPLS network or an SR-MPLS network. By using the MPLS label as identity information to calculate and verify the forwarding proof, it is more suitable for MPLS network or SR-MPLS network scenarios. While achieving path binding, the MPLS label carried in the MPLS encapsulation or SR-MPLS encapsulation can be reused, and there is no need to add additional fields in the message to carry identity information, which helps to simplify the message format and reduce the overhead of transmitting the message.

[0238] Exemplarily, the identity information of forwarding node_i includes the certificate of forwarding node_i. A certificate is a digital credential or electronic file used to prove the identity or authority of an entity. The certificate is issued by a trusted third-party organization, such as a digital certificate certification authority (CA), and contains identity information (such as a public key) used to verify and identify the specified entity. The certificate content includes the public key, information about the certificate holder (such as name, organization, etc.) or the validity period of the certificate. By using the certificate as identity information to calculate the forwarding proof and verify the forwarding proof, the authenticity and integrity of the certificate can be verified, which helps to reduce the risks caused by tampering, eavesdropping or disguise of identity information, and further improves the security and credibility of the forwarding proof.

[0239] Exemplarily, the identity information of the forwarding node_i includes the key of the forwarding node_i. For example, the identity information of the forwarding node_i includes the public key of the forwarding node_i. For another example, the identity information of the forwarding node_i includes the private key of the forwarding node_i.

[0240] Exemplarily, the identity information of forwarding node_i includes an access control token (token) of forwarding node_i. The access control token is a digital certificate used to verify access rights to protected resources. The access control token contains the authorization information and access rights information of the forwarding node. The access control token can be generated by an access control server and issued to the forwarding node. By using the access control token as identity information to calculate the forwarding proof and verify the forwarding proof, since each forwarding node can verify the validity and authority of the access control token, the risk of identity information being tampered with and data leakage is reduced, thereby further improving the security and credibility of the forwarding proof.

[0241] Exemplarily, the identity information of the forwarding node_i includes a router ID of the forwarding node_i.

[0242] Exemplarily, the identity information of the forwarding node_i includes the host name of the forwarding node_i.

[0243] Exemplarily, the identity information of forwarding node_i includes the signature of forwarding node_i. For example, forwarding node_i encrypts the identity information of forwarding node_i using the private key of forwarding node_i to generate the signature of forwarding node_i. By using the signature of forwarding node_i as the identity information to calculate the forwarding proof and verify the forwarding proof, the risk of identity information being tampered with and data leakage is reduced, thereby further improving the security and credibility of the forwarding proof.

[0244] Exemplarily, the identity information of forwarding node_i includes a message authentication code (MAC) tag. A MAC tag is an authentication code used to verify the integrity and authenticity of a message. A MAC tag is a fixed-length value obtained by encrypting and calculating a message, thereby reducing the probability that the message is tampered with or forged during transmission. For example, forwarding node_i uses the shared key and message content between forwarding node_i and other forwarding nodes on the forwarding path to generate a MAC tag, and uses the MAC tag as identity information to calculate the forwarding proof and verify the forwarding proof, thereby further reducing the probability that the forwarding proof is tampered with and forged, and enhancing the security and credibility of the forwarding proof.

[0245] Exemplarily, the identity information of forwarding node_i includes a zero-knowledge (Non-Interactive Zero-Knowledge, NIZK) proof. Zero knowledge is a cryptographic technique used to prove the authenticity of a statement without revealing the information behind it. The proof allows the prover to show the verifier proof of a fact without revealing any other information related to the fact. An example of a zero-knowledge proof as identity information is the Schnorr proof. The Schnorr proof is a zero-knowledge NIZK proof protocol based on the discrete logarithm problem, proposed by Claude Schnorr. By using the NIZK proof as identity information to calculate the forwarding proof and verify the forwarding proof, the true identity of the forwarding node can be hidden, reducing the probability of the true identity of the forwarding node being leaked, while supporting the verification of the NIZK proof as identity information, thereby further reducing the probability of the forwarding proof being tampered with and forged, and enhancing the security and credibility of the forwarding proof.

[0246] Exemplarily, the identity information of forwarding node_i includes Sigma protocol proof. Sigma protocol proof is an interactive protocol based on zero-knowledge proof (Zero-Knowledge Proof). It allows a prover to prove that a statement is true in the interaction with the verifier without revealing the real information about the statement. In the Sigma protocol proof, the prover and the verifier conduct multiple rounds of interaction to achieve the purpose of mutual authentication. The prover attempts to prove the authenticity of a statement to the verifier, and the verifier hopes to confirm the authenticity of the statement and believes that the prover does know how to prove the statement. But the special nature of the protocol is that the prover cannot disclose the real information of the statement to the verifier, thereby protecting the privacy of the prover.

[0247] The following is an example of the triggering conditions for calculating the forwarding proof for the forwarding node.

[0248] In a possible implementation, after forwarding node_i obtains the data message, in response to identifying that the data message carries a trusted path identifier, forwarding node_i performs a step of obtaining a forwarding certificate. The message header in the data message includes the trusted path identifier.

[0249] The trusted path identifier is used to indicate obtaining a forwarding proof. For example, the trusted path identifier is used to distinguish whether the forwarding node needs to calculate the forwarding proof now.

[0250] By including a trusted path identifier in the header of a data message, the forwarding node is supported to determine whether to calculate the forwarding proof based on the presence or absence of the identifier. For example, if the forwarding node_i determines that the data message does not carry a trusted path identifier, the forwarding node_i uses the original forwarding mechanism without calculating the forwarding proof. Specifically, the effects achieved by including a trusted path identifier in the message header include but are not limited to the following aspects.

[0251] First, improve flexibility. Specifically, the trusted path identifier provides an optional mechanism that allows forwarding nodes to determine whether to perform forwarding proof calculations based on specific needs and changes in needs, thereby improving flexibility and scalability.

[0252] Second, simplify the configuration and reduce the possibility of configuration errors. Compared with the static configuration method to configure which messages to generate forwarding proofs for on the forwarding node, the method of including the trusted path identifier in the message header of the data message makes it unnecessary to pre-configure which messages need to generate forwarding proofs on the forwarding node, thereby simplifying the configuration process and reducing the complexity of the configuration. In addition, it also reduces the probability of missing the task of configuring forwarding proofs for certain messages during manual configuration.

[0253] Third, save computing resources: When the data message does not carry a trusted path identifier, the forwarding node can determine that it does not need to perform forwarding proof calculations, thereby saving computing resources and time, thereby improving overall network performance and efficiency.

[0254] In another possible implementation, after forwarding node_i obtains a data message, forwarding node_i identifies the service type carried in the data message; in response to identifying that the data message carries data of a specific service type, the step of obtaining a forwarding certificate is executed, thereby realizing a forwarding certificate for a specific service. For example, in response to identifying that the data message contains a network service header (NSH) in the service function chain protocol, forwarding node_i determines that the data message carries data of a service function chain, and then executes the step of obtaining a forwarding certificate. For another example, forwarding node_i performs application identification on the payload data in the data message to obtain the application type corresponding to the payload data. In response to the application type being a target application, the step of obtaining a forwarding certificate is executed. By executing the step of obtaining a forwarding certificate for a specific service, the effects achieved include but are not limited to the following aspects.

[0255] First, it can flexibly and accurately match business requirements. By determining whether to calculate the forwarding proof based on whether the message contains data related to a specific business, only the data related to a specific business needs to be calculated for the forwarding proof, thereby flexibly calculating the forwarding proof according to the needs of different businesses. This can meet the personalized forwarding proof requirements of different businesses and improve the flexibility and customizability of the network.

[0256] Second, simplify the configuration and reduce the possibility of configuration errors. Compared with the static configuration method of configuring which messages to generate forwarding proofs on the forwarding node, the forwarding node automatically determines whether to generate a forwarding proof by identifying the services carried by the data message. There is no need to pre-configure which messages need to generate forwarding proofs on the forwarding node, thereby simplifying the configuration process and reducing the complexity of the configuration. In addition, it also reduces the probability of missing the task of configuring forwarding proofs for certain messages during manual configuration.

[0257] Third, save computing resources: When the data message does not carry data related to a specific business, the forwarding node can determine that it does not need to perform forwarding proof calculations, thereby avoiding wasting computing resources on other data that does not require proof calculations, saving computing resources and time, and improving overall network performance and efficiency.

[0258] In another possible implementation, after forwarding node_i obtains a data message, forwarding node_i, in response to identifying that the data message contains the identifier of each node in a specific tunnel, performs the step of obtaining a forwarding certificate, so as to verify whether the data message is forwarded through the specific tunnel. For example, when applied to an SRv6 scenario, forwarding node_i, in response to identifying that the data message includes a segment list, performs the step of obtaining a forwarding certificate. For another example, when applied to an MPLS scenario, forwarding node_i, in response to identifying that the data message includes a label stack, performs the step of obtaining a forwarding certificate.

[0259] The following is an example of how a forwarding node obtains the location information of the node or the location information of an upstream node. In one possible implementation, the forwarding node obtains the location information of the node or the location information of the upstream node based on a received data message. For example, the forwarding node obtains the location information of the node carried in the data message; or, the forwarding node obtains the location information of the node after further processing the data related to the location information carried in the data message.

[0260] In a possible implementation, the data packet includes an IPv4 header, the IPv4 header includes a time to live (TTL), the forwarding node_i identifies a value of the TTL, and obtains a position i of the forwarding node_i on the forwarding path based on the value of the TTL.

[0261] TTL is a field in the IPv4 header in the IPv4 protocol, which is used to limit the transmission time or number of hops of a data message in the network. TTL is expressed in the form of an integer. Each time a data message passes through a forwarding node, TTL decreases by 1. When the value of TTL decreases to 0, the data message will be discarded and a timeout message will be returned to the source node. TTL is located in the 9th byte of the IPv4 message header, occupies one byte (8 bits), and is used to store the value of TTL. A method for determining the position of a node in a forwarding path based on TTL is, for example, if the initial value of TTL is k, since the value of TTL decreases by 1 each time a node is passed, when node_i receives a data message and identifies that the value of TTL carried by the data message is ni, node_i determines that this node is the i-th node in the forwarding path.

[0262] In a possible implementation, the data packet includes an IPv6 header, the IPv6 header includes a hop limit, the forwarding node_i identifies a TTL value, and obtains a position i of the forwarding node_i in the forwarding path based on the TTL value.

[0263] In the IPv6 protocol, TTL is called the hop limit, which is also carried in a field in the IPv6 header. The hop limit is equivalent to the TTL in IPv4 and is used to limit the number of hops of a data message in the network. The 7th byte of the IPv6 header occupies one byte (8 bits) to store the value of the hop limit. In order to determine which node this node is in the forwarding path, node_i identifies the value of the hop limit field in the IPv6 header. If the hop limit is 255, it can be determined that this node is the first hop. If the hop limit is 254, it can be determined that this node is the second hop. Similarly, every time the hop limit is reduced by one, the position number of this node is also increased by one.

[0264] In a possible implementation, the data message includes a service index (SI), and the forwarding node obtains the location information of the node based on the SI carried in the data message. The service index (SI) is a field in the network service header (NSH). Since the SI value range is from 255 to 0 and decreases by 1, after the forwarding node identifies the value of SI in the NSH, it can use the value of 256-SI as the location information of the node.

[0265] In a possible implementation, the data message includes a segment list, and the forwarding node_i obtains the location information of the node_i on the forwarding path based on the arrangement order of the SID of the node_i in the segment list.

[0266] The segment list is information used to indicate the forwarding path in the SRv6 scenario. The segment list includes a series of SIDs, each of which represents a node or link in the network. The segment list is arranged in reverse order, that is, the SIDs in the segment list are arranged in the order from the tail node to the head node on the forwarding path. Segment list[0] represents the SID corresponding to the tail node in the forwarding path, segment list[1] represents the SID corresponding to the second to last node in the forwarding path, and so on. Segment list[N] represents the SID corresponding to the head node in the forwarding path. In one possible implementation, forwarding node_i obtains the location information of node_i on the forwarding path based on the offset of node_i's SID compared to segment list[N]. Similarly, forwarding node_i can obtain the location information of the upstream node on the forwarding path based on the offset of the upstream node's SID compared to segment list[N].

[0267] In another possible implementation, the data message includes an address list, the address list includes the address of each forwarding node, and the addresses of different forwarding nodes in the address list are arranged in sequence according to the arrangement order of the forwarding nodes in the forwarding path. Forwarding node_i obtains the location information of node_i on the forwarding path based on the arrangement order of the address of node_i in the address list. The address list is, for example, the above-mentioned encrypted routing table.

[0268] In another possible implementation, the controller sends the location information of each forwarding node upstream of the forwarding node on the forwarding path to each forwarding node on the forwarding path. For example, the controller sends the location information of each forwarding node from position 1 to position i in the forwarding path to forwarding node_i, and forwarding node_i receives the location information of each forwarding node from position 1 to position i in the forwarding path sent by the controller.

[0269] In another possible implementation, different forwarding nodes notify each other of their location information. For example, forwarding node_i notifies each forwarding node from forwarding node_i to forwarding node_N of its location information. The upstream node notifies the location information of the node to the downstream node, so that the downstream node can obtain or verify the forwarding proof based on the location information of the upstream node.

[0270] In another possible implementation, the location information of the node and the location information of the forwarding nodes upstream of the node in the forwarding path are configured in advance on the forwarding node. For example, the configuration information stored by the forwarding node_i includes the location information of each forwarding node from the forwarding node_1 to the forwarding node_i in the forwarding path, and the forwarding node_i obtains the location information of each forwarding node from the forwarding node_1 to the forwarding node_i from the configuration information.

[0271] The location information of the forwarding node is in plain text (such as a positive integer) for exemplary purposes only. In another possible implementation, a certain obfuscation mechanism may be used for the location information of the forwarding node, so that the location information obtained and used by the forwarding node is in the form of ciphertext, thereby reducing the risk of location information leakage leading to the leakage of data sources and the identification of key forwarding nodes by attackers.

[0272] The following is an example of how a forwarding node obtains the identity information of the node or the identity information of an upstream node.

[0273] In a possible implementation, the data message carries the identity information of the forwarding node. For example, after forwarding node_i obtains data message_i, it obtains the identity information of forwarding node_i carried by data message_i. If necessary, forwarding node_i also obtains the identity information of each forwarding node from forwarding node_1 to forwarding node_i carried by data message_i.

[0274] In another possible implementation, different forwarding nodes notify each other of their identity information. For example, in the case of verifying a single-point forwarding proof, forwarding node_i notifies forwarding node_i+1 of its identity information. In the case of verifying a multi-point forwarding proof, forwarding node_i notifies each forwarding node from forwarding node_i+1 to forwarding node_N of its identity information. By notifying the identity information of the current node to the downstream node, it is convenient for the downstream node to obtain the forwarding proof or verify the forwarding proof based on the identity information of the upstream node.

[0275] In another possible implementation, the controller distributes identity information to each forwarding node in the forwarding path. For example, in the case of verifying a single-point forwarding proof, the controller notifies the identity information of forwarding node_i-1 to forwarding node_i, and forwarding node_i receives the identity information of forwarding node_i-1 from the controller, so as to verify the single-point forwarding proof of forwarding node_i-1 based on the identity information of forwarding node_i-1. In the case of verifying a multi-point forwarding proof, the controller notifies the identity information of each node from the head node to forwarding node_i-1 to forwarding node_i, and forwarding node_i receives the identity information of each node from the head node to forwarding node_i-1 from the controller, so as to verify the multi-point forwarding proof of forwarding node_i-1 based on the identity information of each node from the head node to forwarding node_i-1.

[0276] In another possible implementation, forwarding node_i obtains the identity information of forwarding node_i-1 from the configuration information stored in forwarding node_i. Alternatively, forwarding node_i obtains the identity information of each node from the head node to forwarding node_i-1 from the configuration information stored in forwarding node_i.

[0277] In a possible implementation, the forwarding node uses the method of carrying the forwarding proof packet by packet to add the forwarding proof of the node to each data message obtained. For example, each data message in a data stream sent by forwarding node_i to forwarding node_i-1 carries the forwarding proof of forwarding node_i. Since each data message has its own independent forwarding proof, each data message can be independently controlled and verified, thereby increasing the monitoring and verification of data messages, making the data transmission process more secure and reliable.

[0278] In another possible implementation, the forwarding node adds the forwarding proof of the node to the first data message in a data flow by carrying the forwarding proof flow by flow. For example, after forwarding node _i obtains the first data flow, it generates the forwarding proof p_i of forwarding node _i, and adds the forwarding proof p_i to the first data message in the first data flow, without adding the forwarding proof p_i to each data message after the first data message in the first data flow. After forwarding node _i+1 receives the first data message in the first data flow, in response to determining that the forwarding proof p_i carried by the first data message has been verified, forwarding node _i+1 saves the identifier of the first data flow and the identifier (such as permit) that allows the data flow to pass in the session table; when forwarding node _i+1 receives each data message after the first data message in the first data flow, it searches the session table based on the identifier of the first data flow carried in the data message, obtains the identifier that allows the data flow to pass, and then further forwards the data message to the next forwarding node _i+2. Alternatively, after forwarding node _i+1 receives the first data message in the first data flow, in response to determining that the forwarding proof p_i carried by the first data message fails to be verified, forwarding node _i+1 saves the identifier of the first data flow and the identifier (such as the word deny) for refusing the data flow to pass in the session table; when forwarding node _i+1 receives each data message after the first data message in the first data flow, it searches the session table based on the identifier of the first data flow carried in the data message, obtains the identifier for refusing the data flow to pass, and then discards the data message. Since the forwarding proof is carried on the first data message of each data flow, the bandwidth and computing resources consumed by each data message carrying the forwarding proof are avoided, thereby improving the network transmission efficiency.

[0279] In another possible implementation, forwarding node_i adds the forwarding proof p_i of the node to every certain number of data packets in the data stream. Taking the interval number as 3 as an example, when the 1st, 4th, and 7th data packets in a data stream pass through forwarding node_i, forwarding node_i will add the forwarding proof p_i of the node to these data packets. Since it is not necessary to add the forwarding proof to each data packet, but to skip adding the forwarding proof after a certain number of data packets, it can reduce network traffic and transmission overhead, and reduce the number of forwarding proofs.

[0280] In another possible implementation, the forwarding node _i records the number of data packets in the first data stream that have been obtained; in response to the number of data packets in the first data stream that have been obtained reaching a quantity threshold, a forwarding proof p_i is added to the next obtained data packet.

[0281] The following is an example of the system architecture of the embodiment of the present application.

[0282] The embodiment of the present application provides a general trusted path protection technology, which can realize the protection of the data plane forwarding path, so it can be applied to any scenario that requires trusted path protection. The scenarios applied by the embodiment of the present application include any level of computer network. For example, the link layer is applicable to Ethernet or MPLS protocol; the network layer is applicable to IPv4 or IPv6 protocol; the tunnel layer is applicable to SRv6, APN, Virtual Extensible LAN (VxLAN) or Internet Protocol Security (internet protocol security, IPSec); the business layer is applicable to the service function chaining (SFC) protocol, etc.

[0283] The difference between different protocol scenarios mainly lies in the message headers carrying commitment and forwarding proof and the specific carrying locations.

[0284] The following first describes the general trusted path protocol steps, functions, and roles, and then gives examples of the differences in scenarios where different protocols are applied.

[0285] Any scenario that requires a trusted path involves the roles of controller, forwarding node, and observer.

[0286] The controller is used to generate a vector commitment corresponding to a specified forwarding path and output the vector commitment.

[0287] In one possible implementation of output vector commitment, the controller sends a vector commitment to the observer so that the observer can verify the forwarding proof based on the received vector commitment. For example, the controller sends a data message to the observer, the data message includes a vector commitment, and the observer obtains the vector commitment carried by the received data message. For another example, the controller sends a control plane message to the observer, the control plane message includes a vector commitment, and the observer obtains the vector commitment carried by the received control plane message.

[0288] In another possible implementation of outputting the vector commitment, the controller saves the correspondence between the identifier of the forwarding path and the vector commitment in a database, so that an observer can obtain the vector commitment from the database based on the identifier of the forwarding path, and then verify the forwarding proof based on the vector commitment.

[0289] Optionally, the controller saves the corresponding relationship between the identifier of the forwarding path and the vector commitment in the blockchain system. Since the blockchain system stores data in a decentralized manner, the probability of vector commitment being tampered with or eavesdropped is reduced, the data security of vector commitment is improved, and the integrity of vector commitment is effectively protected. In addition, the method of publicly storing vector commitment provides traceability and auditability of the path and calculation results. Alternatively, the controller saves the corresponding relationship between the identifier of the forwarding path and the vector commitment in other types of distributed shared databases outside the blockchain.

[0290] The controller is, for example, a computing device, for example, a server. The controller may optionally obtain identity information of all forwarding nodes in advance before generating the commitment.

[0291] If necessary, the controller can choose to perform key pre-distribution for 1 to N forwarding nodes so that the forwarding node can decrypt the encrypted routing table based on the issued key to determine the next hop of the node; if necessary, the controller can choose to perform remote attestation secret distribution, and the secret is the identity information of the forwarding node in ciphertext form.

[0292] A forwarding node is a node device included in a forwarding path. For example, a forwarding node is a network device, such as a switch, a router, or a firewall. For example, a forwarding node is a computing device, such as a server or a terminal. A forwarding node is a physical device or a virtual device. A forwarding node is a minimum atomic node. In the network hierarchy where the forwarding node is located, there is no secondary node at a lower level than the forwarding node so that data can be forwarded through it without being discovered.

[0293] In one possible implementation, after a forwarding node obtains a data message, in response to determining that the data message needs to be forwarded through a trusted forwarding path, it participates in the calculation of a forwarding proof. In one possible implementation, when a forwarding node_i obtains a data message, in response to recognizing that the message header of the data message includes a trusted path identifier, the forwarding node_i calculates a forwarding proof p_i and discloses the forwarding proof p_i to an observer.

[0294] In a possible implementation, the forwarding proof p_i is a single-point proof, and the forwarding proof p_i is used to prove that the forwarding node _i at position i forwarded the data message.

[0295] In another possible implementation, the forwarding proof p_i is a multi-point proof, and the forwarding proof p_i is used to prove that each forwarding node (r_1, r_2, ..., r_i) in the forwarding path from position 1 to position i has forwarded the data message at the correct position.

[0296] The observer represents the world with public information. The observer can be any device that cares about the credibility of this forwarding path. The observer is used to verify the forwarding proof calculated by the forwarding node based on the commitment C generated by the controller, the identity of the forwarding node, and the location of the forwarding node. In one possible implementation, the observer is unbiased, that is, the observer's observation and verification results are the same as the output of the protocol under correct circumstances.

[0297] In a possible implementation, the observer is separated from the forwarding node in the forwarding path and is set on different hardware devices. The observer does not need to undertake the task of message forwarding. The observer is deployed outside the forwarding path.

[0298] In another possible implementation, the observer and the forwarding node are integrated on the same hardware device, which is responsible for forwarding the message and verifying the forwarding proof. In other words, the forwarding node also plays the role of the observer.

[0299] In a possible implementation, the process of obtaining the forwarding certificate includes the following steps 1 to 4.

[0300] Step 1: path selection. In one possible implementation, the controller selects the forwarding path. In another possible implementation, the terminal selects the forwarding path, and the terminal notifies the controller of the selected forwarding path.

[0301] Step 2: Commitment calculation. For example, the controller obtains the vector commitment of the forwarding path based on the location information of each node in the forwarding path and the identity information of each node in the forwarding path.

[0302] For example, a forwarding path including N forwarding nodes is represented as a vector P = (r_1, r_2, ..., r_N), where r_i represents the identity information of the forwarding node. The controller calculates the vector commitment C corresponding to this path based on the commitment function C = Commit(P) based on the identity information r_i of each forwarding node in the N forwarding nodes and the location information of each forwarding node.

[0303] In a possible implementation, according to the verification algorithm of the vector commitment, if the verification result of the commitment C, position i, identity r_i and related auxiliary data for the forwarding proof is 1, it means that the forwarding proof is verified. If the verification result of the commitment C, position i, identity r_i and related auxiliary data for the forwarding proof is 0, it means that the forwarding proof is not verified. The auxiliary data is, for example, the cryptographic parameters based on which the commitment is calculated.

[0304] In a possible implementation, before forwarding a data message, the controller distributes the public parameters and auxiliary data required for calculating the forwarding proof to each forwarding node in the forwarding path.

[0305] Step 3: Forward proof calculation.

[0306] In one possible implementation, a data message carrying a trusted path identifier begins to be transmitted. When forwarding node_i receives the data message and identifies the trusted path identifier, forwarding node_i calculates a forwarding proof p_i. In one possible implementation, forwarding node_i adds the forwarding proof p_i to the data message, so that the forwarding proof p_i continues to be transmitted along with the data message. In another possible implementation, forwarding node_i separately discloses the forwarding proof p_i to the outside world. For example, forwarding node_i generates a message based on forwarding proof p_i, and the message includes forwarding proof p_i. Forwarding node_i sends a message including forwarding proof p_i to an observer, thereby notifying the observer of the forwarding proof p_i.

[0307] In a possible implementation, forwarding node_i obtains forwarding proof p_i based on the identity information of forwarding node_i, the location information of forwarding node_i and cryptographic parameters. Forwarding proof p_i is a single-point forwarding proof, and forwarding proof p_i is used to prove that forwarding node_i forwarded the data message at position i. Optionally, forwarding node_i uses a single-point open function (Open) to obtain forwarding proof p_i, p_i = Open (i, r_i).

[0308] In another possible implementation, forwarding node_i obtains forwarding proof p_i based on the identity information of each node from node_1 to node_i, the location information of each node from node_1 to node_i, and cryptographic parameters. Forwarding proof p_i is a multi-point forwarding proof. Forwarding proof p_i is used to prove that node_1 forwards a data message at position 1, node_2 forwards a data message at position 2... and node_i forwards this data message at position i. Optionally, forwarding node_i uses a batch open function (BatchOpen) to obtain forwarding proof p_i, p_i = BatchOpen (r_1,..., r_i).

[0309] Step 4: Forward proof verification.

[0310] The observer receives the commitment C, the forwarding proof p_i, and the node set B corresponding to the forwarding proof p_i. The node set B includes one or more nodes in the forwarding path. The observer verifies the correctness of the forwarding proof based on the commitment C, the forwarding proof p_i, the node set B, and other auxiliary data.

[0311] For example, in the scenario of verifying a single-point forwarding proof, the observer verifies the forwarding proof p_i based on the commitment C, the identity information of the forwarding node_i, the location information of the forwarding node_i, and the cryptographic parameters. The forwarding proof p_i is a single-point forwarding proof. Optionally, the forwarding node_i verifies the forwarding proof p_i using a verification function (verify). For example, if Verify(C,p_i,i,r_i)=1, the verification passes; if Verify(C,p_i,i,r_i)=0, the verification fails, where C represents commitment, p_i represents the forwarding proof of forwarding node_i, r_i represents the identity information of forwarding node_i, and i represents the location information of forwarding node_i. Verify(C,p_i,i,r_i)=1 indicates that the commitment, the forwarding proof of forwarding node_i, the identity information of forwarding node_i and the location information of forwarding node_i correspond to each other; Verify(C,p_i,i,r_i)=0 indicates that the commitment, the forwarding proof of forwarding node_i, the identity information of forwarding node_i and the location information of forwarding node_i do not correspond to each other.

[0312] For example, in the scenario of verifying multi-point forwarding proof, the observer verifies the forwarding proof p_i based on the commitment C, the identity information of each forwarding node in the node set B, the location information of each forwarding node in the node set B, and the cryptographic parameters. The forwarding proof p_i is a multi-point forwarding proof. Optionally, the forwarding node_i verifies the forwarding proof p_i using a batch verification function. For example, if batch verify(C,p_i,B,r_B)=1, the verification passes; if batch verify(C,p_i,B,r_B)=1=0, the verification fails, where C represents commitment, p_i represents the forwarding proof of forwarding node_i, B represents the location information of each forwarding node in the node set B, and r_B represents the identity information of each forwarding node in the node set B. batch verify(C,p_i,B,r_B)=1 indicates that the commitment, the forwarding proof of forwarding node_i, the identity information of each forwarding node in the node set B, and the location information of each forwarding node in the node set B correspond to each other; batch verify(C,p_i,B,r_B)=0 indicates that the commitment, the forwarding proof of forwarding node_i, the identity information of each forwarding node in the node set B, and the location information of each forwarding node in the node set B do not correspond to each other.

[0313] Regarding the timing of verifying the forwarding proof, in one possible implementation, a real-time verification method is adopted. Whenever a data packet has passed through a forwarding step, the step of verifying the forwarding proof is executed along with the forwarding step. The real-time in real-time verification means that the time point of verifying the forwarding proof is real-time relative to the time point of receiving the data packet. For example, if any forwarding node on a trusted forwarding path receives a data packet containing a forwarding proof, the forwarding node verifies the forwarding proof carried in the data packet. For another example, if any forwarding node on a trusted forwarding path receives a data packet, the forwarding node generates a forwarding proof and sends the forwarding proof to the observer. In another possible implementation, a one-time verification can also be performed after all the data packet forwarding steps are completed.

[0314] The following is an example of where the forwarding proof is carried in a message when the forwarding proof is carried in a data message.

[0315] In the case of transmitting data based on the IPv6 protocol, in one possible implementation, the forwarding proof is carried by an IPv6 extension header. For example, the forwarding proof is carried by a segment routing header (SRH). For another example, the forwarding proof is carried by a hop-by-hop options header (HBH). For another example, the forwarding proof is carried by a destination options header (DOH). SRH, HBH and DOH are three specific examples of IPv6 extension headers that can carry forwarding proofs.

[0316] Optionally, the forwarding proof is carried by a type-length-value (TLV) in an IPv6 extension header. For example, the forwarding proof is carried by a TLV in an SRH. For another example, the forwarding proof is carried by a TLV in an HBH. For another example, the forwarding proof is carried by a TLV in a DOH.

[0317] In the case of data transmission based on the APN6 protocol, in a possible implementation, the forwarding proof is carried through the APN message header. For example, the forwarding proof is carried through the application-aware network identifier (APN ID) in the APN message header. In the case of data transmission based on the VxLAN protocol, in a possible implementation, the forwarding proof is carried through the VxLAN header, which is suitable for scenarios such as virtualized networks based on the VxLAN protocol or cross-data center interconnection, and provides the function of verifying the source of data in the VxLAN tunnel. In the case of data transmission based on the IPSec protocol, in a possible implementation, the forwarding proof is carried through the IPSec header, so that the data source can be verified and securely transmitted under the IPSec protocol. This method is suitable for scenarios such as virtual private networks (VPNs) or secure communications based on the IPSec protocol, and provides the ability to verify the source of data in the IPSec tunnel. In the case of data transmission based on the MPLS protocol, in a possible implementation, the forwarding proof is carried through the MPLS header. For example, the forwarding path includes a label switching path, and each node in the node_1, node_2...node_N in the forwarding path includes an LSR in the label switching path, so as to verify the source of data and secure transmission under the MPLS protocol. This method is suitable for scenarios such as multi-layer label switching, service provider networks or cross-domain communications based on the MPLS protocol, and provides a mechanism for verifying the source of data in the MPLS network. In the case of transmitting data based on the SFC protocol, in a possible implementation method, the forwarding proof is carried by the NSH. For example, the forwarding proof is carried by the metadata field in the NSH.

[0318] The following is an example of where the vector commitment is carried in a data message, in which the vector commitment is carried in the message.

[0319] In the case of transmitting data based on the IPv6 protocol, in a possible implementation, the vector commitment is carried through an IPv6 extension header. For example, the vector commitment is carried through an SRH. For another example, the vector commitment is carried through an HBH. For another example, the vector commitment is carried through a DOH. SRH, HBH and DOH are specific examples of three IPv6 extension headers that can carry vector commitments.

[0320] Optionally, the vector commitment is carried by a TLV in an IPv6 extension header. For example, the vector commitment is carried by a TLV in an SRH. For another example, the vector commitment is carried by a TLV in an HBH. For another example, the vector commitment is carried by a TLV in a DOH.

[0321] In the case of transmitting data based on the APN6 protocol, in a possible implementation, the vector commitment is carried through the APN message header. For example, the vector commitment is carried through the APN ID in the APN message header. In the case of transmitting data based on the VxLAN protocol, in a possible implementation, the vector commitment is carried through the VxLAN header. In the case of transmitting data based on the IPSec protocol, in a possible implementation, the vector commitment is carried through the IPSec header. In the case of transmitting data based on the MPLS protocol, in a possible implementation, the vector commitment is carried through the MPLS header. In the case of transmitting data based on the SFC protocol, in a possible implementation, the vector commitment is carried through the NSH. For example, the vector commitment is carried through the metadata field in the NSH.

[0322] In a possible implementation, the forwarding proof and the vector commitment are carried in different fields in the same message header. For example, forwarding node _i sends data message _i+1 to forwarding node _i+1.

[0323] Exemplarily, data message _i+1 includes an IPv6 extension header, and the IPv6 extension header includes a forwarding proof of forwarding node _i and the vector commitment. For example, the IPv6 extension header of data packet _i+1 includes an SRH, the SRH includes a first TLV and a second TLV, the first TLV of the SRH includes a forwarding proof of the forwarding node _i, and the second TLV of the SRH includes the vector commitment; or, the IPv6 extension header of data packet _i+1 includes an APN header, the APN header includes an APN ID, the APN ID includes a forwarding proof of the forwarding node _i and the vector commitment; or, the IPv6 extension header of data packet _i+1 includes a DOH, the DOH includes a first TLV and a second TLV, the first TLV of the DOH includes a forwarding proof of the forwarding node _i, and the second TLV of the DOH includes the vector commitment; or, the IPv6 extension header of data packet _i+1 includes an HBH, the HBH includes a first TLV and a second TLV, the first TLV of the HBH includes a forwarding proof of the forwarding node _i, and the second TLV of the HBH includes the vector commitment.

[0324] Exemplarily, data packet _i+1 includes NSH, the NSH includes a metadata field, the metadata field includes the forwarding proof of forwarding node _i and the vector commitment; or, data packet _i+1 includes an MPLS header, the MPLS header includes the forwarding proof of forwarding node _i and the vector commitment; or, data packet _i+1 includes a VxLAN header, the VxLAN header includes the forwarding proof of forwarding node _i and the vector commitment; or, data packet _i+1 includes an IPsec header, the IPsec header includes the forwarding proof of forwarding node _i and the vector commitment.

[0325] By placing the forwarding proof and vector commitment in the same message header, it helps to simplify the format and structure of the message. In this way, there is no need for an additional header to carry the forwarding proof and vector commitment separately, reducing the complexity and redundancy of the message. In addition, placing the forwarding proof and vector commitment in the same message header can simplify the node's processing logic for the message. For example, after receiving the data message _i+1, node_i only needs to parse the message header once to obtain the forwarding proof and vector commitment information. In this way, the processing logic of node_i is clearer and simpler, reducing the complexity of the processing process.

[0326] The verification mode of the forwarding proof provided in the embodiment of the present application is described below. The embodiment of the present application provides three verification modes of the forwarding proof, and the protocol steps and data message headers are slightly different in different verification modes. The three verification modes of the forwarding proof include real-time verification (Postcard) mode, on-path verification (Passport) mode, and end-point verification (Final_only) mode. The real-time verification mode includes an OP sub-mode and an MP sub-mode, the on-path verification mode includes an OP sub-mode and an MP sub-mode, and the end-point verification mode includes an MP sub-mode. Each mode is illustrated below with examples. In order to distinguish between the description of the forwarding node and the observer being integrated into the same hardware device and the forwarding node and the observer being separately set on different hardware devices, the device deployed outside the forwarding path and acting as an observer is referred to as a verification node. The verification node is, for example, a computing device, and the forwarding node is, for example, a server or a terminal.

[0327] Verification mode 1: Real-time verification (Postcard) mode

[0328] In real-time verification mode, the verification node is deployed outside the forwarding path, and the verification node and the forwarding node in the forwarding path are separated and set on different hardware devices. For example, please refer to Figure 1 , the verification node is, for example, Figure 1 The observer in the verification node communicates with Figure 1The head node, forwarding node_2, forwarding node_3 and forwarding node_4 in are connected. In a possible implementation, the verification node is Figure 1 Controller in .

[0329] exist Figure 2 In the method shown, the verification node is, for example, a device other than the nodes in the forwarding path (such as the head node, forwarding node_2, and forwarding node_3). Figure 2 The controller in the method shown is integrated with the verification node on the same device. In other words, the controller not only performs the steps of obtaining vector commitment and sending vector commitment in S210, but also performs the step of verifying forwarding proof in S240.

[0330] When forwarding node_i processes a data message, it obtains a forwarding proof p_i and sends the forwarding proof p_i to the verification node; when the verification node receives the forwarding proof p_i from the forwarding node_i, it verifies the forwarding proof p_i in real time; the forwarding node downstream of the forwarding node_i on the forwarding path does not need to verify the forwarding proof p_i. Optionally, the forwarding node downstream of the forwarding node_i verifies the correctness of the source of the data message based on other methods other than vector commitment, such as aggregatable signatures or symmetric key MAC tags.

[0331] When the OP sub-mode included in the real-time verification mode is adopted, each node in the forwarding path obtains the single-point forwarding proof OP of the node based on the position and identity of the node, and sends the single-point forwarding proof OP of the node to the verification node. When calculating the single-point forwarding proof OP of the node, the identity of the node is required but the identities of one or more nodes before the forwarding node _i on the forwarding path are not required.

[0332] When the MP sub-mode included in the real-time verification mode is adopted, each node in the forwarding path obtains the identity of each node upstream of the node in the forwarding path (for example, identity information r_1 to identity information r_i-1) and the identity of the node based on the control plane, data message or other means, obtains the multi-point forwarding proof MP of the node based on the identity of the node and the identity of each node upstream of the node (for example, identity information r_1 to identity information r_i), and sends the multi-point forwarding proof MP of the node to the verification node.

[0333] Figure 1 It is a schematic diagram of a verification scenario of forwarding proof in a real-time verification mode provided by an embodiment of the present application. Figure 1 The scenario shown is illustrated by taking the forwarding path including four forwarding nodes as an example. The number of forwarding nodes in the forwarding path may be more or less. For example, the number of forwarding nodes in the forwarding path may be only two, or the number of forwarding nodes in the forwarding path may be dozens or hundreds, or more.

[0334] Figure 2 It is a schematic diagram of a method for obtaining and verifying a forwarding certificate in a real-time verification mode provided in an embodiment of the present application. Figure 2 The network deployment scenario based on the method shown is optionally as described above. Figure 1 shown. Figure 2 The forwarding node_3 shown is an optional node device, and the forwarding path may also only include the head node and the forwarding node_2.

[0335] Figure 2 The processing flow of forwarding proof shown includes the following S210 to S240.

[0336] S210, the controller sends a vector commitment to the verification node.

[0337] In (a) of S210, the controller obtains the identity information of each forwarding node and the location information of each node in a forwarding path of length N. The controller obtains a vector P=(r_1, r_2, ..., r_N) composed of N forwarding nodes. Where r_i represents the identity information of forwarding node_i, and i represents the location information of forwarding node_i. The controller calculates the vector commitment based on the identity information of each forwarding node in the forwarding path and the location information of each node.

[0338] In (b) of S210, the controller uses the vector commitment mechanism to calculate a commitment C = commit(P) for a bound forwarding path P = (r_1, r_2, ..., r_N). The controller also calculates an encrypted routing table T for the forwarding path P = (r_1, r_2, ..., r_N). The controller pre-distributes other public parameters and auxiliary data required to calculate the forwarding proof to each node in the forwarding path.

[0339] In (c) of S210, the controller sends a commitment C to the verification node. The length of the commitment C is k. k is related to the security parameter lambda.

[0340] S220, the head node in the forwarding path sends a data message to the second forwarding node in the forwarding path, and sends a forwarding certificate to the verification node.

[0341] In (a) of S220 , the head node obtains the commitment C, the encrypted routing table T and the payload data (payload). The head node generates a data message_1 according to the payload data, and the data message_1 includes the payload data.

[0342] In (b) of S220 , the head node calculates its own forwarding proof OP_1 using the Open function; or, the head node calculates its own forwarding proof MP_1 using the BatchOpen function.

[0343] In (c) of S220 , the head node sends its single-point forwarding certificate OP_1 to the verification node; alternatively, the head node sends its multi-point forwarding certificate MP_1 to the verification node.

[0344] In a possible implementation, the head node decrypts the first routing table entry of the encrypted routing table T based on the key of the head node to obtain the identifier of the forwarding node_2; and the head node adds the remaining encrypted routing table T after the first routing table entry in the encrypted routing table T to the data message_1 to obtain the data message_2; the head node sends the data message_2 to the forwarding node_2 based on the identifier of the forwarding node_2, and the data message_2 includes a protocol message header, and the protocol message header includes a trusted path identifier. In addition, the head node sends a single-point forwarding certificate OP_1 or a multi-point forwarding certificate MP_1 to the verification node.

[0345] S230, forwarding node_i sends data message_i+1 to forwarding node_i+1, and sends forwarding proof_i to the verification node.

[0346] In (a) of S230, forwarding node_i receives data message_i, data message_i includes a protocol message header, and the protocol message header includes a trusted path identifier. Optionally, data message_i also includes identity information r_i of forwarding node_i and location information i of forwarding node_i. Optionally, data message_i also includes identity information and location information of nodes node_1 to node_i-1.

[0347] In (b) of S230, forwarding node_i verifies the correctness of the source of data message_i based on other aggregatable proof methods other than vector commitment (such as cryptographic aggregator, aggregatable signature, MAC tag); if the verification is successful, the intermediate node uses the identity information r_i of this node and the position i of this node in the path as input to calculate a single-point forwarding proof OP_i; or, if the verification is successful, forwarding node_i uses the identity information of each node from node r_1 to r_i to calculate a multi-point forwarding proof MP_i. If the verification fails, forwarding node_i discards the data message. In addition, forwarding node_i decrypts the routing table entry corresponding to forwarding node_i in the encrypted routing table T based on the key of forwarding node_i, obtains the identifier of the next node r_i+1, and forwarding node_i replaces the encrypted routing table T in the data message_i with the remaining encrypted routing table entries after the routing table entry corresponding to forwarding node_i in the encrypted routing table T, and obtains data message_i+1.

[0348] In step (c) of S230, the forwarding node _i sends a data message to the next node _i+1 based on the identifier of the next node _i+1.

[0349] _i+1, data message _i+1 includes a protocol message header, and the protocol message header includes a trusted path identifier. In addition, the forwarding node _i sends a single-point forwarding proof OP_i or a multi-point forwarding proof MP_i to the verification node.

[0350] S240, the verification node verifies the forwarding proof from the forwarding node.

[0351] In (a) of S240, the verification node obtains input data, the input data includes the commitment C, the single-point forwarding proof OP_i from the forwarding node_i, the current position i of the forwarding node_i in this path, and the identity information of the forwarding node_i. Alternatively, the input data includes the commitment C, the multi-point forwarding proof MP_i from the forwarding node_i, the current position of each node from the head node_1 to the forwarding node_i in this path, and the identity information of each node from the head node_1 to the forwarding node_i.

[0352] In (b) of S240 , the verification node verifies the forwarding proof based on the input data.

[0353] If the forwarding proof is a single-point forwarding proof OP_i, the verification node verifies Verify(C,i,r_i,OP_i) according to the vector commitment mechanism, that is, verifies that the identity of the i-th node is r_i.

[0354] If the forwarding proof is a multi-point forwarding proof MP_i, the verification node verifies batchverify(C,B,r_B,MP_i) according to the vector commitment mechanism, where B=(r_1,r_2,…,r_i)

[0355] In (c) of S240 , the verification node controls forwarding of the data message or outputs alarm information based on the verification result.

[0356] Regarding the way in which the verification node controls the forwarding of data messages, in some possible implementations, in response to the forwarding proof P_i failing the verification, the verification node sends a first notification message to the forwarding node_i from which the forwarding proof P_i comes. The first notification message is used to instruct the forwarding node_i to discard the data message. In response to the received first notification message, the forwarding node_i discards the obtained data message_i, thereby blocking the data with illegal sources from being further transmitted from the forwarding node_i to the forwarding node_i+1, thereby improving network security. In some other possible implementations, in response to the forwarding proof P_i passing the verification, the verification node sends a second notification message to the forwarding node_i from which the forwarding proof P_i comes. The second notification message is used to instruct the forwarding node_i to forward the data message. In response to the received second notification message, the forwarding node_i performs the above-mentioned step of sending the data message_i+1 to the next node_i+1 based on the identifier of the next node_i+1.

[0357] With respect to the protocol message based on which the verification node interacts with the forwarding node_i, in some possible implementations, the verification node notifies the forwarding node_i to discard the data message or forward the data message based on the control plane protocol such as the border gateway protocol flow spec (BGP flow specification, referred to as BGP flow spec or BGP FS), path computation element protocol (PCEP), BGP monitoring protocol (BGP monitoring protocol, BMP), network flow (netstream) protocol or border gateway protocol (BGP). For example, the first notification message or the second notification message is a BGP flow spec message, a PCEP message, a BMP message, a netstream protocol message or a BGP message.

[0358] Taking the interaction between the verification node and the forwarding node_i based on the BGP flow spec protocol as an example, for example, the first notification message and the second notification message are BGP flow spec protocol messages. The first notification message includes a network layer reachability information (NLRI) field and an extended group attribute field, the NLRI field includes an identifier of a data message that fails the forwarding proof verification, and the extended group attribute field includes an identifier indicating that the message is discarded. The second notification message includes an NLRI field and an extended group attribute field, the NLRI field includes an identifier of a data message that passes the forwarding proof verification, and the extended group attribute field includes an identifier indicating that the message is forwarded.

[0359] In a possible implementation, in response to determining that the forwarding proof fails verification, the verification node outputs an alarm message. For details of the verification node outputting the alarm message, please refer to the above description of the forwarding node outputting the alarm message.

[0360] In a possible implementation, if the verification is successful, the verification node outputs 1, indicating that the data message is in the trusted path and has passed the correct location. If the verification is unsuccessful, the verification node outputs 0, indicating that the data message is not in the trusted path or has not passed the correct location.

[0361] The forwarding node repeatedly executes S230, and the verification node repeatedly executes S240 until the message transmission is completed.

[0362] By adopting a real-time verification mode, each forwarding node calculates and publishes the forwarding proof, so that the identity of each node is verified, providing hop-by-hop security, and high security. Since each forwarding node calculates and publishes the forwarding proof when processing data packets, observers can obtain and verify these forwarding proofs in real time, realizing real-time transparent tracking of the data transmission process. In addition, the attack window is small. In addition, by using a vector commitment mechanism and a suitable verification algorithm, public auditing of commitments and forwarding proofs can be achieved. Observers can verify the correctness of the commitment and whether the forwarding proof of each node matches the identity of the node and the location of the node, thereby improving the security of the data transmission process.

[0363] Verification mode 2: Passport mode

[0364] In the on-path verification mode, forwarding node _i also acts as an observer. Before calculating its own forwarding proof p_i, forwarding node _i verifies the forwarding proof p_i-1 of the previous node _i-1, thereby reducing the risk of incorrect data message source.

[0365] For example, see Figure 3 , Figure 3 The forwarding nodes 2, 3 and 4 in the table are all verification nodes. Figure 3 The forwarding proof p_1 of the head node is verified. Figure 3 The forwarding proof p_2 of forwarding node_2 is verified. Figure 3 For example, please refer to Figure 4 , Figure 4 Forwarding Node_2 and Forwarding Node_3 are both verification nodes.

[0366] The forwarding proof p_i is, for example, a single-point proof OP, or a multi-point proof MP. In addition, when forwarding node_i processes a data message, forwarding node_i obtains a forwarding proof p_i based on the location information of forwarding node_i and the identity information of forwarding node_i; forwarding node_i sends data message_i+1 to forwarding node_i+1, and data message_i+1 includes forwarding proof p_i. Since the sent data message carries the forwarding proof, the forwarding proof is forwarded to the next node_i+1 along the way with the data message, so that the next node verifies the forwarding proof p_i.

[0367] In a possible implementation, forwarding node _i uses forwarding proof p_i to replace forwarding proof p_i-1 carried in data message _i to obtain data message _i+1. By replacing the forwarding proof of the previous hop with the forwarding proof of this node, the message does not need to store the forwarding proof of each node that has passed, thereby avoiding the increase in the number of message bytes occupied by the proof as the number of nodes increases, saving message space. In addition, since the data message only needs to carry the proof of one node during the forwarding process, instead of the proof of multiple nodes, the network resources required for the transmission of the proof are saved.

[0368] In another possible implementation, forwarding node _i adds forwarding proof p_i to data message _i to obtain data message _i+1.

[0369] In the OP sub-mode of the associated verification mode, the data message may optionally carry the identity information r_i-1 of the previous hop node.

[0370] In the MP sub-mode of the associated verification mode, each forwarding node may optionally learn the identity information of the upstream nodes r_1 to r_i-1 on the control plane or by other means.

[0371] Figure 3 It is a schematic diagram of a verification scenario for forwarding proof in an on-path verification mode provided in an embodiment of the present application. Figure 3 The scenario shown is illustrated by taking a forwarding path including four forwarding nodes as an example. Figure 3 The scenario shown is illustrated by taking the forwarding path including four forwarding nodes as an example. The number of forwarding nodes in the forwarding path may be more or less. For example, the number of forwarding nodes in the forwarding path may be only two, or the number of forwarding nodes in the forwarding path may be dozens or hundreds, or more.

[0372] Figure 4 It is a schematic diagram of a method for obtaining and verifying a forwarding certificate in an on-path verification mode provided in an embodiment of the present application. Figure 4 The method includes the following steps S310 to S340 . Figure 4 The network deployment scenario based on the method shown is optionally as described above. Figure 3 shown. Figure 4 The forwarding node_3 shown is an optional node device, and the forwarding path may also only include the head node and the forwarding node_2.

[0373] S310, the controller sends a vector commitment.

[0374] In (a) of S310 , the controller obtains location information of each node in the forwarding path and identity information of each node in the forwarding path.

[0375] In (b) of S310 , the controller obtains a vector commitment based on the location information and identity information of each node in the forwarding path.

[0376] In (b) of S310 , the controller sends a vector commitment to each forwarding node in the forwarding path.

[0377] S320, the head node sends a data message _2 to the second node, where the data message _2 includes a forwarding proof p_1.

[0378] In (a) of S320 , the head node obtains input data, where the input data includes a commitment C, an encrypted routing table T of length N, and payload data (payload).

[0379] In (b) of S320, the head node generates a data message _1 according to the payload data, and the data message _1 includes the payload data; and the head node calculates its own single-point forwarding proof OP_1 using an open function; or the head node calculates its own multi-point forwarding proof MP_1 using a batch open function; the head node adds the single-point forwarding proof OP_1 or the multi-point forwarding proof MP_1 to a protocol message header including a trusted path identifier, and adds the protocol message header to the data message _1;

[0380] Furthermore, the head node decrypts the first routing table entry of the encrypted routing table T based on the key of the head node to obtain the identifier of the second node r_2; and the head node adds the remaining encrypted routing table T after the first routing table entry in the encrypted routing table T to data message _1 to obtain data message _2.

[0381] In (c) of S320, the head node sends data message 2 to forwarding node 2 based on the identifier of the second node r_2, and data message 2 includes a protocol message header. The protocol message header includes a trusted path identifier. The protocol message header also includes a single-point forwarding proof OP_1 or a multi-point forwarding proof MP_1.

[0382] S330, forwarding node_i verifies forwarding proof_i-1 carried by data message_i.

[0383] In (a) of S330, forwarding node_i receives data message_i, data message_i includes a protocol message header, the protocol message header includes a trusted path identifier, and the protocol message header also includes a single-point forwarding proof OP_i-1 or a multi-point forwarding proof MP_i-1. Optionally, data message_i also includes identity information r_i of forwarding node_i and location information i of forwarding node_i. Optionally, data message_i also includes identity information and location information from node_1 to node_i-1.

[0384] In (b) of S330, node i verifies the data source verification based on the correctness of the single-point forwarding proof OP_i-1 carried in the message header of the authentication data message _i of the previous hop node r_i-1. In another possible implementation, node i verifies the data source verification based on the correctness of the multi-point forwarding proof MP_i-1 carried in the message header of the authentication data message _i from node r_1 to r_i-1. In addition, the data message source verification step can also use other aggregatable proof methods, such as a cryptographic aggregator (accumulator), an aggregatable signature or a MAC tag, etc.

[0385] S340, when the forwarding proof _i-1 is verified, the forwarding node _i sends the data message _i+1 to the next node r_i+1 based on the identifier of the next node r_i+1.

[0386] In (a) in S340, if the forwarding proof _i-1 is verified, the forwarding node i uses the identity information r_i of node i and the position information i of the forwarding node i in the forwarding path as input to calculate the single-point forwarding proof OP_i; or, if the forwarding proof _i-1 is verified, the forwarding node i uses the identity information of each forwarding node from the head node _1 to the forwarding node _i and the position information of each forwarding node from the head node _1 to the forwarding node _i to calculate a multi-point forwarding proof MP_i.

[0387] In (b) of S340, the forwarding node _i uses the single-point forwarding proof OP_i to replace the single-point forwarding proof OP_i-1 in the message header to obtain the data message _i+1; or, the forwarding node _i replaces the multi-point forwarding proof MP_i-1 in the message header based on the multi-point forwarding proof MP_i to obtain the data message _i+1. Optionally, the forwarding node _i also decrypts the routing table entry corresponding to the forwarding node _i in the encrypted routing table T based on the key of the forwarding node _i to obtain the identifier of the next node _i+1, and the forwarding node _i replaces the encrypted routing table T in the data message _i with the remaining encrypted routing table entries after the routing table entry corresponding to the forwarding node _i in the encrypted routing table T, and adds the identity information r_i of the forwarding node _i to the data message _i.

[0388] If the forwarding proof_i-1 fails to be verified, the forwarding node i discards the data message.

[0389] In (c) of S340, the forwarding node _i sends a data message _i+1 to the next node r_i+1 based on the identifier of the next node r_i+1, and the data message _i+1 includes a protocol message header, and the protocol message header includes a trusted path identifier. The protocol message header also includes a single-point forwarding proof OP_i or a multi-point forwarding proof MP_i.

[0390] By adopting the on-path verification mode, each forwarding node calculates and publishes the forwarding proof, so that the identity of each node is verified, providing hop-by-hop security, and high security. In addition, the forwarding proof can be included in the message header on-path, with moderate calculation and communication costs, and moderate protocol flow and complexity, which is a compromise solution.

[0391] Each forwarding node in the forwarding path repeatedly executes S330 to S340 until the message transmission is completed.

[0392] Verification mode three, final_only mode

[0393] In the endpoint verification mode, the tail node in the forwarding path also acts as an observer. The tail node obtains the forwarding proof based on the location information of each forwarding node (including the tail node itself) and the identity information of each forwarding node in the forwarding path, and verifies the obtained forwarding proof. For example, please refer to Figure 5 , Figure 5 It is a schematic diagram of a verification scenario of forwarding proof in an endpoint verification mode provided in an embodiment of the present application. Figure 5 The scenario shown is illustrated by taking a forwarding path including four forwarding nodes as an example. Figure 5 The forwarding node_4 in the forwarding path is a specific example of a tail node that acts as a verification node. The number of forwarding nodes in the forwarding path can be more or less. For example, the number of forwarding nodes in the forwarding path can be only two, and the second forwarding node in the forwarding path (such as Figure 5 Node_2) in the forwarding path acts as a verification node. Alternatively, the number of forwarding nodes in the forwarding path is dozens or hundreds, or more.

[0394] Figure 6 It is a schematic diagram of a method for obtaining and verifying a forwarding certificate in an endpoint verification mode provided in an embodiment of the present application. Figure 6 The method includes the following steps S410 to S440 . Figure 6 The network deployment scenario based on the method shown is optionally as described above. Figure 5 shown.

[0395] In a possible implementation, the processing flow of forwarding proof in the endpoint verification mode includes the following S410 to S440.

[0396] S410, the controller sends a vector commitment.

[0397] In (a) of S410 , the controller obtains location information of each forwarding node in the forwarding path and identity information of each forwarding node in the forwarding path.

[0398] In (b) of S410 , the controller obtains a vector commitment based on the location information of each forwarding node and the identity information of each forwarding node.

[0399] In (c) of S410 , the controller sends a vector commitment to the tail node in the forwarding path.

[0400] S420, the head node sends data message 2 to forwarding node_2.

[0401] In S420 (a), the head node obtains input data, where the input data includes a commitment C, an encrypted routing table T with a length of N, and payload data (payload).

[0402] In (b) of S420 , the head node generates a data message _1 according to the payload data, where the data message _1 includes the payload data; and the head node decrypts the first routing table entry of the encrypted routing table T based on the key of the head node to obtain the identifier of the second node r_2 .

[0403] In (c) of S420, the head node sends data message 2 to forwarding node _2 based on the identifier of the second node r_2, and data message 2 includes a protocol message header, which includes a trusted path identifier and a single-point forwarding certificate OP_1 or a multi-point forwarding certificate MP_1.

[0404] S430, forwarding node _i sends data message _i+1 to the next node r_i+1.

[0405] The forwarding node_i forwards the data message without calculating the forwarding proof and verifying the forwarding proof, and uses other methods other than vector commitment to authenticate the source of the data message; the forwarding node_i decrypts the i-th routing table entry in the encrypted routing table T based on the key of the forwarding node_i, obtains the identifier of the next node_i+1, and the forwarding node_i adds the remaining encrypted routing table after the i-th routing table entry in the routing table T to the data message_i, and obtains the data message_i+1. The forwarding node_i sends the data message_i+1 to the next node r_i+1 based on the identifier of the next node r_i+1, and the data message_i+1 includes a protocol message header, and the protocol message header includes a trusted path identifier.

[0406] S440, the tail node obtains the multi-point forwarding certificate MP_N.

[0407] In (a) of S440, the tail node receives data message _N, which includes a protocol message header, and the protocol message header includes a trusted path identifier. The protocol message header includes a path P = (r_1, r_2, ..., r_N), where r_i is the identity information of the forwarding node.

[0408] In (b) in S440, the tail node obtains the multi-point forwarding proof MP_N based on the identity information of each node from node_1 to node r_N and the position information of each node from node_1 to node r_N. The multi-point forwarding proof MP_N is used to prove that node_1 is in the first position in the forwarding path, and node_2 is in the second position in the forwarding path... and node_i is in the i-th position in the forwarding path... and node_N is in the N-th position in the forwarding path.

[0409] S450, the tail node verifies the multi-point forwarding certificate MP_N.

[0410] The tail node obtains the multi-point forwarding proof MP_N, commitment C, and path P = (r_1, r_2, ..., r_N). The tail node verifies the multi-point forwarding proof MP_N using a batch verification function (batch verify) based on the vector commitment mechanism, commitment C, the location information of each node in path P, and the identity information of each node in path P, and executes batch verify (C, MP_N, P), that is, verifies that the identity of the node at each position i of the entire path is r_i.

[0411] The benefits achieved by adopting the endpoint verification model include but are not limited to the following aspects.

[0412] First, reduce communication overhead: Since each hop node in the forwarding path does not need to send a forwarding proof to the verification node, the forwarding node saves the overhead of generating and transmitting messages to send the forwarding proof, and also saves the bandwidth occupied when the forwarding proof is transmitted in the network.

[0413] Second, reduce computing overhead: Since each hop node in the forwarding path except the tail node does not need to calculate the forwarding proof and verify the forwarding proof, all order-preserving forwarding proofs and forwarding proof verifications are only calculated once at the tail node, and the overall overhead of all devices in the forwarding path is relatively small.

[0414] In a possible implementation, the forwarding node_i supports at least two verification modes, and the forwarding node_i determines the verification mode to be adopted based on the identification bit carried in the data message.

[0415] For example, the data packet _i obtained by the forwarding node _i includes an identifier of the real-time verification mode, and the forwarding node _i sends a forwarding proof p_i to the verification node in response to identifying the identifier of the real-time verification mode carried by the data packet _i.

[0416] For example, the data packet _i obtained by the forwarding node _i includes the identifier of the on-path verification mode, and in response to identifying that the data packet _i carries the identifier of the on-path verification mode, the forwarding node _i obtains the data packet _i+1 based on the data packet _i and the forwarding proof p_i. The data packet _i+1 includes the forwarding proof p_i.

[0417] For example, the data packet _N obtained by the forwarding node_N includes an identifier of the endpoint verification mode. In response to identifying that the data packet _N carries the identifier of the endpoint verification mode, the forwarding node_N obtains the forwarding proof p_N based on the identity information of each node from forwarding node_1 to forwarding node_N and the location information of each node from forwarding node_1 to forwarding node_N, and verifies the forwarding proof p_N.

[0418] By supporting multiple authentication modes and determining the authentication mode to be used based on the identification bit in the data message, the forwarding node can select the appropriate authentication method according to specific needs, thereby providing different levels of security and authentication capabilities.

[0419] In another possible implementation, the forwarding node_i determines the verification mode to be adopted based on the configuration of the control plane. For example, the controller sends a mode identifier to the forwarding node_i. In response to the mode identifier from the controller indicating the real-time verification mode, the forwarding node_i sends a forwarding proof p_i to the verification node when a data message is obtained. In response to the mode identifier from the controller indicating the in-path verification mode, the forwarding node_i obtains the data message_i+1 based on the data message_i and the forwarding proof p_i when the data message is obtained. The data message_i+1 includes the forwarding proof p_i. In response to the mode identifier from the controller indicating the end point verification mode, the forwarding node_i obtains the forwarding proof p_N based on the identity information of each node from forwarding node_1 to forwarding node_N and the location information of each node from forwarding node_1 to forwarding node_N when the data message is obtained, and verifies the forwarding proof p_N.

[0420] The above method is illustrated below with examples in two specific application scenarios. Example 1 provides a trusted path protection mechanism for service function chaining (SFC) based on KZG polynomial proof. In Example 1, the service function chain is a specific example of a forwarding path, the SF or SFC agent is a specific example of a forwarding node, the NSH in Example 1 is a specific example of a message header carrying a vector commitment and a forwarding proof, and the SF_FROM in Example 1 is a specific example of the identity information of a forwarding node. The KZG polynomial commitment is a specific example of a vector commitment. Example 2 provides a trusted path protection mechanism for SRv6. The path indicated by the segment list in Example 2 is a specific example of a forwarding path. The node (SR endpoint) corresponding to the SID in the segment list in Example 2 is a specific example of a forwarding node, the SID is a specific example of identity information, the SID of node_i is used to identify the identity of node_i, and the SRH in Example 2 is a specific example of a message header carrying a vector commitment and a forwarding proof.

[0421] Example 1

[0422] Service Function Chain (SFC) Trusted Path Protection Mechanism Based on KZG Polynomial Proof

[0423] The service function chain is an orderly collection of service functions, which guides traffic to obtain service functions in an orderly manner on demand. The service function chain is an important means to process traffic in an orderly manner on demand in the NFV virtual network. The service function chain itself is a path.

[0424] like Figure 7 As shown in the figure, network devices play different roles in the entire service function chain system according to the different functions used. The roles of the service function chain mainly include classifier (SC), service function (SF) node, service function forwarding node (SFF) node and SFC proxy node.

[0425] The classifier (SC) is located at the boundary entrance of the SFC domain. After the message enters the SFC domain, it will first perform traffic classification, set the service identifier and encapsulate the service message header.

[0426] SF nodes are used to provide business processing services. SF nodes include but are not limited to firewalls (fire wall, FW), load balancers (load balancer, LB), intrusion prevention systems (intrusion prevention systems, IPS), application accelerators, network address translation (network address translation, NAT), Web application firewall (Web application firewall, WAF, also known as website application-level intrusion prevention system), bandwidth control, virus detection, cloud storage, deep packet inspection (deep packet inspection, DPI), intrusion detection, hypertext transfer protocol (hyper text transfer protocol, HTTP) header enrichment, etc. In the business function chain, network traffic needs to pass through each SF node in the established order required by the business logic to achieve the required business.

[0427] Depending on whether the device recognizes the network service header (NSH) message encapsulation, SF nodes can be divided into NSH-aware SF nodes and NSH-unaware SF nodes. NSH-aware SF nodes can recognize NSH messages and forward them, while NSH-unaware SF nodes cannot recognize NSH messages and discard them.

[0428] The SFF node is a device connected to the SF service function point. The SFF node is used to identify the service flow information and forward it based on the service flow information.

[0429] The SFC Proxy node is located between the SFF node and the NSH-unaware SF node associated with the SFF node, and is used to delete or add NSH encapsulation information for the NSH-unaware SF.

[0430] In the business function chain scenario, how to ensure that traffic is forwarded according to the specified network path is a key technical problem. In this embodiment, NSH-aware SF or SFC Proxy is used as a forwarding node, KZG polynomial commitment is used as a specific embodiment of constructing vector commitment, and the message header NSH in SFC is used to carry information related to the trusted path.

[0431] The following is an example of the format of the message header NSH that carries the trusted path related information.

[0432] NSH is a message header used to identify the SFC protocol. NSH meets a certain fixed format and reserves an extensible optional variable-length metadata (Optional Variable-Length Metadata, OVLM) data field. This embodiment implements the trusted path message header in OVLM.

[0433] Figure 8 (a) in the figure shows the overall encapsulation format of the data message in the service function chain scenario. The data message includes the original message, the transport layer encapsulation (transport encapsulation) and the network service header (NSH). The original message (original packet) is the payload in the data message, and the original message includes the carried service data. The transport layer encapsulation includes the content of the transport layer protocol (such as TLS). The following is an example of the format of NSH.

[0434] like Figure 8 As shown in (b) in the figure, NSH includes a 4-byte base header and a 4-byte service path header; the base header provides a basic identifier. The service path header provides a path identifier and a position in the current path. Optionally, NSH also includes a context header. The context header includes an extensible optional variable-length metadata (OVLM) field.

[0435] like Figure 8 As shown in (c) in the figure, the service path header includes a service index (SI) and a service path identifier (SPI). The SPI occupies 24 bits. The service index (SI) indicates the current location of the data packet in the forwarding path, and the SI occupies 8 bits. The format of the service path header is as follows: Figure 8 As shown. In a possible implementation, SF node_i obtains the value of the SI field carried by the service path header, uses the value of the SI field as the position_i of the node, and calculates the forwarding proof p_i of the node based on the position_i. Since the SI value range is from 255 to 0 and decreases by 1, x_i = 256-SI.

[0436] In one possible implementation, after the controller selects a trusted path and calculates commitment C for the trusted path, the controller publicly stores the correspondence between SPI and commitment C in a blockchain or other distributed shared database, and SPI serves as a primary key based on which commitment C is searched.

[0437] like Figure 8 As shown in (d) in the figure, the context header is used to carry values ​​related to the trusted path. The context header includes a commitment C and a forwarding proof p_i, etc. The context header includes a metadata class field, a type field, a length field, and a variable-length metadata field. Variable-length metadata is a variable-length field used to carry metadata related to a specific service or function. The length field is used to indicate the length of the variable-length metadata field. In one possible implementation, data related to the trusted path is carried through a variable-length metadata field, for example, four types of data, namely, commitment, forwarding proof, identity information, and location information, are carried through a variable-length metadata field.

[0438] In the business function chain scenario, the three forwarding proof verification modes described above include real-time verification (Postcard) mode, on-path verification (Passport) mode, and end-point verification (Final_only) mode. All of them can be used. In this embodiment, the OP sub-mode of the on-path verification mode with moderate efficiency and security is selected for analysis:

[0439] For the OP sub-mode in the route verification mode, a commitment, forwarding proof, encrypted routing table, and previous SF node identifier are added to the variable-length metadata field of each data packet. Figure 8 In the variable-length metadata field shown in (d), a commitment field, a P field, a SF_TO_ENC field, and a SF_FROM field are added so that the format of the variable-length metadata field is as shown in the following table.

[0440]

[0441] The commitment field is used to carry the commitment. The P field is used to carry the forwarding proof. Both the commitment and the forwarding proof are G1 group elements of a pairing friendly curve, so the commitment field and the P field both occupy the byte length of one element (elem_length) in the message.

[0442] Pairing Friendly Curve is a type of elliptic curve group with specific mathematical properties, suitable for pairing operations. In cryptography, pairing operation (pairing) refers to mapping two points on elliptic curves to elements on a finite field. When using curve curve_ID = BLS-12381, elem_length = 48 bytes. In other words, the commitment field and the P field are both 48 bytes.

[0443] The SF_FROM field is used to carry the identifier of the previous hop SF node. The identifier of the previous hop SF node carried in the SF_FROM field is in plain text. In one possible implementation, SF node_i receives the identifier of the previous hop SF node sent by the previous hop SF node_i-1, and writes the identifier of the previous hop SF node into the SF_FROM field. In another possible implementation, SF node_i receives the identifier of the previous hop SF node from the SFC service layer, and writes the identifier of the previous hop SF node into the SF_FROM field.

[0444] The SF_IDENT_LENGTH field is used to indicate the length of the SF_FROM field. The SF_FROM field is in bytes, for example.

[0445] The SF_TO_ENC field is used to carry the encrypted routing table. For example, the SF_TO_ENC field includes the address of the next hop SF node. The address of the next hop SF node_i-1 is encrypted by the key of the current SF node_i.

[0446] SF_TO_ENC_i=ENC_(sk_i,SF_TO||SF_TO_ENC_i+1). Where sk_i is the symmetric key of the node currently processing data. ENC is a symmetric encryption algorithm specified by CIPHER_SUITE.

[0447] SF_TO_ENC_i=ENC_(sk_i,SF_TO||SF_TO_ENC_i+1) represents the process of encrypting SF_TO and SF_TO_ENC_i+1 when the current node (node ​​i) processes data. Specifically, node i uses the symmetric key sk_i of node i and the specified symmetric encryption algorithm (determined by CIPHER_SUITE) to encrypt SF_TO and SF_TO_ENC_i+1 as input. The encrypted result SF_TO_ENC_i will be used as the encrypted routing table for transmission to the next node (node ​​i+1).

[0448] SF_TO represents the address of the next hop SF node, and SF_TO_ENC_i+1 represents the encrypted routing table sent by node_i to node_i+1. Node i uses its own symmetric key sk_i to encrypt SF_TO and SF_TO_ENC_i+1 to generate the encrypted routing table SF_TO_ENC_i that the current node (node ​​i) needs to forward data to the next hop.

[0449] Through the above process, the encrypted routing table information can be encrypted hop by hop during transmission. Only those with the corresponding symmetric key can decrypt and access the data, so that each node can only decrypt the next hop information it needs, thereby achieving the security and confidentiality of encrypted routing.

[0450] For example, see Fig. 9 The protocol steps in the on-line verification mode include the following S510 to S540.

[0451] S510, the controller sends a vector commitment to the verification node.

[0452] In (a) of S510, the controller obtains input data, the input data including identity information of each SF node in a service function chain of length N and location information of each SF node, the input data is, for example, a vector P=(r_1, r_2, ..., r_N) composed of N SF nodes, where r_i is a unique identifier of the SF node.

[0453] In (b) of S510, the controller calculates the vector commitment based on the input data. For the KZG polynomial commitment, the controller converts the vector P into N two-dimensional coordinate points <(1,r_1),(2,r_2),…,(N,r_N)>, and the controller calculates the Lagrange interpolation polynomial f(X) of these N points using the following formula (1). In formula (1), x_i represents the location information of SF node_i, and y_i represents the identity information of SF node_i.

[0454]

[0455] The controller calculates the secret s using formula (2) to achieve secret initialization. In formula (2), g is the group generator.

[0456] s,[s 2 ],...,[s N ],where[s i ] = g i*s ; Formula (2)

[0457] The controller uses formula (3) to calculate the commitment C=Commit(f(X)) of this polynomial and fills the commitment C into the field commitment.

[0458]

[0459] In addition, the controller calculates an encrypted routing table T of the forwarding path P = (r_1, r_2, ..., r_N).

[0460] In (c) of S510 , the controller sends a commitment C and an encrypted routing table T to each node in the forwarding path. The commitment C is a G1 group element with a length of 48 bytes.

[0461] S520, the first SF node in the forwarding path sends data message _2 and forwarding proof p_1.

[0462] In (a) of S520 , the first SF node obtains input data, where the input data includes a commitment C, an encrypted routing table T of length N, and payload data.

[0463] In (b) of S520, the first SF node generates a data message _1 according to the payload data, where the data message _1 includes the payload data; and the first SF node uses the Open function to calculate its own forwarding proof OP_1 using the following formula (4).

[0464] OP i = p[f(x i )=y i ]=C T ; Formula (4)

[0465] C_T is the commitment of the auxiliary polynomial T_y(X) of order N-1. The auxiliary polynomial T_y(X) is determined based on the following formula (5).

[0466]

[0467] The new coefficient is determined by the following formula (6).

[0468] t N-1 =f N ;tj =f j+1 +x i ·t j+1 ; Formula (6)

[0469] The first SF node calculates the forwarding proof using the following formula (7).

[0470] OP i =[T y (s)]1; Formula (7)

[0471] The first SF node fills the forwarding proof into the field P of NSH. Based on the key of the first SF node, the first SF node decrypts the first routing table entry of the encrypted routing table T and obtains the identification of the second SF node. The first SF node fills the identity information of the node into the SF_FROM field in NSH, fills the remaining encrypted routing table into the SF_TO_ENC field in NSH, and fills the commitment C into the commitment field in NSH.

[0472] In (c) of S520, the first SF node sends a datagram_2 to the second SF node, and the datagram_2 includes an NSH. The SPI field in the NSH includes a trusted path identifier. The field P in the NSH also includes a single-point forwarding proof OP_1 or a multi-point forwarding proof MP_1. In addition, the first SF node sends a forwarding proof p_1 to the verification node.

[0473] S530, SF node_i receives data message_i.

[0474] In (a) of S530, SF node_i receives data message_i, data message_i includes an NSH, the SPI field in the NSH includes a trusted path identifier, and the NSH also includes identity information r_i of the SF node_i currently forwarding or processing the data message and location information i of the SF node_i. The location information of the SF node_i is obtained based on the SI.

[0475] In (b) of S530, SF node_i verifies the source of the data message. SF node_i verifies the source of the data message. SF node_i verifies the correctness of OP_i-1 in the authentication data message header of the previous hop node_i-1. The verification method is based on checking whether the Pairing in the following formula (8) is established.

[0476]

[0477] Formula (8) is the verification formula of the forwarding proof. e(G_1,G_2)->G_T is a public pairing function, g_1,g_2 are generators (both are pre-distributed public parameters / functions).

[0478] S540: When the verification is successful, SF node _i sends data message _i+1 to the identifier of the next SF node _i+1 based on the identifier of the next SF node _i+1.

[0479] In one possible implementation, SF node_i responds to determining that the pairing in formula (8) is not established, SF node_i determines that the forwarding proof verification fails, and SF node_i discards the data message. SF node_i responds to determining that the pairing in formula (8) is established, SF node_i determines that the forwarding proof verification is successful, and SF node_i uses the identity information r_i of the node and the current position i in this path of the node as input, and uses formula (4) to calculate a single point forwarding proof OP_i. SF node_i replaces the forwarding proof OP_i-1 carried in the message header with the new forwarding proof OP_i calculated by itself.

[0480] SF node_i decrypts the i-th routing table entry in the encrypted routing table T in data message_i based on the key of SF node_i, obtains the identifier of the next SF node_i+1, and adds the remaining encrypted routing table after the i-th routing table entry in the encrypted routing table T to the SF_TO_ENC field in data message_i to obtain data message_i+1.

[0481] Each SF node in the service chain repeats the process from S530 to S540 until the transmission is completed.

[0482] Example 2

[0483] Trusted Path Protection Mechanism for SRv6

[0484] SRv6 is Segment Routing based on the IPv6 forwarding plane. SRv6 adds a routing extension header (Segment Routing Header, SRH) to the IPv6 message. SRH includes the IPv6 address list segment list that records the forwarding path and optional TLV (Type-Length-Value).

[0485] In a possible implementation, the SID is used to carry the location information of the forwarding node. Fig.10 As shown, the SID includes a location (locator) field and a function (function) field. The locator field is used to carry the location information of the forwarding node. The locator field provides IPv6 routing capabilities and implements addressing forwarding through the locator field. Based on the locator field, the forwarding node_i uses the SRv6 protocol to calculate the position x_i of the forwarding node_i on the forwarding path.

[0486] The function field is used to carry instructions for the forwarding action to be performed by the forwarding node. Different forwarding behaviors are expressed by different functions. A trusted path identifier is extended in the function field. The arguments field is an optional field. The arguments field is a supplement to the function and is the parameters corresponding to the instruction when it is executed. These parameters may contain flows, services, or any other related information. In one possible implementation, the public parameters of the trusted path are carried in the arguments field of the SID, so that the public parameters of the trusted path do not need to be pre-distributed on the control plane.

[0487] A segment list is formed by combining multiple SIDs. The segment list is used to indicate the IPv6 path obtained by orderly arranging n IPv6 network nodes. When forwarding a message, the forwarding node determines the forwarding path P = (r_1, r_2, ..., r_N) of the message based on the segment list field, the source address (Source Address, SA) and the destination address (Destination Address, DA).

[0488] After the data message passes through the first half of the forwarding path, that is, after the message passes through each node from node_1 to node_i-1, the identity information (r_1, r_2, ..., r_i-1) of each node from node_1 to node_i-1 is made public through SRH; in addition, during the data message forwarding process, the identity information (r_1, r_2, ..., r_i-1) of each node from node_1 to node_i-1 is carried in SRH. In addition, the identity information (r_i, r_i+1, ..., r_N) of each node in the path that the data message has not passed through is continued to be hidden in the encrypted routing table through SRH.

[0489] For example, when a data packet is forwarded to node _i, the status of the SRv6 segment list is shown in the following table.

[0490] NULL NULL r_i-1 … r_2 r_1

[0491] For a selected forwarding path P = (r_1, r_2, ..., r_N), the head node adds the SID of the head node (which is a specific example of the head node's identity information r_1) to segment list [N]. segment list [N] is the innermost (last row in the table) field in segmentlist. It is added to segment list [N] because SRv6 uses the reverse order insertion method for routing. Segment list [N] is used to carry the SID of the head node; the head node sets the values ​​of other fields in the segment list except segmentlist [N] to empty. In addition, the head node adds the encrypted routing table T corresponding to P = (r_1, r_2, ..., r_N) to the TLV field in SRH for storage.

[0492] In addition, for any node_i from the head node to the tail node, when node_i obtains data message_i, node_i obtains the ciphertext of the SID of the next node_i+1 in the forwarding path carried in the TLV of the SRH in the data message_i (the identity information of the next node_i+1); node_i decrypts the ciphertext of the SID of the next node_i+1 based on the key of node_i+1 to obtain the plaintext of the SID of node_i+1; node_i fills the SID of node_i+1 into the segmentlist[Ni] in the data message_i to obtain the data message_i+1, and node_i forwards the data message_i+1 to node_i+1.

[0493] In this way, the total length of the segment list remains unchanged, and the SID (identity information) of node_1 to node_i that the data message has passed in the forwarding process in the segment list is made public, which provides a basis for the subsequent multi-point forwarding proof (MP) calculation and verification. The SID (identity information) of node_i to node_N that the data message has not passed in the forwarding process in the segment list is empty, thereby reducing the risk of the identity of node_i to node_N being disclosed.

[0494] SRv6, a flexible protocol that can carry path information and addresses of nodes in the path, is suitable for implementing the MP sub-mode in the path verification mode and the MP sub-mode in the endpoint verification mode.

[0495] For the MP sub-mode in the route verification mode, the difference from Example 1 is that in Example 1, the identifier of the previous node (SF_FROM) is added to the data message, while in Example 2, each data message already includes the identifier of the previous node (SID) in the segment list, so there is no need to add the identifier of the previous node (SID) in the TLV field. Specifically, the commitment field, the proof (P, specifically the multi-point proof) field, and the encrypted routing table T are added to the TLV in the SRH of the data message.

[0496] (SF_TO_ENC) field. Since the node identifier (SID) in SRv6 is an IPv6 address, and the length of the IPv6 address is 128 bits, there is no need to add an additional field in the message header to identify the length of the node identifier. Therefore, the message header format is as follows.

[0497]

[0498] Commitment and forwarding proof (P) are both G1 group elements of a pairing friendly curve, so the byte length (elem_length) of one element is used to represent commitment and forwarding proof (P). When using curve curve_ID = BLS-12381, the length of commitment and forwarding proof (P) is 48 bytes.

[0499] For example, see Fig.11 The protocol steps in the on-line verification mode include the following S610 to S640.

[0500] S610: The controller sends a vector commitment.

[0501] In (a) of S610 , the controller obtains the identity information of each SR endpoint in the forwarding path corresponding to the segment list and the location information of each SR endpoint in the segment list.

[0502] In (b) of S610, the controller obtains a vector commitment based on the identity information of each SR endpoint and the location information of each SR endpoint, where the vector commitment is used to indicate the correspondence between the identity information of each SR endpoint and the location information of each SR endpoint.

[0503] In (c) of S610 , a vector commitment is sent to each SR endpoint except the head node in the forwarding path corresponding to the segment list.

[0504] S620, the head node (the first SR endpoint) in the forwarding path sends IPv6 data packet _2 to the second SR endpoint in the forwarding path corresponding to the segment list, and the TLV in the SRH in the IPv6 data packet _2 includes the forwarding proof of the head node.

[0505] The head node is, for example, the node corresponding to the last SID in the segment list. The second SR endpoint in the forwarding path is, for example, the node corresponding to the last SID in the segment list.

[0506] In S620 (a), the head node obtains input data, where the input data includes a commitment C, an encrypted routing table T of length N, and payload data.

[0507] In (b) of S620, the head node generates a data message_1 according to the payload data, where the data message_1 includes the payload data;

[0508] The head node calculates its own forwarding proof using a batch open (BatchOpen) function or calculates a single point's forwarding proof using an open function, and adds the forwarding proof to the P field in the TLV in the SRH.

[0509] In addition, the head node decrypts the routing table entry corresponding to the node in the encrypted routing table T based on the key of the node, and obtains the SID of the next node r_2. In addition, the head node adds the remaining encrypted routing table T after the first routing table entry in the encrypted routing table T, the SID of the node, and the SID of the next node r_2 to the data message _1 to obtain the data message _2.

[0510] In S620 (c), the head node sends data message 2 to the second SR endpoint. Data message 2 includes an SRH, and the SRH includes a trusted path identifier and a forwarding certificate of the head node.

[0511] S630, SR endpoint_i receives IPv6 data packet_i.

[0512] Data message_i includes an SRH, which includes a trusted path identifier, identity information of each node from head node_1 to head node_i, and location information of each node from head node_1 to head node_i. The location information is, for example, a positive integer, such as 1, 2, or 3, and the location information is obtained based on the locator in the SID.

[0513] S640, SR endpoint_i sends data message_i+1 to the next node_i+1 based on the identifier of the next node_i+1.

[0514] In (a) of S640, SR endpoint_i verifies the forwarding proof p_i carried by the SRH in IPv6 data message_i to verify the source of IPv6 data message_i. SR endpoint_i obtains the multi-point forwarding proof MP_i-1 carried by the message header of data message_i; SR endpoint_i verifies the multi-point forwarding proof MP_i-1 according to the identity information of each node from SR endpoint_1 to SR endpoint_i-1.

[0515] In (b) of S640, if the multi-point forwarding proof MP_i-1 is successfully verified, SR endpoint_i obtains a multi-point forwarding proof MP_i using the identity information from node_1 to node_i and the location information from node_1 to node_i. The location information x_i of node_i and the identity information y_i of node_i are obtained from the segment list. SR endpoint_i replaces the multi-point forwarding proof MP_i-1 in the message header of data message_i with the new multi-point forwarding proof MP_i. In addition, SR endpoint_i decrypts the i-th routing table entry in the encrypted routing table T based on the key of SR endpoint_i to obtain the identity information of the next node_i+1. SR endpoint_i fills the remaining encrypted routing table T after the i-th routing table entry in the encrypted routing table T and the identity information of the next node_i+1 into the segment list to obtain data message_i+1.

[0516] In (c) of S640, SR endpoint_i sends data message_i+1 to next node_i+1 based on the identifier of next node_i+1, and data message_i+1 includes an SRH, and the TLV of the SRH includes the forwarding proof of SR endpoint_i.

[0517] If the multipoint forwarding proof MP_i-1 fails to verify, SR endpoint_i discards data message_i.

[0518] Each SR endpoint in the forwarding path corresponding to the segment list repeats S630 to S640 until the data message transmission is completed.

[0519] In a SRv6 scenario, in one possible implementation, a SID is used to carry a trusted path identifier. For example, the function field in the SID is used to carry the trusted path identifier. For another example, the arguments field in the SID is used to carry the trusted path identifier.

[0520] In an exemplary embodiment, SR endpoint_i receives data message_i. The message header in data message_i includes an IPv6 basic header. The destination address field of the IPv6 basic header includes the SID of SR endpoint_i, and the SID of SR endpoint_i includes the trusted path identifier. SR endpoint_i identifies the content of the destination address field of the IPv6 basic header, and in response to identifying that the destination address field of the IPv6 basic header includes the SID of the current node, and the SID includes the trusted path identifier, SR endpoint_i performs the step of obtaining a forwarding proof. In a possible implementation, SR endpoint_i saves the correspondence between the trusted path identifier and the calculation instructions of the forwarding proof, searches for the correspondence based on the identified trusted path identifier, obtains the calculation instructions of the forwarding proof, and executes the calculation instructions of the forwarding proof, thereby obtaining a single-point forwarding proof or a multi-point forwarding proof.

[0521] In SRv6 scenarios, it can also be extended to use the endpoint verification mode to obtain and verify forwarding proofs. Fig.12 , the steps of obtaining and verifying the forwarding certificate in the endpoint verification mode include S710 to S750.

[0522] S710: The controller sends a vector commitment to the tail node (the last SR endpoint) in the forwarding path corresponding to the segment list. S710 is the same as S510 in the first embodiment.

[0523] The controller calculates the commitment and public parameters. Please refer to Example 1 for the calculation method. The controller passes the commitment and public parameters directly to the tail node.

[0524] S720: The head node sends IPv6 data packet _2 to the second SR endpoint.

[0525] S730, SR endpoint_i receives IPv6 data packet_i, and sends IPv6 data packet_i+1 to the next node_i+1 based on the identifier of the next node_i+1.

[0526] S740, the tail node obtains the forwarding certificate.

[0527] In (a) of S740 , the tail node obtains a data packet N including an SRH. The tail node obtains a path P=(r_1, r_2, …, r_N) from the SRH. Where r_i is the identity information of the forwarding node, and in this embodiment, the identity information of the forwarding node is the SID.

[0528] In a possible implementation, the tail node obtains the SID of node_i carried in the SRH as the identity information of node_i; the tail node determines the offset of the SID of node_i compared to the SID of the head node or as the location information of node_i.

[0529] In (b) of S740, the tail node obtains the multi-point forwarding proof based on the location information of each node in the forwarding path and the identity information of each node in the forwarding path. The calculation method of the multi-point forwarding proof is referred to above.

[0530] S750, the tail node verifies the forwarding proof.

[0531] The tail node obtains the multi-point forwarding proof MP_N, commitment C, and path P = (r_1, r_2, ..., r_N). The tail node verifies the multi-point forwarding proof MP_N using a batch verification function (batch verify) based on the vector commitment mechanism, commitment C, the location information of each node in path P, and the identity information of each node in path P, and executes batch verify (C, MP_N, P), that is, verifies that the identity of the node at each position i of the entire path is r_i.

[0532] When using the endpoint verification mode in SRv6, since the segment list itself carries the identity information and location information of each node, there is basically no need to modify the data plane of the SRv6 protocol to carry the identity information and location information of the node. For example, the commitment and public parameters are delivered to the tail node at the application level or control level, and then the tail node verifies the forwarding path based on the existing information at one time.

[0533] Fig.13 810 is a schematic diagram of a forwarding proof acquisition device 810 provided in an embodiment of the present application. The device 810 includes an acquisition unit 811 and a processing unit 812.

[0534] The device 810 is optionally provided at Figure 1 The acquisition unit 811 is used to execute Figure 2 (a) in S220 in the method shown;

[0535] Processing unit 812, for executing Figure 2 The device 810 is optionally provided at S220 (b) in the method shown. Figure 1 The acquisition unit 811 is used to execute Figure 2 In the method shown in S230 (a); the processing unit 812 is used to execute Figure 2In some possible implementations, the apparatus 810 further includes a sending unit 813 for executing Figure 2 In the method shown, (c) in S220 or (c) in S230.

[0536] The device 810 is optionally provided at Figure 3 The acquisition unit 811 is used to execute Figure 4 (a) in S320 in the method shown;

[0537] Processing unit 812, for executing Figure 4 The device 810 is optionally provided at S320 (a) in the method shown. Figure 2 The acquisition unit 811 is used to execute Figure 4 In the method shown in S330 (a); the processing unit 812 is used to execute Figure 4 In some possible implementations, the apparatus 810 further includes a sending unit 813, which is used to Figure 4 (c) in S340 in the method shown.

[0538] The device 810 is optionally provided at Figure 5 The forwarding node_4 in the acquisition unit 811 is used to execute Figure 6 In the method shown, S440; the processing unit 812 is used to execute S450.

[0539] The device 810 is optionally provided at Figure 7 SF node_1, SF node_2 or proxy (forwarding node_3) in the SF node_1, SF node_2 or proxy (forwarding node_3). The acquisition unit 811 is used to execute Fig. 9 In the method shown in S520 (a); the processing unit 812 is used to execute Fig. 9 The sending unit 813 is used to execute Fig. 9 (c) in S520 in the method shown.

[0540] The device 810 is optionally provided at Fig.11 The acquisition unit 811 is used to execute Fig.11 In the method shown in S620 (a); the processing unit 812 is used to execute Fig.11 (b) in S620 in the method shown.

[0541] The device 810 is optionally provided at Fig.11 The second SR endpoint or the third SR endpoint in the acquisition unit 811 is used to execute Fig.11In the method shown in S640 (a); the processing unit 812 is used to execute Fig.11 The sending unit 813 is used to execute Fig.11 The method shown is S640.

[0542] Fig.13 The described device embodiments are merely illustrative. For example, the division of the above units is only a logical functional division. There may be other division methods in actual implementation, such as multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Each functional unit in each embodiment of the present application may be integrated into a processing unit 812, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0543] Each unit in the forwarding proof acquisition device 810 is implemented in whole or in part by software, hardware, firmware or any combination thereof.

[0544] For the implementation details of each unit in the forwarding proof acquisition device 810, and the interaction process between the forwarding proof acquisition device 810 and other devices, please refer to the description in the previous method embodiments, which will not be described in detail here.

[0545] In conjunction with the computing device 900 described below, some possible implementations of the various functional units in the forwarding proof acquisition device 810 using hardware or software are described below.

[0546] In the case of software implementation, for example, the processing unit 812 and the acquisition unit 811 are composed of Fig.16 At least one processor 901 in the processor 901 reads the program code stored in the memory 902 and generates a software function unit to implement it.

[0547] In the case of hardware implementation, for example, Fig.13 The above-mentioned units are implemented by different hardware in the computing device, for example, the processing unit 812 is implemented by Fig.16 The sending unit 813 is implemented by a part of the processing resources of at least one processor 901 (for example, one or two cores of a multi-core processor), or by a programmable device such as a field-programmable gate array (FPGA) or a coprocessor. Fig.16 The network interface 903 is implemented in.

[0548] Fig.148 is a schematic diagram of a forwarding proof verification device 820 provided in an embodiment of the present application. The forwarding proof verification device 820 includes an acquisition unit 821 and a verification unit 822.

[0549] Device 820 is optionally provided at Figure 1 The verification node (observer) in . The acquisition unit 821 is used to execute Figure 2 (a) of the method S240 shown; verification unit 822, for executing Figure 2 (b) in S240 in the method shown.

[0550] Device 820 is optionally provided at Figure 3 The acquisition unit 821 is used to execute Figure 4 In the method shown in S330 (a); the verification unit 822 is used to perform Figure 4 (b) in S330 in the method shown.

[0551] Device 820 is optionally provided at Figure 5 The acquisition unit 821 is used to execute Figure 6 In the method shown, S440; the verification unit 822 is used to execute S450.

[0552] Device 820 is optionally provided at Figure 7 The acquisition unit 821 is used to execute Fig. 9 In the method shown in S530 (a); the verification unit 822 is used to perform Fig. 9 (b) in S530 in the method shown.

[0553] Device 820 is optionally provided at Fig.11 The second SR endpoint or the third SR endpoint in the acquisition unit 821 is used to execute Fig.11 In the method shown in S630; the verification unit 822 is used to execute Fig.11 (a) in S640 in the method shown.

[0554] Fig.14 The device embodiments described are merely illustrative. For example, the division of the above units is only a logical functional division. There may be other division methods in actual implementation, such as multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. The functional units in the various embodiments of the present application may be integrated into a processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0555] Each unit in the verification device 820 of the forwarding certificate is implemented in whole or in part by software, hardware, firmware or any combination thereof.

[0556] For the implementation details of each unit in the forwarding proof verification device 820, and the interaction process between the forwarding proof verification device 820 and other devices, please refer to the description in the previous method embodiments, which will not be described in detail here.

[0557] In conjunction with the computing device 900 described below, some possible implementations of the various functional units in the verification device 820 for forwarding proof using hardware or software are described below.

[0558] In the case of software implementation, for example, the verification unit 822 is composed of Fig.16 At least one processor 901 in the processor 901 reads the program code stored in the memory 902 and generates a software function unit to implement it.

[0559] In the case of hardware implementation, for example, Fig.14 The above-mentioned units are implemented by different hardware in the computing device, for example, the verification unit 822 is implemented by Fig.16 The acquisition unit 821 is implemented by a portion of the processing resources of at least one processor 901 (for example, one core or two cores of a multi-core processor), or by a programmable device such as a field-programmable gate array (FPGA) or a coprocessor. Fig.16 The network interface 903 is implemented in.

[0560] Fig.15 8 is a schematic diagram of a forwarding proof verification device 830 provided in an embodiment of the present application. The forwarding proof verification device 830 includes an acquisition unit 831 and a processing unit 832.

[0561] The device 830 is optionally provided at Figure 1 The acquisition unit 831 is used to execute Figure 2 (a) of the method S210 shown; processing unit 832, for executing Figure 2 Optionally, the device 830 further includes a sending unit 833, which is configured to execute (c) in S210.

[0562] The device 830 is optionally provided at Figure 3 The acquisition unit 831 is used to execute Figure 4 In the method shown in S310 (a), the processing unit 832 is used to execute Figure 4The sending unit 833 is used to execute (c) in S310 in the method shown.

[0563] The device 830 is optionally provided at Figure 5 The acquisition unit 831 is used to execute Figure 6 In the method shown, in step (a) of S410, the processing unit 832 is used to execute step (b) of S410, and the sending unit 833 is used to execute step (c) of S410.

[0564] Optionally, the acquisition unit 831 is used to execute Fig. 9 In the method shown in S510 (a); the processing unit 832 is used to execute Fig. 9 The sending unit 833 is used to execute step (c) in S510 in the method shown.

[0565] The device 830 is optionally provided at Fig.11 The acquisition unit 831 is used to execute Fig.11 In the method shown in S610 (a); the processing unit 832 is used to execute Fig.11 The sending unit 833 is used to execute step (b) in S610 in the method shown.

[0566] Fig.15 The device embodiments described are merely illustrative. For example, the division of the above units is only a logical functional division. There may be other division methods in actual implementation, such as multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. The functional units in the various embodiments of the present application may be integrated into a processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0567] Each unit in the verification device 830 of the forwarding certificate is implemented in whole or in part by software, hardware, firmware or any combination thereof.

[0568] For the implementation details of each unit in the forwarding proof verification device 830, and the interaction process between the forwarding proof verification device 830 and other devices, please refer to the description in the previous method embodiments, which will not be described in detail here.

[0569] In conjunction with the computing device 900 described below, some possible implementations of the various functional units in the verification device 830 for forwarding proof using hardware or software are described below.

[0570] In the case of software implementation, for example, the acquisition unit 831 and the processing unit 832 are composed of Fig.16At least one processor 901 in the processor 901 reads the program code stored in the memory 902 and generates a software function unit to implement it.

[0571] In the case of hardware implementation, for example, Fig.15 The above-mentioned units are implemented by different hardware in the computing device, for example, the processing unit 832 is implemented by Fig.16 The acquisition unit 831 is implemented by a portion of the processing resources of at least one processor 901 (for example, one or two cores of a multi-core processor), or by a programmable device such as a field-programmable gate array (FPGA) or a coprocessor. Fig.16 The network interface 903 is implemented in.

[0572] Fig.16 It is a structural diagram of a computing device 900 provided in an embodiment of the present application.

[0573] The computing device 900 includes at least one processor 901 , a memory 902 , and at least one network interface 903 .

[0574] The processor 901 is, for example, a general-purpose central processing unit (CPU), a network processor (NP), a graphics processing unit (GPU), a neural-network processing unit (NPU), a data processing unit (DPU), a microprocessor, or one or more integrated circuits for implementing the solution of the present application. For example, the processor 901 includes an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The PLD is, for example, a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0575] The memory 902 is, for example, a read-only memory (ROM) or other static storage device that can store static information and instructions, a random access memory (RAM) or other dynamic storage device that can store information and instructions, an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. Optionally, the memory 902 exists independently and is connected to the processor 901 through the internal connection 904. Alternatively, the memory 902 and the processor 901 are optionally integrated together.

[0576] The network interface 903 uses any transceiver-like device for communicating with other devices or communication networks. The network interface 903 includes, for example, at least one of a wired network interface or a wireless network interface. The wired network interface is, for example, an Ethernet interface. The Ethernet interface is, for example, an optical interface, an electrical interface, or a combination thereof. The wireless network interface is, for example, a wireless local area network (WLAN) interface, a cellular network interface, or a combination thereof.

[0577] In some embodiments, the processor 901 includes one or more CPUs, such as Fig.16 CPU0 and CPU1 are shown in the figure.

[0578] In some embodiments, the computing device 900 optionally includes multiple processors, such as Fig.16 901 and processor 905 are shown in FIG. Each of these processors is, for example, a single-core processor (single-CPU), or a multi-core processor (multi-CPU). The processor here optionally refers to one or more devices, circuits, and / or processing cores for processing data (such as computer program instructions).

[0579] In some embodiments, the computing device 900 further includes an internal connection 904. The processor 901, the memory 902, and the at least one network interface 903 are connected via the internal connection 904. The internal connection 904 includes a path to transmit information between the above components. Optionally, the internal connection 904 is a single board or a bus. Optionally, the internal connection 904 is divided into an address bus, a data bus, a control bus, etc.

[0580] In some embodiments, computing device 900 further includes an input-output interface 906. Input-output interface 906 is connected to internal connection 904.

[0581] Optionally, the processor 901 implements the method in the above embodiment by reading the program code stored in the memory 902, or the processor 901 implements the method in the above embodiment by the program code stored internally. In the case where the processor 901 implements the method in the above embodiment by reading the program code stored in the memory 902, the memory 902 stores the program code 910 that implements the method provided in the embodiment of the present application.

[0582] For more details on how the processor 901 implements the above functions, please refer to the descriptions in the previous method embodiments, which will not be repeated here.

[0583] The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referenced to each other, and each embodiment focuses on the differences from other embodiments.

[0584] A refers to B, which means that A is the same as B or A is a simple variant of B.

[0585] The terms "first" and "second" in the description and claims of the embodiments of the present application are used to distinguish different objects, rather than to describe a specific order of objects, and cannot be understood as indicating or implying relative importance. For example, the first forwarding proof and the second forwarding proof are used to distinguish different forwarding proofs, rather than to describe a specific order of forwarding proofs, and cannot be understood as the first forwarding proof being more important than the second forwarding proof.

[0586] The information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.) and signals involved in the embodiments of this application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions. For example, the identity information involved in this application is obtained with full authorization.

[0587] In the embodiments of the present application, unless otherwise specified, "at least one" means one or more, and "multiple" means two or more. For example, multiple forwarding nodes means two or more forwarding nodes.

[0588] The above embodiments can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in accordance with the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from a website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. The available medium may be a magnetic medium, (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk SolidState Disk (SSD)), etc.

[0589] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, a person skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for obtaining a forwarding certificate, characterized in that: The method comprises: A first forwarding node acquires a first data message, where a forwarding path of the first data message includes at least two forwarding nodes, and the at least two forwarding nodes include the first forwarding node; The first forwarding node acquires location information of the first forwarding node and identity information of the first forwarding node, where the location information of the first forwarding node indicates a first location of the first forwarding node on the forwarding path, and the identity information of the first forwarding node indicates an identity of the first forwarding node; The first forwarding node obtains a first forwarding proof based on the location information of the first forwarding node and the identity information of the first forwarding node, where the first forwarding proof is used to prove that the first forwarding node is at the first position on the forwarding path.

2. The method according to claim 1, characterized in that The at least two forwarding nodes further include a second forwarding node, where the second forwarding node is an upstream node of the first forwarding node in the forwarding path, and the first forwarding node obtains a first forwarding certificate based on location information of the first forwarding node and identity information of the first forwarding node, including: The first forwarding node obtains a first forwarding proof based on the location information of the first forwarding node, the identity information of the first forwarding node, the location information of the second forwarding node and the identity information of the second forwarding node, the location information of the second forwarding node indicating a second position of the second forwarding node on the forwarding path, and the identity information of the second forwarding node indicating the identity of the second forwarding node.

3. The method according to claim 2, characterized in that The second forwarding node includes at least one node from the first forwarding node on the forwarding path to the previous forwarding node of the first forwarding node on the forwarding path.

4. The method according to claim 2 or 3, characterized in that: After the first forwarding node obtains the first forwarding proof based on the location information of the first forwarding node and the identity information of the first forwarding node, the method further includes: The first forwarding node verifies the first forwarding proof based on a vector commitment, location information of the first forwarding node, identity information of the first forwarding node, location information of the second forwarding node, and identity information of the second forwarding node, wherein the vector commitment indicates a correspondence between the locations of the at least two forwarding nodes and the identities of the at least two forwarding nodes.

5. The method according to any one of claims 1 to 3, characterized in that After the first forwarding node obtains the first forwarding proof based on the location information of the first forwarding node and the identity information of the first forwarding node, the method further includes: The first forwarding node obtains a second data message based on the first data message and the first forwarding proof, where the first data message includes payload data, and the second data message includes the first forwarding proof and the payload data; The first forwarding node sends the second data message to a third forwarding node, and the third forwarding node is a next node of the first forwarding node on the forwarding path.

6. The method according to claim 5, characterized in that The first data message also includes a second forwarding proof, and the first forwarding node obtains the second data message based on the first data message and the first forwarding proof, including: The first forwarding node replaces the second forwarding proof in the first data message with the first forwarding proof to obtain a second data message; or, The first forwarding node adds the first forwarding proof to the first data message to obtain a second data message.

7. The method according to claim 5 or 6, characterized in that: The second data message further includes a vector commitment indicating a correspondence between a position of the first forwarding node and an identity of the first forwarding node and a correspondence between a position of the second forwarding node and an identity of the second forwarding node.

8. The method according to claim 7, characterized in that The second data message includes an Internet Protocol version 6 (IPv6) extension header, and the IPv6 extension header includes the first forwarding proof and the vector commitment; or The second data packet includes a network service header NSH, the NSH includes a metadata field, and the metadata field includes the first forwarding proof and the vector commitment; or, The second data packet includes a multi-protocol label switching (MPLS) header, and the MPLS header includes the first forwarding proof and the vector commitment; or, The second data packet includes a virtualized extended local area network VxLAN header, and the VxLAN header includes the first forwarding proof and the vector commitment; or, The second data packet includes an Internet Protocol security (IPsec) header, and the IPsec header includes the first forwarding proof and the vector commitment.

9. The method according to claim 8, characterized in that The IPv6 extension header includes a segment routing header SRH, the SRH includes a first type-length-value TLV and a second TLV, the first TLV of the SRH includes the first forwarding proof, and the second TLV of the SRH includes the vector commitment; or, The IPv6 extension header includes an application-aware network APN message header, the APN message header includes an application-aware network identifier APN ID, and the APN ID includes the first forwarding proof and the vector commitment; or, The IPv6 extension header includes a destination options header DOH, the DOH includes a first TLV and a second TLV, the first TLV of the DOH includes a first forwarding proof, and the second TLV of the DOH includes the vector commitment; or, The IPv6 extension header includes a hop-by-hop options header HBH, the HBH includes a first TLV and a second TLV, the first TLV of the HBH includes a first forwarding proof, and the second TLV of the HBH includes the vector commitment; or.

10. The method according to any one of claims 5 to 9, characterized in that The first data message includes a first encrypted routing table entry, and the first forwarding node sends the second data message to the third forwarding node, including: The first forwarding node decrypts the first encrypted routing table entry using the key of the first forwarding node to obtain the identifier of the third forwarding node; the first forwarding node sends the second data message to the third forwarding node based on the identifier of the third forwarding node; or, The first forwarding node uses the key of the first forwarding node to decrypt the first encrypted routing table entry to obtain the output interface of the first forwarding node; the first forwarding node sends the second data packet based on the output interface of the first forwarding node, and the output interface of the first forwarding node is used to communicate with the third forwarding node.

11. The method according to any one of claims 5 to 12, characterized in that The second data message includes a second encrypted routing table entry, which is encrypted based on the key of the third forwarding node, and the second encrypted routing table entry is used to indicate a sub-forwarding path from the third forwarding node to the fifth forwarding node included in the forwarding path.

12. The method according to claim 11, characterized in that The second encrypted routing table entry includes at least one of a node identification ciphertext or an output interface ciphertext, the node identification ciphertext is a ciphertext obtained by encrypting the identification of the fifth forwarding node based on the key of the third forwarding node, the output interface ciphertext is a ciphertext obtained by encrypting the identification of the output interface of the third forwarding node based on the key of the third forwarding node, and the output interface of the third forwarding node is used to communicate with the fifth forwarding node.

13. The method according to any one of claims 1 to 3, characterized in that The first data message includes a second forwarding proof, and the first forwarding node obtains the first data message, including: the first forwarding node receives the first data message from a second forwarding node, and the second forwarding node is an upstream node of the first forwarding node in the forwarding path; The method also includes: the first forwarding node verifies the second forwarding proof based on a vector commitment, identity information of the second forwarding node, and location information of the second forwarding node, wherein the vector commitment indicates a correspondence between the location of the first forwarding node and the identity of the first forwarding node and a correspondence between the location of the second forwarding node and the identity of the second forwarding node.

14. The method according to claim 13, characterized in that The first forwarding node verifies the second forwarding proof based on the vector commitment, the identity information of the second forwarding node, and the location information of the second forwarding node, including: The first forwarding node verifies the second forwarding proof based on the vector commitment, the identity information of the second forwarding node, the location information of the second forwarding node, the identity information of a fourth forwarding node, and the location information of the fourth forwarding node, wherein the fourth forwarding node includes at least one node from the head node on the forwarding path to the previous forwarding node of the second forwarding node on the forwarding path.

15. The method according to claim 13 or 14, characterized in that After the first forwarding node verifies the second forwarding proof based on the vector commitment, the identity information of the second forwarding node, and the location information of the second forwarding node, the method further includes: In response to determining that the second forwarding proof fails verification, the first forwarding node discards the first data message or outputs an alarm message; In response to determining that the second forwarding proof passes verification, the first forwarding node forwards the first data packet.

16. The method according to any one of claims 4, 7 to 9 or 13 to 15, characterized in that The vector commitment includes at least one of a KZG polynomial commitment, a fast Reed-Solomon interactive algebra FRI commitment, a succinct non-interactive argument of knowledge SNARK proof, an RSA accumulator, a FC function commitment, a Pedersen commitment, a Merkle Tree commitment or a Walker Tree commitment.

17. The method according to any one of claims 1 to 3, characterized in that After the first forwarding node obtains the first forwarding proof based on the location information of the first forwarding node and the identity information of the first forwarding node, the method further includes: The first forwarding node sends the first forwarding certificate to the verification node.

18. The method according to any one of claims 1 to 17, characterized in that The header of the first data message includes a trusted path identifier, where the trusted path identifier is used to indicate obtaining a forwarding certificate, and the first forwarding node obtaining a first forwarding certificate based on the location information of the first forwarding node and the identity information of the first forwarding node includes: In response to identifying the trusted path identifier in the first data message, the first forwarding node obtains a first forwarding proof based on location information of the first forwarding node and identity information of the first forwarding node.

19. The method according to claim 18, characterized in that The message header in the first data message includes an IPv6 basic header, the destination address field of the IPv6 basic header includes a segment identifier SID of the first forwarding node, and the SID of the first forwarding node includes the trusted path identifier.

20. The method according to claim 19, characterized in that The SID of the first forwarding node includes a function field, and the function field includes the trusted path identifier; or, The SID of the first forwarding node includes a parameter field, and the parameter field includes the trusted path identifier.

21. The method according to any one of claims 1 to 20, characterized in that The identity information of the first forwarding node includes at least one of an address, a certificate, a public key, a segment identifier SID, a multi-protocol label switching MPLS label, an access control token token, a router identifier routerID, a host name, or identity information encrypted based on a key of the first forwarding node.

22. The method according to claim 21, characterized in that The identity information encrypted based on the key of the first forwarding node includes at least one of a signature, a message authentication code MAC tag, a zero-knowledge NIZK proof, or a Sigma protocol proof.

23. The method according to any one of claims 1 to 22, characterized in that The forwarding path includes a service function chain, and the at least one forwarding node includes a service function SF node in the service function chain; or, The forwarding path includes a segment list path, and the at least two forwarding nodes include segment routing (SR) endpoints in the segment list path; The forwarding path includes a label switched path, and the at least two forwarding nodes include a label switched router LSR in the label switched path.

24. A method for verifying a forwarding certificate, characterized in that: The method comprises: The verification node obtains a vector commitment, identity information of a first forwarding node, location information of the first forwarding node, and a first forwarding proof, wherein the location information of the first forwarding node indicates a first location of the first forwarding node on a forwarding path, the forwarding path includes at least two forwarding nodes, the at least two forwarding nodes include the first forwarding node, the identity information of the first forwarding node is used to indicate the identity of the first forwarding node, the vector commitment indicates a correspondence between the location of the first forwarding node and the identity of the first forwarding node, and the first forwarding proof is used to prove that the first forwarding node is at the first location on the forwarding path; The verification node verifies the first forwarding proof based on the vector commitment, the identity information of the first forwarding node, and the location information of the first forwarding node.

25. The method according to claim 24, characterized in that The at least two forwarding nodes further include a second forwarding node, where the second forwarding node is an upstream node of the first forwarding node included in the forwarding path, and the verification node verifies the first forwarding proof based on the vector commitment, the identity information of the first forwarding node, and the location information of the first forwarding node, including: The verification node verifies the first forwarding proof based on the vector commitment, the location information of the first forwarding node, the identity information of the first forwarding node, the location information of the second forwarding node, and the identity information of the second forwarding node, and the vector commitment also indicates the correspondence between the location of the second forwarding node and the identity of the second forwarding node.

26. A method for verifying a forwarding certificate, characterized in that: The method comprises: The controller obtains identity information of a first forwarding node, location information of the first forwarding node, identity information of a second forwarding node, and location information of the second forwarding node, wherein the identity information of the first forwarding node is used to indicate the identity of the first forwarding node, the location information of the first forwarding node is used to indicate the location of the first forwarding node on a forwarding path, the identity information of the second forwarding node is used to indicate the identity of the second forwarding node, and the location information of the second forwarding node is used to indicate the location of the second forwarding node on a forwarding path, wherein the forwarding path includes the first forwarding node and the second forwarding node; The controller obtains a vector commitment based on the identity information of the first forwarding node, the location information of the first forwarding node, the identity information of the second forwarding node, and the location information of the second forwarding node, the vector commitment indicating a correspondence between the location of the first forwarding node and the identity of the first forwarding node and a correspondence between the location of the second forwarding node and the identity of the second forwarding node, and the vector commitment is used to verify the forwarding proof.

27. The method according to claim 26, characterized in that After the controller obtains the vector commitment based on the identity information of the at least two forwarding nodes and the location information of the at least two forwarding nodes, the method further includes: The controller sends the vector commitment to the first forwarding node, the second forwarding node or the verification node; or, The controller saves the corresponding relationship between the identifier of the forwarding path and the vector commitment in a database.

28. A device for obtaining a forwarding certificate, characterized in that: The device is arranged at a first forwarding node, and comprises: an acquiring unit, configured to acquire a first data message, wherein a forwarding path of the first data message includes at least two forwarding nodes, and the at least two forwarding nodes include the first forwarding node; acquire location information of the first forwarding node and identity information of the first forwarding node, wherein the location information of the first forwarding node indicates a first location of the first forwarding node on the forwarding path, and the identity information of the first forwarding node indicates an identity of the first forwarding node; A processing unit is used to obtain a first forwarding proof based on the location information of the first forwarding node and the identity information of the first forwarding node, wherein the first forwarding proof is used to prove that the first forwarding node is at the first position on the forwarding path.

29. The device according to claim 28, characterized in that The at least two forwarding nodes also include a second forwarding node, which is an upstream node of the first forwarding node in the forwarding path. The processing unit is used to obtain a first forwarding proof based on location information of the first forwarding node, identity information of the first forwarding node, location information of the second forwarding node and identity information of the second forwarding node, the location information of the second forwarding node indicates a second position of the second forwarding node on the forwarding path, and the identity information of the second forwarding node indicates the identity of the second forwarding node.

30. The device according to claim 28 or 29, characterized in that The processing unit is further configured to verify the first forwarding proof based on a vector commitment, location information of the first forwarding node, identity information of the first forwarding node, location information of the second forwarding node, and identity information of the second forwarding node, wherein the vector commitment indicates a correspondence between the locations of the at least two forwarding nodes and the identities of the at least two forwarding nodes.

31. The device according to any one of claims 28 to 30, characterized in that The obtaining unit is further configured to cause the first forwarding node to obtain a second data packet based on the first data packet and the first forwarding proof, wherein the first data packet includes payload data, and the second data packet includes the first forwarding proof and the payload data; The device further includes: a sending unit, configured to send the second data message, and the third forwarding node is a next node of the first forwarding node on the forwarding path.

32. The device according to claim 31, characterized in that The first data message includes a first encrypted routing table entry, and the sending unit is used to decrypt the first encrypted routing table entry using the key of the first forwarding node to obtain the identifier of the third forwarding node; The first forwarding node sends the second data message to the third forwarding node based on the identifier of the third forwarding node; or, uses the key of the first forwarding node to decrypt the first encrypted routing table entry to obtain the outbound interface of the first forwarding node; The first forwarding node sends the second data packet based on an outbound interface of the first forwarding node, where the outbound interface of the first forwarding node is used to communicate with the third forwarding node.

33. The device according to claim 31 or 32, characterized in that The first data packet includes a second forwarding proof, and the obtaining unit is used to receive the first data packet from a second forwarding node, where the second forwarding node is an upstream node of the first forwarding node in the forwarding path; the processing unit is further used to verify the second forwarding proof based on a vector commitment, identity information of the second forwarding node, and location information of the second forwarding node, wherein the vector commitment indicates a correspondence between the location of the first forwarding node and the identity of the first forwarding node and a correspondence between the location of the second forwarding node and the identity of the second forwarding node.

34. The device according to claim 33, characterized in that The processing unit is further used to discard the first data message or output an alarm message in response to determining that the second forwarding proof fails verification; in response to determining that the second forwarding proof passes verification, instruct the sending unit to forward the first data message.

35. The device according to claim 28 or 29, characterized in that The device also includes: a sending unit, configured to send the first forwarding certificate to a verification node.

36. A verification device for forwarding proof, characterized in that: The device comprises: an acquiring unit, configured to acquire a vector commitment, identity information of a first forwarding node, location information of the first forwarding node, and a first forwarding proof, wherein the location information of the first forwarding node indicates a first location of the first forwarding node on a forwarding path, the forwarding path includes at least two forwarding nodes, the at least two forwarding nodes include the first forwarding node, the identity information of the first forwarding node is used to indicate an identity of the first forwarding node, the vector commitment indicates a correspondence between the location of the first forwarding node and the identity of the first forwarding node, and the first forwarding proof is used to prove that the first forwarding node is at the first location on the forwarding path; A verification unit is used to verify the first forwarding proof based on the vector commitment, the identity information of the first forwarding node, and the location information of the first forwarding node.

37. The device according to claim 36, characterized in that The at least two forwarding nodes also include a second forwarding node, where the second forwarding node is an upstream node of the first forwarding node included in the forwarding path, and the verification unit is used to verify the first forwarding proof based on the vector commitment, the location information of the first forwarding node, the identity information of the first forwarding node, the location information of the second forwarding node, and the identity information of the second forwarding node, and the vector commitment also indicates the correspondence between the location of the second forwarding node and the identity of the second forwarding node.

38. A verification device for forwarding proof, characterized in that: The device comprises: an acquiring unit, for acquiring identity information of a first forwarding node, location information of the first forwarding node, identity information of a second forwarding node, and location information of the second forwarding node, wherein the identity information of the first forwarding node is used to indicate the identity of the first forwarding node, the location information of the first forwarding node is used to indicate the location of the first forwarding node on a forwarding path, the identity information of the second forwarding node is used to indicate the identity of the second forwarding node, and the location information of the second forwarding node is used to indicate the location of the second forwarding node on a forwarding path, wherein the forwarding path includes the first forwarding node and the second forwarding node; a processing unit, configured to obtain a vector commitment based on the identity information of the first forwarding node, the position information of the first forwarding node, the identity information of the second forwarding node, and the position information of the second forwarding node, the vector commitment indicating a correspondence between the position of the first forwarding node and the identity of the first forwarding node and a correspondence between the position of the second forwarding node and the identity of the second forwarding node, the vector commitment being used to verify a forwarding proof.

39. The device according to claim 38, characterized in that The device also includes: a sending unit, configured for the controller to send the vector commitment to the first forwarding node, the second forwarding node or the verification node; or A storage unit is used to store the corresponding relationship between the identifier of the forwarding path and the vector commitment in a database.

40. A computing device, characterized in that The computing device comprises: a processor, the processor is coupled to a memory, the memory stores at least one computer program instruction, and the at least one computer program instruction is loaded and executed by the processor so that the computing device implements the method according to any one of claims 1 to 23.

41. A computing device, characterized in that The computing device comprises: a processor, the processor is coupled to a memory, the memory stores at least one computer program instruction, and the at least one computer program instruction is loaded and executed by the processor so that the computing device implements the method of claim 24 or 25.

42. A computing device, characterized in that The computing device comprises: a processor, the processor is coupled to a memory, the memory stores at least one computer program instruction, the at least one computer program instruction is loaded and executed by the processor, so that the computing device implements the method described in any one of claims 26 or 27.

43. A network system, characterized in that: The system comprises the apparatus as claimed in any one of claims 28 to 35, the apparatus as claimed in claim 36 or 37, and the apparatus as claimed in claim 38 or 39; or, the system comprises the device as claimed in claim 40, the device as claimed in claim 41, and the device as claimed in claim 42.

44. A computer-readable storage medium, characterized in that The storage medium stores at least one instruction, and when the instruction is executed on a computer, the computer executes the method according to any one of claims 1 to 27.

45. A computer program product, characterized in that The computer program product comprises one or more computer program instructions, and when the computer program instructions are loaded and executed by a computer, the computer is caused to execute the method according to any one of claims 1 to 27.

Images