Forwarding proof acquisition method and device, and forwarding proof verification method and device

Abstract

Embodiments of the present application provide a forwarding proof acquisition method and device, and a forwarding proof verification method and device. On the basis of the location of a forwarding node on a forwarding path and the identity of the forwarding node, a forwarding proof is acquired, achieving the location binding of the forwarding proof. A forwarding proof is not only related to the identity of a forwarding node, but also to the location of the forwarding node on a forwarding path. Only by a correct node and when a data packet is forwarded to a correct location on a forwarding path, a correct forwarding proof can be calculated, so that the forwarding proof and the actual forwarding situation of the data packet have high binding performance. If a node in a path is skipped or an extra unspecified node is passed by during forwarding, the correspondence no longer exists due to the identity of the node and the location of the node, and therefore, a forwarding proof acquired on the basis of the identity of the node and the location of the node cannot pass verification, thereby improving the trustworthiness of forwarding proofs.

Description

Method for obtaining forwarding certificate, method and device for verifying forwarding certificate

[0001] This application claims priority to Chinese patent application No. 202310784326.7 filed on June 28, 2023, entitled “Method for verifying message forwarding path locking and order-preserving forwarding”, and claims priority to Chinese patent application No. 202310892814.X filed on July 19, 2023, entitled “Method for obtaining forwarding certificate, method and device for verifying forwarding certificate”, all contents of which are incorporated by reference into this application. Technical Field

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

[0003] Proof of Forwarding (PfForwarding) is a type of data generated during the forwarding process to verify the forwarding of a data message. This helps reduce the likelihood of data messages being tampered with or forged during forwarding, thereby improving data transmission security.

[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.

[0005] Summary of the Invention

[0006] The present invention provides a method for obtaining a forwarding certificate, a method for verifying a forwarding certificate, and an apparatus for verifying a forwarding certificate, which can improve the credibility of the forwarding certificate. The technical solution is as follows.

[0007] 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 the 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 in the first position on the forwarding path.

[0008] 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 only when the data message is forwarded to the correct position on the forwarding path by the correct node, 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 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, thereby improving the credibility of the forwarding proof.

[0009] 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 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, 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 the 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.

[0010] Because the forwarding proof is obtained based on the locations and identities of multiple forwarding nodes, it can simultaneously verify whether multiple nodes are at corresponding locations on the forwarding path. This leverages the advantages of batch processing to improve the overall verification performance of the forwarding path, saving time in computing and verifying proofs. Furthermore, this approach ensures that the time required to obtain the forwarding proof does not increase linearly with the number of nodes in the forwarding path, making it more suitable for large-scale networking and improving scalability.

[0011] 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 every node from the first forwarding node on the forwarding path to the previous forwarding node of the first forwarding node on the forwarding path.

[0012] 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.

[0013] 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, where the vector commitment indicates the correspondence between the locations of at least two forwarding nodes and the identities of the at least two forwarding nodes.

[0014] By verifying the forwarding proofs associated with multiple nodes based on vector commitments, it is possible to verify that multiple nodes are at the correct position in the forwarding path at once, eliminating the need to verify the forwarding proofs of each node separately. This reduces the number of verifications required for the entire forwarding path and speeds up verification. Furthermore, since the verification covers the location and identity of multiple nodes, it also enables more comprehensive verification.

[0015] 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 payload data; the first forwarding node sends the second data packet to the third forwarding node, and the third forwarding node is the next node of the first forwarding node on the forwarding path.

[0016] Because the data packets transmitted from this node to the next node carry this node's forwarding proof, the next node can easily verify the data source based on this node's forwarding proof, thereby improving network security. If an attacker hijacks and / or diverts data packets from this node to a device controlled by the attacker and then forwards them back to a downstream node in the forwarding path, the downstream node can identify the problem with the data source based on the failure to verify the forwarding proof, thereby reducing the risk of further transmission of the attack packet.

[0017] 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.

[0018] By replacing the previous hop's forwarding proof with the current node's forwarding proof, the message no longer needs to store the forwarding proof of every node it has passed through. This prevents the number of message bytes occupied by the proof from increasing with the number of nodes, saving message space. Furthermore, since the data message only needs to carry the proof of one node during forwarding, rather than multiple nodes, network resources required to transmit the proof are saved.

[0019] In some possible implementations, the second data packet further includes a 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.

[0020] By carrying 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.

[0021] 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, making it suitable for scenarios such as IPv6 networks, and providing a function for verifying the source of data based on the forwarding proof in the IPv6 network.

[0022] 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, which is suitable for scenarios such as business function chains, and facilitates verification of whether the data packets are forwarded in the order specified by the business function chain.

[0023] 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, which is suitable for scenarios such as MPLS protocol communication. It provides a mechanism for verifying the source of data in the MPLS network, making it easier to verify whether the data packets are forwarded in the order specified by the MPLS tunnel.

[0024] 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, 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, making it easier to verify whether the data packets are forwarded in the order specified by the VxLAN tunnel.

[0025] 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, which 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, making it easier to verify whether the data packets are forwarded in the order specified by the IPSec tunnel.

[0026] 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) header, the APN header includes an application-aware network identifier (APN ID), and the APN ID includes a first forwarding proof and a 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 the first forwarding proof, and the second TLV of the DOH includes a vector commitment. 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 the first forwarding proof, and the second TLV of the HBH includes a vector commitment.

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

[0028] 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 first forwarding node's key 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 first forwarding node's key 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.

[0029] Because the identity of the next forwarding node can only be obtained by decrypting it based on the node's key, the confidentiality of the identity of the next forwarding node is improved. Without a node's key, an attacker cannot know the node's next hop node. This makes it impossible for an attacker to pre-calculate the forwarding proof based on the node's known location and identity, making it more difficult to crack the forwarding proof and further improving network security. Furthermore, when an attacker attempts to skip a node and forward data directly to the node's subsequent nodes, since the attacker cannot obtain the node's key, it cannot decrypt the subsequent node's identity, causing the illegal forwarding of data to stagnate, effectively achieving a passive interception effect.

[0030] 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 the sub-forwarding path from the third forwarding node to the fifth forwarding node included in the forwarding path.

[0031] 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 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 in deeper layers. This achieves path hiding and reduces 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.

[0032] In some possible implementations, the second encrypted routing table entry includes at least one of a node identification ciphertext or an outgoing 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, and the outgoing interface ciphertext is a ciphertext obtained by encrypting the identification of the outgoing interface of the third forwarding node based on the key of the third forwarding node, and the outgoing interface of the third forwarding node is used to communicate with the fifth forwarding node.

[0033] 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, where 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, where 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.

[0034] 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, 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.

[0035] By verifying the previous hop's forwarding proof based on vector commitment, it's possible to confirm the location and identity of the previous hop, mitigating the risk of incorrect data provenance. Furthermore, because each node's verification is based on the previous hop's, a continuous verification chain is formed, reducing the probability of any node in the forwarding path masquerading, spoofing, or tampering with data packets, thereby improving network security.

[0036] 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.

[0037] By discarding data packets that fail verification, the system prevents packets with questionable data sources from being transmitted from this node to the next node, thereby quickly preventing the further spread of packets with questionable data sources. This reduces the probability of unauthorized data access and tampering, reduces the possibility of network attacks, and improves network security. By outputting alarm information, the management or control plane can be notified of verification failures in a timely manner, reducing the risk of network attacks.

[0038] 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, an FC function commitment, a Pedersen commitment, a Merkle Tree commitment, or a Walker Tree commitment.

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

[0040] 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.

[0041] By transmitting the forwarding proof to the verification node, the forwarding proof can be verified by the verification node in real time during the message forwarding process.

[0042] In some possible implementations, the message header in the first data message includes a trusted path identifier, 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.

[0043] 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.

[0044] By including a trusted path identifier in the message header of a data message, forwarding nodes are 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 require forwarding proof generation. This simplifies the configuration process and reduces configuration complexity.

[0045] 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.

[0046] 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 the message.

[0047] 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, a router identifier router ID, or a host name.

[0048] 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.

[0049] 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.

[0050] By using encrypted identity information to calculate or verify the forwarding proof, the security and privacy of the forwarding proof can be further improved due to the higher security and privacy of the identity information.

[0051] 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.

[0052] By using NIZK proof as identity information to calculate 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.

[0053] 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 label switching routers LSR in the label switching path.

[0054] The above method supports applications in scenarios such as service function chains, SRv6, and MPLS that require data packets to be forwarded in a certain order.

[0055] In a second aspect, a method for verifying a forwarding proof is provided, the method comprising: a verification node obtaining 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 position of the first forwarding node on a forwarding path, the forwarding path includes at least two forwarding nodes, and 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 position of the first forwarding node and the identity of the first forwarding node; the first forwarding proof is used to prove that the first forwarding node is in 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.

[0056] 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 and position of the node cannot pass the verification.

[0057] In some possible implementations, 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.

[0058] Because forwarding proofs are based on the locations of multiple forwarding nodes and their authenticated identities, it is possible to verify that multiple nodes are at their corresponding locations on the forwarding path at once. This leverages the advantages of batch processing to improve overall forwarding path verification performance and saves time on computing and verifying proofs. Furthermore, this approach ensures that the time required to verify the forwarding proofs increases almost linearly with the number of nodes in the forwarding path, making it more suitable for large-scale networking and improving scalability.

[0059] 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, 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 comprises 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, 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, and the vector commitment is used to verify the forwarding proof.

[0060] Because vector commitments are derived based on the identity and location information of forwarding nodes, they are related to both the identity and location information of the forwarding nodes. These commitments can reflect the correspondence between the location and identity information of forwarding nodes along the forwarding path. Therefore, when verifying forwarding proofs based on vector commitments, the identity, location, and forwarding proofs must correspond to each other for verification to pass. A forwarding proof obtained without a correspondence between the identity and location information will fail verification. Furthermore, because vector commitments are encrypted, the identity and location information of the forwarding nodes contained therein cannot be directly obtained from the vector commitments themselves. It is also difficult to decrypt or reverse engineer the vector commitments to obtain the identity and location information of the forwarding nodes. This conceals the identity and location information of the forwarding nodes along the forwarding path, thereby enhancing the privacy and confidentiality of the identity and location information of the forwarding nodes.

[0061] 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 sending the vector commitment to the first forwarding node, the second forwarding node, or the verification node; or the controller storing the correspondence between the forwarding path identifier and the vector commitment in a database.

[0062] 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.

[0063] In a fourth aspect, a device for obtaining a forwarding certificate 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 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; a processing unit, used to obtain a first forwarding certificate based on the location information of the first forwarding node and the identity information of the first forwarding node, the first forwarding certificate being used to prove that the first forwarding node is in the first position on the forwarding path.

[0064] 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. The processing unit is used to obtain 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 indicates the 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.

[0065] 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.

[0066] In some possible implementations, the apparatus further 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 the locations of at least two forwarding nodes and the identities of the at least two forwarding nodes.

[0067] 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, where 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 for sending the second data packet, and the third forwarding node is the next node of the first forwarding node on the forwarding path.

[0068] 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.

[0069] In some possible implementations, the second data packet further includes a 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.

[0070] 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,

[0071] 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,

[0072] 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,

[0073] 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; or,

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

[0075] 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

[0076] 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 a first forwarding proof and a vector commitment; or,

[0077] 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 a vector commitment; or,

[0078] 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

[0079] In some possible implementations, the first data packet includes a first encrypted routing table entry, and a 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 packet to the third forwarding node based on the identifier of the third forwarding node; or, decrypt the first encrypted routing table entry using the key of the first forwarding node 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.

[0080] 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 the sub-forwarding path from the third forwarding node to the fifth forwarding node included in the forwarding path.

[0081] In some possible implementations, the second encrypted routing table entry includes at least one of a node identification ciphertext or an outgoing 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, and the outgoing interface ciphertext is a ciphertext obtained by encrypting the identification of the outgoing interface of the third forwarding node based on the key of the third forwarding node, and the outgoing interface of the third forwarding node is used to communicate with the fifth forwarding node.

[0082] 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 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, where 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.

[0083] In some possible implementations, the processing unit is configured to verify the second forwarding proof based on the vector commitment, identity information of the second forwarding node, location information of the second forwarding node, identity information of a fourth forwarding node, and 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.

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

[0085] 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, an FC function commitment, a Pedersen commitment, a Merkle Tree commitment, or a Walker Tree commitment.

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

[0087] In some possible implementations, the header of the first data message includes a trusted path identifier, which is used to indicate obtaining a forwarding certificate. The processing unit is used to obtain a first forwarding certificate 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.

[0088] 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.

[0089] 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,

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

[0091] 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, a router identifier router ID, a host name, or identity information encrypted based on a key of the first forwarding node.

[0092] 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.

[0093] 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,

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

[0095] 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.

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

[0097] 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, and the at least two forwarding nodes include the first forwarding node; the identity information of the first forwarding node indicates 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 proves that the first forwarding node is at the first location on the forwarding path;

[0098] A verification unit is configured 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.

[0099] In some possible implementations, 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. The verification unit is configured to verify the first forwarding proof based on the 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. The vector commitment further indicates a correspondence between the location of the second forwarding node and the identity of the second forwarding node.

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

[0101] an acquiring unit, configured to acquire 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, and 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, where the forwarding path includes the first forwarding node and the second forwarding node;

[0102] a processing unit, configured to obtain 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, 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, and the vector commitment is used to verify the forwarding proof.

[0103] In some possible implementations, the apparatus further includes: a sending unit configured to control the sending of the vector commitment to the first forwarding node, the second forwarding node, or the verification node; or a storing unit configured to store a correspondence between the identifier of the forwarding path and the vector commitment in a database.

[0104] In a seventh aspect, a computing device is provided, comprising a processor 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 to cause the computing device to perform the method provided in the first aspect or any optional embodiment of the first aspect, wherein the network interface is configured to receive or send messages. Specific details of the computing device provided in the seventh aspect can be found in the first aspect or any optional embodiment of the first aspect, and are not further described here.

[0105] In an eighth aspect, a computing device is provided, comprising a processor 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 to cause the computing device to implement the method provided in the second aspect or any optional embodiment of the second aspect. Specific details of the computing device provided in the eighth aspect can be found in the second aspect or any optional embodiment of the second aspect, and are not further described here.

[0106] In a ninth aspect, a computing device is provided, comprising a processor 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 to cause the computing device to implement the method provided in the third aspect or any optional embodiment of the third aspect. Specific details of the computing device provided in the ninth aspect can be found in the third aspect or any optional embodiment of the third aspect, and are not further described here.

[0107] In the tenth aspect, a computer-readable storage medium is provided, which stores at least one instruction. When the instruction is executed on a computer, the computer executes the method provided by the first aspect or any optional method of the first aspect.

[0108] In the eleventh aspect, a computer-readable storage medium is provided, which stores at least one instruction. When the instruction is executed on a computer, the computer executes the method provided by the second aspect or any optional method of the second aspect.

[0109] In the twelfth aspect, a computer-readable storage medium is provided, which stores at least one instruction. When the instruction is executed on a computer, the computer executes the method provided by the third aspect or any optional method of the third aspect.

[0110] 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 run by a computer, the computer executes the method provided by the first aspect or any optional method of the first aspect.

[0111] In the 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 in the above-mentioned second aspect or any optional method of the second aspect.

[0112] 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 run by a computer, the computer executes the method provided by the third aspect or any optional method of the third aspect.

[0113] 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.

[0114] 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.

[0115] 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.

[0116] 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.

[0117] 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

[0118] FIG1 is a schematic diagram of a verification scenario of a forwarding certificate in a real-time verification mode provided by an embodiment of the present application;

[0119] FIG2 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;

[0120] FIG3 is a schematic diagram of a verification scenario of a forwarding certificate in an on-path verification mode provided by an embodiment of the present application;

[0121] FIG4 is a schematic diagram of a method for obtaining and verifying a forwarding certificate in an on-path verification mode provided by an embodiment of the present application;

[0122] FIG5 is a schematic diagram of a verification scenario of a forwarding certificate in an endpoint verification mode provided by an embodiment of the present application;

[0123] FIG6 is a schematic diagram of a method for obtaining and verifying a forwarding certificate in an endpoint verification mode provided by an embodiment of the present application;

[0124] FIG7 is a schematic diagram of a business function chain scenario provided by an embodiment of the present application;

[0125] FIG8 is a schematic diagram of a message encapsulation format in a service function chain scenario provided by an embodiment of the present application;

[0126] 9 is a schematic diagram of a verification scenario of a forwarding certificate in a path-based verification mode under a business function chain scenario provided by an embodiment of the present application;

[0127] FIG10 is a schematic diagram of a message encapsulation format in an SRv6 scenario provided in an embodiment of the present application;

[0128] 11 is a schematic diagram of a method for obtaining and verifying a forwarding certificate in a path-within-path verification mode in an SRv6 scenario according to an embodiment of the present application;

[0129] FIG12 is a schematic diagram of a verification scenario of a forwarding certificate in an endpoint verification mode under an SRv6 scenario provided by an embodiment of the present application;

[0130] FIG13 is a schematic diagram of the structure of a device for obtaining a forwarding certificate provided in an embodiment of the present application;

[0131] FIG14 is a schematic diagram of the structure of a verification device for forwarding proof provided in an embodiment of the present application;

[0132] FIG15 is a schematic diagram of the structure of a verification device for forwarding proof provided in an embodiment of the present application;

[0133] FIG16 is a schematic diagram of the structure of a computing device provided in an embodiment of the present application. DETAILED DESCRIPTION

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

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

[0136] In the context of routing security, network attacks include route hijacking, route injection, and traffic detour. Route hijacking occurs when an attacker, with malicious intent, hijacks and / or diverts network traffic to a network device or autonomous system (AS) controlled by the attacker, where it then monitors, tampers with, or intercepts traffic. Route hijacking is often referred to as prefix hijacking or Internet Protocol (IP) hijacking. Another possible non-malicious cause of route hijacking is network misconfiguration. Route injection involves injecting forged routing information into network devices such as routers, disseminating it throughout the network. Through route injection, an attacker can alter network routing paths, redirecting traffic to a path controlled by the attacker. Traffic detour occurs when an attacker tamperes with the configuration of network devices to divert traffic from the intended path, redirecting it to a path specified by the attacker. This attack can be used to bypass security measures or carry out specific network attacks.

[0137] Regardless of whether the attack is motivated by subjective malice or non-malicious intent, the primary goal of the trusted path mechanism (also known as a secure routing mechanism or path validation mechanism) is to mitigate network attacks by ensuring that data packets are forwarded hop-by-hop along the forwarding paths planned by network controllers or terminals, and providing publicly verifiable proof of forwarding. The trusted path mechanism is a key supporting technology for ensuring routing security at all levels of the Internet and for enabling cutting-edge architectures and applications such as path-aware networking (PAN) and application-aware networking (APN). However, current trusted path mechanisms have certain security limitations. Consequently, routing security remains an internationally recognized cybersecurity challenge.

[0138] A complete trusted path mechanism includes two technical components: path locking and path verification. Path locking, also known as path binding, is a mechanism that ensures that data packets are forwarded along a specific forwarding path. Path verification verifies that data packets are forwarded along the specified forwarding path.

[0139] If path locking is achieved using non-cryptographic traversal proofs, for example, the head node adds a field with an initial value to the data packet header. Each forwarding node then adds its identity information to the packet, effectively using the identity information of all forwarding nodes as a forwarding proof. However, this approach lacks a strong binding between the forwarding proof and the forwarding node's position on the forwarding path, making it impossible to generate a forwarding proof that is strongly bound to the forwarding node's position. For example, it is impossible to ensure that only the node at the i-th position on the forwarding path can generate the i-th proof. This results in poor credibility of the forwarding proof, making it extremely easy to forge or tamper with the forwarding proof. For example, if a data packet does not follow the designated path hop by hop, but instead skips nodes along the forwarding path or passes through unnecessary, unspecified nodes, the forwarding proof obtained in this scenario can still pass verification with a certain probability, indicating that the forwarding proof's credibility is insufficient. Furthermore, even if the data packet carries the proofs of all nodes along the path, since the proofs are independent of the forwarding node's position on the forwarding path, there is no guarantee that the data was forwarded along that path. For example, the traversal proof could be added by a device outside the forwarding path after the message is forwarded. In other words, there is no strong binding relationship between the forwarding proof and the actual message forwarding situation, which means that data messages can be forwarded arbitrarily and then given a forged traversal proof. The traversal proof obtained at the end point is unreliable.

[0140] If path locking is achieved by using cryptographic traversal credentials, for example, each forwarding node establishes a key pair with the controller one by one, and then each routing node uses cryptography to generate an identity-binding certificate, and then passes the certificate, although the problem of forgery is slightly improved, the position of the forwarding node on the forwarding path is not taken into consideration 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 to add a forged traversal certificate to the tail node, resulting in the traversal certificate obtained from the tail node being unreliable, and it cannot be guaranteed that it will be forwarded according to the specified forwarding path during the transit process.

[0141] In view of this, in order to address the problem of poor credibility of the forwarding proof in the path locking mechanism due to the fact that the forwarding proof is independent of the position of the forwarding node on the forwarding path, 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 achieving 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. This ensures that the correct forwarding proof can only be calculated when the data message is forwarded to the correct position on the forwarding path by the correct node. This makes the forwarding proof strongly bound to the actual forwarding status of the data message and makes the forwarding proof publicly verifiable and difficult to tamper with.

[0142] Position accuracy 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.

[0143] The correctness of the forwarding proof means that the forwarding proof obtained based on the node's identity and the node's position can be verified under the condition that the node's identity and the node's position 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, where 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 node's identity and the node's position correspond to each other is not met, the forwarding proof obtained based on the node's identity and the node's position 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 node's identity and the node's position will no longer correspond to each other, and therefore the forwarding proof obtained based on the node's identity and the node's position cannot be verified.

[0144] For example, if the selected forwarding path is forwarding node A → forwarding node B → forwarding node C → forwarding node D, then 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 this path, the forwarding proof 1 obtained based on at least one of the following: 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 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 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 forwarding proof 2 is calculated using the position (5) and identity (D) of forwarding node D on forwarding path 2, and verified using the commitment generated at the beginning, forwarding proof 2 will also fail verification because the position (5) and identity (D) on which forwarding proof 2 is based do not match.

[0145] 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 a specific node 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.

[0146] In one possible implementation, after forwarding node_i obtains a data packet, 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.

[0147] The identity information of forwarding node i indicates the identity of forwarding node i. For example, the identity information of forwarding node i is the identifier of forwarding node i. The location information of forwarding node i indicates the location i of forwarding node i on the forwarding path of the data packet. For example, the location information of forwarding node i is the sequence number of forwarding node i. The location information can optionally be represented as a positive integer, e.g., the location information of the head node is 1, the location information of the second forwarding node is 2, the location information of the third forwarding node is 3, and so on.

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

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

[0150] Vector commitment is a cryptographic technique used to prove the correctness of the value and position of each piece of information in a sequence of information (such as a vector, array, or list containing at least two elements), while maintaining the confidentiality of the information, typically without revealing the original content. Specifically, vector commitment allows each piece of information in a sequence to be committed and generates a corresponding proof, which other parties can verify to confirm the integrity of the sequence.

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

[0152] A commitment function involves entity A secretly selecting N sequentially ordered pieces of information M = (m_1, m_2, …, m_N) at once. It then calculates a commitment based on M and publicly reveals it. The commitment captures the ordering between M and the N pieces of information within it. However, the commitment prevents anyone from inferring the plaintext of the N pieces of information or the position of each piece of information within it. Typically, after calculating the commitment based on M, entity A cannot modify M.

[0153] The open function is used to obtain proofs to verify the information at a specific location. Specifically, entity A computes an opening proof (OP) and publicly discloses it, thereby proving that the information originally promised at location i is m_i. Open functions include single-point open functions and batch open functions.

[0154] The single-point open 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 prove that the information at position i is m_i;

[0155] The batch open function involves entity A computing a multi-point open proof (MP_B) at once. The multi-point open proof is used to prove that the set of multiple pieces of information m_i is B, where each m_i is at its corresponding position i. This multi-point open proof allows for simultaneous verification of information at multiple locations.

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

[0157] 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.

[0158] 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.

[0159] In an optional implementation of the present application, the node device responsible for routing (such as a controller or user device) serves 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. 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.

[0160] In one possible implementation, a forwarding proof associated with a single forwarding node is obtained based on a single-point open function, and the forwarding proof associated with the single forwarding node is verified based on a single-point verification function, thereby verifying the proof of the single node. In another possible implementation, a forwarding proof associated with multiple forwarding nodes is verified based on a batch verification function. A forwarding proof associated with multiple forwarding nodes is obtained based on a multi-point open function, thereby verifying multiple nodes in the path at once.

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

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

[0163] Specifically, vector commitments inherently possess positional binding, reflecting the binding relationship between the value of information and its position within the vector. Therefore, vector commitments are derived based on the identity and position information of the forwarding node, making them relevant to both the identity and position information of the forwarding node. This aligns the position and identity information of the forwarding node along the forwarding path. Therefore, when verifying a forwarding proof based on a vector commitment, the identity, position, and forwarding proof must correspond to each other for verification to succeed. A forwarding proof obtained without a corresponding identity and position information will fail verification. In other words, only node i at the correct position i can calculate a correct forwarding proof p_i, which cannot be forged by others.

[0164] Second, it helps to conceal the path. Because the vector commitment itself is in the form of ciphertext, the identity and location information of the forwarding nodes contained in it cannot be directly obtained through the vector commitment itself. It is also difficult to decrypt or reversely infer the identity and location information of the forwarding nodes from the vector commitment. This hides the identity and location information of the forwarding nodes on the forwarding path, thereby improving the privacy and confidentiality of the identity and location information of the forwarding nodes.

[0165] Third, it reduces the time it takes to obtain and verify commitments, improving their efficiency. Using a single-point commitment approach requires committing to the location and identity of each node one by one. If a forwarding path includes n nodes, it would take n times as long to obtain and verify commitments. Using a vector commitment approach, however, allows for a single commitment to a forwarding path containing at least two nodes (equivalent to a vector). If a forwarding path includes n nodes, obtaining and verifying commitments might only take log n or a constant amount of time. This reduces the risk of the committed data volume growing superlinearly with the number of nodes in the forwarding path, allowing for faster completion of the commitment and verification process, significantly improving efficiency and making it more suitable for scenarios involving a large number of nodes in the forwarding path. Furthermore, single-point commitments cannot bind the identity and location information of forwarding nodes, requiring other methods to achieve location binding, such as using a list to record location information. Vector commitments, however, offer location binding capabilities, allowing for direct binding of multiple identities to corresponding location information, simplifying the verification process.

[0166] The three functions listed above, commit, open, and verify, are merely examples of functions available for obtaining and verifying proofs of forwarding. In another possible implementation, other types of functions within vector commitment can be used to obtain and verify proofs of forwarding. For example, the create witness function (which functions as the open function) can be used to obtain proofs of forwarding, the verify eval function (which functions as the verify function) can be used to obtain proofs of forwarding, the create witness batch function (which functions as the batch open function) can be used to obtain multi-point proofs of forwarding, and the verify eval batch function (which functions as the batch verify function) can be used to verify multi-point proofs of forwarding.

[0167] If necessary, embodiments of the present application can optionally support forwarding nodes verifying the source of received data packets based on vector commitments and forwarding proofs, thereby ensuring the correctness of the data packet's source to a certain extent. In one possible implementation, data packets carry forwarding proofs along the way. When forwarding node_i receives data packet_i, forwarding node_i verifies the forwarding proof carried by data packet_i based on the vector commitment.

[0168] The methods for verifying the source of data messages based on vector commitment and forwarding proof include the following implementation methods.

[0169] Method 1 for verifying the source of a data message: Verify the single-point forwarding proof (OP) based on the location information and 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, where k is a positive integer less than or equal to i.

[0170] 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 packet received by forwarding node_i carries the single-point forwarding proof generated by the previous hop node of forwarding node i (node_i-1). The single-point forwarding proof is used to prove that node_i-1 forwarded the data packet at position i-1 on the forwarding path. Forwarding node_i verifies the single-point forwarding proof carried by the data packet 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.

[0171] 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.

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

[0173] 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. It can gradually verify that each hop node in the entire forwarding path is in the correct position with almost no jumps or interruptions.

[0174] 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.

[0175] Fourth, the correctness of the node's location can be verified. Since the forwarding proof of each forwarding node is obtained based on its identity 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.

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

[0177] 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.

[0178] First, efficiency is improved: compared with each node verifying the single-point forwarding proof separately, the multi-point forwarding proof can verify the forwarding proof 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 of calculating and verifying the proof.

[0179] Second, it reduces the number of verifications: By verifying the forwarding proofs of multiple nodes, the number of actual verifications can be reduced. For example, if there are m nodes on a forwarding path, verifying each node's single-point forwarding proof requires m verifications. However, by verifying the multi-point forwarding proofs of m nodes, all m nodes can be verified at once, reducing the number of verifications required to just one. This reduces the number of verifications required for the entire forwarding path and speeds up verification.

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

[0181] 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 verification scope covers the location and identity of each node on the entire forwarding path, thereby fully verifying the entire forwarding path.

[0182] In one possible implementation, the forwarding proof carried by a data packet is verified based on the location information and identity information of each node that the data packet has passed along the forwarding path. For example, a data packet received by forwarding node _i carries a multi-point forwarding proof. This multi-point forwarding proof is obtained based on the identity information and location information of each node from the head node to the previous node _i-1 on the forwarding path. Forwarding node _i verifies the multi-point forwarding proof carried by the data packet based on the vector commitment, the identity information and 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 packet passes through for verification, the benefits achieved include, but are not limited to, the following aspects.

[0183] First, from the perspective of verifying the source of the path, node _i is allowed to verify the first 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.

[0184] 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 separately. This takes advantage of batch processing to improve the overall verification performance, reduces time and computing costs, and improves verification efficiency.

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

[0186] Utilizing the identity and location information of each node in the forwarding path for verification is merely an example. Other implementations of this application support tracing and verifying nodes within a certain range preceding the current node on the forwarding path. The verifier can flexibly specify the required tracing scope based on actual needs, allowing different nodes to verify different parts of the forwarding path, thereby providing more flexible and adjustable tracing capabilities. The following example uses verification of nodes two or three hops before the forwarding node as an example.

[0187] In another possible implementation, forwarding node_i verifies the forwarding proof based on the vector commitment, the identity information of the two nodes preceding forwarding node_i in the forwarding path, and the location information of the two nodes preceding forwarding node_i, thereby tracing back and verifying the correctness of the two nodes preceding forwarding node_i. For example, a 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; a 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.

[0188] In another possible implementation, forwarding node_i verifies the forwarding proof based on the identity information of the three hops preceding forwarding node_i in the forwarding path, the location information of the three hops preceding forwarding node_i, and the vector commitment, thereby tracing back and verifying the correctness of the three hops preceding the current node. For example, a 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; a 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.

[0189] 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 passed through each forwarding node on the forwarding path in sequence.

[0190] 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, it proves that there may be a problem with the source of the data, for example, 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 message with problematic data source from being further transmitted from this node to the next node, thereby quickly preventing the data message with problematic data source from further propagation, reducing the probability of unauthorized data access and tampering, reducing the possibility of network attacks, and improving network security.

[0191] In one possible implementation, in response to determining that the forwarding proof carried by the data message fails verification, the forwarding node outputs an alarm message, where the alarm message indicates that the forwarding proof fails verification. In one possible implementation, the forwarding node notifies the alarm message to a network management system (NMS), an element management system (EMS), or a controller via a management plane protocol. For example, the forwarding node sends a Network Configuration Protocol (NETCOF) message to the controller, where the NETCOF message includes alarm information, where the NETCOF message indicates that the forwarding proof fails verification. In another example, the forwarding node sends a Simple Network Management Protocol (SNMP) message to the controller, where the SNMP message includes alarm information, where the SNMP message indicates that the forwarding proof fails verification. In another example, the forwarding node sends an alarm message to the controller based on telemetry indicating that the forwarding proof fails verification. In another example, the forwarding node sends an alarm message to the controller indicating that the forwarding proof fails verification based on Representational State Transfer (RESTful). For another example, based on a log management protocol, the forwarding node sends information indicating that the forwarding proof has failed verification in the form of a log to the controller. For example, the forwarding node sends a System Logging Protocol (Syslog) message to the controller, which includes an alarm indicating that the forwarding proof has failed verification. Syslog is a standard UNIX system log management protocol used to send log information generated by devices or applications to a remote server. In one possible implementation, the forwarding node outputs the alarm information using an alert notification. The alert notification can be sent via SMS, email, instant messaging, or other means, allowing administrators or network security teams to receive it promptly and take appropriate countermeasures. In another possible implementation, the forwarding node outputs the alarm information using a logging method. For example, forwarding node_i records the information about data packet_i that failed verification in the system log. In yet another possible implementation, forwarding node_i sends the alarm information to the controller. The controller provides a visual display of the alarm information, allowing administrators to quickly identify the problem and take appropriate measures.

[0192] 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.

[0193] 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.

[0194] 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 to prove and verify that one or N points (such as N identity information) are on this polynomial in constant time. The size of the committed data and the size of the data for each forwarding proof are both constants O(1). In the polynomial commitment, the information m_i is converted into the form of points (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 an index (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 the goal 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).

[0195] By using the KZG polynomial commitment method to obtain commitments and verify commitments, since KZG polynomial commitments have a constant time computational complexity when calculating commitments and opening proofs, and are 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, which is independent of the number of nodes N contained in the path. In other words, the time required to obtain commitments and the time required to verify commitments remain constant, and the amount of data for forwarding proofs remains constant. The time required to obtain commitments, the time required to verify commitments, and the amount of data for forwarding proofs do not increase with the length of the forwarding path. Even when the network scale is complex and the forwarding path includes a large number of nodes, commitments can still be obtained and verified quickly, thereby greatly improving the efficiency of obtaining and verifying commitments.

[0196] The implementation details of the KZG polynomial commitment are described in detail in the examples. The KZG polynomial commitment is only one possible way to obtain vector commitments. It not only achieves the effects of forwarding proof and position binding, but also has the advantage of high efficiency. Vector commitments obtained through other methods can also achieve the effects of forwarding proof and position binding.

[0197] In other possible implementations, fast Reed-Solomon interactive (FRI) commitments are used to obtain and verify commitments based on the identity and location information of forwarding nodes. FRI commitments are a commitment mechanism used in interactive proof systems to verify the integrity of polynomials. They can quickly verify whether a polynomial satisfies a set of constraints without having to calculate the entire polynomial item by item. Based on Reed-Solomon codes and interactive proof protocols, FRI commitments significantly reduce the complexity of verifying polynomials by constructing multiple small-scale Reed-Solomon codes and related proofs.

[0198] Other possible implementations employ succinct non-interactive argument of knowledge (SNARK) commitments, obtaining and verifying commitments based on the identity and location information of forwarding nodes. A SNARK commitment is a protocol used to prove the correctness of a computation and that the inputs held by one party satisfy specific conditions. SNARK proofs are non-interactive, meaning the prover does not need to interact with the verifier; they simply generate a proof and send it to the verifier. SNARK proofs are compact, small in size, and require relatively short verification times.

[0199] In other possible implementations, scalable transparent arguments of knowledge (STARK) commitments are used to obtain proofs of forwarding or vector commitments based on the identity and location information of the forwarding node; or STARK commitments are used to verify proofs of forwarding based on vector commitments. STARKs are a type of zero-knowledge proof technology that does not require a trusted third party to set up and initiate. Therefore, they are more decentralized and distributed, reducing the impact of single points of failure on obtaining proofs of forwarding or vector commitments and providing higher security. Furthermore, STARKs are post-quantum secure, so their use helps improve the proofs of forwarding's ability to resist quantum computing attacks and is more reliable in protecting the security of proofs of forwarding and identity information. Furthermore, the data size of proofs of forwarding generated using STARKs is relatively small, meaning that proofs can be transmitted using less storage space and offering advantages in verification efficiency. The next-hop forwarding node or verification node can verify the validity of the proof of forwarding in a relatively short period of time.

[0200] In other possible implementations, Bulletproofs are used to obtain proofs of forwarding or vector commitments based on the identity and location information of the forwarding node; or Bulletproofs are used to verify proofs of forwarding based on vector commitments. Bulletproofs are a type of zero-knowledge proof technology. Bulletproofs are cryptographic primitives used in zero-knowledge proofs to prove that a value satisfies a certain relationship without providing additional proof information. Bulletproofs also do not require a trusted third party to set up and start, making them more decentralized and distributed, reducing the impact of single points of failure on obtaining proofs of forwarding or vector commitments, and also providing higher security.

[0201] In other possible implementations, an RSA accumulator is used to obtain and verify commitments based on the identity and location information of forwarding nodes. An RSA accumulator is a data structure used to accumulate the elements of a set into an accumulator, allowing for subsequent verification of an element's membership in the set. Based on the RSA additive homomorphic property, an RSA accumulator can verify the presence of a specific element without disclosing the elements of the set.

[0202] In other possible implementations, FC function commitments are used to obtain and verify commitments based on the identity and location information of forwarding nodes. FC function commitments are a commitment mechanism that binds inputs to function calculation results, allowing the calculation results to be verified without exposing the inputs. FC function commitments can be implemented by combining zero-knowledge proof systems with commitment mechanisms. They can be used to protect computer privacy and verify the correctness of calculation results.

[0203] In other possible implementations, Pedersen commitments are used to obtain and verify commitments based on the identity and location information of forwarding nodes. Pedersen commitments are a commitment mechanism used to commit a value or vector to a hidden value. Based on the discrete logarithm problem, Pedersen commitments allow only the committer who knows the hidden value to verify the correctness of the commitment without revealing the actual value.

[0204] In other possible implementations, Merkle tree commitments are used to obtain and verify commitments based on the identity and location information of forwarding nodes. Merkle tree commitments are a commitment mechanism used to bind multiple elements in a set into a tree-like structure. The Merkle tree combines elements level by level using a hash function to generate a root hash, which serves as a commitment to the entire tree. During the verification phase, only certain elements in the set and the hash values ​​along the associated paths are needed to verify that the elements belong to the tree.

[0205] In other possible implementations, Verkle tree commitments are used to obtain and verify commitments based on the identity and location information of forwarding nodes. Verkle tree commitments are a commitment mechanism used to bind multiple elements in a set into a non-binary tree structure. Verkle trees use polynomial commitments to commit to paths from the root to the leaves of the tree and aggregate multiple paths. During the verification phase, only certain elements in the set and the polynomial commitments on the associated paths are needed to verify whether the elements belong to the tree.

[0206] In other possible implementations, the source of a data message is verified based on an aggregatable signature. For example, a data message contains a digital signature. This signature can be the signature of the previous hop, Node_i-1, or the aggregate signature of all nodes from Node_1 to Node_i-1 in the previous half. The characteristic of an aggregate signature is that the aggregation result of an infinite number of signatures is equal to the length of a single signature. Given the existence of a public key infrastructure (PKI), that is, the public identity of the node is known, Node_i can verify the correctness of this signature.

[0207] 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.

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

[0209] For example, node_i can only know the address of the next node_i+1 on the forwarding path to determine the next hop forwarding. Node_i cannot know the address of each node on the forwarding path from node_i+2 to the last node_N.

[0210] An encrypted routing table is used to guide data packets forwarding hop by hop along a specified forwarding path. The contents of an encrypted routing table are in ciphertext. To distinguish between the entire encrypted routing table and the portion of the encrypted routing table corresponding to a single forwarding node, the portion of the encrypted routing table corresponding to a single forwarding node is referred to as an encrypted routing table entry. An encrypted routing table contains at least one encrypted routing table entry.

[0211] 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 instruct node_i to forward the data packet to node_i+1, the next node after 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.

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

[0213] For example, in an IP network scenario, 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 an Internet Protocol version 4 (IPv4) network scenario, 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 an Internet Protocol version 6 (IPv6) network scenario, 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.

[0214] 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.

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

[0216] For example, in a layer 2 forwarding scenario, the address ciphertext of node_i+1 is obtained by encrypting the Media Access Control (MAC) address of node_i+1 based on the key of node_i.

[0217] 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 (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 (in reverse order).

[0218] 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.

[0219] 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 being peeled layer by layer. Specifically, in the encrypted routing table, each node can only decrypt the entry corresponding to the node in the encrypted routing table based on the key of the node. Therefore, based on the encrypted routing table, the node only knows the identifier of the next hop of the node, 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 layer by layer 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.

[0220] First, it reduces the probability of pre-calculating the proof of forwarding before forwarding. If the forwarding path, or routing table, is public, attackers could pre-calculate the proof of forwarding based on known location and identity information, thereby compromising data security. However, using an encrypted routing table hides the identity of each node in the complete path. During transmission, the node identities are revealed hop by hop. During each forwarding hop, only the identity of the next hop is known; the identities of subsequent nodes cannot be known in advance. This reduces the possibility of attackers pre-calculating the proof of forwarding during transmission, preventing attackers from obtaining the complete path and identity information from the outset and pre-calculating the proof of forwarding.

[0221] Second, after a malicious attacker diverts data, it becomes impossible to determine where it will be forwarded next. This prevents the forwarding of the data from being properly forwarded, effectively halting the forwarding process. Specifically, if an attacker attempts to skip a node and forward data directly to a subsequent node, they cannot obtain the node's key and, therefore, cannot decrypt the address of the subsequent node. Consequently, the attacker cannot determine which node the data was forwarded 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 a data packet intended for forwarding node B to forwarding node B'. However, forwarding node B' does not have forwarding node B's key. Therefore, forwarding node B' cannot decrypt the identifier of forwarding node C based on the encrypted routing table carried in the data packet. Consequently, forwarding node B' cannot forward the data packet to forwarding node C, and forwarding node C also struggles to calculate the correct forwarding proof. Consequently, the forwarding proof carried in the data packet cannot be verified, halting forwarding. This allows a macroscopic observer to observe the data packet's forwarding halt at node b', achieving a passive halt and enabling timely detection and prevention of malicious activity.

[0222] Third, after an attacker redirects data across a section of a trusted path, it cannot be forwarded back to subsequent nodes on the trusted path, thus assuming the data never left the trusted path. Specifically, even if the attacker forwards data to a node on an untrusted path, the attacker cannot forward the data to subsequent nodes on the trusted path due to the lack of the subsequent node's key and the correct forwarding proof, nor can the attacker calculate a correct forwarding proof.

[0223] In some possible implementations, a portion of the routing table entries in the encrypted routing table are encrypted, including the ciphertext identifiers of nodes downstream of node_i in the forwarding path; another portion of the routing table entries are decrypted, including the plaintext identifiers of nodes upstream of node_i in the forwarding path. For example, in the encrypted routing table carried in the data packet received by node_i, the routing table entries corresponding to each node from node_1 to node_i-1 are all decrypted. The routing table entry corresponding to node_1 includes the identifier of node_1, the routing table entry corresponding to node_2 includes the identifier of node_2, and so on. The routing table entry corresponding to node_i-1 includes the identifier of node_i-1; the routing table entry corresponding to each node from node_i to node_N is encrypted. In this way, a complete forwarding path is effectively divided into two segments. The first half of the path (corresponding to the routing table entries for each node from node_1 to node_i-1) that the message has already traversed is publicly available to node_i, allowing node_i to verify the forwarding proof based on the identifiers of each node in the first half of the path. The second half of the path (corresponding to the routing table entries for each node from node_i+1 to node_N) that the message has not yet traversed is kept confidential from node_i, maintaining path confidentiality. In particular, because the forwarding path of the data message remains relatively confidential before forwarding, the risk of the data message being pre-timed and ambushed is reduced, as is the risk of the data message being diverted in the first half of the path and then skipping nodes to return to the second half of the trusted path.

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

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

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

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

[0228] In some other possible implementations, the encrypted routing table entry corresponding to node_i includes the outgoing interface ciphertext of node_i+1. The outgoing interface ciphertext of node_i+1 is the ciphertext obtained by encrypting the identifier of node_i's designated outgoing interface using node_i's key. The designated outgoing 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 node_N-1, the previous hop of the tail node, the identifier of the outgoing interface on node_N-1 used for communication with the tail node is encrypted using the key of node_N-1. Then, the identifier of the outgoing interface on node_N-2 used for communication with node_N-1 is encrypted using the key of node_N-2. The ciphertext of node_N-2's outgoing interface is added to the ciphertext of node_N-1's outgoing interface, and so on, until the identifier of the outgoing interface on the head node used for communication with the second node is encrypted using the 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 following the next node in advance, thereby protecting the path confidentiality while completing the forwarding task.

[0229] In some possible implementations, the controller generates an encrypted routing table. For example, before forwarding a data message, the controller distributes symmetric keys to each node in the forwarding path 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, sending 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 to obtain the identifier ciphertext of node_i+1. The identifier ciphertext of node_i+1 is the encrypted routing table entry 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. During the data message forwarding phase, each forwarding node decrypts the routing table entry corresponding to the node based on the symmetric key received from the controller to obtain the identifier of the next node.

[0230] In some possible implementations, the encrypted routing table is generated without a network controller. Instead, the encrypted routing table is generated by exchanging keys between forwarding nodes. For example, key distribution is performed between node_i and the previous hop node_i-1 or the next hop node_i+1. The subsequent process is the same as the controller's process for generating the encrypted routing table.

[0231] In other possible implementations, path anonymity is achieved without using an encrypted routing table. In some embodiments, the entire path is pre-disclosed at a level such as the control plane or service plane. While security is somewhat reduced, it remains usable. In other words, the three technical benefits of binding forwarding proofs to locations, ensuring the correct source of data packets, and the efficiency of obtaining and verifying commitments are not necessarily tied to encrypted routing tables. Even when the forwarding path is public, these three technical benefits can still be achieved to a certain extent by obtaining forwarding proofs based on location, verifying the source of data packets based on vector commitments, using KZG polynomial commitments, or other methods.

[0232] The following provides examples of identity information that can be used to obtain or verify a forwarding certificate.

[0233] In some possible implementations, the identity information of the forwarding node is publicly verifiable. 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 other possible implementations, the identity information of forwarding node_i is a publicly verifiable, unforgeable identity proof that can only be calculated by forwarding node_i and can be verified by multiple parties. Exemplarily, the identity information of forwarding node_i includes identity information encrypted based on the key of forwarding node_i. Optionally, the identity information encrypted based on the key of forwarding node_i is identity information encrypted based on the symmetric key of forwarding node_i; alternatively, the identity information encrypted based on the key of forwarding node_i is identity information encrypted based on the private key of forwarding node_i. By using the 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.

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

[0235] 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) networks to define a function or instruction in the network. The SID is in the form of an IPv6 address with 128 bits. By using the SID as identity information to calculate and verify the forwarding proof, it is more suitable for SRv6 network scenarios. While achieving path binding, the SID carried in the SRv6 encapsulation can be reused, eliminating the need to add additional fields to the message to carry identity information, thereby helping to simplify the message format and reduce the overhead of transmitting the message.

[0236] Exemplarily, the identity information of forwarding node_i includes a multi-protocol label switching (MPLS) label of forwarding node_i. An MPLS label is a short, 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 forwarding proofs, it is more suitable for scenarios in MPLS networks or SR-MPLS networks. 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, thereby helping to simplify the message format and reduce the overhead of transmitting the message.

[0237] Exemplarily, the identity information of forwarding node_i includes the certificate of forwarding node_i. A certificate is a digital credential or electronic document 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 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.

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

[0239] Exemplarily, the identity information of forwarding node_i includes an access control token for forwarding node_i. An access control token is a digital certificate used to verify access rights to protected resources. The access control token contains the forwarding node's authorization information and access rights information. 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 and verify the forwarding proof, each forwarding node can verify the validity and authority of the access control token, thereby reducing the risk of identity information tampering and data leakage, thereby further enhancing the security and credibility of the forwarding proof.

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

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

[0242] 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 its private key to generate its signature. Using the signature of forwarding node_i as identity information to calculate and verify the forwarding proof reduces the risk of identity information tampering and data leakage, thereby further enhancing the security and credibility of the forwarding proof.

[0243] 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 the message, thereby reducing the probability of the message being tampered with or forged during transmission. For example, forwarding node_i uses the shared key between forwarding node_i and other forwarding nodes on the forwarding path and the message content to generate a MAC tag. The MAC tag is then used as identity information to calculate and verify the forwarding proof, thereby further reducing the probability of the forwarding proof being tampered with or forged, thereby enhancing the security and credibility of the forwarding proof.

[0244] 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.

[0245] 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 true 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, while the verifier hopes to confirm the authenticity of the statement and believes that the prover actually knows how to prove the statement. However, the special nature of the protocol is that the prover cannot disclose the true information of the statement to the verifier, thereby protecting the privacy of the prover.

[0246] The following example illustrates the triggering conditions for calculating the forwarding proof for a forwarding node.

[0247] In one possible implementation, after forwarding node_i receives 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.

[0248] 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 currently needs to calculate a forwarding proof.

[0249] By including a trusted path identifier in the data packet header, forwarding nodes can determine whether to calculate a forwarding proof based on the presence of the identifier. For example, if forwarding node_i determines that a data packet does not carry a trusted path identifier, forwarding node_i uses its existing forwarding mechanism without calculating a forwarding proof. Specifically, including a trusted path identifier in the packet header achieves benefits including, but not limited to, the following aspects.

[0250] First, it improves flexibility. Specifically, the trusted path identifier provides an optional mechanism that allows forwarding nodes to determine whether to calculate forwarding proofs based on specific needs and changes in needs, thereby improving flexibility and scalability.

[0251] Second, it simplifies configuration and reduces the possibility of configuration errors. Compared to static configuration methods that require forwarding nodes to generate forwarding proofs for certain packets, the inclusion of trusted path identifiers in data packet headers eliminates the need to pre-configure forwarding proofs on forwarding nodes, simplifying the configuration process and reducing configuration complexity. Furthermore, it reduces the probability of manually overlooking the task of generating forwarding proofs for certain packets.

[0252] 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.

[0253] In another possible implementation, after forwarding node_i obtains a data message, forwarding node_i identifies the type of service 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 and obtains 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.

[0254] First, it flexibly and precisely matches service requirements. By determining whether to calculate a Proof of Forwarding based on whether a message contains data related to a specific service, Proof of Forwarding calculations are performed only for data related to a specific service. This allows Proof of Forwarding calculations to be flexibly tailored to the needs of different services. This allows personalized Proof of Forwarding requirements to be met for different services, improving the flexibility and customizability of the network.

[0255] Second, it simplifies configuration and reduces the possibility of configuration errors. Compared to static configuration, which requires forwarding nodes to configure which packets to generate forwarding proofs for, forwarding nodes automatically determine whether to generate forwarding proofs by identifying the services carried by data packets. This eliminates the need to pre-configure which packets require forwarding proofs on forwarding nodes, simplifying the configuration process and reducing configuration complexity. Furthermore, it reduces the probability of manually omitting the task of generating forwarding proofs for certain packets.

[0256] 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 calculate the forwarding proof, thereby avoiding wasting computing resources on other data that does not require calculation proof, saving computing resources and time, and improving overall network performance and efficiency.

[0257] In another possible implementation, after forwarding node i receives a data packet, it performs a forwarding proof step in response to recognizing that the data packet contains the identifier of each node in a specific tunnel, thereby verifying that the data packet is forwarded through the specific tunnel. For example, in an SRv6 scenario, forwarding node i performs a forwarding proof step in response to recognizing that the data packet includes a segment list. For another example, in an MPLS scenario, forwarding node i performs a forwarding proof step in response to recognizing that the data packet includes a label stack.

[0258] The following examples illustrate how a forwarding node obtains its own location information or the location information of an upstream node. In one possible implementation, the forwarding node obtains its own location information or the location information of an upstream node based on a received data packet. For example, the forwarding node obtains its own location information carried in the data packet; alternatively, the forwarding node obtains its own location information by further processing data related to the location information carried in the data packet.

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

[0260] 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 is reduced by 1. When the value of TTL is reduced 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. For example, a method for determining the position of a node in a forwarding path based on TTL is that, if the initial value of TTL is k, since the value of TTL is reduced 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.

[0261] 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 the position i of the forwarding node_i in the forwarding path based on the TTL value.

[0262] In the IPv6 protocol, TTL is called the hop limit, and the hop limit 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 a data packet takes in the network. The 7th byte of the IPv6 header occupies one byte (8 bits) to store the hop limit value. 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.

[0263] In one possible implementation, a data packet includes a service index (SI). A forwarding node obtains its own location information based on the SI carried in the data packet. The SI is a field in the network service header (NSH). Because the SI value ranges from 255 to 0 and decrements by 1, after a forwarding node identifies the SI value in the NSH, it can use the value 256-SI as its own location information.

[0264] 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 order in which the SID of the node_i is arranged in the segment list.

[0265] 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].

[0266] In another possible implementation, the data packet includes an address list, which includes the address of each forwarding node. The addresses of different forwarding nodes in the address list are arranged in the order in which the forwarding nodes are arranged in the forwarding path. Forwarding node_i obtains the location information of node_i in the forwarding path based on the order in which the addresses of node_i are arranged in the address list. The address list is, for example, the encrypted routing table described above.

[0267] In another possible implementation, the controller sends the location information of each forwarding node upstream of the forwarding node 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.

[0268] In another possible implementation, different forwarding nodes communicate their location information to each other. For example, forwarding node_i communicates its location information to each forwarding node from forwarding node_i to forwarding node_N. The upstream node communicates its location information to the downstream node, allowing the downstream node to obtain or verify the forwarding proof based on the upstream node's location information.

[0269] In another possible implementation, the forwarding node's location information and the location information of the forwarding nodes upstream of the node in the forwarding path are preconfigured on the forwarding node. For example, forwarding node_i stores configuration information including the location information of each forwarding node from forwarding node_1 to forwarding node_i in the forwarding path. Forwarding node_i obtains the location information of each forwarding node from forwarding node_1 to forwarding node_i from the configuration information.

[0270] The forwarding node location information is in plain text (e.g., a positive integer) for exemplary purposes only. In another possible implementation, an obfuscation mechanism can be used for the forwarding node location information, so that the location information obtained and used by the forwarding node is in ciphertext form, thereby reducing the risk of location information leakage, which could lead to the disclosure of data sources and the identification of key forwarding nodes by attackers.

[0271] The following describes an example of how a forwarding node obtains its own identity information or the identity information of an upstream node.

[0272] In one possible implementation, a data packet carries the identity information of a forwarding node. For example, after receiving data packet i, forwarding node i obtains the identity information of forwarding node i carried in data packet i. If necessary, forwarding node i also obtains the identity information of each forwarding node from forwarding node i through forwarding node i carried in data packet i.

[0273] In another possible implementation, different forwarding nodes communicate their identity information to each other. For example, when verifying a single-point forwarding proof, forwarding node_i communicates its identity information to forwarding node_i+1. When verifying a multi-point forwarding proof, forwarding node_i communicates its identity information to each forwarding node from forwarding node_i+1 to forwarding node_N. By communicating its identity information to downstream nodes, downstream nodes can obtain or verify forwarding proofs based on the upstream node's identity information.

[0274] In another possible implementation, the controller distributes identity information to each forwarding node in the forwarding path. For example, when verifying a single-point forwarding proof, the controller notifies forwarding node_i-1 of its identity information. Forwarding node_i receives the identity information of forwarding node_i-1 from the controller and verifies the single-point forwarding proof of forwarding node_i-1 based on the identity information of forwarding node_i-1. When verifying a multi-point forwarding proof, the controller notifies forwarding node_i of the identity information of each node from the head node to forwarding node_i-1. Forwarding node_i receives the identity information of each node from the head node to forwarding node_i-1 from the controller and verifies 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.

[0275] In another possible implementation, forwarding node_i obtains the identity information of forwarding node_i-1 from the configuration information stored by 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 by forwarding node_i.

[0276] In one possible implementation, forwarding nodes use a packet-by-packet forwarding proof method, adding their own forwarding proof to each received data packet. For example, each data packet in a data stream sent from forwarding node _i to forwarding node _i-1 carries forwarding proof from forwarding node _i. Because each data packet has its own independent forwarding proof, each data packet can be independently controlled and verified, thereby increasing monitoring and verification of data packets and making data transmission more secure and reliable.

[0277] In another possible implementation, the forwarding node adds its own forwarding proof to the first data packet in a data stream by carrying the forwarding proof on a stream-by-stream basis. For example, after forwarding node _i obtains the first data stream, it generates forwarding proof p_i for forwarding node _i and adds forwarding proof p_i to the first data packet in the first data stream, without having to add forwarding proof p_i to each data packet after the first data packet in the first data stream. After forwarding node _i+1 receives the first data packet in the first data stream, in response to determining that the forwarding proof p_i carried by the first data packet has been verified, forwarding node _i+1 saves the identifier of the first data stream and the identifier (such as permit) for allowing the data stream to pass in the session table. When forwarding node _i+1 receives each data packet after the first data packet in the first data stream, it searches the session table based on the identifier of the first data stream carried in the data packet, obtains the identifier for allowing the data stream to pass, and then further forwards the data packet to the next forwarding node _i+2. Alternatively, after forwarding node _i+1 receives the first data packet in the first data flow, in response to determining that the forwarding proof p_i carried by the first data packet fails verification, forwarding node _i+1 saves the identifier of the first data flow and an identifier (such as the word "deny") for denying the data flow to the session table. When forwarding node _i+1 receives each data packet after the first data packet in the first data flow, it searches the session table based on the identifier of the first data flow carried in the data packet, and upon obtaining an identifier for denying the data flow, it discards the data packet. Carrying the forwarding proof with the first data packet of each data flow avoids the bandwidth and computing resources consumed by carrying the forwarding proof for each data packet, thereby improving network transmission efficiency.

[0278] In another possible implementation, forwarding node_i adds its own forwarding proof p_i to every certain number of data packets in the data stream. For example, if the interval is 3, then when the first, fourth, and seventh data packets in a data stream pass through forwarding node_i, forwarding node_i will add its own forwarding proof p_i to these packets. Because forwarding proofs don't need to be added to every data packet, but rather skip adding them after a certain number of packets, network traffic and transmission overhead can be reduced, thereby reducing the number of forwarding proofs.

[0279] 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, the forwarding proof p_i is added to the next obtained data packet.

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

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

[0282] The differences between different protocol scenarios mainly lie in the message headers carrying commitment and forwarding proof and their specific carrying locations.

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

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

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

[0286] In one possible implementation of output vector commitments, the controller sends a vector commitment to an observer, allowing the observer to verify the proof of forwarding based on the received vector commitment. For example, the controller sends a data packet containing a vector commitment to the observer, and the observer obtains the vector commitment carried in the received data packet. Another example is the controller sends a control plane packet containing a vector commitment to the observer, and the observer obtains the vector commitment carried in the received control plane packet.

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

[0288] Optionally, the controller stores the correspondence between the forwarding path identifier and the vector commitment in a blockchain system. Because blockchain systems store data in a decentralized manner, the probability of vector commitments being tampered with or eavesdropped on is reduced, improving the data security of vector commitments and effectively protecting their integrity. Furthermore, publicly storing vector commitments provides traceability and auditability of paths and calculation results. Alternatively, the controller stores the correspondence between the forwarding path identifier and the vector commitment in a distributed shared database other than a blockchain.

[0289] 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.

[0290] If necessary, the controller can choose to perform key pre-distribution of 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.

[0291] 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, router, or firewall. Another example is a computing device, such as a server or terminal. A forwarding node can be a physical or virtual device. A forwarding node is a minimal, atomic node. Within the network hierarchy where a forwarding node resides, there are no lower-level nodes below it, allowing data to be forwarded through it undetected.

[0292] In one possible implementation, after receiving a data packet, a forwarding node, in response to determining that the data packet needs to be forwarded via a trusted forwarding path, participates in the calculation of a forwarding proof. In one possible implementation, upon receiving a data packet, forwarding node_i, in response to recognizing that the data packet header includes a trusted path identifier, calculates a forwarding proof p_i and discloses the forwarding proof p_i to an observer.

[0293] 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.

[0294] In another possible implementation, the forwarding proof p_i is a multi-point proof, which 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 to the correct location.

[0295] The observer represents the world with public information. It can be any device that cares about the trustworthiness of the forwarding path. The observer verifies the forwarding proof computed by the forwarding node based on the commitment C generated by the controller, the identity of the forwarding node, and its location. In one possible implementation, the observer is unbiased, meaning that its observations and verifications are identical to the protocol output under a correct scenario.

[0296] In one possible implementation, the observer is separated from the forwarding nodes in the forwarding path and is installed on different hardware devices. The observer does not need to be responsible for message forwarding. The observer is deployed outside the forwarding path.

[0297] In another possible implementation, the observer and forwarding node are integrated into the same hardware device, which is responsible for forwarding messages and verifying forwarding proofs. In other words, the forwarding node also plays the role of the observer.

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

[0299] 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 notifies the controller of the selected forwarding path.

[0300] 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.

[0301] 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 identity information r_i of each forwarding node in the N forwarding nodes and the location information of each forwarding node based on the commitment function C = Commit(P).

[0302] In one possible implementation, according to the vector commitment verification algorithm, if the verification result of the commitment C, position i, identity r_i, and related auxiliary data against the forwarding proof is 1, the forwarding proof passes verification. If the verification result of the commitment C, position i, identity r_i, and related auxiliary data against the forwarding proof is 0, the forwarding proof fails verification. The auxiliary data may be, for example, the cryptographic parameters used to calculate the commitment.

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

[0304] Step 3: Forwarding proof calculation.

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

[0306] In one possible implementation, forwarding node _i obtains forwarding proof p_i based on its identity information, location information, and cryptographic parameters. Forwarding proof p_i is a single-point forwarding proof that proves that forwarding node _i forwarded the data packet at location i. Alternatively, forwarding node _i obtains forwarding proof p_i using a single-point open function (Open), where p_i = Open(i, r_i).

[0307] 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, proving that node_1 forwarded the data message at position 1, node_2 forwarded the data message at position 2, and so on, and that node_i forwarded the data message at position i. Optionally, forwarding node_i obtains forwarding proof p_i using a batch open function (BatchOpen), where p_i = BatchOpen(r_1,…,r_i).

[0308] Step 4: Forwarding proof verification.

[0309] The observer receives the commitment C, the forwarding proof p_i, and the node set B corresponding to the forwarding proof p_i. 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.

[0310] 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 forwarding node_i, the location information of forwarding node_i, and cryptographic parameters. Forwarding proof p_i is a single-point forwarding proof. Optionally, 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.

[0311] For example, in the scenario of verifying a 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 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.

[0312] Regarding the timing of verifying the forwarding proof, in one possible implementation, a real-time verification method is adopted, and each time a data message passes 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 message. For example, if any forwarding node on a trusted forwarding path receives a data message containing a forwarding proof, the forwarding node verifies the forwarding proof carried in the data message. For another example, if any forwarding node on a trusted forwarding path receives a data message, 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 message forwarding steps are completed.

[0313] The following example illustrates the location where the forwarding proof is carried in a data message when the forwarding proof is carried in the message.

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

[0315] Optionally, the forwarding proof is carried via a type-length-value (TLV) in the IPv6 extension header. For example, the forwarding proof is carried via a TLV in the SRH. Another example is the forwarding proof is carried via a TLV in the HBH. Another example is the forwarding proof is carried via a TLV in the DOH.

[0316] In the case of transmitting data based on the APN6 protocol, in a possible implementation, the forwarding proof is carried by the APN message header. For example, the forwarding proof is carried by the application-aware network identifier (APN ID) in the APN message header. In the case of transmitting data based on the VxLAN protocol, in a possible implementation, the forwarding proof is carried by 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 transmitting data based on the IPSec protocol, in a possible implementation, the forwarding proof is carried by 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 transmitting data based on the MPLS protocol, in a possible implementation, the forwarding proof is carried by the MPLS header. For example, the forwarding path includes a label switching path, and each node in Node_1, Node_2...Node_N in the forwarding path includes an LSR in the label switching path, thereby verifying 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 one possible implementation, the forwarding proof is carried by the NSH. For example, the forwarding proof is carried by the metadata field in the NSH.

[0317] The following example illustrates the location where the vector commitment is carried in a data message when the vector commitment is carried in the message.

[0318] When transmitting data over the IPv6 protocol, one possible implementation involves carrying a vector commitment via an IPv6 extension header. For example, the vector commitment can be carried via the SRH. Another example is the vector commitment can be carried via the HBH. Another example is the vector commitment can be carried via the DOH. SRH, HBH, and DOH are specific examples of three IPv6 extension headers capable of carrying vector commitments.

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

[0320] When data is transmitted based on the APN6 protocol, in one possible implementation, the vector commitment is carried in the APN header. For example, the vector commitment is carried in the APN ID in the APN header. When data is transmitted based on the VxLAN protocol, in one possible implementation, the vector commitment is carried in the VxLAN header. When data is transmitted based on the IPSec protocol, in one possible implementation, the vector commitment is carried in the IPSec header. When data is transmitted based on the MPLS protocol, in one possible implementation, the vector commitment is carried in the MPLS header. When data is transmitted based on the SFC protocol, in one possible implementation, the vector commitment is carried in the NSH. For example, the vector commitment is carried in the metadata field in the NSH.

[0321] In one 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.

[0322] Exemplarily, data packet_i+1 includes an IPv6 extension header, and the IPv6 extension header includes the 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 the 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 the 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 the 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 the forwarding proof of the forwarding node _i, and the second TLV of the HBH includes the vector commitment.

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

[0324] By placing the Proof of Forwarding and Vector Commitment in the same message header, the message format and structure are simplified. This eliminates the need for separate headers to carry the Proof of Forwarding and Vector Commitment, reducing message complexity and redundancy. Furthermore, placing the Proof of Forwarding and Vector Commitment in the same message header simplifies the message processing logic of nodes. For example, after receiving data message _i+1, node_i only needs to parse the message header once to obtain the Proof of Forwarding and Vector Commitment information. This makes node_i's processing logic clearer and more concise, reducing complexity in the process.

[0325] 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 forwarding proof, and the protocol steps and data packet headers are slightly different in different verification modes. The three verification modes of 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 the OP sub-mode and the MP sub-mode, the on-path verification mode includes the OP sub-mode and the MP sub-mode, and the end-point verification mode includes the MP sub-mode. Each mode is described 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 separated and set in 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.

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

[0327] In real-time verification mode, the verification node is deployed outside the forwarding path and is separate from the forwarding nodes in the forwarding path and is installed on different hardware devices. For example, referring to Figure 1, the verification node is the observer in Figure 1. The verification node is connected to the head node, forwarding node_2, forwarding node_3, and forwarding node_4 in Figure 1 via a communication network. In one possible implementation, the verification node is the controller in Figure 1.

[0328] In the method shown in Figure 2 , the verification node is, for example, a device other than the nodes in the forwarding path (e.g., the head node, forwarding node_2, and forwarding node_3). Optionally, the controller and verification node in the method shown in Figure 2 are integrated into the same device. In other words, the controller not only performs the steps of obtaining and sending vector commitments in S210 , but also performs the step of verifying the forwarding proof in S240 .

[0329] When processing a data packet, forwarding node_i obtains a forwarding proof p_i and sends it to the verification node. Upon receiving the forwarding proof p_i from forwarding node_i, the verification node verifies the forwarding proof p_i in real time. Forwarding nodes downstream of forwarding node_i on the forwarding path do not need to verify the forwarding proof p_i. Optionally, forwarding nodes downstream of forwarding node_i can verify the correctness of the data packet's origin using methods other than vector commitment, such as aggregatable signatures or symmetric key MAC tags.

[0330] 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 without the identity of one or more nodes located before the forwarding node _i on the forwarding path.

[0331] 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 itself based on the control plane, data message or other means, obtains the multi-point forwarding proof MP of the node itself based on the identity of the node itself 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 itself to the verification node.

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

[0333] Figure 2 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. The network deployment scenario underlying the method illustrated in Figure 2 may optionally be as illustrated in Figure 1 above. Forwarding Node_3 illustrated in Figure 2 is an optional node device, and the forwarding path may also include only the head node and forwarding node_2.

[0334] The processing flow of forwarding proof shown in FIG2 includes the following S210 to S240.

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

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

[0337] In step (b) of S210 , the controller uses the vector commitment mechanism to compute a commitment C = commit(P) for the bound forwarding path P = (r_1, r_2, …, r_N). The controller also computes 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 compute the forwarding proof to each node in the forwarding path.

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

[0339] 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.

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

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

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

[0343] In one possible implementation, the head node decrypts the first routing entry in encrypted routing table T using its key to obtain the identifier of forwarding node 2. Furthermore, the head node appends the remaining encrypted routing table T after the first routing entry in encrypted routing table T to data message 1, obtaining data message 2. Based on the identifier of forwarding node 2, the head node sends data message 2 to forwarding node 2. Data message 2 includes a protocol header that includes a trusted path identifier. Furthermore, the head node sends a single-point forwarding proof OP_1 or a multi-point forwarding proof MP_1 to the verification node.

[0344] S230, forwarding node_i sends data packet_i+1 to forwarding node_i+1, and sends forwarding proof_i to verification node.

[0345] In step (a) of step S230 , forwarding node _i receives data packet _i. Data packet _i includes a protocol header including a trusted path identifier. Optionally, data packet _i also includes identity information r_i of forwarding node _i and location information i of forwarding node _i. Optionally, data packet _i also includes identity information and location information of nodes node_1 through node_i-1.

[0346] In step (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 the node and the position i of the 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 nodes 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 replaces the encrypted routing table T in 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, obtaining data message_i+1.

[0347] In step (c) of step S230 , forwarding node _i sends data packet _i+1 to next node _i+1 based on the identifier of next node _i+1. Data packet _i+1 includes a protocol header including a trusted path identifier. Furthermore, forwarding node _i sends a single-point forwarding proof OP_i or a multi-point forwarding proof MP_i to the verification node.

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

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

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

[0351] 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.

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

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

[0354] 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 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 further transmission of data from an illegal source from the forwarding node_i to the forwarding node_i+1, thereby improving network security. In other possible implementations, in response to the forwarding proof P_i passing 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.

[0355] Regarding the protocol messages based on which the verification node interacts with forwarding node_i, in some possible implementations, the verification node notifies forwarding node_i of discarding or forwarding data messages based on a control plane protocol such as a border gateway protocol flow spec (BGP flow specification, or BGP flow spec or BGP FS), a path computation element protocol (PCEP), a BGP monitoring protocol (BMP), a network stream protocol, or a 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.

[0356] Taking the interaction between the verification node and 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 community attribute field. The NLRI field includes an identifier of a data message that failed the forwarding proof verification, and the extended community attribute field includes an identifier indicating that the message was discarded. The second notification message includes the NLRI field and an extended community attribute field. The NLRI field includes an identifier of a data message that passed the forwarding proof verification, and the extended community attribute field includes an identifier indicating that the message was forwarded.

[0357] In one 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.

[0358] In one possible implementation, if the verification passes, the verification node outputs 1, indicating that the data message is on the trusted path and has passed the correct location. If the verification fails, the verification node outputs 0, indicating that the data message is not on the trusted path or has not passed the correct location.

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

[0360] By adopting a real-time verification model, each forwarding node calculates and publishes a proof of forwarding, ensuring that each node's identity is verified. This provides hop-by-hop security and high security. Since each forwarding node calculates and publishes a proof of forwarding while processing a data packet, observers can obtain and verify these proofs in real time, enabling real-time, transparent tracking of the data transmission process. Furthermore, the attack window is small. Furthermore, by using a vector commitment mechanism and a suitable verification algorithm, commitments and proofs of forwarding can be publicly audited. Observers can verify the correctness of the commitments and whether each node's proof of forwarding matches its identity and location, thereby enhancing the security of the data transmission process.

[0361] Verification mode 2: Passport mode

[0362] 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.

[0363] For example, referring to Figure 3, forwarding nodes 2, 3, and 4 are all verification nodes. Forwarding node 2 verifies the forwarding proof p_1 of the head node in Figure 3. Forwarding node 3 verifies the forwarding proof p_2 of forwarding node 2 in Figure 3. Forwarding node 4 verifies the forwarding proof p_3 of forwarding node 3 in Figure 3. For example, referring to Figure 4, forwarding nodes 2 and 3 are both verification nodes.

[0364] Forwarding proof p_i can be, for example, a single-point proof OP or a multi-point proof MP. Furthermore, when forwarding node_i processes a data packet, it obtains a forwarding proof p_i based on its location information and identity information. Forwarding node_i then sends data packet_i+1 to forwarding node_i+1, which includes forwarding proof p_i. Because the forwarding proof is carried in the data packet, it is forwarded along with the data packet to the next node_i+1, allowing the next node to verify forwarding proof p_i.

[0365] In one possible implementation, forwarding node _i replaces the forwarding proof p_i-1 carried in data packet _i with forwarding proof p_i to obtain data packet _i+1. By replacing the forwarding proof of the previous hop with the forwarding proof of the current node, the message no longer needs to store the forwarding proof of every node it has passed through. This prevents the number of message bytes occupied by proofs from increasing with the number of nodes, thus saving message space. Furthermore, since a data message only needs to carry the proof of a single node during forwarding, rather than multiple nodes, network resources required to transmit proofs are conserved.

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

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

[0368] 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 through other means.

[0369] FIG3 is a schematic diagram of a verification scenario of a forwarding proof in an on-path verification mode provided by an embodiment of the present application. The scenario shown in FIG3 is illustrated by taking an example where the forwarding path includes four forwarding nodes. The scenario shown in FIG3 is illustrated by taking an example where the forwarding path includes four forwarding nodes. 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, or the number of forwarding nodes in the forwarding path can be dozens or hundreds, or even more.

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

[0371] S310: The controller sends a vector commitment.

[0372] 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.

[0373] 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.

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

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

[0376] 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.

[0377] In step (b) of step S320 , the head node generates a data message _1 based on the payload data, where the data message _1 includes the payload data. Furthermore, the head node calculates its own single-point forwarding proof OP_1 using the open function, or calculates its own multi-point forwarding proof MP_1 using the batch open function. The head node adds the single-point forwarding proof OP_1 or the multi-point forwarding proof MP_1 to the protocol message header including the trusted path identifier, and adds the protocol message header to the data message _1.

[0378] Furthermore, the head node decrypts the first routing table entry of the encrypted routing table T based on the head node's key 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.

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

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

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

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

[0383] 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.

[0384] 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.

[0385] In step (b) of step S340 , forwarding node _i replaces the single-point forwarding proof OP_i-1 in the message header with the single-point forwarding proof OP_i to obtain data message _i+1. Alternatively, 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 data message _i+1. Optionally, forwarding node _i further decrypts the routing table entry corresponding to forwarding node _i in the encrypted routing table T based on the key of forwarding node _i to obtain the identifier of the next node _i+1. Furthermore, forwarding node _i replaces the encrypted routing table T in 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 adds the identity information r_i of forwarding node _i to data message _i.

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

[0387] In step (c) of step S340 , forwarding node _i sends data packet _i+1 to next node r_i+1 based on the identifier of next node r_i+1. Data packet _i+1 includes a protocol header including a trusted path identifier, a single-point forwarding proof OP_i, or a multi-point forwarding proof MP_i.

[0388] By adopting an on-link verification model, each forwarding node calculates and publishes a forwarding proof, ensuring the identity of each node is verified, providing hop-by-hop security and high security. Furthermore, the forwarding proof can be incorporated into the packet header, resulting in moderate computational and communication costs, and a moderate protocol flow and complexity, making this a compromise solution.

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

[0390] Verification mode three, end point verification (final_only) mode

[0391] In the endpoint verification mode, the tail node in the forwarding path also serves as an observer. The tail node obtains a forwarding certificate based on the location information of each forwarding node (including the tail node itself) in the forwarding path and the identity information of each forwarding node, and the tail node verifies the obtained forwarding certificate. For example, please refer to Figure 5, which is a schematic diagram of a verification scenario of a forwarding certificate under an endpoint verification mode provided by an embodiment of the present application. The scenario shown in Figure 5 is illustrated by taking the forwarding path including 4 forwarding nodes as an example. Forwarding node_4 in Figure 5 is a specific example of a tail node acting 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 node_2 in Figure 5) acts as a verification node. Alternatively, the number of forwarding nodes in the forwarding path is dozens or hundreds, or more.

[0392] FIG6 is a schematic diagram of a method for obtaining and verifying a forwarding certificate in an endpoint verification mode provided by an embodiment of the present application. The method in FIG6 includes the following steps S410 to S440. The network deployment scenario based on the method shown in FIG6 can optionally be as shown in FIG5 above.

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

[0394] S410: The controller sends a vector commitment.

[0395] 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.

[0396] 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.

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

[0398] S420: The head node sends data packet 2 to forwarding node_2.

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

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

[0401] 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. Data message 2 includes a protocol message header, which includes a trusted path identifier and a single-point forwarding proof OP_1 or a multi-point forwarding proof MP_1.

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

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

[0404] S440: The egress node obtains the multi-point forwarding certificate MP_N.

[0405] In step (a) of step S440 , the tail node receives data message _N, which includes a protocol message header including 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.

[0406] 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.

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

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

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

[0410] First, it reduces 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 by the forwarding proof when transmitting in the network.

[0411] Second, it reduces computational 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.

[0412] 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 used based on an identification bit carried in the data message.

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

[0414] For example, data packet _i obtained by forwarding node _i includes an identifier of the associated verification mode. In response to identifying that data packet _i carries the identifier of the associated verification mode, forwarding node _i obtains data packet _i+1 based on data packet _i and forwarding proof p_i. Data packet _i+1 includes forwarding proof p_i.

[0415] For example, the data packet _N obtained by the forwarding node _N includes the 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.

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

[0417] In another possible implementation, 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 forwarding node_i. In response to the mode identifier from the controller indicating the real-time verification mode, 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 path verification mode, forwarding node_i obtains data message_i+1 based on data message_i and forwarding proof p_i when a data message is obtained. Data message_i+1 includes forwarding proof p_i. In response to the mode identifier from the controller indicating the end point verification mode, forwarding node_i obtains 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 a data message is obtained, and verifies forwarding proof p_N.

[0418] The following examples in two specific application scenarios illustrate the above method. Example 1 provides a service function chaining (SFC) trusted path protection mechanism 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 the 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.

[0419] Example 1

[0420] Service Function Chain (SFC) trusted path protection mechanism based on KZG polynomial proof

[0421] A service function chain (SFC) is an organized collection of service functions that guides traffic to obtain service functions in an orderly and on-demand manner. It is a key means of processing traffic on-demand and in an orderly manner within NFV virtual networks. The SFC itself is a path.

[0422] As shown in Figure 7, network devices play different roles in the entire service function chain system depending on their functions. The service function chain roles mainly include the service classifier (SC), service function (SF) node, service function forwarder (SFF) node, and SFC proxy node.

[0423] 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.

[0424] SF nodes are used to provide business processing services. SF nodes include, but are not limited to, firewalls (FWs), load balancers (LBs), intrusion prevention systems (IPSs), application accelerators, network address translation (NAT), web application firewalls (WAFs, also known as website-level intrusion prevention systems), bandwidth control, virus detection, cloud storage, deep packet inspection (DPI), intrusion detection, and HTTP header enrichment. In the business function chain, network traffic must pass through each SF node in the order specified by the business logic to implement the required services.

[0425] Based on whether the device recognizes 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 and forward NSH messages, while NSH-unaware SF nodes cannot recognize and discard NSH messages.

[0426] SFF nodes are devices that connect to SF service function points. SFF nodes are used to identify service flow information and forward traffic based on it.

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

[0428] In a service function chain (SF) scenario, ensuring traffic is forwarded along a designated network path is a key technical challenge. In this embodiment, an NSH-aware SF or SFC Proxy acts as a forwarding node, using KZG polynomial commitments as a specific implementation for constructing vector commitments. The NSH header in the SFC carries information related to the trusted path.

[0429] The following example illustrates the format of the NSH packet header that carries trusted path information.

[0430] The NSH is a message header used to identify the SFC protocol. The NSH conforms to a certain fixed format and reserves a data field for scalable optional variable-length metadata (OVLM). This embodiment implements the trusted path message header in OVLM.

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

[0432] As shown in (b) of Figure 8 , the NSH consists of 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 location within the current path. Optionally, the NSH also includes a context header. The context header includes an extensible Optional Variable-Length Metadata (OVLM) field.

[0433] As shown in (c) of Figure 8 , 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 shown in Figure 8 . In one 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 this node, and calculates the forwarding proof p_i of this node based on the position _i. Since the SI value range is from 255 to 0 and decreases by 1, x_i = 256-SI.

[0434] 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 the primary key based on which commitment C is searched.

[0435] As shown in (d) in Figure 8, 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 the variable-length metadata field.

[0436] In the business function chain scenario, the three forwarding proof verification modes described above, including real-time verification (Postcard) mode, on-path verification (Passport) mode, and end-point verification (Final_only) mode, can all be used. In this embodiment, the OP sub-mode of the on-path verification mode, which has a relatively moderate efficiency and security, is selected for analysis:

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

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

[0439] Pairing-Friendly Curves are a class of elliptic curves with specific mathematical properties that make them suitable for pairing operations. In cryptography, pairing involves mapping points on two elliptic curves to elements in a finite field. In the case of curve_ID = BLS-12381, elem_length = 48 bytes. In other words, both the commitment field and the P field are 48 bytes.

[0440] The SF_FROM field carries 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 from 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.

[0441] 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.

[0442] 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.

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

[0444] SF_TO_ENC_i = ENC_(sk_i, SF_TO || SF_TO_ENC_i+1) represents the encryption of SF_TO and SF_TO_ENC_i+1 when the current node (node ​​i) processes data. Specifically, node i uses its symmetric key sk_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, is used as the encrypted routing table for transmission to the next node (node ​​i+1).

[0445] 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.

[0446] 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 the encrypted route.

[0447] For example, referring to FIG. 9 , the protocol steps in the associated verification mode include the following S510 to S540 .

[0448] S510: The controller sends a vector commitment to the verification node.

[0449] In step (a) of step S510 , the controller obtains input data, which includes the identity information and location information of each SF node in a service function chain (SF) of length N. The input data may be, for example, a vector P = (r_1, r_2, …, r_N) consisting of N SF nodes. Here, r_i is a unique identifier of the SF node.

[0450] In step (b) of step S510 , the controller calculates a 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)>. The controller then calculates the Lagrange interpolation polynomial f(X) for 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.

[0451] The controller uses formula (2) to calculate the secret s, thereby achieving secret initialization. In formula (2), g is the group generator. s, [s 2 ],...,[s N ],where[s i ]=g i*S ;Formula (2)

[0452] 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.

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

[0454] 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.

[0455] S520: The first SF node in the forwarding path sends data message _2 and forwarding proof p_1.

[0456] 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.

[0457] In S520 (b), the first SF node generates a data message _1 according to the payload data, wherein the data message _1 includes the payload data; and the first SF node calculates its own forwarding proof OP_1 using the Open function and the following formula (4). i =p[f(x i )=y i ]=C T ;Formula (4)

[0458] 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).

[0459] The new coefficient is determined by the following formula (6). N-1 =f N ;t j =f j+1 +x j ·t j+1 ;Formula (6)

[0460] The first SF node uses the following formula (7) to calculate the forwarding proof. i =[T y (s)]1; Formula (7)

[0461] The first SF node fills the forwarding proof into the field P of the 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 the NSH, fills the remaining encrypted routing table into the SF_TO_ENC field in the NSH, and fills the commitment C into the commitment field in the NSH.

[0462] In step (c) of step S520 , the first SF node sends a data packet _2 to the second SF node. The data packet _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. Furthermore, the first SF node sends a forwarding proof p_1 to the verification node.

[0463] S530, SF node_i receives data message_i.

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

[0465] In step (b) of step S530 , SF node _i verifies the source of the data message. SF node _i verifies the correctness of OP_i-1 in the data message header based on the authentication of the previous hop node _i-1. The verification method is based on checking whether the pairing in the following formula (8) holds.

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

[0467] S540: If the verification is successful, SF node _i sends data packet _i+1 to the identifier of the next SF node _i+1 based on the identifier of the next SF node _i+1.

[0468] In one possible implementation, in response to determining that the pairing in formula (8) does not hold, SF node_i determines that the forwarding proof verification has failed, and SF node_i discards the data message. In response to determining that the pairing in formula (8) holds, SF node_i determines that the forwarding proof verification has succeeded. SF node_i uses the identity information r_i of the node and the current position i in the path of the node as input and calculates a single point forwarding proof OP_i using formula (4). 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.

[0469] 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.

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

[0471] Example 2

[0472] Trusted path protection mechanism for SRv6

[0473] SRv6 is Segment Routing (SR) based on the IPv6 forwarding plane. SRv6 adds a new routing header (SRH) to IPv6 packets. The SRH contains a segment list of IPv6 addresses that records the forwarding path and optional TLVs (Type-Length-Value).

[0474] In one possible implementation, the SID carries the location information of the forwarding node. As shown in Figure 10, the SID includes a locator field and a 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 and forwarding. Based on the locator field, forwarding node_i uses the SRv6 protocol to calculate the location x_i of forwarding node_i on the forwarding path.

[0475] 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 corresponding parameters of 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.

[0476] A segment list is formed by combining multiple SIDs. A segment list indicates an IPv6 path formed by an ordered sequence of n IPv6 network nodes. When forwarding a packet, the forwarding node determines the packet's forwarding path, P = (r_1, r_2, ..., r_N), based on the segment list fields, the source address (SA), and the destination address (DA).

[0477] After the data packet has passed through the first half of the forwarding path, that is, after passing 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 the SRH. Furthermore, during the data packet 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 the SRH. Furthermore, the identity information (r_i, r_i+1, ..., r_N) of each node in the path not traversed by the data packet is kept hidden in the encrypted routing table through the SRH.

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

[0479] For a selected forwarding path P = (r_1, r_2, …, r_N), the head node adds the head node's SID (a specific example of the head node's identity information r_1) to segment list[N]. Segment list[N] is the innermost field (the last row in the table) in the segment list. This addition to segment list[N] is due to SRv6's reverse-order routing method. Segment list[N] carries the head node's SID; the head node sets the values ​​of all other fields in the segment list other than segment list[N] to null. Furthermore, the head node adds the encrypted routing table T corresponding to P = (r_1, r_2, …, r_N) to the TLV field in the SRH for storage.

[0480] 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 (the identity information of the next node_i+1) carried in the TLV of the SRH in the data message_i; 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 segment list[Ni] in the data message_i to obtain data message_i+1, and node_i forwards the data message_i+1 to node_i+1.

[0481] 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 during forwarding 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 during forwarding in the segment list is empty, thereby reducing the risk of the identity of node_i to node_N being disclosed.

[0482] 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.

[0483] For the MP sub-mode in the in-path 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, a commitment field, a proof (P, specifically a multi-point proof) field, and an encrypted routing table T (SF_TO_ENC) field are added to the TLV in the SRH of the data message. 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.

[0484] A commitment and a forwarding proof (P) are both G1 group elements of a pairing-friendly curve, so they are represented by the length of one element (elem_length). When using curve curve_ID = BLS-12381, the length of both the commitment and forwarding proof (P) is 48 bytes.

[0485] For example, referring to FIG. 11 , the protocol steps in the associated verification mode include the following S610 to S640 .

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

[0487] 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.

[0488] 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 a correspondence between the identity information of each SR endpoint and the location information of each SR endpoint.

[0489] 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.

[0490] S620, the head node (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. The TLV in the SRH in IPv6 data packet _2 includes the forwarding proof of the head node.

[0491] 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.

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

[0493] In S620 (b), the head node generates a data message _1 according to the payload data, where the data message _1 includes the payload data;

[0494] The head node calculates its own forwarding proof using the BatchOpen function or calculates the forwarding proof of a single point using the Open function, and adds the forwarding proof to the P field in the TLV in the SRH.

[0495] In addition, the head node decrypts the routing table entry corresponding to this node in the encrypted routing table T using its own key to obtain the SID of the next node r_2. Furthermore, the head node adds the remaining encrypted routing table T after the first routing table entry in the encrypted routing table T, its own SID, and the SID of the next node r_2 to data packet _1 to obtain data packet _2.

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

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

[0498] Data packet_i contains an SRH, which includes a trusted path identifier, the identity information of each node from headnode_1 to headnode_i, and the location information of each node from headnode_1 to headnode_i. The location information is a positive integer, such as 1, 2, or 3, and is obtained based on the locator in the SID.

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

[0500] In step (a) of step S640 , SR endpoint_i verifies the forwarding proof p_i carried by the SRH in IPv6 datagram_i to verify the source of IPv6 datagram_i. SR endpoint_i obtains the multipoint forwarding proof MP_i-1 carried in the header of datagram_i. SR endpoint_i verifies the multipoint forwarding proof MP_i-1 based on the identity information of each node from SR endpoint_1 to SR endpoint_i-1.

[0501] In (b) of S640, if the multi-point forwarding proof MP_i-1 is successfully verified, SR endpoint_i uses the identity information from node_1 to node_i and the location information from node_1 to node_i to obtain a multi-point forwarding proof MP_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 SR endpoint_i's key to obtain the identity information of the next node_i+1. SR endpoint_i then 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.

[0502] In step (c) of step S640, SR endpoint _i sends data message _i+1 to next node _i+1 based on the identifier of next node _i+1. Data message _i+1 includes an SRH. The TLV of the SRH includes the forwarding proof of SR endpoint _i.

[0503] If the multipoint forwarding proof MP_i-1 fails to be verified, SR endpoint_i discards data packet_i.

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

[0505] In an SRv6 scenario, one possible implementation involves using a SID to carry a trusted path identifier. For example, the function field in the SID can carry the trusted path identifier. Another example is using the arguments field in the SID to carry the trusted path identifier.

[0506] 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. 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 certificate. In a possible implementation, SR endpoint_i saves the correspondence between the trusted path identifier and the calculation instruction of the forwarding certificate, searches for the correspondence based on the identified trusted path identifier, obtains the calculation instruction of the forwarding certificate, executes the calculation instruction of the forwarding certificate, and thereby obtains a single-point forwarding certificate or a multi-point forwarding certificate.

[0507] In the SRv6 scenario, the endpoint verification mode can also be used to obtain and verify the forwarding proof. Referring to Figure 12, the steps of obtaining and verifying the forwarding proof in the endpoint verification mode include S710 to S750.

[0508] 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 Example 1.

[0509] 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 egress node.

[0510] S720: The head node sends IPv6 datagram _2 to the second SR endpoint.

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

[0512] S740: The tail node obtains the forwarding certificate.

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

[0514] In one 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 uses it as the location information of node_i.

[0515] In step (b) of step S740 , the tail node obtains a multi-point forwarding certificate based on the location information and identity information of each node in the forwarding path. The calculation method of the multi-point forwarding certificate is described above.

[0516] S750, the tail node verifies the forwarding certificate.

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

[0518] When using 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 node identity information and location information. For example, the commitment and public parameters are passed to the tail node at the application layer or control plane, and then the tail node verifies the forwarding path based on the existing information at one time.

[0519] 13 is a schematic diagram of a forwarding certificate acquisition device 810 according to an embodiment of the present application. The device 810 includes an acquisition unit 811 and a processing unit 812.

[0520] The device 810 is optionally provided at the head node in FIG1 . The acquisition unit 811 is used to execute (a) in S220 of the method shown in FIG2 ; the processing unit 812 is used to execute (b) in S220 of the method shown in FIG2 . The device 810 is optionally provided at the forwarding node_2, forwarding node_3, or forwarding node_4 in FIG1 . The acquisition unit 811 is used to execute (a) in S230 of the method shown in FIG2 ; the processing unit 812 is used to execute (b) in S230 of the method shown in FIG2 . In some possible implementations, the device 810 further includes: a sending unit 813, used to execute (c) in S220 or (c) in S230 of the method shown in FIG2 .

[0521] The device 810 is optionally provided at the head node in FIG3 . The acquisition unit 811 is used to execute (a) in S320 of the method shown in FIG4 ; the processing unit 812 is used to execute (a) in S320 of the method shown in FIG4 . The device 810 is optionally provided at the forwarding node_2, forwarding node_3, or forwarding node_4 in FIG2 . The acquisition unit 811 is used to execute (a) in S330 of the method shown in FIG4 ; the processing unit 812 is used to execute (b) in S340 of the method shown in FIG4 . In some possible implementations, the device 810 further includes: a sending unit 813, used for (c) in S340 of the method shown in FIG4 .

[0522] The apparatus 810 may be optionally provided in the forwarding node_4 in Figure 5. The acquiring unit 811 is configured to execute S440 in the method shown in Figure 6; the processing unit 812 is configured to execute S450.

[0523] Device 810 may optionally be provided in SF Node 1, SF Node 2, or a proxy (forwarding node 3) in FIG7 . Acquisition unit 811 is configured to execute step (a) of S520 in the method shown in FIG9 ; processing unit 812 is configured to execute step (b) of S520 in the method shown in FIG9 ; and sending unit 813 is configured to execute step (c) of S520 in the method shown in FIG9 .

[0524] The apparatus 810 is optionally provided in the head node in Figure 11. The acquisition unit 811 is used to execute (a) of S620 in the method shown in Figure 11; the processing unit 812 is used to execute (b) of S620 in the method shown in Figure 11.

[0525] The apparatus 810 is optionally provided at the second SR endpoint or the third SR endpoint in FIG11 , wherein the acquiring unit 811 is configured to execute step (a) of S640 in the method shown in FIG11 ; the processing unit 812 is configured to execute step (b) of S640 in the method shown in FIG11 ; and the sending unit 813 is configured to execute step S640 in the method shown in FIG11 .

[0526] The device embodiment described in FIG13 is merely illustrative. For example, the division of the above units is merely a logical functional division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Each functional unit in each embodiment of the present application can be integrated into a processing unit 812, or each unit can exist physically separately, or two or more units can be integrated into a single unit.

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

[0528] 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 and will not be described in detail here.

[0529] 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.

[0530] In the case of software implementation, for example, the processing unit 812 and the acquisition unit 811 are implemented by software functional units generated after at least one processor 901 in FIG. 16 reads the program code stored in the memory 902 .

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

[0532] 14 is a schematic diagram of the structure 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.

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

[0534] The device 820 is optionally provided in forwarding node_2, forwarding node_3 or forwarding node_4 in Figure 3. The acquisition unit 821 is used to execute (a) of S330 in the method shown in Figure 4; the verification unit 822 is used to execute (b) of S330 in the method shown in Figure 4.

[0535] The apparatus 820 may be optionally provided at the forwarding node_4 in Figure 5. The acquiring unit 821 is configured to execute S440 in the method shown in Figure 6; the verifying unit 822 is configured to execute S450.

[0536] The device 820 is optionally provided in the SF node_2 or the proxy (forwarding node_3) in Figure 7. The acquisition unit 821 is used to execute (a) of S530 in the method shown in Figure 9; the verification unit 822 is used to execute (b) of S530 in the method shown in Figure 9.

[0537] The device 820 is optionally provided at the second SR endpoint or the third SR endpoint in FIG. 11 , and the acquisition unit 821 is used to execute S630 in the method shown in FIG. 11 ; the verification unit 822 is used to execute (a) in S640 in the method shown in FIG. 11 .

[0538] The device embodiment described in FIG14 is merely illustrative. For example, the division of the above units is merely a logical functional division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. The functional units in the various embodiments of the present application can be integrated into a processing unit, or each unit can exist physically separately, or two or more units can be integrated into a single unit.

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

[0540] 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 and will not be described in detail here.

[0541] 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.

[0542] In the case of software implementation, for example, the verification unit 822 is implemented by a software functional unit generated by at least one processor 901 in FIG. 16 after reading the program code stored in the memory 902 .

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

[0544] 15 is a schematic diagram of the structure 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.

[0545] The device 830 is optionally provided in the controller in FIG1 . The acquisition unit 831 is used to execute (a) of the method S210 shown in FIG2 ; the processing unit 832 is used to execute (b) of the method S210 shown in FIG2 . Optionally, the device 830 further includes a sending unit 833, which is used to execute (c) of S210.

[0546] The device 830 is optionally provided in the controller in Figure 3. The acquisition unit 831 is used to execute step (a) of S310 in the method shown in Figure 4; the processing unit 832 is used to execute step (b) of S310 in the method shown in Figure 4. The sending unit 833 is used to execute step (c) of S310.

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

[0548] Optionally, the acquiring unit 831 is configured to execute (a) in S510 of the method shown in Figure 9 , the processing unit 832 is configured to execute (b) in S510 of the method shown in Figure 9 , and the sending unit 833 is configured to execute (c) in S510 .

[0549] The device 830 is optionally provided in the controller in Figure 11. The acquisition unit 831 is configured to execute step (a) of S610 in the method shown in Figure 11; the processing unit 832 is configured to execute step (b) of S610 in the method shown in Figure 11. The sending unit 833 is configured to execute step (c) of S610.

[0550] The device embodiment described in FIG15 is merely illustrative. For example, the division of the above units is merely a logical functional division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. The functional units in the various embodiments of the present application can be integrated into a processing unit, or each unit can exist physically separately, or two or more units can be integrated into a single unit.

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

[0552] 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 and will not be described in detail here.

[0553] 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.

[0554] In the case of software implementation, for example, the acquisition unit 831 and the processing unit 832 are implemented by software functional units generated after at least one processor 901 in FIG. 16 reads the program code stored in the memory 902 .

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

[0556] FIG16 is a schematic structural diagram of a computing device 900 provided in an embodiment of the present application.

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

[0558] 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.

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

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

[0561] In some embodiments, processor 901 includes one or more CPUs, such as CPU0 and CPU1 shown in FIG. 16 .

[0562] In some embodiments, computing device 900 may optionally include multiple processors, such as processor 901 and processor 905 shown in FIG16 . Each of these processors may be, for example, a single-CPU or a multi-CPU. A processor herein may optionally refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0563] In some embodiments, computing device 900 further includes internal connections 904. Processor 901, memory 902, and at least one network interface 903 are connected via internal connections 904. Internal connections 904 include pathways that transmit information between these components. Internal connections 904 may optionally be a single board or bus. Internal connections 904 may optionally be divided into an address bus, a data bus, a control bus, and the like.

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

[0565] 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 internally stored program code. 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 program code 910 that implements the method provided in the embodiment of the present application.

[0566] 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.

[0567] The various embodiments in this specification are described in a progressive manner. 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.

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

[0569] The terms "first" and "second" in the description and claims of the embodiments of this application are used to distinguish different objects, not to describe a specific order of objects, and should not be understood to indicate or imply relative importance. For example, the first forwarding proof and the second forwarding proof are used to distinguish different forwarding proofs, not to describe a specific order of forwarding proofs, and should not be understood to mean that the first forwarding proof is more important than the second forwarding proof.

[0570] 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 the relevant countries and regions. For example, the identity information involved in this application is obtained with full authorization.

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

[0572] 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 can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrations. The available medium can 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 drive (SSD)).

[0573] 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, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate 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 10, 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 router ID, 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 the identity information of a first forwarding node, the location information of the first forwarding node, the identity information of a second forwarding node, and the 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 the 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. a position on a forwarding path, the forwarding path including 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