Method and apparatus for acquiring forwarding proof, and method and apparatus for verifying forwarding proof

Abstract

The present application belongs to the field of network security. Provided are a method and apparatus for acquiring a forwarding proof, and a method and apparatus for verifying a forwarding proof. In the present application, a forwarding proof is obtained in view of an expected sequential position of a forwarding node on a forwarding path and the identity of the forwarding node, thereby realizing the position binding of the forwarding proof and the fault tolerance for non-critical nodes. The forwarding proof is not only related to the identity of the forwarding node, but is also related to the expected sequential position of the forwarding node. Only when a data packet is forwarded to a correct sequential position on the forwarding path can a node having correct identity calculate a correct forwarding proof, such that the forwarding proof and the actual forwarding condition of the data packet are strongly bound. If an expected node is skipped or redundant unexpected nodes are passed by during a forwarding process, the identities of the nodes no longer match the sequential positions of the nodes; therefore, forwarding proofs obtained on the basis of the identities of the nodes and the sequential positions of the nodes cannot pass verification, thus improving the credibility of the forwarding proofs.

Description

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

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on January 16, 2024, with application number 202410067738.3 and invention name “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 security, and in particular 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. Summary of the Invention

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

[0006] In a first aspect, a method for obtaining a forwarding proof is provided, wherein a first forwarding node obtains a first data packet, and at least two key nodes corresponding to the first data packet include a first forwarding node, and the key node is a forwarding node passed through in an expected forwarding path determined by a path planner for the first data packet; the first forwarding node obtains a sequential position of the first forwarding node in the expected forwarding path and identity information of the first forwarding node, the sequential position of the first forwarding node in the expected forwarding path is different from the sequential position of the first forwarding node in an actual forwarding path of the first data packet, and the identity information of the first forwarding node indicates the identity of the first forwarding node; the first forwarding node obtains a forwarding proof of the first forwarding node based on the sequential position of the first forwarding node in the expected forwarding path and the identity information of the first forwarding node, and the forwarding proof of the first forwarding node is used to prove that the first forwarding node forwards the first data packet at the sequential position in the expected forwarding path.

[0007] Based on the method provided in the first aspect, since the forwarding proof is obtained by combining the sequential position of the forwarding node in the expected forwarding path and the identity information of the forwarding node, the forwarding proof is not only related to the identity information of the forwarding node, but also related to the sequential position of the forwarding node in the expected forwarding path. Based on this, the forwarding proof can verify whether the identity of the forwarding node is correct (for example, whether the forwarding node is the forwarding node that the path planner expects the business data to pass through when it is transmitted) and whether the sequential position of the forwarding node is correct (for example, whether the sequential relationship between the forwarding nodes conforms to the sequential relationship of the forwarding nodes that the path planner expects the business data to pass through when it is transmitted). For example, if a key node in the expected forwarding path is skipped during the forwarding process, or an extra unspecified node that does not exist in the expected forwarding path is passed, the forwarding proof obtained based on the identity information of the key node and the sequential position of the key node will no longer match, thereby improving the credibility of the forwarding proof.

[0008] In particular, when the sequential position of a forwarding node in the expected forwarding path differs from the sequential position of the forwarding node in the actual forwarding path, the forwarding proof is obtained using the sequential position of the forwarding node in the expected forwarding path rather than the sequential position of the forwarding node in the actual forwarding path. This ensures that the sequential position based on which the forwarding proof is obtained is consistent with the sequential position based on which the vector commitment is obtained, thereby achieving fault tolerance in path verification. For example, data packets are allowed to pass through some non-critical nodes (such as old equipment, weak equipment, or equipment produced by third-party network manufacturers) during actual transmission, reducing the risk of critical nodes downstream of non-critical nodes interrupting business data transmission or outputting alarms due to failure to verify the forwarding proof.

[0009] Based on the method provided in the first aspect, in some embodiments, at least two key nodes also include a second forwarding node, the second forwarding node is a key node located upstream of the first forwarding node in the expected forwarding path, and the first forwarding node obtains the forwarding proof of the first forwarding node based on the sequential position of the first forwarding node in the expected forwarding path and the identity information of the first forwarding node, including: the first forwarding node obtains the forwarding proof of the first forwarding node based on the sequential position of the first forwarding node in the expected forwarding path, the identity information of the first forwarding node, the sequential position of the second forwarding node in the expected forwarding path, and the identity information of the second forwarding node, the identity information of the second forwarding node indicates the identity of the second forwarding node, and the forwarding proof of the first forwarding node is used to prove that the first forwarding node and the second forwarding node are respectively in corresponding sequential positions in the expected forwarding path.

[0010] Because the forwarding proof is obtained based on the expected sequential positions and identities of multiple key nodes, the obtained forwarding proof can simultaneously verify whether multiple key nodes are in the corresponding sequential positions in the expected forwarding path. This utilizes batch processing to improve the overall verification performance of the forwarding path, saving the time required to calculate and verify the proof. In addition, this method ensures that the time required to obtain the forwarding proof does not increase linearly with the number of key nodes, making it more suitable for large-scale networks and improving scalability.

[0011] Based on the method provided in the first aspect, in some implementations, the first forwarding node is the last key node in the expected forwarding path, and the second forwarding node includes all key nodes in the expected forwarding path except the first forwarding node.

[0012] By combining the sequential position and identity of each node from the first key node to the local end in the forwarding path to obtain a forwarding proof, the sequential position and identity information of each key node that the message has passed on the actual forwarding path can be verified at one time, reducing time and computing costs, improving verification efficiency, and making verification more complete.

[0013] Based on the method provided in the first aspect, in some embodiments, the method also includes: the first forwarding node obtains the sequential position of the first forwarding node in the actual forwarding path based on the first data packet; the first forwarding node sends the forwarding certificate of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path to the verification node.

[0014] Because key nodes send their own sequential positions in the actual forwarding path to verification nodes, verification nodes can perceive the sequential positions of key nodes in the actual forwarding path, thereby ensuring the recordability of non-key nodes. For example, a verification node can determine the presence of non-key nodes between two adjacent key nodes based on the discontinuity of their sequential positions in the actual forwarding path. The verification node can also determine the number of non-key nodes between two adjacent key nodes based on the difference in their sequential positions in the actual forwarding path.

[0015] In addition, since the sequence position of the actual forwarding path is recorded by the key nodes, there is no need to require non-key nodes to perform additional actions beyond forwarding. The existence of non-key nodes can also be recorded indirectly, which improves compatibility.

[0016] Based on the method provided in the first aspect, in some embodiments, the verification node includes a third forwarding node, which is a key node located downstream of the first forwarding node in the expected forwarding path, and the first forwarding node sends a forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path to the verification node, including: the first forwarding node obtains a second data packet based on the first data packet, the forwarding proof of the first forwarding node, and the sequential position of the first forwarding node in the actual forwarding path, the second data packet includes the payload of the first data packet, the forwarding proof of the first forwarding node, and the sequential position of the first forwarding node in the actual forwarding path; the first forwarding node sends the second data packet to the third forwarding node.

[0017] Since the actual sequence position and forwarding proof are carried in the same data packet and sent to the key node downstream of the forwarding path, the actual sequence position of the key node is transmitted together with the business data, realizing the in-band transmission of the actual sequence position. In the mode where the key node also serves as the verification node (observer), there is no need to construct independent data packets to transmit the actual sequence position and forwarding proof respectively. Therefore, the overall transmission overhead of the actual sequence position and forwarding proof is relatively small. The verification node can obtain the actual sequence position of the key node and the forwarding proof of the key node at the same time by parsing a data packet. Therefore, the verification node is more efficient in obtaining the actual sequence position of the key node and the forwarding proof of the key node.

[0018] Based on the method provided in the first aspect, in some embodiments, the first data packet includes a first position list, the first position list includes the sequential positions of the key nodes located upstream of the first forwarding node in the expected forwarding path in the actual forwarding path, and the second data packet includes a second position list, the second position list includes the first position list and the sequential position of the first forwarding node in the actual forwarding path.

[0019] Since the data message carries a list of the sequential positions of the upstream key nodes in the actual forwarding path, each key node is further added with the sequential position of the local end in the actual forwarding path on the basis of the list carried in the data message, so that the data message can carry the sequential position of each key node in the actual forwarding path that the data message has passed, and the actual sequential position carried in the data message is more complete, reducing the risk of missing the actual sequential position of the key node that has been passed but not recorded.

[0020] Based on the method provided in the first aspect, in some embodiments, the second data packet includes an Internet Protocol version 6 (IPv6) extension header, and the IPv6 extension header includes a forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path. In an IPv6 scenario, using the IPv6 extension header to carry the forwarding proof and the actual sequential position supports proof of whether the data flow passes through the expected IPv6 nodes in the expected sequence.

[0021] Based on the method provided in the first aspect, in some embodiments, the second data packet includes a network service packet header NSH, the NSH includes a metadata field, the metadata field includes a forwarding certificate of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path.

[0022] In the service function chaining (SFC) scenario, by using the NSH unique to the SFC scenario to carry forwarding proof and actual sequence position, it supports proving whether the data flow passes through the expected service functions (SFs) in the expected order, and records whether the data flow passes through unexpected SFs, which helps each SF process traffic in an orderly manner as needed.

[0023] Based on the method provided in the first aspect, in some implementations, the second data packet includes a Multi-Protocol Label Switching (MPLS) header, and the MPLS header includes a forwarding certificate of the first forwarding node and a sequential position of the first forwarding node in the actual forwarding path.

[0024] In MPLS scenarios, by using the MPLS header to carry forwarding proof and actual sequence position, it supports proving whether the data flow passes through the expected MPLS nodes in the expected sequence (such as the sequence indicated by the MPLS label stack). This is suitable for scenarios such as MPLS protocol-based communication, and 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.

[0025] Based on the method provided in the first aspect, in some embodiments, the second data packet includes a virtualized extended local area network VxLAN header, the VxLAN header includes a forwarding certificate of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path; or, in a VxLAN scenario, it is suitable for scenarios such as virtualized networks based on the VxLAN protocol or cross-data center interconnection, and provides a function for verifying the source of data in the VxLAN tunnel, which facilitates verification of whether the data packets are forwarded in sequence in the order specified by the VxLAN tunnel.

[0026] Based on the method provided in the first aspect, in some embodiments, the second data packet includes an Internet Protocol security (IPsec) header, which includes a forwarding certificate of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path. This method is applicable to network scenarios based on the IPsec protocol and provides a function for verifying the source of data within the IPsec tunnel, facilitating verification of whether the forwarding path traversed by the data packet during actual forwarding matches the pre-planned IPsec tunnel.

[0027] Based on the method provided in the first aspect, in some embodiments, the IPv6 extension header includes a segment routing header (SRH), which includes a type-length-value TLV. The TLV in the SRH includes a forwarding proof of the first forwarding node and the ordinal position of the first forwarding node in the actual forwarding path. The above method is applicable to SRv6 scenarios and facilitates verification of whether the forwarding path traversed by a data packet during actual forwarding matches a pre-planned segment list.

[0028] Based on the method provided in the first aspect, in some embodiments, 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 forwarding certificate for the first forwarding node and the ordinal position of the first forwarding node in the actual forwarding path. This method is applicable to APN6 scenarios and facilitates verification of whether the forwarding path traversed by a data packet during actual forwarding matches the forwarding path pre-planned in the APN network.

[0029] Based on the method provided in the first aspect, in some embodiments, the IPv6 extension header includes a destination option header DOH, the DOH includes a TLV, and the TLV of the DOH includes a forwarding certificate of the first forwarding node and a sequential position of the first forwarding node in the actual forwarding path.

[0030] Based on the method provided in the first aspect, in some implementations, the IPv6 extension header includes a hop-by-hop option header HBH, the HBH includes a TLV, and the TLV of the HBH includes a forwarding certificate of the first forwarding node and a sequential position of the first forwarding node in the actual forwarding path.

[0031] Based on the method provided in the first aspect, in some embodiments, the first forwarding node sends a forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path to the verification node, including: the first forwarding node generates a notification message, the notification message includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path; the first forwarding node sends a notification message to the verification node.

[0032] By constructing independent messages to announce the actual sequential position of key nodes and their forwarding proofs, verification nodes can infer the existence and number of non-critical nodes in the actual forwarding path based on the received sequential position of the key nodes in the actual forwarding path, thereby achieving recordability of non-critical nodes. Furthermore, since any key node can send the forwarding proof and actual sequential position to the verification node upon receiving a data message, the verification node can verify the forwarding proof and record the actual sequential position in real time, without having to wait until the data message is transmitted to the last key node to verify the forwarding proof and record the actual sequential position. This enables real-time, transparent tracking of the data transmission process, minimizing the attack window.

[0033] Based on the method provided in the first aspect, in some implementations, the notification message includes a network configuration protocol NETCONF message, and the NETCONF message includes a forwarding certificate of the first forwarding node and a sequential position of the first forwarding node in an actual forwarding path.

[0034] The above method supports the scenario where the management plane protocol transmits forwarding proof and actual sequence position.

[0035] The notification message includes a Hypertext Transfer Protocol (HTTP) message, and the payload field in the HTTP message includes the forwarding certificate of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path.

[0036] The above method supports scenarios where data plane protocol transmission forwarding proof and actual sequence position are required.

[0037] Based on the method provided in the first aspect, in some embodiments, the first data packet includes a segment list, the segment list includes a segment identifier SID of the first forwarding node, and the first forwarding node obtains the sequential position of the first forwarding node in the expected forwarding path, including: the first forwarding node obtains the sequential position of the first forwarding node in the expected forwarding path based on the sequential position of the SID of the first forwarding node in the segment list.

[0038] The above method provides a fast, high-performance method for obtaining the expected sequence position based on the data plane. Because forwarding nodes can obtain the expected sequence position based on the segment list carried in the received data packet, there is no need to configure and save a large number of table entries to determine the expected sequence position. This reduces the storage resource overhead incurred by forwarding nodes to pre-store the expected sequence position and the performance overhead caused by table lookups to determine the expected sequence position.

[0039] Based on the method provided in the first aspect, in some embodiments, the first data packet includes a path identifier, and the first forwarding node obtains the sequential position of the first forwarding node in the expected forwarding path, including: the first forwarding node obtains the sequential position of the first forwarding node in the expected forwarding path based on the path identifier and a corresponding relationship saved by the first forwarding node, and the corresponding relationship includes the path identifier and the sequential position of the first forwarding node in the expected forwarding path.

[0040] The above approach provides a method for obtaining the expected sequential position by combining the path identifiers carried in the data plane with the corresponding relationship provided by the control plane. Because the data message does not need to carry the expected sequential position of each key node, it further reduces the overhead of data message transmission while supporting path verification.

[0041] Based on the method provided in the first aspect, in some embodiments, before the first forwarding node obtains the first data packet, the method further includes: the first forwarding node receives the sequential position of the first forwarding node in the expected forwarding path from the path planner.

[0042] Since the path planner pre-distributes the expected sequence position in the forwarding path before forwarding the data message, there is no need to carry the expected sequence position of each key node in the data message. The forwarding node can also know the expected sequence position, thereby further reducing the overhead of data message transmission on the basis of supporting path verification.

[0043] Based on the method provided in the first aspect, in some embodiments, a first forwarding node obtains a first data packet, including: the first forwarding node receives the first data packet from a second forwarding node, where the second forwarding node is a key node located upstream of the first forwarding node in a forwarding path, and the first data packet includes a forwarding proof of the second forwarding node; the method also includes: the first forwarding node verifies the forwarding proof of the second forwarding node based on a first vector commitment, identity information of the second forwarding node, and a sequential position of the second forwarding node in an expected forwarding path, the first vector commitment indicating a correspondence between the sequential positions of at least two key nodes in the expected forwarding path and the identities of the at least two key nodes, where the at least two key nodes include the second forwarding node.

[0044] By verifying the forwarding proof of the previous forwarding node, it is possible to confirm whether the sequence position of the previous forwarding node is the expected sequence position and whether the previous forwarding node is the expected forwarding node, supporting the verification of the correctness of the previous hop source. In network attack scenarios such as route hijacking, route injection, and traffic detour, if the attacker redirects the traffic to the path specified by the attacker, the forwarding proof cannot be verified, thereby enabling timely detection of network attacks in data packets and reducing the risk of incorrect data sources. In addition, since the verification of each node is based on the verification of the previous hop, it is equivalent to forming a continuous verification chain, thereby reducing the probability of any hop node in the forwarding path disguising, deceiving, or tampering with the data packet, thereby improving network security.

[0045] Based on the method provided in the first aspect, in some implementations, the path planner is a source host that generates payload data of the first data packet; or, the path planner is the first forwarding device in the expected forwarding path.

[0046] The above method supports scenarios where the source terminal calculates the path or the network head node calculates the path, and has richer application scenarios.

[0047] In a second aspect, a method for verifying a forwarding certificate is provided, the method comprising:

[0048] The verification node obtains a forwarding proof of a first forwarding node, a first vector commitment, identity information of the first forwarding node, and a sequential position of the first forwarding node in an expected forwarding path. The first vector commitment indicates a correspondence between the sequential positions of at least two key nodes in the expected forwarding path and the identities of the at least two key nodes. The at least two key nodes include the first forwarding node. The identity information of the first forwarding node indicates the identity of the first forwarding node. The forwarding proof of the first forwarding node is used to prove that the first forwarding node is in the sequential position of the first forwarding node in the expected forwarding path. The verification node verifies the forwarding proof of the first forwarding node based on the first vector commitment, the identity information of the first forwarding node, and the sequential position of the first forwarding node.

[0049] Since the forwarding proof is verified by combining the vector commitment, the expected sequential position of the key nodes and the identity information of the key nodes, if the key nodes in the expected forwarding path are skipped during the forwarding process, or if extra unspecified nodes that do not exist in the expected forwarding path are passed through, the identity information of the key nodes and the sequential position of the key nodes will no longer match, resulting in the forwarding proof obtained based on the identity information of the key nodes and the sequential position of the key nodes failing to pass the verification, thereby improving the credibility of the forwarding proof.

[0050] Furthermore, in many source address or centralized routing technologies, network attacks such as route hijacking, route injection, and traffic detour, or network device misconfiguration may cause the actual forwarding path of the data plane to deviate from the expected forwarding path of the control plane. The above method can verify whether the business data is actually forwarded along the expected forwarding path during transmission, which helps to solve the problem of inconsistency between the expected forwarding path determined by the control plane and the actual forwarding path of the data plane.

[0051] In particular, when the sequential position of a forwarding node in the expected forwarding path differs from the sequential position of the forwarding node in the actual forwarding path, the forwarding proof is obtained using the sequential position of the forwarding node in the expected forwarding path rather than the sequential position of the forwarding node in the actual forwarding path. This ensures that the sequential position based on which the forwarding proof is obtained is consistent with the sequential position based on which the vector commitment is obtained, thereby achieving fault tolerance in path verification. For example, data packets are allowed to pass through some non-critical nodes (such as old equipment, weak equipment, or equipment produced by third-party network manufacturers) during actual transmission, reducing the risk of critical nodes downstream of non-critical nodes interrupting business data transmission or outputting alarms due to failure to verify the forwarding proof.

[0052] Based on the method provided in the second aspect, in some embodiments, the at least two key nodes further include a second forwarding node, where the second forwarding node is a key node located upstream of the first forwarding node in the expected forwarding path. The verification node verifies the forwarding proof of the first forwarding node based on the first vector commitment, the identity information of the first forwarding node, and the sequential position of the first forwarding node in the expected forwarding path, including:

[0053] The verification node verifies the forwarding proof of the first forwarding node based on the first vector commitment, the sequential position of the first forwarding node in the expected forwarding path, the identity information of the first forwarding node, the sequential position of the second forwarding node in the expected forwarding path, and the identity information of the second forwarding node. The identity information of the second forwarding node indicates the identity of the second forwarding node. The forwarding proof of the first forwarding node is used to prove that the first forwarding node and the second forwarding node are both in corresponding sequential positions in the expected forwarding path.

[0054] Because the forwarding proof is verified based on the expected sequential positions and identities of multiple key nodes, it is possible to verify that multiple key nodes are in their corresponding sequential positions in the expected forwarding path at once. This utilizes 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 key nodes, making it more suitable for large-scale networking and improving scalability.

[0055] Based on the method provided in the second aspect, in some embodiments, the verification node obtains the forwarding proof of the first forwarding node, including: the verification node receives the forwarding proof of the first forwarding node from the first forwarding node.

[0056] In a third aspect, a method for verifying a forwarding proof is provided, the method also including: a first forwarding node obtains a first data packet, and the first forwarding node is deployed at the boundary of a first autonomous domain AS; the first forwarding node obtains a forwarding proof of a verified AS based on the sequential position of the verified AS and the identity information of the verified AS, and the identity information of the verified AS indicates the identity of the verified AS; the first forwarding node verifies the forwarding proof of the verified AS based on a second vector commitment, the sequential position of the verified AS, and the identity information of the verified AS, and the second vector commitment indicates the correspondence between the identity information of each AS in at least two ASs and the sequential position of each AS.

[0057] Because the forwarding proof of the verified AS is obtained based on the identity information of the verified AS and the sequential position of the verified AS, and the forwarding proof of the verified AS is compared with the vector commitment, it is determined whether the verified AS is the expected AS or / and whether the sequential position of the verified AS is the expected sequential position, thereby realizing AS-level path verification. In the cross-AS transmission scenario, it is possible to verify whether the AS that the data packet is to pass through or the AS that has passed through belongs to the AS passed in the planned expected path, reducing the risk caused by the data packet passing through an unexpected AS. For example, it reduces the risk of network transmission quality degradation caused by the data packet passing through an AS whose network transmission quality does not meet the requirements (for example, the delay or packet loss rate does not meet the standards), or reduces the security risk caused by the data packet passing through an AS whose network security does not meet the requirements (for example, an AS that has been identified as having security risks).

[0058] Based on the method provided in the third aspect, in some embodiments, the verified AS includes at least one of a neighbor AS of the first AS, the first AS, or each AS from the source AS to the first AS, the neighbor AS includes the previous AS of the first AS in the actual forwarding path of the first data packet and / or the next AS of the first AS in the reachable path of the destination IP address of the first data packet, the source AS is the AS communicating with the source host, and the source host is the device that generates the payload data of the first data packet.

[0059] By obtaining and verifying the forwarding proof of the next AS, the sequence position and identity of the next AS to which the data message may be forwarded can be verified in advance before the data message is actually forwarded, thereby reducing the security risk of business data transmission caused by the data message entering an unexpected AS.

[0060] By obtaining and verifying the forwarding proof of the previous AS, it is possible to verify whether the data message comes from an AS with an unexpected sequence position or / and identity, thereby enhancing the security of data messages in cross-AS transmission scenarios.

[0061] Based on the method provided in the third aspect, in some embodiments, the sequential position of the verified AS includes the expected sequential position of the verified AS or the actual sequential position of the verified AS. The expected sequential position of the verified AS is used to indicate the sequential relationship between the verified AS and the AS through which the expected forwarding path of the first data packet passes. The actual sequential position of the verified AS is used to indicate the sequential relationship between the verified AS and the AS through which the actual forwarding path of the first data packet passes.

[0062] By using the expected sequential position of the verified AS for path verification, an unexpected AS can be inserted between two expected ASs in the actual forwarding path, thereby achieving AS-level fault tolerance on the basis of AS-level path verification.

[0063] By using the actual sequential position of the verified AS for path verification, it is possible to verify whether the identity and sequential position of each AS passed by the actual forwarding path are completely consistent with the identity and sequential position of each AS passed by the expected forwarding path, thereby achieving more stringent AS-level path verification.

[0064] Based on the method provided in the third aspect, in some embodiments, the verified AS includes a neighbor AS of the first AS, the first data packet carries the actual sequential position of the first AS, and the actual sequential position of the verified AS is obtained based on the actual sequential position of the first AS and the sequential relationship between the first AS and the verified AS.

[0065] The above method provides a fast, high-performance method for obtaining the actual sequence position of an AS based on the data plane. Because forwarding nodes can obtain the actual sequence position of the verified AS based on the segment list carried in the received data packet, there is no need to configure and save a large number of table entries to determine the expected sequence position. This reduces the storage resource overhead incurred by forwarding nodes to pre-store the expected sequence position, and also reduces the performance overhead caused by table lookups to determine the expected sequence position.

[0066] Based on the method provided in the third aspect, in some implementations, the verified AS includes a first AS, and the first data packet carries the actual sequential position of the first AS.

[0067] Since the data packet carries the actual sequence position of the current AS, it is equivalent to the data packet carrying the AS-level TTL. For example, every time the data packet passes through an AS, the actual sequence position of the AS in the data packet is updated once. The forwarding node can know which AS the data packet currently passes through based on the content of the header of the received data packet. This not only supports strict path verification based on the actual sequence position of the AS, but also does not require the data packet to carry the complete sequence position of all ASs it has passed through, reducing the overhead of the data packet and lowering the implementation complexity.

[0068] Based on the method provided in the third aspect, in some embodiments, the first data packet carries an AS list, the AS list includes the identity information of each AS through which the expected forwarding path of the first data packet passes, and the expected sequential position of the verified AS is obtained based on the sequential position of the identity information of the verified AS in the AS list.

[0069] Since the data message indicates each AS through which the expected forwarding path passes through through the AS list, it not only supports path verification based on the expected sequence position of the AS, but also achieves fault tolerance of AS-level path verification. There is no need to configure and save a large number of table entries to determine the expected sequence position, thereby reducing the storage resource overhead caused by the forwarding node to pre-save the expected sequence position, and also reduces the performance overhead caused by the forwarding node looking up the table to determine the expected sequence position.

[0070] Based on the method provided in the third aspect, in some implementations, the first data packet carries the second vector commitment.

[0071] Vector commitment is equivalent to the reference value used to compare with the forwarding proof when verifying the forwarding proof. Since vector commitment is carried in data packets, it reduces the storage resource overhead incurred by forwarding nodes to pre-store vector commitments, and also reduces the performance overhead incurred by forwarding nodes to determine vector commitment table matches.

[0072] Based on the method provided in the third aspect, in some implementations, based on the method provided in the third aspect, in some implementations, the first data packet includes an Internet Protocol version 6 IPv6 extension header, and the IPv6 extension header carries the sequence position of the verified AS, the identity information of the verified AS, and the second vector commitment; or,

[0073] The first data packet includes a network service header NSH, the NSH includes a metadata field, and the metadata field carries the sequence position of the verified AS, the identity information of the verified AS, and the second vector commitment; or,

[0074] The first data packet includes a Multi-Protocol Label Switching (MPLS) header, wherein the MPLS header carries the sequence position of the verified AS, the identity information of the verified AS, and the second vector commitment; or,

[0075] The first data packet includes a virtualized extended local area network (VxLAN) header, wherein the VxLAN header carries the sequence position of the verified AS, the identity information of the verified AS, and the second vector commitment; or,

[0076] The first data message includes an Internet Protocol security IPsec header, and the IPsec header carries the sequence position of the authenticated AS, identity information of the authenticated AS, and a second vector commitment.

[0077] Based on the method provided in the third aspect, in some embodiments, the destination IP address of the first data packet includes the first IP address, and before the first forwarding node obtains the first data packet, the method further includes: the first forwarding node receiving a routing protocol message from the verified AS, the routing protocol message carrying the first IP address and the identity information of the verified AS; the first forwarding node storing a first correspondence, the first correspondence including the first IP address and the identity information of the verified AS;

[0078] After the first forwarding node obtains the first data message, the method further includes: the first forwarding node obtains identity information of the verified AS based on the first IP address and the first corresponding relationship.

[0079] The above method supports the authenticated AS to notify the identity information of the AS in advance through the control plane.

[0080] Based on the method provided in the third aspect, in some embodiments, the first data packet carries a path identifier, and the path identifier is used to identify the expected forwarding path. Before the first forwarding node obtains the first data packet, the method further includes: the first forwarding node receives a notification message from the path planner, and the notification message carries the path identifier, the sequential position of the verified AS, and the identity information of the verified AS; the first forwarding node saves the second corresponding relationship, and the second corresponding relationship includes the path identifier, the sequential position of the verified AS, and the identity information of the verified AS;

[0081] After the first forwarding node obtains the first data packet, the method further includes: the first forwarding node obtaining the sequence position of the verified AS and the identity information of the verified AS based on the path identifier and the second correspondence. The above method supports the method in which the path planner pre-notifies the sequence position of the verified AS and the identity information of the verified AS.

[0082] In a fourth aspect, a device for obtaining a forwarding certificate is provided. The device is provided at a first forwarding node and includes:

[0083] An acquisition unit is used to acquire a first data packet, wherein the at least two key nodes corresponding to the first data packet include a first forwarding node, and the key node is a forwarding node passed through in the expected forwarding path determined by the path planner for the first data packet; the sequential position of the first forwarding node in the expected forwarding path and the identity information of the first forwarding node are obtained, the sequential position of the first forwarding node in the expected forwarding path is different from the sequential position of the first forwarding node in the actual forwarding path of the first data packet, and the identity information of the first forwarding node indicates the identity of the first forwarding node; a processing unit is used to obtain a forwarding certificate of the first forwarding node based on the sequential position of the first forwarding node in the expected forwarding path and the identity information of the first forwarding node, the forwarding certificate of the first forwarding node is used to prove that the first forwarding node forwards the first data packet at the sequential position in the expected forwarding path.

[0084] Based on the device provided in the fourth aspect, in some embodiments, at least two key nodes also include a second forwarding node, which is a key node located upstream of the first forwarding node in the expected forwarding path. The processing unit is used to obtain a forwarding certificate of the first forwarding node based on the sequential position of the first forwarding node in the expected forwarding path, the identity information of the first forwarding node, the sequential position of the second forwarding node in the expected forwarding path, and the identity information of the second forwarding node. The identity information of the second forwarding node indicates the identity of the second forwarding node. The forwarding certificate of the first forwarding node is used to prove that the first forwarding node and the second forwarding node are respectively in corresponding sequential positions in the expected forwarding path.

[0085] Based on the apparatus provided in the fourth aspect, in some implementations, the first forwarding node is the last key node in the expected forwarding path, and the second forwarding node includes all key nodes in the expected forwarding path except the first forwarding node.

[0086] Based on the apparatus provided in the fourth aspect, in some embodiments, the processing unit is further configured to obtain a sequential position of the first forwarding node in the actual forwarding path based on the first data packet;

[0087] The device also includes: a sending unit, configured to send the forwarding certificate of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path to the verification node.

[0088] Based on the device provided in the fourth aspect, in some embodiments, the verification node includes a third forwarding node, which is a key node located downstream of the first forwarding node in the expected forwarding path; the processing unit is further used to obtain a second data packet based on the first data packet, the forwarding proof of the first forwarding node, and the sequential position of the first forwarding node in the actual forwarding path, the second data packet including the payload of the first data packet, the forwarding proof of the first forwarding node, and the sequential position of the first forwarding node in the actual forwarding path; and the sending unit is used to send the second data packet to the third forwarding node.

[0089] Based on the device provided in the fourth aspect, in some embodiments, the first data packet includes a first position list, the first position list includes the sequential positions of the key nodes located upstream of the first forwarding node in the expected forwarding path in the actual forwarding path, and the second data packet includes a second position list, the second position list includes the first position list and the sequential position of the first forwarding node in the actual forwarding path.

[0090] Based on the device provided in the fourth aspect, in some embodiments, the second data packet includes an Internet Protocol version 6 IPv6 extension header, the IPv6 extension header includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path; or, the second data packet includes a network service header NSH, the NSH includes a metadata field, the metadata field includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path; or, the second data packet includes a multi-protocol label switching MPLS header, the MPLS header includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path; or, the second data packet includes a virtualized extended local area network VxLAN header, the VxLAN header includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path; or, the second data packet includes an Internet Protocol security IPsec header, the IPsec header includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path.

[0091] Based on the device provided in the fourth aspect, in some embodiments, the IPv6 extension header includes a segment routing header SRH, the SRH includes a type-length-value TLV, and the TLV of the SRH includes a forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path.

[0092] 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 forwarding certificate of the first forwarding node and a sequential position of the first forwarding node in an actual forwarding path.

[0093] The IPv6 extension header includes a destination options header DOH, the DOH includes a TLV, and the TLV of the DOH includes a forwarding certificate of the first forwarding node and a sequential position of the first forwarding node in an actual forwarding path.

[0094] The IPv6 extension header includes a hop-by-hop option header HBH, the HBH includes a TLV, and the TLV of the HBH includes a forwarding certificate of the first forwarding node and a sequential position of the first forwarding node in an actual forwarding path.

[0095] Based on the apparatus provided in the fourth aspect, in some embodiments, the processing unit is further configured to generate a notification message, the notification message including a forwarding certificate of the first forwarding node and a sequential position of the first forwarding node in the actual forwarding path;

[0096] The sending unit is used to send a notification message to the verification node.

[0097] Based on the apparatus provided in the fourth aspect, in some implementations, the notification message includes a network configuration protocol NETCONF message, the NETCONF message includes a forwarding certificate of the first forwarding node and a sequential position of the first forwarding node in the actual forwarding path; or,

[0098] The notification message includes a Hypertext Transfer Protocol (HTTP) message, and the payload field in the HTTP message includes the forwarding certificate of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path.

[0099] Based on the device provided in the fourth aspect, in some embodiments, the first data packet includes a segment list, the segment list includes a segment identifier SID of the first forwarding node, and the processing unit is used to obtain the sequential position of the first forwarding node in the expected forwarding path based on the sequential position of the SID of the first forwarding node in the segment list.

[0100] Based on the device provided in the fourth aspect, in some embodiments, the first data packet includes a path identifier, and the processing unit is used to obtain the sequential position of the first forwarding node in the expected forwarding path based on the path identifier and the corresponding relationship saved by the first forwarding node, and the corresponding relationship includes the path identifier and the sequential position of the first forwarding node in the expected forwarding path.

[0101] Based on the apparatus provided in the fourth aspect, in some implementations, the acquiring unit is further configured to receive a sequential position of the first forwarding node in the expected forwarding path from a path planner.

[0102] Based on the apparatus provided in the fourth aspect, in some embodiments, the acquiring unit is configured to receive a first data packet from a second forwarding node, where the second forwarding node is a key node upstream of the first forwarding node in the forwarding path, and the first data packet includes a forwarding certificate of the second forwarding node;

[0103] The processing unit is further configured to verify the forwarding proof of the second forwarding node based on the first vector commitment, identity information of the second forwarding node, and a sequential position of the second forwarding node in the expected forwarding path, wherein the first vector commitment indicates a correspondence between sequential positions of at least two key nodes in the expected forwarding path and the identities of the at least two key nodes, the at least two key nodes including the second forwarding node.

[0104] Based on the apparatus provided in the fourth aspect, in some implementations, the path planner is a source host that generates payload data of the first data packet; or, the path planner is the first forwarding device in the expected forwarding path.

[0105] In a fifth aspect, a forwarding proof verification device is provided, the device including: an acquisition unit, configured to acquire a forwarding proof of a first forwarding node, a first vector commitment, identity information of the first forwarding node, and a sequential position of the first forwarding node in an expected forwarding path, the first vector commitment indicating a correspondence between the sequential positions of at least two key nodes in the expected forwarding path and the identities of the at least two key nodes, the at least two key nodes including the first forwarding node, the identity information of the first forwarding node indicating the identity of the first forwarding node, and the forwarding proof of the first forwarding node being used to prove that the first forwarding node is in the sequential position of the first forwarding node in the expected forwarding path; and a verification unit, configured to verify the forwarding proof of the first forwarding node based on the first vector commitment, the identity information of the first forwarding node, and the sequential position of the first forwarding node.

[0106] Based on the device provided in the fifth aspect, in some embodiments, at least two key nodes further include a second forwarding node, which is a key node located upstream of the first forwarding node in the expected forwarding path. The verification unit is used to verify the forwarding proof of the first forwarding node based on the first vector commitment, the sequential position of the first forwarding node in the expected forwarding path, the identity information of the first forwarding node, the sequential position of the second forwarding node in the expected forwarding path, and the identity information of the second forwarding node. The identity information of the second forwarding node indicates the identity of the second forwarding node. The forwarding proof of the first forwarding node is used to prove that the first forwarding node and the second forwarding node are both in corresponding sequential positions in the expected forwarding path.

[0107] Based on the apparatus provided in the fifth aspect, in some embodiments, the acquiring unit is configured to receive a forwarding certificate from the first forwarding node of the first forwarding node.

[0108] In a sixth aspect, a forwarding proof verification device is provided, the device being provided at a first forwarding node, and further comprising:

[0109] An acquiring unit, configured to acquire a first data packet, wherein the first forwarding node is deployed at a boundary of a first autonomous domain AS;

[0110] a processing unit, configured to obtain a forwarding certificate of the verified AS based on a sequence position of the verified AS and identity information of the verified AS, wherein the identity information of the verified AS indicates an identity of the verified AS;

[0111] The processing unit is further configured to verify the forwarding proof of the verified AS based on the second vector commitment, the ordinal position of the verified AS, and the identity information of the verified AS, wherein the second vector commitment indicates a correspondence between the identity information of each AS in at least two ASs and the ordinal position of each AS.

[0112] Based on the device provided in the sixth aspect, in some embodiments, the verified AS includes at least one of a neighbor AS of the first AS, the first AS, or each AS from the source AS to the first AS, the neighbor AS includes the previous AS of the first AS in the actual forwarding path of the first data packet and / or the next AS of the first AS in the reachable path of the destination IP address of the first data packet, the source AS is the AS communicating with the source host, and the source host is the device that generates the payload data of the first data packet.

[0113] Based on the device provided in the sixth aspect, in some embodiments, the sequential position of the verified AS includes the expected sequential position of the verified AS or the actual sequential position of the verified AS. The expected sequential position of the verified AS is used to indicate the sequential relationship between the verified AS and the AS through which the expected forwarding path of the first data packet passes. The actual sequential position of the verified AS is used to indicate the sequential relationship between the verified AS and the AS through which the actual forwarding path of the first data packet passes.

[0114] Based on the device provided in the sixth aspect, in some embodiments, the verified AS includes a neighbor AS of the first AS, the first data packet carries the actual sequential position of the first AS, and the actual sequential position of the verified AS is obtained based on the actual sequential position of the first AS and the sequential relationship between the first AS and the verified AS.

[0115] Based on the device provided in the sixth aspect, in some implementations, the verified AS includes a first AS, and the first data packet carries the actual sequential position of the first AS.

[0116] Based on the device provided in the sixth aspect, in some embodiments, the first data packet carries an AS list, the AS list includes the identity information of each AS through which the expected forwarding path of the first data packet passes, and the expected sequential position of the verified AS is obtained based on the sequential position of the identity information of the verified AS in the AS list.

[0117] Based on the apparatus provided in the sixth aspect, in some implementation manners, the first data packet carries the second vector commitment.

[0118] Based on the apparatus provided in the sixth aspect, in some embodiments, the first data packet includes an Internet Protocol version 6 (IPv6) extension header, and the IPv6 extension header carries the sequence position of the verified AS, the identity information of the verified AS, and the second vector commitment; or,

[0119] The first data packet includes a network service header NSH, the NSH includes a metadata field, and the metadata field carries the sequence position of the verified AS, the identity information of the verified AS, and the second vector commitment; or,

[0120] The first data packet includes a Multi-Protocol Label Switching (MPLS) header, wherein the MPLS header carries the sequence position of the verified AS, the identity information of the verified AS, and the second vector commitment; or,

[0121] The first data packet includes a virtualized extended local area network (VxLAN) header, wherein the VxLAN header carries the sequence position of the verified AS, the identity information of the verified AS, and the second vector commitment; or,

[0122] The first data message includes an Internet Protocol security IPsec header, and the IPsec header carries the sequence position of the authenticated AS, identity information of the authenticated AS, and a second vector commitment.

[0123] Based on the device provided in the sixth aspect, in some embodiments, the destination IP address of the first data packet includes the first IP address, and the obtaining unit is further configured to receive a routing protocol message from the verified AS, the routing protocol message carrying the first IP address and identity information of the verified AS;

[0124] The processing unit is further configured to store a first correspondence, where the first correspondence includes the first IP address and identity information of the verified AS;

[0125] The obtaining unit is further configured to obtain identity information of the verified AS based on the first IP address and the first corresponding relationship.

[0126] Based on the apparatus provided in the sixth aspect, in some embodiments, the first data packet carries a path identifier, which is used to identify the expected forwarding path. The acquiring unit is further configured to receive a notification message from the path planner, where the notification message carries the path identifier, the sequential position of the verified AS, and the identity information of the verified AS.

[0127] The processing unit is further configured to store a second corresponding relationship, the second corresponding relationship including a path identifier, a sequential position of the verified AS, and identity information of the verified AS;

[0128] The acquiring unit is further configured to acquire the sequence position of the authenticated AS and the identity information of the authenticated AS based on the path identifier and the second corresponding relationship.

[0129] In the seventh aspect, a forwarding device is provided, which includes a processor coupled to a memory, wherein the memory stores at least one computer program instruction, and the at least one computer program instruction is loaded and executed by the processor to enable the forwarding device to execute the method provided in the first aspect or any optional method of the first aspect, the method provided in the second aspect or any optional method of the second aspect, or the method provided in the third aspect or any optional method of the third aspect, wherein the network interface is used to receive or send messages. The specific details of the forwarding device provided in the seventh aspect can be found in the method provided in the first aspect or any optional method of the first aspect, the method provided in the second aspect or any optional method of the second aspect, or the method provided in the third aspect or any optional method of the third aspect, wherein the network interface is used to receive or send messages, which will not be repeated here.

[0130] In an eighth aspect, a computing device is provided, comprising a processor coupled to a memory, wherein the memory stores at least one computer program instruction, and the at least one computer program instruction is loaded and executed by the processor to enable the computing device to implement the method provided in the first aspect or any optional embodiment of the first aspect, the method provided in the second aspect or any optional embodiment of the second aspect, or the method provided in the third aspect or any optional embodiment of the third aspect. Specific details of the computing device provided in the eighth aspect can be found in the method provided in the first aspect or any optional embodiment of the first aspect, the method provided in the second aspect or any optional embodiment of the second aspect, or the method provided in the third aspect or any optional embodiment of the third aspect, and will not be repeated here.

[0131] In the ninth 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 embodiment of the first aspect, the method provided by the second aspect or any optional embodiment of the second aspect, or the method provided by the third aspect or any optional embodiment of the third aspect.

[0132] In the tenth 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 embodiment of the first aspect, the method provided by the second aspect or any optional embodiment of the second aspect, or the method provided by the third aspect or any optional embodiment of the third aspect.

[0133] In the eleventh aspect, a chip is provided, comprising a memory and a processor, the memory being used to store computer instructions, and the processor being used to call and run the computer instructions from the memory to execute the method provided by the first aspect or any optional embodiment of the first aspect, the method provided by the second aspect or any optional embodiment of the second aspect, or the method provided by the third aspect or any optional embodiment of the third aspect.

[0134] In a twelfth aspect, a network system is provided, which includes the apparatus of the fourth aspect and the apparatus of the fifth aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0135] FIG1 is a schematic diagram of an application scenario provided by an embodiment of the present application;

[0136] FIG2 is a schematic diagram of a path verification method provided in an embodiment of the present application;

[0137] FIG3 shows an architecture diagram of a trusted path network system provided by an embodiment of the present application;

[0138] FIG4 shows an architecture diagram of another trusted path network system provided by an embodiment of the present application;

[0139] FIG5 shows an architecture diagram of another trusted path network system provided by an embodiment of the present application;

[0140] FIG6 is a schematic diagram of an application scenario provided by an embodiment of the present application;

[0141] FIG7 is a schematic diagram of a message format provided in an embodiment of the present application;

[0142] FIG8 is a schematic diagram of a message format provided in an embodiment of the present application;

[0143] FIG9 is a schematic diagram of a scenario of transmitting data streams between ASs provided in an embodiment of the present application;

[0144] FIG10 is a flow chart of a path verification method provided in an embodiment of the present application;

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

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

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

[0148] FIG14 is a schematic structural diagram of a device provided in an embodiment of the present application. DETAILED DESCRIPTION

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

[0150] The following is an explanation of some terminology concepts involved in the embodiments of this application.

[0151] (1) Path Verification Mechanism

[0152] The path verification mechanism refers to a technology that supports verification of whether the business data is forwarded according to the expected forwarding path during actual transmission. In some embodiments of the present application, a forwarding certificate of the verification object is obtained based on the identity information of the verification object and the sequential position of the verification object, and the forwarding certificate of the verification object is verified based on the vector commitment, the identity information of the verification object and the sequential position of the verification object, using the vector commitment as reference data, thereby realizing the path verification mechanism. For example, if the forwarding certificate of the verification object passes, the forwarding node determines that the verification object is the object that the business data is expected to pass through and the sequential position of the verification object meets the requirements of the expected forwarding path, then the forwarding node further forwards the message; if the forwarding certificate of the verification object fails, it is determined that the verification object is not the object that the business data is expected to pass through or the sequential position of the verification object meets the requirements of the expected forwarding path, then the forwarding node performs a predetermined processing action other than forwarding the message.

[0153] In an embodiment of the present application, the verification object includes a verification object at the device (node) level and a verification object at the autonomous system (AS) level. The verification object at the device level includes at least one of the current node, the neighboring node of the current node, and / or each node passed by the upper half of the path. The verification object at the AS level includes at least one of the current AS, the neighboring AS of the current AS, each AS passed by the upper half of the path, and / or the next AS of the current AS. Accordingly, the path verification mechanism includes a path verification method at the device level and a path verification method at the AS level. The path verification method at the device level, for example, includes abstracting each forwarding node passed during the service data transmission process as a verification object, and verifying the forwarding node based on the identity information of the forwarding node and the sequential relationship between the forwarding nodes. The path verification method at the AS level, for example, includes abstracting each AS passed during the service data transmission process as a verification object, and verifying the AS based on the identity information of the AS and the sequential relationship between the ASs.

[0154] In some embodiments, one of the two methods, a device-level path verification method and an AS-level path verification method, is selected for execution. In other embodiments, both the device-level path verification method and the AS-level path verification method are executed. For example, the path verification method that the forwarding node needs to execute is determined based on the network deployment location of the forwarding node. For example, the forwarding node inside the AS executes the device-level path verification method, for example, the forwarding node inside the AS performs path verification for the previous hop node or the next hop node of the node. The forwarding node at the AS boundary executes the AS-level path verification method. For example, the forwarding node at the AS boundary performs path verification for the previous AS or the next AS of the AS.

[0155] The term "current" mainly refers to the time when the data message (business data) is obtained. For example, when the data message arrives at the i-th node during the forwarding process, the i-th node is the current node, and the AS where the i-th node is located is the current AS. The neighbor node of the current node refers to the node that has a neighbor relationship with the current node (the node to which the data message is currently transmitted). For example, the neighbor nodes of the current node include the previous node of the current node (also called the previous hop node) or the next node of the current node. The main difference in the method flow executed for different verification objects lies in the difference in identity information and sequential position of the input data of the algorithm.

[0156] (2) Expected forwarding path

[0157] The expected forwarding path refers to the forwarding path determined by the path planner before forwarding the data packet. For example, the expected forwarding path is the forwarding path determined by the controller based on the network topology by performing path calculation. The expected forwarding path includes at least two forwarding nodes. For example, the expected forwarding node includes a key node 1 and a tail node. In some embodiments, the expected forwarding path also includes one or more intermediate nodes between the key node 1 and the tail node. The expected forwarding path is, for example, an end-to-end path. In a segment routing (segment routing over IPv6, SRv6) scenario based on Internet Protocol version 6 (internet protocol version 6, IPv6), the expected forwarding path is, for example, represented by a segment list (segment list), a candidate path (candidate path, CP) or an SR policy (policy). In the scenario of multi-protocol label switching (MPLS) or segment routing over multi-protocol label switching (SR-MPLS), the expected forwarding path is, for example, represented by an MPLS label stack. In the scenario of SFC, the expected forwarding path is, for example, represented by a service function chain.

[0158] (3) Actual forwarding path

[0159] The actual forwarding path refers to the path that the data message actually passes through when forwarding. For example, the actual forwarding path includes each device from the ingress device of the network that the data message enters to the egress device of the network. In some scenarios provided in this application, there is at least one non-critical node between two key nodes in the actual forwarding path. For example, please refer to (b) in Figure 1, there are key nodes A, key nodes B and key nodes C in the actual forwarding path, and there are non-critical nodes a and non-critical nodes b between key nodes A and key nodes B in the actual forwarding path, and there is non-critical node c between key nodes B and key nodes C in the actual forwarding path.

[0160] (4) Roles involved in the path verification mechanism

[0161] Path verification is typically implemented through the collaborative efforts of three entities: the path planner, the forwarding node, and the verification node. The path planner determines the vector commitment, the forwarding node determines the forwarding proof during the forwarding process, and the verification node compares the vector commitment with the forwarding proof for verification.

[0162] In some implementations, the path planner, forwarding nodes, and verification nodes are physically separate entities. For example, the path planner is a controller, the forwarding nodes are forwarding devices such as routers or switches, and the verification nodes are auditors, the destination host for service data, or user devices. In one possible implementation, the verification nodes are deployed outside the forwarding path. The verification nodes are separate from the forwarding nodes in the forwarding path and are deployed on separate hardware devices. The verification nodes do not need to be responsible for message forwarding.

[0163] In other embodiments, the three entities of the path planner, the forwarding node, and the verification node are integrated together. For example, the verification node and the forwarding node are integrated into the same hardware device, which is responsible for forwarding the message and verifying the forwarding proof. In other words, the verification node is the forwarding node itself, which also serves as the verification node to verify the correctness of the source of the previous hop. For example, in the actual data forwarding process, when each forwarding node receives a data message, it verifies the forwarding proof of the previous forwarding node carried by the data message, thereby realizing on-path verification. For another example, after the data transmission is completed, the tail node verifies once that the data message has indeed passed through the expected forwarding path in sequence, without the need for each forwarding node to perform path verification.

[0164] (5) Forwarding Node

[0165] A forwarding node, also known as a forwarding device, refers to a device or a collection of devices used to forward data. 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 device or a virtual device.

[0166] (6) Path planning method

[0167] A path planner refers to an entity used to plan a forwarding path. In some embodiments, the path planner is a controller. In other embodiments, the path planner is a source host, where the source host refers to a device that generates data packets, such as a terminal or a server. In other embodiments, the path planner is the first forwarding device where a data packet enters a network, such as the first forwarding node in the intended forwarding path, such as a switch or a router. As an example, the path planner is the first forwarding device in the network that the data packet enters. For example, the path planner is the ingress device of the network that the data packet enters.

[0168] (7) Key nodes

[0169] A key node is a specific type of forwarding node. The term "key" is primarily defined based on the expected forwarding path. In this embodiment, a forwarding node in the expected forwarding path is referred to as a key node, and the AS where the forwarding node resides is referred to as a key AS.

[0170] A key node is also called a forwarding key node or an expected node. A key node is a forwarding node that the business data specified by the path planner needs to pass through during the forwarding process. The expected forwarding path determined by the path planner includes at least two key nodes. Key nodes generally support the ability to calculate the forwarding proof and / or the ability to verify the forwarding proof. For example, the key node stores configuration information related to the calculation of the forwarding proof and / or the verification of the forwarding proof, and activates the function of enabling the calculation of the forwarding proof and / or the verification of the forwarding proof. During the business data transmission process, when a data packet carrying business data reaches a key node, the key node is able to calculate the forwarding proof.

[0171] A type of forwarding node opposite to a critical node is a non-critical node. A non-critical node is a forwarding node that the network path planner has not specified for the business data to pass through. A non-critical node is not located in the expected forwarding path. Data packets may pass through one or more non-critical nodes during actual forwarding. For example, a non-critical node is an additional forwarding node that the actual forwarding path passes through compared to the expected forwarding path. Non-critical nodes generally do not support the calculation of forwarding proofs and / or the verification of forwarding proofs. Alternatively, non-critical nodes support but do not activate the calculation of forwarding proofs and / or the verification of forwarding proofs. Alternatively, non-critical nodes support but do not activate the calculation of forwarding proofs and / or the verification of forwarding proofs. Non-critical nodes are, for example, old devices, devices with weak capabilities, or devices produced by third-party network manufacturers. For another example, a non-critical node is a Layer 2 switch.

[0172] When the controller arranges the expected forwarding path, it does not know in advance which non-critical nodes exist, nor will it arrange the non-critical nodes into the expected forwarding path. In the actual forwarding process, the critical nodes may decide on their own to pass through these non-critical nodes, resulting in the actual forwarding path having more non-critical nodes than the expected forwarding path. For example, please refer to Figure 1, the sequence positions of critical node A and critical node B in the expected forwarding path are adjacent. However, when critical node A actually forwards the data message, critical node A does not forward the data message directly to critical node B, but forwards the data message to critical node B through a tunnel, which passes through non-critical node a and non-critical node b. Non-critical node a and non-critical node b are used to forward data messages from critical node A to critical node B. Due to the use of tunnel forwarding, the actual forwarding path has more non-critical nodes a and non-critical nodes b than the expected forwarding path.

[0173] (8) Forwarding path locking

[0174] Forwarding path lockability is a technical effect that is expected to be achieved by the embodiments of this application. Forwarding path lockability means that during the actual transmission process, business data is indeed forwarded hop by hop according to the trusted path (expected forwarding path) pre-planned by the path planner, thereby improving the transmission security of business data. In some embodiments of this application, forwarding path lockability specifically includes the effects of correct key node identity and correct key node sequence relationship.

[0175] The correctness of the key node identity refers to the match between the identity of the key node that the business data passes through during the actual transmission process and the identity of the key node expected by the path planner. For example, the path planner expects the business data to pass through N key nodes, and the business data does pass through the N key nodes during the actual transmission process. In some embodiments of the present application, since the path planner determines the vector commitment based on the identity information of the N key nodes in the expected forwarding path, the forwarding node determines the forwarding proof based on the identity information of the key node, and the verification node verifies the forwarding proof based on the vector commitment and the identity information of the key node, the vector commitment and the forwarding proof are both bound to the identity information of the key node. Based on this, only the forwarding proof determined using the correct identity information of the key node can pass the verification. It is difficult for a third party to forge the correct forwarding proof due to the difficulty in obtaining the correct identity information of the key node, thereby achieving the correctness of the key node identity.

[0176] The correctness of the key node sequence relationship, also known as data in-order forwarding, position locking, or sequence position binding, means that the order of key nodes in the actual forwarding path is consistent with the order of key nodes in the expected forwarding path determined by the path planner. Key nodes in the expected forwarding path cannot be skipped, nor can additional key nodes not included in the expected forwarding path be passed through. For example, if the path planner expects business data to first pass through key node A, then key node B, and finally key node C, the business data will actually pass through key node A, then key node B, and finally key node C during transmission. It cannot pass through key node C first, then key node B, and finally key node A. It cannot skip key node B and go directly to key node C, or pass through key node D before passing through key node C. In some embodiments of the present application, the path planner determines a vector commitment based on the sequential positions of N key nodes in the expected forwarding path, the forwarding node determines a forwarding proof based on the sequential positions of the key nodes, and the verification node verifies the forwarding proof based on the vector commitment and the sequential positions of the key nodes. Therefore, both the vector commitment and the forwarding proof are bound to the sequential positions of the key nodes. Based on this, only forwarding proofs determined using the correct sequential positions of the key nodes can pass verification. Since it is difficult for a third party to obtain the correct sequential positions of the key nodes, it is difficult to forge a correct forwarding proof, thereby ensuring the correct identity of the key nodes.

[0177] In some embodiments of the present application, a vector commitment is obtained by combining the sequence position of key nodes and the identity information of key nodes. This makes the vector commitment not only related to the identity information of the key nodes, but also to the sequence position of the key nodes. Therefore, when verifying the forwarding proof based on the vector commitment, only the forwarding proof generated by satisfying the conditions of correct sequence relationship and correct identity information can pass verification. Based on this, if the path planner specifies that the business data passes through the first key node and the i-th key node passed by the business data is the first key node, the correct forwarding proof p_i can be calculated based on the correct identity information of the first key node and the correct sequence position (i) of the first key node, making it difficult for others to forge the forwarding proof. Conversely, if the business data skips the expected key node during the actual forwarding process, or passes through an extra, unexpected key node, then when the business data is transmitted to the downstream key node of the skipped key node or the extra key node, the sequence position of the downstream key node will be inconsistent with the expected sequence position. Therefore, the forwarding proof obtained at the downstream key node cannot pass verification, thereby achieving the correctness of the key node identity and the correctness of the key node sequence relationship at the same time.

[0178] For example, if the expected forwarding path is key node A → key node B → key node C → key node D, then the expected sequence position of key node A is 1, the expected sequence position of key node B is 2, the expected sequence position of key node C is 3, and the expected sequence position of key node D is 4. If the business data is actually forwarded hop by hop along the expected forwarding path, the forwarding proof 1 obtained based on the identity of key node A and the expected sequence position of key node A (1), the identity of key node B and the expected sequence position of key node B (2), the identity of key node C and the expected sequence position of key node C (3), or the identity of key node D and the expected sequence position of key node D (4) can pass verification. If the key node C that is expected to be passed is skipped during the forwarding process, the actual forwarding path 2 is key node A → key node B → key node D. Taking key node D as an example, key node D obtains forwarding proof 2 based on the actual sequence position (3) and identity (D). Since the actual sequence position (3) and identity (D) based on forwarding proof 2 do not match, forwarding proof 2 cannot pass verification. For another example, when passing through an extra unspecified node, an extra key node E is added to forwarding path 1. The actual forwarding path 2 is key node A → key node B → key node C → key node E → key node D. If the actual sequence position (5) and identity (D) of key node D on forwarding path 2 are used to calculate forwarding proof 2, and the commitment generated at the beginning is used for adjacent verification, forwarding proof 2 will also fail verification because the actual sequence position (5) and identity (D) on which forwarding proof 2 is based do not match.

[0179] (9) Fault Tolerance of Path Verification

[0180] The fault tolerance of path verification is a technical effect expected to be achieved by the embodiments of the present application. The fault tolerance of path verification includes node-level fault tolerance and AS-level fault tolerance.

[0181] Fault tolerance in node-level path verification means that while achieving path lockability, business data is allowed to pass through non-critical nodes during actual transmission, reducing the risk of critical nodes downstream of non-critical nodes interrupting business data transmission or outputting alarms due to forwarding proof verification failures. In other words, it supports the existence of one or more critical nodes between two critical nodes in the actual forwarding path, without strictly requiring that the sequential position of each critical node in the expected forwarding path be the same as the sequential position of the corresponding critical node in the actual forwarding path in order for forwarding proof verification to pass.

[0182] A typical application scenario requiring fault tolerance for non-critical nodes is when service data passes through non-critical nodes during the actual forwarding process. For example, the order in which service data is expected to pass through at least two critical nodes is the same as the order in which the at least two critical nodes actually forward the service data, and the expected sequence position of the at least two critical nodes is different from the sequence position in which the at least two critical nodes actually forward the service data. For example, the actual forwarding path of a first data packet contains additional non-critical nodes compared to the expected forwarding path of the first data packet.

[0183] As an example, key node A and key node B are adjacent in sequence in the expected forwarding path, but key node A and key node B establish a tunnel during the actual transmission of business data. Key node A transmits business data to key node B through a series of intermediate nodes in the tunnel, resulting in the key node A and key node B being not adjacent in sequence in the actual forwarding path.

[0184] For example, an expected forwarding path is a Layer 3 forwarding path composed of Layer 3 forwarding devices. In the Layer 3 forwarding path, key node B is the next forwarding node of key node A. Key node A actually transmits service data to key node B through a Layer 2 tunnel. The Layer 2 tunnel passes through one or more Layer 2 forwarding devices, resulting in the sequential positions of key nodes A and key node B in the actual forwarding path being non-adjacent. In the actual forwarding path, each Layer 2 forwarding device through which the Layer 2 tunnel passes exists between key nodes A and B.

[0185] For example, the expected forwarding path is an SRv6 path composed of SRv6 endpoint devices. The key node B in the SRv6 path is the next SRv6 endpoint device of the key node A, and the key node A actually transmits service data to the key node B through the IP layer tunnel. The IP layer tunnel passes through one or more native IPv6 forwarding devices, resulting in the key nodes A and B being in non-adjacent sequential positions in the actual forwarding path. In the actual forwarding path, there is each native IPv6 forwarding device passed by the IP layer tunnel between the key nodes A and B.

[0186] The main reason for critical nodes downstream of non-critical nodes failing to verify the forwarding proof is that the path planner calculates the vector commitment based on the critical node's sequential position in the expected forwarding path. If the critical node calculates the forwarding proof using the critical node's sequential position in the actual forwarding path, and verifies the forwarding proof using the vector commitment and the critical node's sequential position in the actual forwarding path, and the sequential position of the critical node in the actual forwarding path differs from the sequential position of the critical node in the expected forwarding path (the reasons and scenarios for the different sequential positions are described below), the sequential position based on which the vector commitment is calculated will deviate from the sequential position based on which the forwarding proof is calculated, causing the critical node to fail the forwarding proof verification based on the vector commitment.

[0187] In addition, since there is a certain degree of uncertainty about which forwarding nodes the business data passes through during actual transmission, the path planner is usually unable to perceive the sequential position of the key nodes in the actual forwarding path, nor is the path planner able to perceive the existence of non-critical nodes in the actual forwarding path. Therefore, it is difficult for the path planner to achieve fault tolerance by using the sequential position of the key nodes in the actual forwarding path to calculate the vector commitment.

[0188] In view of this, in some embodiments of the present application, the key node uses the sequential position of the key node in the expected forwarding path to calculate the forwarding proof, and uses vector commitment and the sequential position of the key node in the expected forwarding path to verify the forwarding proof, so that the sequential position based on which the vector commitment is calculated is consistent with the sequential position based on which the forwarding proof is calculated, thereby reducing the risk of interruption of business data transmission or output of alarm due to failure of the forwarding proof verification based on the vector commitment.

[0189] (10) Sequential position of key nodes in the expected forwarding path

[0190] The sequential position of a key node in an expected forwarding path is also referred to as the expected sequential position of the key node, the expected order, or the relative sequential position of the key node. The sequential position of a key node in an expected forwarding path is used to characterize the sequential relationship between the key node and other key nodes (such as the first key node) in the expected forwarding path. The sequential position of a key node in an expected forwarding path can also characterize the order in which the key node forwards data packets compared to other key nodes in the expected forwarding path. For example, the smaller the sequential position of a key node in an expected forwarding path, the closer the sequential position of the key node is to the first key node in the expected forwarding path, and the earlier the key node forwards data packets compared to other key nodes. Conversely, the larger the sequential position of a key node in an expected forwarding path, the closer the sequential position of the key node is to the last forwarding node in the expected forwarding path, and the later the key node forwards data packets compared to other forwarding nodes.

[0191] In some embodiments, the data form of the sequential position in the expected forwarding path is a sequence number (also called a serial number). The sequence number representing the sequential position in the expected forwarding path is hereinafter referred to as the expected sequence number. For example, the expected sequence number is a positive integer. For example, the expected sequence number uses an ascending order to represent the order from first to last. For example, for an expected forwarding path passing through N key nodes, the expected sequence number of the first key node is 1, the expected sequence number of the second key node is 2, and so on. Each key node is 1 greater than the expected sequence number of the previous key node, and the expected sequence number of the nth key node is N.

[0192] For example, please refer to Figure 1. "A-1" in Figure 1 indicates that the sequence position (expected sequence number) of the key node A in the expected forwarding path is 1, "B-2" indicates that the sequence position (expected sequence number) of the forwarding node B in the expected forwarding path is 2, and "C-3" indicates that the sequence position (expected sequence number) of the forwarding node C in the expected forwarding path is 3. In other words, the order in which the three forwarding nodes planned by the controller in the path planning stage forward data packets is: key node A forwards the data packet first, forwarding node B forwards the data packet second, and forwarding node C forwards the data packet third.

[0193] Alternatively, the expected sequence numbers of the forwarding nodes are represented in descending order. The larger the expected sequence number of forwarding node_i, the closer the forwarding node_i is to the first forwarding node in the expected forwarding path, and the earlier the forwarding node_i performs data packet forwarding compared to other forwarding nodes.

[0194] Of course, the sequential position of forwarding node_i in the expected forwarding path and the expected sequence number of forwarding node_i do not necessarily have to be numerically equal. The expected sequence number of forwarding node_i can also be used to convert the sequential position of forwarding node_i in the expected forwarding path using a formula or table. Alternatively, the sequential position in the expected forwarding path can use data other than sequence numbers. As long as data can represent the sequential relationship between key nodes, it can be used as the sequential position in the expected forwarding path. This embodiment does not limit the data format used for the sequential position in the expected forwarding path.

[0195] In some embodiments, the sequence position of the expected forwarding path is determined by the path planner during the path planning phase. For example, based on the path planning requirements, the path planner assigns a corresponding sequence position to each key node to represent the order in which each key node forwards data packets.

[0196] Regarding the use of sequential positions within the expected forwarding path, in some embodiments of the present application, the sequential positions within the expected forwarding path are used to determine vector commitments, calculate proofs of forwarding, and verify proofs of forwarding. For example, the control plane uses the sequential positions of each key node within the expected forwarding path when determining vector commitments, and the forwarding plane uses the sequential positions of each key node within the expected forwarding path when calculating proofs of forwarding. For more information on the specific use of sequential positions within the expected forwarding path, please refer to the description of the subsequent method embodiments.

[0197] (11) Sequential position in the actual forwarding path

[0198] The sequence position in the actual forwarding path is used to represent the sequence relationship between the nodes passed through in the actual forwarding path. The sequence position of the forwarding node in the actual forwarding path is also called the actual sequence position or true sequence position of the forwarding node.

[0199] In some embodiments, the data form of the sequential position in the actual forwarding path is a sequence number (also called a serial number). The sequence number representing the sequential position in the actual forwarding path will be referred to as the actual sequence number below. For example, the actual sequence number is a positive integer. For example, the actual sequence number uses an ascending order to represent the order from first to last. For example, for an actual forwarding path passing through n forwarding nodes (including key nodes and non-key nodes), the actual sequence number of the first forwarding node is 1, the actual sequence number of the second forwarding node is 2, and so on. Each forwarding node is 1 greater than the actual sequence number of the previous forwarding node, and the actual sequence number of the nth forwarding node is n.

[0200] Regarding the use of the sequence position in the actual forwarding path, in some embodiments of the present application, the sequence position in the actual forwarding path is used to achieve the recordability of non-critical nodes. For example, the sequence position in the actual forwarding path will be added to the data message by the forwarding node, and during the data message forwarding process, the data message carries the sequence position in the actual forwarding path. In some embodiments of the present application, in order to avoid the mismatch between the sequence position in the actual forwarding path and the sequence position in the expected forwarding path, the forwarding proof determined using the sequence position in the actual forwarding path and the vector commitment determined using the sequence position in the expected forwarding path do not match, resulting in the forwarding proof determined using the sequence position in the actual forwarding path being unable to pass verification and thus causing transmission failure, the sequence position in the actual forwarding path is neither used to determine the vector commitment, nor used for the calculation of the forwarding proof, nor used for the verification of the forwarding proof, thereby achieving fault tolerance of non-critical nodes. Of course, in the absence of the need to achieve fault tolerance of non-critical nodes, the sequence position in the actual forwarding path can also be used to determine the vector commitment, the calculation of the forwarding proof, and the verification of the forwarding proof.

[0201] In some embodiments of determining the sequential position of an actual forwarding path, in scenarios applied to Internet Protocol version 4 (IPv4) networks, the sequential position of the actual forwarding path is determined based on a time-to-live (TTL). For example, a data packet includes an IPv4 header, which includes a time to live (TTL). Forwarding node_i identifies the value of the TTL and, based on the TTL value, determines the position i of forwarding node_i on the forwarding path. If the initial value of the TTL is k, and the TTL value decreases by 1 with each node passed, then when forwarding node_i receives a data packet and identifies the TTL value carried by the data packet as ni, node_i determines that it is the i-th node in the forwarding path. For example, after the first forwarding node in a forwarding path receives a data packet, it determines its position in the actual forwarding path as 256-255=1 based on the TTL in the data packet being 255. The first forwarding node updates the TTL in the data packet from 255 to 254 and forwards it to the second forwarding node. After the second forwarding node in the forwarding path receives a data packet, it determines its position in the actual forwarding path as 256-254=2 based on the TTL in the data packet being 254. The second forwarding node updates the TTL in the data packet from 254 to 253 and forwards it to the third forwarding node. After the third forwarding node in the forwarding path receives a data packet, it determines its position in the actual forwarding path as 256-253=3 based on the TTL in the data packet being 253, and so on.

[0202] In some embodiments of determining the sequence position of an actual forwarding path, in scenarios applied to IPv6 networks, the sequence position of the actual forwarding path is determined based on a hop limit. As an example, a data packet includes an IPv6 header, and the IPv6 header includes a hop limit. Forwarding node_i identifies the value of the hop limit and obtains the position i of forwarding node_i on the forwarding path based on the value of the hop limit. If the initial value of the hop limit is k, since the value of the hop limit decreases by 1 each time a node is passed through, when forwarding node_i receives a data packet and identifies that the hop limit value carried by the data packet is ni, node_i determines that this node is the i-th node in the forwarding path. As an example, after the first forwarding node in the forwarding path receives a data packet, the first forwarding node determines that the sequence position of this node in the actual forwarding path is 256-255=1 based on the hop limit in the data packet being 255. The first forwarding node updates the hop limit in the data packet from 255 to 254 and forwards it to the second forwarding node. After the second forwarding node in the forwarding path receives the data packet, it determines its position in the actual forwarding path as 256-254=2 based on the hop limit in the data packet (254). The second forwarding node updates the hop limit in the data packet from 254 to 253 and forwards it to the third forwarding node. After the third forwarding node in the forwarding path receives the data packet, it determines its position in the actual forwarding path as 256-253=3 based on the hop limit in the data packet (253). And so on.

[0203] In some embodiments of determining the ordinal position of the actual forwarding path, as applied to the SFC scenario, the ordinal position of the actual forwarding path is determined based on the service index (SI). The service index (SI) is a field in the network service header (NSH). The SI value ranges from 255 to 0, and the SI is decremented by 1 with each data packet. After a forwarding node identifies the SI value in the NSH, it can use the value 256-SI as the ordinal position of the node in the actual forwarding path.

[0204] (12) The difference between the sequential position of the expected forwarding path and the sequential position of the actual forwarding path

[0205] The sequential position of forwarding node_i in the expected forwarding path may be the same as or different from the sequential position of forwarding node_i in the actual forwarding path. Whether the sequential position of forwarding node_i in the actual forwarding path is the same as the sequential position of forwarding node_i in the expected forwarding path mainly depends on whether there are non-critical nodes in the actual forwarding path.

[0206] In some scenarios, the actual forwarding path passes through one or more non-critical nodes that are not routed into the intended forwarding path by a routing planner. This can cause a discrepancy between the forwarding node's position in the actual forwarding path and its position in the intended forwarding path. This discrepancy between the forwarding node's position in the actual forwarding path and its position in the intended forwarding path indicates the number of non-critical nodes upstream of the critical node in the actual forwarding path.

[0207] For example, referring to (a) in FIG. 1 , the sequence position of forwarding node B in the expected forwarding path is 2. However, since key node A and forwarding node b exist upstream of forwarding node B in the actual forwarding path, neither key node A nor forwarding node b are arranged into the forwarding path by the path planner, resulting in the sequence position of forwarding node B in the actual forwarding path being 4. The sequence position (4) of forwarding node B in the actual forwarding path differs from the sequence position (2) of forwarding node B in the expected forwarding path by 4-2=2, where 2 represents the number of non-key nodes (key node A and forwarding node b) upstream of forwarding node B. For another example, the sequence position of forwarding node C in the expected forwarding path is 3. However, since key node A, forwarding node b, and forwarding node c exist upstream of forwarding node C in the actual forwarding path, neither key node A, forwarding node b, nor forwarding node c are arranged into the forwarding path by the path planner, resulting in the sequence position of forwarding node C in the actual forwarding path being 6. The sequence position (6) of forwarding node C in the actual forwarding path differs from the sequence position (3) of forwarding node C in the expected forwarding path by 6-3=3, where 3 represents the number of non-critical nodes upstream of forwarding node C (critical node A, forwarding node b, and forwarding node c).

[0208] Since non-critical nodes may be inserted between different critical nodes in the actual forwarding path, the sequential positions of two critical nodes that are continuous in the expected forwarding path are discontinuous in the actual forwarding path. For example, the expected forwarding path includes a first forwarding node and a second forwarding node that are adjacent in position. The sequential position of the first forwarding node in the expected forwarding path and the sequential position of the second forwarding node in the expected forwarding path are continuous (for example, the difference in the sequential positions is 1). Since there are one or more non-critical nodes between the first forwarding node and the second forwarding node in the actual forwarding path, the sequential positions of the first forwarding node and the second forwarding node in the actual forwarding path are discontinuous. The deviation of the sequential positions of the first forwarding node and the second forwarding node in the actual forwarding path represents the number of non-critical nodes located between the first forwarding node and the second forwarding node.

[0209] For example, referring to Figure 1 (a), the sequence positions of key node A and forwarding node B in the expected forwarding path are 1 and 2, respectively. Key node A and forwarding node B are sequentially positioned continuously in the expected forwarding path. However, due to the insertion of two non-critical nodes (node ​​a and node b) between key node A and forwarding node B in the actual forwarding path, the sequence positions of key node A and forwarding node B in the actual forwarding path are 1 and 4, respectively. The sequence positions of key node A and forwarding node B in the actual forwarding path are discontinuous. The deviation in the sequence positions of key node A and forwarding node B in the actual forwarding path represents the number of non-critical nodes between key node A and forwarding node B.

[0210] For another example, the sequence positions of forwarding nodes B and C in the expected forwarding path are 2 and 3, respectively. Forwarding nodes B and C are continuous in the expected forwarding path. However, due to the insertion of a non-critical node (node ​​c) between forwarding nodes B and C in the actual forwarding path, the sequence positions of forwarding nodes B and C in the actual forwarding path are 4 and 6, respectively. The sequence positions of forwarding nodes B and C in the actual forwarding path are discontinuous. The deviation in the sequence positions of forwarding nodes B and C in the actual forwarding path indicates the number of non-critical nodes between forwarding nodes B and C.

[0211] In some embodiments, the order of at least two key nodes in the expected forwarding path is the same as the order of each key node in the actual forwarding path, and the order position of at least two key nodes in the expected forwarding path is different from the order position of each key node in the actual forwarding path. In other words, the order between at least two key nodes is not disrupted, but non-key nodes are inserted between different key nodes. As a specific example, please refer to (a) in Figure 1. The order of key node A, forwarding node B, and forwarding node C in the expected forwarding path is first key node A, then forwarding node B, and finally forwarding node C; please refer to (b) in Figure 1; the order of key node A, forwarding node B, and forwarding node C in the actual forwarding path is also, first key node A, then forwarding node B, and finally forwarding node C. However, the order position (2) of forwarding node B in the expected forwarding path is different from the order position (4) of forwarding node B in the actual forwarding path, and the order position (3) of forwarding node C in the expected forwarding path is different from the order position (6) of forwarding node C in the actual forwarding path.

[0212] (13) Recordability of non-critical nodes

[0213] The recordability of non-critical nodes is a technical effect that is expected to be achieved in the embodiments of the present application. The recordability of non-critical nodes refers to the function of recording that a data message has passed through a non-critical node in the scenario where the data message passes through a non-critical node during the forwarding process. In some embodiments, the recordability of non-critical nodes is achieved by recording the sequential position of the critical nodes in the actual forwarding path. For example, if the sequential positions of two adjacent critical nodes in the actual forwarding path recorded are discontinuous, it is determined that there are non-critical nodes between the two critical nodes. Based on the difference in the sequential positions of two adjacent critical nodes in the actual forwarding path recorded, the number of non-critical nodes between the two critical nodes is determined. For example, if the difference in the sequential positions of two adjacent critical nodes in the actual forwarding path recorded is k, it is determined that there are (k-1) non-critical nodes between the two critical nodes.

[0214] There are multiple implementations for recording the locations of non-critical nodes. In some embodiments, when forwarding a data message, the critical node adds a list of the sequential positions of the critical nodes in the actual forwarding path to the data message, thereby achieving the recordability of the non-critical nodes. In other embodiments, the critical node achieves the recordability of the non-critical nodes by sending a message independent of the data message and carrying the list of the sequential positions of the critical nodes in the actual forwarding path. In still other embodiments, the critical node saves the list of the sequential positions of the critical nodes in the actual forwarding path in a locally stored log record.

[0215] For example, please refer to Figure 1, where key node A, key node B, and key node C are three adjacent key nodes. Key node A adds the sequence position of this node in the actual forwarding path to the data message as 1; key node B adds the sequence position of this node in the actual forwarding path to the data message as 4; key node B determines that there are two non-critical nodes between this node and the previous key node (key node A) based on the difference in sequence position between this node and the previous key node (key node A) in the actual forwarding path being 4-1=3. Key node C adds the sequence position of this node in the actual forwarding path to the data message as 6; key node C determines that there is one non-critical node between this node and the previous key node (key node B) based on the difference in sequence position between this node and the previous key node (key node B) in the actual forwarding path being 6-4=2.

[0216] (14) Vector Commitment

[0217] To facilitate understanding, the following first explains the common definition of "vector commitment" in cryptography, and then further explains "vector commitment" in conjunction with the application scenario of the trusted path in the embodiments of the present application.

[0218] A vector commitment is a type of data obtained through cryptographic techniques. It's used to prove the correctness of the value and position of each piece of information within a set of sequential information (such as a vector, array, or list containing at least two elements), while maintaining the information's confidentiality and typically without revealing its original content. Specifically, a vector commitment allows each piece of information within a set of sequential information to be committed and generates a corresponding proof, which other parties can verify to confirm the integrity of the sequenced information. Vector commitments are commonly found in zero-knowledge proofs. A vector commitment primarily consists of three phases: commit, open, and verify.

[0219] The commitment phase refers to the calculation of a vector commitment. For example, entity A secretly selects N sequentially ordered pieces of information M = (m_1, m_2, …, m_N) at once. It then calculates a commitment based on information M and makes the commitment public. The commitment contains the ordering relationship between information M and the N pieces of information within M. However, the outside world cannot infer the plaintext of the N pieces of information from the commitment, nor can it infer the position of each piece of information within the N pieces of information. Typically, after calculating the commitment based on information M, entity A cannot modify information M. The calculation of a vector commitment can be implemented using a commitment function.

[0220] The opening phase refers to the computation of proofs. Proofs are used to verify 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 a specific location i is m_i. Proof computation is performed using the open function, which includes single-point open and batch open functions.

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

[0222] A batch open function involves entity A calculating a multi-point open proof (MP) at once. This proof proves that the set B formed by multiple pieces of information m_i is a collection of information, where each m_i is at its corresponding position i. This allows for simultaneous verification of information at multiple locations. The computational complexity of multi-point proofs is generally higher than that of single-point proofs. The calculation method for multi-point proofs can be found in the following link.

[0223] [https: / / github.com / khovratovich / Kate / blob / 66aae66cd4e99db3182025c27f02e147dfa0c034 / Kate_amortized.pdf][KZG].

[0224] The verification phase refers to the verification of the proof. For example, the verifier uses commitment and open proofs to verify that the object initially committed or selected by entity A is indeed information M. Verification is achieved through the verification function. Verification includes single-point verification and batch verification.

[0225] Single-point verification refers to the single-point open proof (OP_i). The verifier can use the commitment, the single-point open 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 open proof.

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

[0227] For a more detailed explanation of vector commitments, refer to the paper "Constant-Size Commitments to Polynomials and Their Applications." The actual algorithms defined in the paper include but are not limited to setup, commit, open, create witness, verifyeval, create witness batch, verify eval batch, etc.

[0228] In the application scenario of the embodiment of the present application, vector commitment is used to prove the correctness of the identity information and sequential position of the forwarding node in the actual forwarding path. For example, the path planner is regarded as entity A in the vector commitment technology, and information M is used to represent the trusted path (expected forwarding path) P = (r_1, r_2,…r_i…, r_N). The information m_i in the information M represents the identity information r_i of the key node i, i is the expected sequence number of the key node in the expected forwarding path, and the set B is used to represent a certain section of the trusted path (expected forwarding path). The proof in the vector commitment is specifically a forwarding proof. The most important property of the vector commitment is order preservation, that is, the information m_i of the commitment and the opening proof must be bound to the position i.

[0229] Embodiments of the present application relate to the application of vector commitments in device-level path verification and the application of vector commitments in AS-level path verification. To distinguish between different vector commitments, "first vector commitment" or "device-level vector commitment" is used to describe the vector commitment applied in device-level path verification, and "second vector commitment" or "AS-level vector commitment" is used to describe the vector commitment applied in AS-level path verification. For example, a device-level vector commitment is obtained based on the identity information of each forwarding node in an expected forwarding path and the order relationship of each forwarding node in the expected forwarding path. For example, an AS-level vector commitment is obtained based on the identity information of each AS passed through in an expected forwarding path and the order relationship of each AS passed through in the expected forwarding path.

[0230] (15) KZG polynomial commitment

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

[0232] (16) Forwarding Proof

[0233] The embodiments of the present application relate to the application of forwarding proof in device-level path verification and the application of forwarding proof in AS-level path verification. In order to distinguish different forwarding proofs, the forwarding proof applied in device-level path verification is described as "first forwarding proof" or "device-level forwarding proof", and the forwarding proof applied in AS-level path verification is described as "second forwarding proof" or "AS-level forwarding proof". The node-level forwarding proof is used to prove that a specific node forwards a data message at a specific sequential position in the forwarding path. The AS-level forwarding proof is used to prove that a specific AS forwards a data message at a specific sequential position in the forwarding path. The forwarding proof includes a single-point forwarding proof (OP) and a multi-point forwarding proof (MP).

[0234] OP represents a forwarding proof associated with a single forwarding node, used to prove that a specific node forwarded a data packet at a specific sequential position corresponding to that specific node in the forwarding path. Alternatively, OP represents a forwarding proof associated with a single AS, used to prove that a specific AS forwarded a data packet at a specific sequential position corresponding to that specific node in the forwarding path.

[0235] MP (multi proof) represents a forwarding proof associated with multiple forwarding nodes, used to prove that each node in a specific path forwards a data packet at the corresponding sequential position. For example, for the expected forwarding path from key node A to key node B to key node C to key node D, the OP includes the OP of key node A, the OP of key node B, the OP of key node C, and the OP of key node D, and the MP includes the MP of path AB, the MP of path ABC, and the MP of path ABCD. Alternatively, MP represents a forwarding proof associated with multiple autonomous systems (ASs), used to prove that multiple ASs forward data packets at corresponding specific sequential positions in the forwarding path.

[0236] The method for obtaining the single-point forwarding proof is based on the sequential position of a single key node of the verified node in the expected forwarding path and the identity information of the single key node of the verified node.

[0237] The verified node's single-point forwarding proof is used to prove that the verified node forwarded data packet A and that the verified node's sequence position is correct. Taking the verified node as key node A, key node A obtains forwarding proof A based on its identity information, its sequence position in the expected forwarding path, and cryptographic parameters. Forwarding proof A is a single-point forwarding proof, proving that key node A forwarded the data packet in the expected sequence position. Optionally, key node A uses a single-point open function (open) to obtain single-point forwarding proof A, where single-point forwarding proof A = open(i, r_i).

[0238] The method for obtaining the multi-point forwarding proof is based on the sequential positions of at least two key nodes in the expected forwarding path and the identity information of at least two key nodes.

[0239] For example, the verified node obtains a first forwarding certificate based on the sequential position of the verified node in the expected forwarding path, the identity information of the verified node, the sequential position of the second forwarding node in the expected forwarding path, and the identity information of the second forwarding node. The identity information of the second forwarding node indicates the identity of the second forwarding node. The first forwarding certificate is used to prove that the verified node and the second forwarding node are respectively in corresponding sequential positions in the expected forwarding path.

[0240] Taking key node i as an example, key node i obtains a forwarding proof p_i based on the identity information of each node from key node 1 to key node i, the sequential position of each key node from key node 1 to key node i in the expected forwarding path, and cryptographic parameters. Forwarding proof p_i is a multi-point forwarding proof, which proves that key node 1 forwarded a data message at sequence position 1, key node 2 forwarded a data message at sequence position 2, and so on, and that key node i forwarded this data message at sequence position i. Optionally, key node i obtains forwarding proof p_i using a batch open function (batchopen), where p_i = batchopen(r_1,…,r_i).

[0241] Whether it's a single-point forwarding proof or a multi-point forwarding proof, the sequence position used in determining and verifying the forwarding proof is the sequence position in the expected forwarding path, not the sequence position in the actual forwarding path. Taking Figure 1 as an example, the sequence positions of the three key nodes used in determining and verifying the forwarding proof are the expected continuous sequence positions 1, 2, and 3, rather than the actual non-contiguous sequence positions 1, 4, and 6. Because the sequence position in the actual forwarding path does not participate in the process of determining and verifying the forwarding proof, the risk of transmission interruption caused by determining and verifying the forwarding proof based on the sequence position in the actual forwarding path is reduced.

[0242] The forwarding proof of the verified node includes a single-point forwarding proof and a multi-point forwarding proof. The following examples illustrate how to obtain a single-point forwarding proof and a multi-point forwarding proof. In some embodiments, either the single-point forwarding proof or the multi-point forwarding proof is used.

[0243] The method for obtaining the single-point forwarding proof is based on the sequential position of a single key node of the verified node in the expected forwarding path and the identity information of the single key node of the verified node.

[0244] The verified node's single-point forwarding proof is used to prove that the verified node forwarded data packet A and that the verified node's sequence position is correct. Taking the verified node as key node A, key node A obtains forwarding proof A based on its identity information, its sequence position in the expected forwarding path, and cryptographic parameters. Forwarding proof A is a single-point forwarding proof, proving that key node A forwarded the data packet in the expected sequence position. Optionally, key node A uses a single-point open function (open) to obtain single-point forwarding proof A, where single-point forwarding proof A = open(i, r_i).

[0245] The method for obtaining the multi-point forwarding proof is based on the sequential positions of at least two key nodes in the expected forwarding path and the identity information of at least two key nodes.

[0246] For example, the verified node obtains a first forwarding certificate based on the sequential position of the verified node in the expected forwarding path, the identity information of the verified node, the sequential position of the second forwarding node in the expected forwarding path, and the identity information of the second forwarding node. The identity information of the second forwarding node indicates the identity of the second forwarding node. The first forwarding certificate is used to prove that the verified node and the second forwarding node are respectively in corresponding sequential positions in the expected forwarding path.

[0247] Taking key node i as an example, key node i obtains a forwarding proof p_i based on the identity information of each node from key node 1 to key node i, the sequential position of each key node from key node 1 to key node i in the expected forwarding path, and cryptographic parameters. Forwarding proof p_i is a multi-point forwarding proof, which proves that key node 1 forwarded a data message at sequence position 1, key node 2 forwarded a data message at sequence position 2, and so on, and that key node i forwarded this data message at sequence position i. Optionally, key node i obtains forwarding proof p_i using a batch open function (batchopen), where p_i = batchopen(r_1,…,r_i).

[0248] Whether it's a single-point forwarding proof or a multi-point forwarding proof, the sequence position used in determining and verifying the forwarding proof is the sequence position in the expected forwarding path, not the sequence position in the actual forwarding path. Taking Figure 1 as an example, the sequence positions of the three key nodes used in determining and verifying the forwarding proof are the expected continuous sequence positions 1, 2, and 3, rather than the actual non-contiguous sequence positions 1, 4, and 6. Because the sequence position in the actual forwarding path does not participate in the process of determining and verifying the forwarding proof, the risk of transmission interruption caused by determining and verifying the forwarding proof based on the sequence position in the actual forwarding path is reduced.

[0249] For the sake of simplicity, the following embodiments of this application sometimes use the form of "OP+underscore+position" to simply represent a single-point forwarding proof calculated by a node at a specific sequential position. The form of "MP+underscore+position" is used to simply represent a multi-point forwarding proof calculated by a node at a specific sequential position. For example, OP_i represents the single-point forwarding proof calculated by the i-th key node in the actual forwarding path, and MP_i represents the multi-point forwarding proof calculated by the i-th key node on the forwarding path.

[0250] (17) Identity information of forwarding node

[0251] The identity information of the forwarding node_i is used to indicate the identity of the forwarding node_i. The identity information of the forwarding node_i is, for example, the identifier of the forwarding node_i.

[0252] In some embodiments, the identity information of the forwarding node is publicly verifiable identity information. By using publicly verifiable identity information to calculate and verify the forwarding proof, the difficulty of obtaining the identity information is reduced, thereby reducing the complexity of calculating and verifying the forwarding proof based on the identity information. In other possible implementations, the identity information of forwarding node_i is a publicly verifiable and 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; or, 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 the forwarding proof or verify the forwarding proof, the security and privacy of the calculation and verification of the forwarding proof are further improved due to the higher security and privacy of the identity information.

[0253] 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 may optionally be the IP address of forwarding node_i. For example, the address used as the identity information of forwarding node_i may be the IPv4 address of forwarding node_i or the IPv6 address of forwarding node_i. Alternatively, the address used as the identity information of forwarding node_i may be the media access control (MAC) address of forwarding node_i.

[0254] 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 forwarding proofs, 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.

[0255] Exemplarily, the identity information of forwarding node_i includes the MPLS label of forwarding node_i. An MPLS label is a short, fixed-length connection identifier used to replace IP forwarding in MPLS or SR-MPLS networks. By using the MPLS label as identity information to calculate and verify proof of forwarding, it is more suitable for MPLS or SR-MPLS network scenarios. While achieving path binding, the MPLS label carried in the MPLS or SR-MPLS encapsulation can be reused, eliminating the need to add additional fields to the message to carry identity information. This helps simplify the message format and reduce the overhead of message transmission.

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

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

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

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

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

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

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

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

[0264] Exemplarily, the identity information of forwarding node_i includes Sigma protocol proof. Sigma protocol proof is an interactive protocol based on zero-knowledge proof. It allows a prover to prove that a statement is true in an interaction with a 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 reveal the true information of the statement to the verifier, thereby protecting the privacy of the prover.

[0265] (18)segment list

[0266] The segment list is used to indicate the expected forwarding path in SRv6 scenarios. 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 key node 1 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 key node 1 in the forwarding path.

[0267] (19) Time to live (TTL)

[0268] The TTL is a field in the IPv4 header that limits the transmission time or number of hops a datagram can take on a network. The TTL is expressed as an integer. Each time a datagram passes through a forwarding node, the TTL decreases by 1. When the TTL reaches 0, the datagram is discarded and a time-exceeded message is returned to the source node. The TTL is located in the ninth byte of the IPv4 header, occupying one byte (8 bits) and used to store the TTL value.

[0269] (20) Hop limit

[0270] In the IPv6 protocol, TTL is called the hop limit and 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 datagram takes within the network. The 7th byte (8 bits) of the IPv6 header is used to store the hop limit value.

[0271] (21) Autonomous system (AS)

[0272] An AS is a group of network devices with the same routing policy, managed by the same entity. Each AS on the Internet is assigned an autonomous system number (AS number), which allows other network devices to find the corresponding AS based on the AS number. For simplicity, the following examples of this application use the "AS+number" format to simplify the representation of specific ASs. For example, an AS is simply represented as AS1.

[0273] (22) AS identity information

[0274] The identity information of the AS is used to indicate the identity of the AS. For example, the identity information of the AS is the AS number or the secret value of the AS. The AS number (autonomous system number) is also called the AS number or AS number. The AS number is a positive integer, and the AS number value range is usually from 1 to 65535. Each AS has a unique AS number. The AS number can be used to uniquely identify an AS on the Internet. The secret value of the AS is the ciphertext data obtained by encrypting the AS number. For example, the AS number is encrypted based on the key preset in each forwarding device in the AS to obtain the secret value of the AS.

[0275] (23) Autonomous system path (AS_path)

[0276] AS_path is a path attribute in the BGP protocol. AS_path is typically carried in BGP protocol messages. AS_path is used to record the ASs traversed from the source AS to the destination AS. AS_path consists of a series of AS numbers that describe all ASs that a BGP protocol message passes through from the source AS to the destination AS. A pair of adjacent ASs in the AS_path represents two ASs with an upstream and downstream relationship in the forwarding path. Based on the AS_path, the order between each AS from the source AS to the destination AS can be determined. For example, a BGP protocol message includes an address prefix P1 and an AS_path. The AS_path is [AS 3AS1AS 6], indicating that address prefix P1 originates from AS 6, then passes through AS1, and finally reaches AS 3. The AS_path indicates that when forwarding a data packet with a source address matching address prefix P1, the order of AS 3, AS1, and AS 6 is AS 6 first, then AS1, and finally AS 3. For the detailed definition, format, and usage of AS_path, refer to Section 4.3 "Path Attributes" in RFC 4271.

[0277] (24)AS List

[0278] The AS list includes the identity information of at least two ASs. For example, the AS list includes the identity information of the ASs where each key node passed through in the expected forwarding path is located. In addition, the AS list is also used to indicate the expected forwarding order of at least two ASs. For example, the arrangement order of the identity information of each AS in the AS list matches the expected forwarding order of each AS. The sequential position of the identity information of an AS in the AS list identifies the sequential position of the AS in each AS passed through by the expected forwarding path. Take the AS identity information as an AS number as an example. For example, the first AS number in the AS list identifies the first AS passed through by the expected forwarding path, the second AS number in the AS list identifies the second AS passed through by the expected forwarding path, and so on.

[0279] The following examples illustrate the application scenarios of the device-level path verification method and the corresponding method flow.

[0280] Many source address or centralized path calculation routing technologies feature the ability for the source host or centralized controller to specify a network path through a series of specific network devices or virtualized network functions. For example, SR technology or SFC both support the control plane's ability to specify a network path. However, one challenge is that even if the source host or centralized controller specifies a path on the control plane, it cannot know whether the data packet actually strictly follows this path on the forwarding plane (data plane). For example, network attacks such as route hijacking, route injection, and traffic detour, or network device misconfiguration issues can cause the actual forwarding path on the data plane to deviate from the expected forwarding path on the control plane.

[0281] Among them, route hijacking attack refers to the attacker hijacking and / or diverting network traffic to network devices or AS controlled by the attacker for monitoring, tampering or interception. Route hijacking attack is also called prefix hijacking attack or Internet Protocol (IP) hijacking attack. Route injection refers to the input of forged routing information into network devices such as routers, so that the forged routing information is propagated throughout the network. Attackers can change the routing path of the network through route injection, causing traffic to be redirected to the path controlled by the attacker. Traffic detour refers to the attacker tampering with the configuration of network devices to detour traffic from the expected path, causing traffic to be redirected to the path specified by the attacker.

[0282] In short, the problem that needs to be solved urgently is the inconsistency between the expected forwarding path determined by the control plane and the actual forwarding path of the data plane. This problem will cause technologies such as SR or SFC to lose their original technical advantages of being able to achieve path specification.

[0283] To address this issue, the trusted path mechanism (also known as a secure routing mechanism or path validation mechanism) emerged. It addresses these issues, ensuring that data packets are forwarded hop-by-hop along the path planned by the path planner, and providing publicly verifiable proof of forwarding. A complete trusted path mechanism includes two technical components: a path locking mechanism and a path validation mechanism. This can also be considered a coordinated effort between protocols and methods at both the control and data plane levels.

[0284] At present, there is still a lack of a strictly secure trusted path mechanism both at home and abroad, and the existing trusted path mechanisms all have certain limitations in terms of security.

[0285] For example, if a non-cryptographic traversal proof approach is used to implement path locking, for example, key node 1 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, since the forwarding proof is not strongly bound to the forwarding node's position on the forwarding path, a strong position-bound forwarding proof cannot be generated. 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 forward hop by hop along the designated path, 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 lacks credibility. 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 this 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.

[0286] For another example, if path locking is achieved using cryptographic traversal credentials, for example, each forwarding node establishes a key pair with the controller, and then each routing node uses cryptography to generate an identity-binding certificate, and then passes the certificate, although the problem of forgery has been 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.

[0287] Based on the above problems, some embodiments of the present application provide solutions based on forwarding proof and vector commitment, which help solve the locking mechanism and forwarding path verification mechanism of the forwarding path in the trusted network.

[0288] In some embodiments, a forwarding proof is obtained based on the sequential position of the forwarding node in the actual forwarding path and the identity information of the forwarding node, and the forwarding proof is verified based on the vector commitment, the actual sequential position of the forwarding node in the forwarding path, and the identity information of the forwarding node, thereby achieving the position binding of the forwarding proof. That is, the forwarding proof is no longer only related to the identity of the forwarding node, but also to the position of the forwarding node on the forwarding path, so that the correct forwarding proof can be calculated 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, and the forwarding proof has public verifiability that is difficult to tamper with, thereby solving the problem of poor credibility of the forwarding proof due to the fact that the forwarding proof is independent of the position of the forwarding node on the forwarding path. The above embodiment helps to strictly lock the expected forwarding path planned by the path planner, and then verify whether the actual forwarding situation of the data message strictly corresponds to this expected forwarding path.

[0289] Although the above-mentioned implementation method achieves absolute order preservation, the strictness of the path verification may be too high. For example, this method requires that each forwarding node passed through in the actual forwarding path supports the calculation of the forwarding proof, and does not allow any form of "forwarding data packets but not calculating the forwarding proof" to exist in the actual forwarding path. However, in IP networks, there are a large number of weak or outdated network devices, or devices produced by third-party network manufacturers that do not support functions. These forwarding nodes do not necessarily have subjective malicious aggressiveness, but do not cooperate in calculating the forwarding proof. This embodiment defines these forwarding nodes as non-critical nodes. Taking into account compatibility and availability, these non-critical nodes need to be fault-tolerant. For example, it is necessary to tolerate the insertion of non-critical nodes in the middle of critical nodes, or to tolerate the existence of transparent tunnels in the middle of critical nodes without interrupting transmission due to passing through non-critical nodes. How to make the forwarding path locking mechanism and forwarding path verification mechanism support fault tolerance for non-critical nodes is the most important effect of this embodiment.

[0290] Optionally, how to make the forwarding path locking mechanism and the forwarding path verification mechanism support the recordability of non-critical nodes is also an effect to be achieved by this embodiment. The following is an explanation of the technical means corresponding to the several effects expected to be achieved by the embodiment of this application.

[0291] Technical Effect 1: Forwarding Path Lockability

[0292] In some embodiments, the critical path binding is achieved through the cryptographic technology of vector commitment. This embodiment uses the order-preserving property of vector commitment to achieve the above technical effect 1. For example, in the commitment stage, the path controller obtains the vector commitment based on the sequential position of each key node in the expected forwarding path and the identity information of each key node through the commitment function in the vector commitment technology. In the opening stage, each key node calculates the forwarding proof in sequence based on the sequential position of the key node and the identity information of the key node through the opening function in the vector commitment technology when receiving the data message in sequence. The key node or verification node verifies the forwarding proof through the verification function in the vector commitment technology based on the vector commitment, the sequential position of the key node and the identity information of the key node.

[0293] In some embodiments, when each key node receives data packets in sequence, it obtains a forwarding proof OP related to a single key node based on a single-point open function, and publicly announces the forwarding proof OP related to the single key node; the key node or an external verification node verifies the forwarding proof OP related to the single key node based on a single-point verification function, thereby verifying whether the order of a certain key node actually passed through is consistent with the expected order of the key node. In another possible implementation, when each key node receives data packets in sequence, it obtains a forwarding proof MP related to multiple key nodes based on a multi-point open function, and verifies the forwarding proof MP related to multiple key nodes based on a batch verification function, thereby verifying whether the order of multiple key nodes is consistent with the expected order of the multiple key nodes at one time.

[0294] Technical Effect 2: Source Correctness

[0295] Source correctness refers to verifying the correctness of the source of the data packet. Source correctness includes the correctness of the previous hop and the correctness of the first half of the path.

[0296] For example, when key node i receives data packet _i, key node i verifies the forwarding proof of the previous hop i-1 carried by data packet _i based on the vector commitment; if the forwarding proof of the previous hop i-1 fails to be verified, it is determined that the previous hop of the data packet is incorrect; if the forwarding proof of the previous hop i-1 passes the verification, it is determined that the previous hop of the data packet is correct.

[0297] The correctness of the first half path is, for example, when the key node i receives the data packet _i, the key node i verifies the forwarding proof from the first node to the previous hop i-1 carried by the data packet _i based on the vector commitment; if the forwarding proof from the first node to the previous hop i-1 fails to be verified, it is determined that the first half path of the data packet is incorrect; if the forwarding proof from the first node to the previous hop i-1 passes the verification, it is determined that the first half path of the data packet is correct.

[0298] The following is an example of how to implement source correctness.

[0299] The previous hop correctness verification method verifies the single-point forwarding proof (OP) based on the location information and identity information of a single key node. For example, a data packet received by key node i carries the single-point forwarding proof related to key node_k. Key node i verifies the single-point forwarding proof of key node_k based on the vector commitment, the identity information of key node_k, and the location information of key node_k. Key node_k is the upstream node of key node i in the forwarding path. The single-point forwarding proof of key node_k is used to prove that node_k forwards the data packet at position k on the forwarding path. The single-point forwarding proof of key node_k is obtained based on the position k and the identity information of key node_k, where k is a positive integer less than or equal to i.

[0300] Optionally, the key 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 key node i carries the single-point forwarding proof generated by key node i's previous hop node (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. Key node i verifies the single-point forwarding proof carried by the data packet based on the vector commitment, node_i-1's identity information, and node_i-1's location information. Similarly, each hop node is responsible for verifying the single-point forwarding proof of the previous hop node.

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

[0302] Optionally, the trigger condition for verifying the forwarding proof carried by the data message is that the data message contains a trusted path identifier. For example, after receiving the data message, if the key node determines that the data message header contains a trusted path identifier, it verifies the forwarding proof carried by the data message.

[0303] Optionally, the key node verifies the forwarding proof carried by the data message. If the forwarding proof carried by the data message passes the verification, the key node calculates the forwarding proof and publishes the forwarding proof. If the forwarding proof carried by the data message fails the verification, the key node does not need to calculate the forwarding proof and, for example, directly discards the data message.

[0304] Technical Effect 3: Computational Efficiency and Communication (Space) Efficiency

[0305] Computational efficiency and communication (space) efficiency refer to reducing the computation time and verification time of proofs, and reducing the amount of data required to transmit additional proofs and / or parameters, while ensuring safety. In the embodiments of the present application, the computation time and verification time of proofs are both constant, and the amount of data required to transmit additional proofs is constant, regardless of the number of nodes N included in the forwarding path.

[0306] Vector commitment mechanism is a general term for a class of technologies that encompasses a variety of specific construction methods. Optionally, a method based on KZG polynomial commitments (Kate-Zaverucha-Goldberg polynomial commitments) can be used to obtain and verify commitments based on the identity and location information of forwarding nodes. This further reduces the time required to obtain commitments, improves their efficiency, and avoids the superlinear growth of forwarding proof verification time as the number of nodes in the forwarding path increases, minimizing the verification time for forwarding proofs.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0320] Technical Effect 4: Fault Tolerance of Non-Critical Nodes

[0321] Fault tolerance of non-critical nodes does not conflict with the order-preserving verification mentioned above, mainly for two reasons.

[0322] First, the sequential relationship between the key nodes specified by the controller, such as the sequential relationship between key node A, key node B, and key node C in Figure 1, still needs to be achieved through the corresponding means of forwarding path locking.

[0323] Second, the fault tolerance of non-critical nodes is mainly based on the sequential position of critical nodes in the expected forwarding path to determine the vector commitment and to determine the forwarding proof implementation.

[0324] There are two ways to implement the fault tolerance mechanism.

[0325] Method 1 for implementing fault tolerance: During the commitment phase, a vector commitment is determined based on the identity information and the ordinal position of each key node in the expected forwarding path. This vector commitment binds the correspondence between the identity information and the ordinal position. For example, each key node is mathematically represented by a two-tuple (x_i = i, y_i = r_i), where i is the expected ordinal number of the key node in the expected forwarding path, and r_i is the identity information of the key node with expected ordinal number i in the expected forwarding path. The vector commitment is bound to the two-tuple (x_i = i, y_i = r_i) of each key node in the expected forwarding path.

[0326] During the forwarding phase, a forwarding proof is also calculated based on the key node's identity information r_i and the key node's sequential position i in the expected forwarding path. Optionally, the forwarding proof is calculated as MP instead of OP. MP is a forwarding proof calculated for a segment of the path, used to verify that all key nodes in the first half of the actual forwarding path are in the correct sequential position. For example, the sequential relationship between all key nodes in the first half of the actual forwarding path is consistent with the sequential relationship between all key nodes in the first half of the expected forwarding path.

[0327] The second fault-tolerant implementation method is that during the commitment phase, the correspondence between the identity information and the sequential position of the key nodes is no longer bound, but only the identity information of the key nodes is bound. For example, the vector commitment is determined based on the identity information of each key node in the expected forwarding path, and the sequential position of each key node in the expected forwarding path is not used when determining the vector commitment. This method of no longer using the sequential position of the key nodes is equivalent to mathematically converting each forwarding node into a binary tuple (x_i=r_i, y_i=r_i), where r_i is the identity information of key node i, and the x and y in the binary tuple of the forwarding node are both identity information, and the sequential position i is no longer included. The vector commitment is bound to the binary tuple (x_i=r_i, y_i=r_i) of each key node in the expected forwarding path. When calculating the forwarding proof, OP can be used to calculate the forwarding proof of a single node, and MP can be used to calculate the forwarding proof of multiple nodes in a path. In addition, when calculating the forwarding proof, non-critical nodes that may exist in the middle are ignored. However, the forwarding proof obtained in this way can only prove that the data packet has passed through this key node, but cannot prove the correctness of the sequence position of the key nodes, resulting in some loss of position binding.

[0328] Technical Effect 5: Recordability of Non-Critical Nodes

[0329] Alternatively, based on the first fault-tolerant implementation method, key nodes can record their position in the actual forwarding path while forwarding data packets. Based on this recorded position, the presence and number of non-critical nodes in the actual forwarding path can be inferred, thereby achieving recordability of non-critical nodes. Furthermore, since key nodes are responsible for recording the position in the actual forwarding path, non-critical nodes do not need to perform additional actions beyond forwarding, while still being able to indirectly record their presence, resulting in improved compatibility.

[0330] In some implementations, the structure of the data message is expanded by adding a new list to the data message to record the sequence position of the actual forwarding path of the key nodes. The list is hereinafter referred to as the actual sequence position list (also called the real sequence number list).

[0331] The actual sequence position list is used to record the sequence position of each key node in the actual forwarding path. In some embodiments, when key node A is forwarding a data message, key node A obtains the sequence position of this node in the actual forwarding path, and writes the sequence position of this node in the actual forwarding path into the actual sequence position list carried by the data message. Key node A forwards the data message containing the list of actual sequence positions of this node to key node B. Key node B writes the sequence position of key node B in the actual forwarding path after the sequence position of key node A in the actual sequence position list, and forwards the list containing the sequence positions of key node A and key node B to key node C. By analogy, every time a data message passes through a key node, the actual sequence position list carried in the data message will increase by the actual sequence position of one key node. When the data message reaches the last key node, after the last key node adds the actual sequence position of this node to the actual sequence position list carried in the data message, the actual sequence position list carried in the data message includes the actual sequence position of each key node passed by the actual forwarding path.

[0332] Optionally, the order of the entries in the actual sequence list matches the order of the key nodes in the actual forwarding path. For example, the first entry in the actual sequence list is used to record the sequence position of the first key node in the actual forwarding path; the second entry in the actual sequence list is used to record the sequence position of the second key node in the actual forwarding path; and so on, the i-th entry in the actual sequence list is used to record the sequence position of the i-th key node in the actual forwarding path.

[0333] Optionally, two adjacent entries in the actual sequence position list are used to record the sequence positions of two adjacent key nodes in the expected forwarding path. The difference between the actual sequence positions recorded in the two adjacent entries represents the number of non-key nodes between the corresponding two key nodes.

[0334] Optionally, the length of the actual sequential position list is 1 byte multiplied by the path length n, that is, n bytes. Among them, the path length is determined based on the number of key nodes passed by the actual forwarding path, and the path length n represents a total of n key nodes passed in the actual forwarding path. 1 byte is used to store the sequential position of a key node in the actual forwarding path. Considering that 1 byte can store a maximum of 256 values, and the maximum value of TTL (sequential position in the actual forwarding path) is 255, 1 byte is sufficient to carry the sequential position of any key node in the actual forwarding path.

[0335] For example, the expected forwarding path planned by the controller is ABCD, and the corresponding sequence positions of key nodes A, B, C, and D are 1234, respectively. There is one non-critical node between key node A and key node B, two non-critical nodes between key node B and key node C, and two non-critical nodes between key node C and key node D. In this scenario, key node A adds its sequence position (1) in the actual forwarding path to the first entry in the actual sequence position list carried in the data message, key node B adds its sequence position (3) in the actual forwarding path to the second entry in the actual sequence position list carried in the data message, key node C adds its sequence position (5) in the actual forwarding path to the third entry in the actual sequence position list carried in the data message, and key node D adds its sequence position (9) in the actual forwarding path to the fourth entry in the actual sequence position list carried in the data message. The actual sequence position list carried in the data message finally received by the destination host of the data message is shown in the following table.

[0336] In other embodiments, non-critical nodes achieve recordability by recording their own sequential position in the actual forwarding path during the process of forwarding data packets. For example, if there are one or more forwarding nodes in the actual forwarding path that do not support forwarding proof calculation or forwarding proof verification but support recording the sequential position of the actual forwarding path, upon receiving a data packet, the forwarding node determines the sequential position of the node in the actual forwarding path based on the TTL or other fields in the data packet, adds the node's sequential position in the actual forwarding path to the actual sequential position list carried in the data packet, or sends the node's sequential position in the actual forwarding path to the verification node.

[0337] By utilizing vector commitments, the present embodiment can achieve technical effect 1: critical path binding and technical effect 2: source correctness. By utilizing polynomial commitment technology, the present embodiment can achieve technical effect 3: computational efficiency and communication (space) efficiency.

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

[0339] The embodiments of the present application provide a universal trusted path protection technology that can protect the data plane forwarding path, so it can be applied to any scenario at any level of a computer network that requires trusted path protection. 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, application-aware networking (APN), virtual extensible LAN (VxLAN) or Internet Protocol Security (IPSec); the business layer is applicable to service function chaining (SFC) protocols, etc. The difference between different protocol scenarios mainly lies in the message headers carrying commitments and forwarding certificates and the specific carrying locations. The following first describes the universal trusted path protocol steps, functions and roles, and then explains the specific embodiments in different protocol scenarios.

[0340] In any scenario that requires a trusted path, there are several roles: path planner, forwarding node, and verification node.

[0341] The path planner determines a network forwarding path within any of the network hierarchies listed above. This forwarding path can be represented by a vector P = (r_1, r_2, …, r_N) formed by the information of N forwarding nodes (or routing nodes). Here, r_i is the publicly verifiable identity of forwarding node i. After determining this forwarding path, the path planner calculates the corresponding commitment C for this forwarding path. The path planner obtains the identity information of all forwarding nodes in the network in advance.

[0342] Optionally, the path planner performs remote attestation secret distribution, where the secret is the identity information of the forwarding nodes in ciphertext form. For example, the path planner sends the ciphertext identity information of each of the N forwarding nodes in the intended forwarding path, so that the N forwarding nodes in the intended forwarding path can determine the vector commitment based on the received ciphertext identity information.

[0343] Forwarding nodes are further divided into key nodes and non-key nodes. Please refer to the previous description for the definition of key nodes and non-key nodes.

[0344] When each key node receives a data packet with a trusted path identifier in its header, it calculates a forwarding proof p_i and publishes it to the verification node. p_i can be a single-point proof (OP), which proves that the key node r_i at position i forwarded the data packet; p_i can also be a multi-point proof (MP), which proves that the key nodes (r_1, r_2, ..., r_i) at positions i from 1 to i all forwarded the data packet to the correct location.

[0345] A validator, also known as an observer, is any device that cares about the trustworthiness of the forwarding path. It 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 validator is unbiased, meaning that its observations and verifications are identical to the protocol output under a correct scenario.

[0346] Figure 2 is a schematic diagram of a path verification method provided by an embodiment of the present application. The method shown in Figure 2 is interactively executed by a path planner, a forwarding node, and a verification node.

[0347] The method shown in Figure 2 involves the interaction between multiple key nodes during the service data transmission process. In order to distinguish different forwarding nodes, "key node A" and "key node B" are used to distinguish and describe multiple different key nodes. The method shown in Figure 2 involves the data message processing process performed by multiple forwarding nodes along the actual forwarding path. Since the processing processes performed by different key nodes have commonalities, for the sake of simplicity, the method shown in Figure 2 focuses on the processing processes performed by two key nodes as an example. Of course, there may be three or more key nodes in the actual forwarding path. The processing processes performed by more key nodes can refer to the processing processes performed by key node A or key node B.

[0348] Key nodes A and B are both nodes that the expected forwarding path passes through. In other words, when planning the forwarding path, the path planner pre-specifies that the business data must be forwarded through key nodes A and B in sequence.

[0349] The method illustrated in Figure 2 involves the processing of data packets by a forwarding node. To distinguish the descriptions, "first data packet" is used to describe the data packet serving as input data, and "second data packet" is used to describe the data packet serving as output results. Both the first data packet and the second data packet carry business data. The destination of the second data packet can be in various situations. In some embodiments, the second data packet is sent to the next forwarding node. In other embodiments, the second data packet is output to the application or operating system of the device and processed independently.

[0350] The method shown in FIG2 relates to an application scenario for achieving fault tolerance for non-critical nodes. For example, in an actual forwarding path of a first data packet, there are at least two critical nodes passing through at least one non-critical node. For example, the order of the at least two critical nodes in the expected forwarding path of the first data packet is the same as the order of the at least two critical nodes in the actual forwarding path of the first data packet, and the sequential positions of the at least two critical nodes in the expected forwarding path are different from the sequential positions of the at least two critical nodes in the actual forwarding path.

[0351] The method shown in FIG2 includes the following steps.

[0352] S210: The path planner determines the expected forwarding path.

[0353] The expected forwarding path includes at least two key nodes. For example, the path planner determines an expected forwarding path P = (r_1, r_2, ..., r_N), where P is a vector consisting of the identity information of each of the N key nodes and the sequential position of each of the N key nodes. R_i is the publicly verifiable identity information of the key node, such as a certificate issued by a CA or an access token issued by an access control server. S210 is also called the path selection step.

[0354] S220: The path planner determines a first vector commitment.

[0355] The first vector commitment indicates a correspondence between the sequential positions of at least two key nodes in the expected forwarding path and the identities of the at least two key nodes. For example, the path planner calculates the first vector commitment based on the identity information of each key node in the expected forwarding path and the sequential position of each key node.

[0356] In some embodiments, the input data used by the path planner to determine the vector commitment includes a desired forwarding path of length N, such as a vector P = (r_1, r_2, ..., r_N). The path planner utilizes the commitment function in the vector commitment mechanism to compute a vector commitment C = commit(P) bound to the desired forwarding path P based on the identity information of each of the N key nodes and the ordinal position of each of the N key nodes. The path planner outputs a commitment C of length k, where k is related to a security parameter lambda.

[0357] 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. Auxiliary data may include, for example, the cryptographic parameters used to calculate the commitment. S220 is also called a path commitment or path initialization step.

[0358] In one possible implementation, before forwarding a data packet, the controller distributes the identity information and auxiliary data required to calculate the forwarding proof to each key node in the expected forwarding path, thereby achieving data pre-distribution. Auxiliary data, for example, includes cryptographic parameters used to calculate the vector commitment.

[0359] Optionally, the path planner sends a first vector commitment to the verification node before forwarding the data packet, thereby delivering the first vector commitment to the verification node via control plane pre-distribution. Alternatively, the path planner sends the first vector commitment to the first key node in the expected forwarding path, which then adds the first vector commitment to the data packet, allowing the first vector commitment to be delivered to the verification node along with the service data.

[0360] S230, key node A obtains data packet A.

[0361] Data packet A carries service data. Optionally, data packet A also carries a vector commitment, so that the verification node can verify the forwarding proof by obtaining the vector commitment carried in the data packet.

[0362] Optionally, data packet A also carries a trusted path identifier, thereby triggering a forwarding proof determination process and / or verification process through the trusted path identifier.

[0363] The source of data message A includes various situations. In some embodiments, all or part of the content of data message A is received from the source host. For example, key node A is the entry PE that communicates with the source host. The source host generates business data and sends the business data to key node A. Key node A generates data message A based on the business data from the source host and the vector commitment. Data message A includes a message header and a payload field. The message header carries the vector commitment, and the payload field carries the business data. In other embodiments, all or part of the content of data message A is generated by key node A itself. For example, key node A itself is the source host, and key node A generates data message A by itself through the application or operating system of this device.

[0364] The following example illustrates the triggering conditions for the subsequent determination of the forwarding proof by key node A.

[0365] In one possible implementation, if key node A determines that the header of data packet A carries a trusted path identifier, it then performs the subsequent steps of obtaining a forwarding certificate based on the identity information and sequential position. If key node A determines that the header of data packet A does not carry a trusted path identifier, it does not perform the subsequent steps of obtaining a forwarding certificate based on the identity information and sequential position and forwards data packet A to the next forwarding node. The trusted path identifier indicates that data packet A needs to be forwarded via a trusted path.

[0366] 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 key node A determines that a data packet does not contain a trusted path identifier, key node A uses the existing forwarding mechanism without calculating a forwarding proof.

[0367] In another possible implementation, after key node A obtains a data message, key node A identifies the service type carried in the data message; in response to identifying that the data message carries data of a specific service type, the step of obtaining a forwarding certificate is executed, thereby realizing a forwarding certificate for a specific service. For example, in response to identifying that the data message contains a network service header (NSH) in the service function chain protocol, key node A 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, key node A 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 the target application, the step of obtaining a forwarding certificate is executed.

[0368] In another possible implementation, after receiving a data packet, key node A, in response to recognizing that the data packet contains the identifier of each node in a specific tunnel, performs the step of obtaining a forwarding proof to verify whether the data packet is forwarded through the specific tunnel. For example, in an SRv6 scenario, key node A performs the step of obtaining a forwarding proof in response to recognizing that the data packet carries a segment list. For another example, in an MPLS scenario, key node A performs the step of obtaining a forwarding proof in response to recognizing that the data packet carries a label stack.

[0369] S240, key node A obtains the sequence position of the verified node in the expected forwarding path and the identity information of the verified node.

[0370] A verified node refers to a forwarding device that is the subject of verification. Verified nodes include, but are not limited to, the current node, its neighboring nodes, and each node from the first forwarding node to the current node. The sequence position of the verified node in the expected forwarding path differs from the sequence position of key node A in the actual forwarding path of data packet A. The identity information of the verified node indicates the identity of key node A.

[0371] In some embodiments, the verified node is the current node. For example, when a data message is transmitted to key node A, the verified node is key node A. Key node A obtains the sequential position of key node A in the expected forwarding path and the identity information of key node A, and obtains a first forwarding certificate based on the sequential position of key node A in the expected forwarding path and the identity information of key node A. By performing path verification on the current node, it is helpful to verify whether the current node is the expected forwarding node or whether the sequential position of the current node is the expected sequential position. In particular, when key node A is the first forwarding node or the source host, it helps to verify the correctness of the source of the data message.

[0372] In some embodiments, the verified node includes a neighbor node of the current node.

[0373] For example, the verified node is the next node of the current node. When the data message is transmitted to key node A, the verified node is key node B. Key node A obtains the sequence position of key node B in the expected forwarding path and the identity information of key node B. Key node A obtains forwarding proof A based on the sequence position of key node B in the expected forwarding path and the identity information of key node B. By performing path verification on the next node, it helps to verify whether the next node is the expected forwarding node or whether the sequence position of the next node is the expected sequence position, thereby reducing the risk of data messages being transmitted to unintended forwarding nodes.

[0374] For example, the verified node is the previous node of the current node. When the data packet is transmitted to key node B, the verified node is key node A. Key node B obtains the sequence position of key node A in the expected forwarding path and the identity information of key node A. Key node B obtains forwarding proof A based on the sequence position of key node A in the expected forwarding path and the identity information of key node A. Path verification of the next node helps to verify whether the next node is the expected forwarding node or whether the sequence position of the next node is the expected sequence position, thereby reducing the risk of data packets being transmitted to unintended forwarding nodes.

[0375] For another example, the verified nodes include the current node and the previous node of the current node. When a data message is transmitted to key node A, the verified nodes include key node A and the previous node of key node A (e.g., the source host). Key node A obtains forwarding proof A based on the sequential position of key node A in the expected forwarding path, the identity information of key node A, the sequential position of the previous node of key node A in the expected forwarding path, and the identity information of the previous node of key node A. Forwarding proof A can verify whether key node A and the previous node of key node A both forward the data message in the expected sequential position. In this case, key node A corresponds to the first forwarding node, and the previous node of key node A corresponds to the second forwarding node.

[0376] In some embodiments, the verified nodes include each node from the first forwarding node to the current node. For example, when a data message is transmitted to a key node B, the verified nodes include key node A and key node B. Key node B obtains the sequential position of key node A in the expected forwarding path, the identity information of key node A, the sequential position of key node B in the expected forwarding path, and the identity information of key node B. Key node B obtains forwarding proof A based on the sequential position of key node A in the expected forwarding path, the identity information of key node A, the sequential position of key node B in the expected forwarding path, and the identity information of key node B. By performing path verification on each node passed through in the first half of the path, it is helpful to verify whether the data message passes through an unexpected forwarding node.

[0377] There are many ways to obtain the sequential position of the verified node in the expected forwarding path. The following two implementation methods are used as examples.

[0378] Method 1 for obtaining the sequential position of the verified node in the expected forwarding path: obtaining the sequential position of the verified node in the expected forwarding path through a data message carrying service data.

[0379] In some embodiments, a predetermined field of data packet A carries the sequential position of the verified node in the expected forwarding path. For example, the header of data packet A carries the sequential position of the verified node in the expected forwarding path. For example, the header of the data packet includes a type-length-value (TLV) or a reserved field, and the TLV or reserved field carries the sequential position of the verified node in the expected forwarding path.

[0380] In some embodiments, key node A further processes the contents of a predetermined field in data packet A to obtain the ordinal position of the verified node in the expected forwarding path. For example, the header of data packet A carries path information, which includes the identifier of each key node in the expected forwarding path. The order of the identifiers of each key node in the path information matches the order of the identifiers of each key node in the expected forwarding path. Key node A determines the ordinal position of the verified node in the expected forwarding path based on the ordinal position of the verified node's identifier in the path information.

[0381] For example, in some implementations of obtaining the sequential position in an SRv6 scenario, data packet A includes a segment routing header (SRH), the SRH includes a segment list, the segment list includes the SID of the key node A, and the key node A obtains the sequential position of the verified node in the expected forwarding path based on the sequential position of the SID of the key node A in the segment list. For example, if the SID of the key node A is the i-th entry in the segment list, the sequential position of the verified node in the expected forwarding path is determined to be i. As an example, the key node A determines the sequential position of the verified node in the expected forwarding path based on the offset of the SID of node_i compared to the segment list[N]. Optionally, the key node A also obtains the relative position of the upstream node on the forwarding path based on the offset of the SID of the upstream node of the key node A compared to the segment list[N].

[0382] In some implementations of obtaining sequential position in an SFC scenario, data packet A includes a path identifier, and key node A obtains the path identifier carried in data packet A. Key node A obtains the sequential position of the verified node in the expected forwarding path based on the path identifier and a corresponding relationship stored by key node A. The corresponding relationship includes the path identifier and the sequential position of the verified node in the expected forwarding path. For example, key node A searches the corresponding relationship based on the path identifier to obtain the sequential position of the node corresponding to the path identifier. The path identifier is used to identify the expected forwarding path. The corresponding relationship is obtained, for example, through control plane pre-distribution.

[0383] Since the sequential position in the expected forwarding path is obtained through the data message, the sequential position in the expected forwarding path can be obtained relatively quickly, saving the performance overhead and computing overhead of the forwarding device in obtaining the sequential position in the expected forwarding path through table lookup matching, and also saving the storage space occupied in the forwarding device by obtaining the sequential position in the expected forwarding path through table lookup matching.

[0384] Method 2 for obtaining the sequence position of the expected forwarding path: obtaining the sequence position in the expected forwarding path by pre-distribution on the control plane.

[0385] Control plane pre-distribution is primarily based on interaction between the path planner and the forwarding nodes. For example, when determining the expected forwarding path, the path planner determines the sequential position of the verified node in the expected forwarding path. The path planner sends the sequential position of the verified node in the expected forwarding path to key node A. Key node A receives the sequential position of the verified node in the expected forwarding path from the path planner.

[0386] In some embodiments, the action of sending the sequence position of the verified node in the expected forwarding path is implemented based on a management plane protocol. For example, the path planning direction sends a management plane protocol message, such as a Network Configuration Protocol (NETCONF) message, a Representational State Transfer Configuration (RESTCONF) message, or a Simple Network Management Protocol (SNMP) message, to key node A. The management plane protocol message carries the sequence position of the verified node in the expected forwarding path. Key node A receives the management plane protocol message and obtains the sequence position of the node in the expected forwarding path carried in the management plane protocol message. For another example, the path planning direction sends a control plane protocol message such as a Border Gateway Protocol (BGP) message, a Path Computation Element Protocol (PCEP) message, or a Border Gateway Protocol Flow Spec (BGP flow specification, BGP flow spec or BGP FS) message to key node A. The control plane protocol message carries the sequence position of the verified node in the expected forwarding path. Key node A receives the control plane protocol message and obtains the sequence position of the node in the expected forwarding path carried in the control plane protocol message. For another example, the path planning direction sends an application layer protocol message such as an APN message or a Hypertext Transfer Protocol (HTTP) message to key node A. The application layer protocol message carries the sequence position of the verified node in the expected forwarding path.

[0387] In other embodiments, the controller sends the sequential position of each key node upstream of the key node on the expected forwarding path to each key node on the expected forwarding path. For example, the controller sends the sequential position of each key node in the expected forwarding path from the first key node to key node i to key node i.

[0388] In other embodiments, the network administrator pre-configures the sequential position of each key node on the expected forwarding path. Optionally, when using the MP mode to calculate multi-point forwarding proofs, the network administrator also configures the sequential position of each key node upstream of each key node on the expected forwarding path. For example, if the configuration information stored by key node i includes the relative position of each key node from key node 1 to key node i in the forwarding path, key node i obtains the relative position of each key node from key node 1 to key node i from the configuration information.

[0389] There are many ways to obtain the identity information of the verified node. The following two implementation methods are used as examples.

[0390] Method 1 for obtaining the identity information of the verified node: Obtain the identity information of the verified node through a data message carrying business data.

[0391] In some embodiments, a predetermined field of data packet A carries the identity information of the node being verified. For example, the header of data packet A carries the identity information of the node being verified. For example, the header of the data packet includes a TLV or a reserved field, and the TLV or reserved field carries the identity information of the node being verified.

[0392] As an example, the verified node is key node A, the destination address field of the IP header of data packet A includes the IP address of key node A, and key node A obtains the IP address of key node A from the destination address field of the IP header of data packet A.

[0393] For example, when using the OP mode to calculate a single-point forwarding proof, data packet A carries the identity information of key node A. Key node A obtains the identity information of this node carried in data packet A to calculate the OP. For another example, when using the MP mode to calculate a multi-point forwarding proof, data packet A also carries the identity information of a second forwarding node. Key node A also obtains the identity information of the second forwarding node carried in data packet A to calculate the MP.

[0394] For example, in some implementations of obtaining the identity information of the verified node in the SRv6 scenario, data packet A includes an SRH, the SRH includes a segment list, the segment list includes the SID of each node in the expected forwarding path, and the key node A obtains the SID of the verified node carried by the segment list to obtain the identity information of the verified node.

[0395] The second method for obtaining the identity information of the verified node is to obtain the sequential position in the expected forwarding path through control plane pre-distribution.

[0396] For example, when determining the expected forwarding path, the path planner determines the identity information of the verified node. The path planner sends the identity information of the verified node to the key node A. The key node A receives the identity information from the path planner.

[0397] S250, key node A obtains node-level forwarding proof A based on the sequential position of the verified node in the expected forwarding path and the identity information of the verified node.

[0398] The forwarding proof A is used to prove that the verified node is in the sequential position of the verified node in the expected forwarding path.

[0399] For example, the verified node is the current node (key node A), and key node A obtains device-level forwarding proof A based on the sequential position of key node A in the expected forwarding path and the identity information of key node A, so as to verify whether key node A is in the expected order and whether key node A is the expected node based on forwarding proof A.

[0400] For example, the verified node is the next node of the current node (critical node B), and critical node A obtains forwarding proof A based on the sequential position of critical node B in the expected forwarding path and the identity information of critical node B, so as to verify whether the data message will be sent to the node with the expected sequence and the expected correct identity based on forwarding proof A.

[0401] S260, key node A sends forwarding proof A to the verification node, and sends data message B to key node B.

[0402] Key node A sends forwarding proof A to the verification node, allowing the verification node to verify the sequence position and identity of key node A based on forwarding proof A. Data packet B carries the business data in data packet A. By sending data packet B to key node B, the business data is transferred from this node to the next key node that the path planner expects to pass through.

[0403] When the key node B also serves as the verification node, or the key node downstream of the key node B (for example, the tail node at the end of the path) also serves as the verification node, the forwarding proof and the business data are carried by the same data message, for example. For example, the verification node is the key node B, and the key node B is the key node downstream of the key node A in the expected forwarding path. The key node A obtains the data message B based on the business data carried in the data message A and the forwarding proof of the verified node (for example, the forwarding proof A of the key node A). The payload field of the data message B carries the business data carried in the data message A. The message header of the data message B carries the forwarding proof of the verified node. The key node A sends the data message B to the key node B. In this case, the key node A corresponds to the first forwarding node, the key node B corresponds to the third forwarding node, the data message A corresponds to the first data message, and the data message B corresponds to the second data message.

[0404] When the verification node is deployed outside the forwarding path, key node A constructs a separate message to carry the forwarding proof of the verified node. For example, key node A generates a first message, which can be a control plane message, a management plane message, or a data message, and carries the forwarding proof of the verified node. Key node A sends the first message to the verification node.

[0405] S320 , key node B receives data message B from key node A.

[0406] Key node B is a key node upstream of key node A in the forwarding path. Key node B is an intermediate node or a tail node.

[0407] S340, key node B obtains the sequence position of the verified node in the expected forwarding path and the identity information of the verified node.

[0408] S350, the key node B obtains the device-level forwarding proof B based on the sequential position of the verified node in the expected forwarding path and the identity information of the verified node.

[0409] For example, the verified node is the current node (critical node B), and critical node B obtains the device-level forwarding proof B based on the sequential position of critical node B in the expected forwarding path and the identity information of critical node B, so as to verify whether critical node B forwards the data message in the expected sequential position based on the forwarding proof B.

[0410] For example, the verified node is the previous node of the current node (key node A), and key node B obtains forwarding proof B based on the sequential position of key node A in the expected forwarding path and the identity information of key node A, so as to verify whether the data message comes from a node in the expected order and with the correct identity based on forwarding proof B.

[0411] For example, the nodes to be verified include the current node (key node B) and the previous node of the current node (key node A). Key node B obtains forwarding proof B based on the sequential position of key node A in the expected forwarding path, the identity information of key node A, the sequential position of key node B in the expected forwarding path, and the identity information of key node B. In this way, based on forwarding proof B, it is verified whether key node A forwards data packets at the expected sequential position and whether key node B forwards data packets at the expected sequential position. In this case, key node B corresponds to the first forwarding node, and key node A corresponds to the second forwarding node.

[0412] For example, the verified node is the next node of the current node (key node C), and the key node B obtains the forwarding proof B based on the sequential position of the key node C in the expected forwarding path and the identity information of the key node C, so as to verify whether the data message will be sent to the node with the expected sequence and the expected correct identity based on the forwarding proof B.

[0413] For example, the verified nodes include the current node (critical node B) and the next node of the current node (critical node C). The critical node B obtains the forwarding proof B based on the sequential position of the critical node B in the expected forwarding path, the identity information of the critical node B, the sequential position of the critical node C in the expected forwarding path, and the identity information of the critical node C, so as to verify whether the critical node B forwards the data message in the expected sequential position and whether the data message will be sent to a node whose sequence is consistent with the expectations and whose identity is correct as expected based on the forwarding proof B.

[0414] For example, the verified node is each node passed by the first half of the path, and the key node B obtains the forwarding proof B based on the sequential position of the key node A in the expected forwarding path, the identity information of the key node A, the sequential position of the key node B in the expected forwarding path, and the identity information of the key node B.

[0415] S360, key node B sends forwarding certificate B of key node B to the verification node, and sends data message C to key node C.

[0416] In some embodiments, the critical node B verifies the correctness of the source of the data packet B. If the source correctness verification of the data packet B passes, the critical node B further performs the subsequent forwarding proof determination process. If the source correctness verification of the data packet B fails, the critical node B does not need to perform the subsequent forwarding proof determination process, and the critical node B can directly discard the data packet.

[0417] In some embodiments of verifying the correctness of the source of data packet B by key node B, key node B verifies whether data packet B originates from key node A, which is the previous key node of key node B in the expected forwarding path. For example, key node B verifies the correctness of key node A's single-point forwarding proof OP_i-1 carried in data packet B based on key node A's identity information, key node A's expected sequence position, and node-level vector commitment, thereby verifying whether data packet B's previous hop is correct. In another example, key node B verifies the correctness of key node A's multi-point forwarding proof MP_i-1 carried in data packet B based on key node A's identity information, key node A's expected sequence position, key node B's identity information, key node B's expected sequence position, and node-level vector commitment, thereby verifying whether the forwarding path segment traversed by data packet B is correct. 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.

[0418] In some embodiments, a key node also serves as a verification node. For example, the verification node is key node C, which is a key node located downstream of key node B in the expected forwarding path. Key node B obtains data packet C based on received data packet B and forwarding proof B of key node B. Key node B sends data packet C to key node C. Data packet C includes the payload of data packet B and forwarding proof B of key node B. In this case, key node B corresponds to the first forwarding node, key node C corresponds to the third forwarding node and the verification node, data packet B corresponds to the first data packet, and data packet C corresponds to the second data packet.

[0419] At step S270, the verifying node obtains a forwarding proof, a device-level vector commitment, the identity information of the verified node, and the ordinal position of the verified node in the expected forwarding path. The verified node is included in at least two key nodes. The identity information of the verified node indicates the identity of the verified node. The forwarding proof of the verified node is used to prove that the verified node is in the ordinal position of the verified node in the expected forwarding path.

[0420] In one possible implementation, in S250 and S260, a forwarding proof related to a single verified node is obtained based on a single-point open function, and in S270, the forwarding proof related to the single verified node is verified based on a single-point verification function, thereby verifying the proof of the single node. In another possible implementation, in S250 and S260, forwarding proofs related to multiple verified nodes are verified based on a batch verification function, and in S270, forwarding proofs related to multiple verified nodes are obtained based on a multi-point open function, thereby verifying multiple nodes in the path at one time.

[0421] Of course, the three functions "commit," "open," and "verify" are merely examples of functions that can be used to implement the acquisition and verification of forwarding proofs. In another possible implementation, other types of functions in vector commitment are used to implement the acquisition and verification of forwarding proofs. For example, in S250 and S260, a witness creation function ("create witness" (equivalent to the "open" function) is used to obtain a forwarding proof, and in S270, a verification calculation function ("verify eval" (equivalent to the "verify" function) is used to obtain a forwarding proof. In another example, in S250 and S260, a batch creation function ("create witness batch" (equivalent to the "batch open" function) is used to obtain multi-point forwarding proofs, and in S270, a batch verification calculation function ("verify eval batch" (equivalent to the "batch verify" function) is used to verify the multi-point forwarding proofs.

[0422] S280, the verification node verifies the forwarding proof A and / or the forwarding proof B based on the device-level vector commitment, the identity information of the verified node, and the sequential position of the verified node in the expected forwarding path.

[0423] In some embodiments, the verification node uses the verification function in the vector commitment mechanism to perform operations based on the device-level vector commitment, the identity information of the verified node, the sequential position of the verified node in the expected forwarding path, and the forwarding proof of the verified node.

[0424] For example, if the device-level vector commitment, the identity information of the verified node, the sequential position of the verified node in the expected forwarding path, and the forwarding proof of the verified node match each other, and the output result of the verification function is 1, the verifying node determines that the forwarding proof of the verified node has been verified, indicating that the verified node is indeed the key node expected by the path planner (the expected forwarding path passes through the verified node) and the sequential position of the verified node in the actual forwarding path meets the requirements of the expected forwarding path.

[0425] Conversely, if the device-level vector commitment, the identity information of the verified node, the sequence position of the verified node in the expected forwarding path, and the forwarding proof of the verified node do not match, the output of the verification function is 0, and the forwarding proof of the verified node is verified successfully, indicating that the verified node is not the key node expected by the path planner (the expected forwarding path does not pass through the verified node) or the sequence position of the verified node in the actual forwarding path does not meet the requirements of the expected forwarding path.

[0426] For example, the verification node verifies the forwarding proof A from the key node A based on the device-level vector commitment, the identity information of the key node A, and the sequential position of the key node A in the expected forwarding path to determine whether the identity and sequential position of the key node A meet expectations.

[0427] For another example, the verification node verifies the forwarding proof from key node B based on the device-level vector commitment, the identity information of key node B, and the sequential position of key node B in the expected forwarding path, so as to determine whether the identity and sequential position of key node B meet expectations. For another example, the verification node verifies the forwarding proof from key node B based on the device-level vector commitment, the identity information of key node A, the sequential position of key node A in the expected forwarding path, the identity information of key node B, and the sequential position of key node B in the expected forwarding path, so as to determine whether the identity and sequential position of key node A and the identity and sequential position of key node B both meet expectations.

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

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

[0430] 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 information of key nodes and their expected sequential positions. This makes the vector commitments related to both the identity information and the expected sequential positions of key nodes. Vector commitments can reflect the correspondence between the expected sequential positions of key nodes on the forwarding path and their identity information. Therefore, when verifying a forwarding proof based on a vector commitment, the identity information, expected sequential position, and forwarding proof must correspond to each other for verification to pass. A forwarding proof obtained without a correspondence between the identity information and the expected sequential position will fail verification. In other words, only key node i at expected sequential position i can calculate the correct forwarding proof p_i, which cannot be forged by others.

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

[0432] 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 the 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 the 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 processes, significantly improving efficiency and making them more suitable for scenarios involving a large number of nodes in the forwarding path. Furthermore, single-point commitments cannot bind the identity information of key nodes to their expected sequential positions, requiring other methods to achieve position binding, such as using a list to record the expected sequential positions. Vector commitments, however, offer position binding capabilities, allowing for direct binding of multiple identities to their corresponding expected sequential positions, simplifying the verification process.

[0433] The method provided in this embodiment achieves position binding of the forwarding proof by combining the position of the forwarding node on the forwarding path and the identity of the forwarding node to obtain the forwarding proof. 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.

[0434] Furthermore, since the key nodes in the expected forwarding path use the sequential positions in the expected forwarding path to calculate the forwarding proof, and the vector commitment and the sequential positions of the key nodes in the expected forwarding path are used to verify the forwarding proof, the sequential positions based on which the vector commitment is calculated are consistent with the sequential positions based on which the forwarding proof is calculated, thereby achieving fault tolerance for non-critical nodes, thereby reducing the risk of interruption of business data transmission or output of alarms due to failure of the forwarding proof verification based on the vector commitment.

[0435] In some embodiments, the key node not only sends the forwarding proof of the node to the verification node, but also sends the sequential position of the node in the actual forwarding path to the verification node, so as to achieve the recordability of non-key nodes.

[0436] For example, key node A obtains the sequence position of the first forwarding node in the actual forwarding path as 1 based on data packet A; key node A sends the sequence position 1 to the verification node; key node B obtains the sequence position of key node B in the actual forwarding path as 4 based on data packet B, and key node B sends the sequence position 4 to the verification node; key node C obtains the sequence position of key node C in the actual forwarding path as 6 based on data packet C, and key node C sends the sequence position 6 to the verification node.

[0437] Regarding how to transmit the actual sequential positions of key nodes to the verification nodes, this embodiment uses two methods as examples to illustrate.

[0438] The actual sequence position transmission method 1: The actual sequence position of the key node is transmitted together with the business data

[0439] Transmission mode 1 is equivalent to the in-band mode. For example, when forwarding a data message, a key node adds its sequence position in the actual forwarding path to the data message, forwarding the data message containing the service data and the actual sequence position of the node. This allows the actual sequence position of the node to be transmitted along with the service data to the next forwarding node after the key node. For example, a data message includes a message header and a payload field encapsulated within the message header. The message header carries the actual sequence position of the key node, and the payload field carries the service data.

[0440] In some embodiments, the actual sequence position and forwarding proof are transmitted to the verification node along with the business data. For example, the verification node is key node B, which is located downstream of key node A in the expected forwarding path. Key node A obtains data message B based on data message A, the forwarding proof of key node A, and the sequential position of key node A in the actual forwarding path. Data message B includes the payload of data message A, the forwarding proof of key node A, and the sequential position of key node A in the actual forwarding path. Key node A sends data message B to key node B. In this case, key node A corresponds to the first forwarding node, key node B corresponds to the third forwarding node, data message A corresponds to the first data message, and data message B corresponds to the second data message.

[0441] In another example, the verification node is key node C, which is located downstream of key node B in the expected forwarding path. Key node B obtains data message C based on data message B, the forwarding proof of key node B, and the sequential position of key node B in the actual forwarding path. Data message C includes the payload of data message B, the forwarding proof of key node B, the sequential position of key node A in the actual forwarding path, and the sequential position of key node B in the actual forwarding path. Key node B sends data message C to forwarding node C. In this case, key node B corresponds to the first forwarding node, key node C corresponds to the third forwarding node, data message B corresponds to the first data message, and data message C corresponds to the second data message.

[0442] Since the actual sequence position and forwarding proof are carried in the same data packet and sent to the key node downstream of the forwarding path, in the mode where the key node also serves as the verification node (observer), there is no need to construct independent data packets to transmit the actual sequence position and forwarding proof respectively. Therefore, the overall transmission overhead of the actual sequence position and forwarding proof is relatively small. The verification node can obtain the actual sequence position of the key node and the forwarding proof of the key node at the same time by parsing a data packet. Therefore, the verification node is more efficient in obtaining the actual sequence position of the key node and the forwarding proof of the key node.

[0443] In some embodiments, data packet A includes a first position list, the first position list includes the sequential positions of key nodes located upstream of the first forwarding node in the expected forwarding path in the actual forwarding path, and data packet B includes a second position list, the second position list includes the first position list and the sequential positions of the first forwarding node in the actual forwarding path.

[0444] The following examples illustrate the actual sequential position of key nodes, forwarding proof, and the position of vector commitment in the message.

[0445] In the case of transmitting data based on the IPv6 protocol, in one possible implementation, the actual sequence position, forwarding proof, and vector commitment of key nodes are carried through the IPv6 extension header. For example, the actual sequence position, forwarding proof, and vector commitment of key nodes are carried through the segment routing header (SRH). In another example, the actual sequence position, forwarding proof, and vector commitment of key nodes are carried through the hop-by-hop options header (HBH). In another example, the actual sequence position, forwarding proof, and vector commitment of key nodes are carried through the destination options header (DOH). SRH, HBH, and DOH are specific examples of three IPv6 extension headers that can carry forwarding proof.

[0446] Optionally, the forwarding proof is carried via a TLV in the IPv6 extension header. For example, the actual sequence position of key nodes, the forwarding proof, and the vector commitment can be carried via a TLV in the SRH. Alternatively, the actual sequence position of key nodes, the forwarding proof, and the vector commitment can be carried via a TLV in the HBH. Alternatively, the actual sequence position of key nodes, the forwarding proof, and the vector commitment can be carried via a TLV in the DOH.

[0447] When transmitting data based on the APN6 protocol, in one possible implementation, the APN header carries the actual sequence position, forwarding proof, and vector commitment of key nodes. For example, the APN header carries the actual sequence position, forwarding proof, and vector commitment of key nodes. When transmitting data based on the VxLAN protocol, in one possible implementation, the VxLAN header carries the actual sequence position, forwarding proof, and vector commitment of key nodes. This is applicable to scenarios such as virtualized networks based on the VxLAN protocol or cross-data center interconnections, and provides data source verification within the VxLAN tunnel. When transmitting data based on the IPSec protocol, in one possible implementation, the IPSec header carries the actual sequence position, forwarding proof, and vector commitment of key nodes, enabling data source verification and secure transmission under the IPSec protocol. This approach is applicable to scenarios such as virtual private networks (VPNs) or secure communications based on the IPSec protocol, providing data source verification within the IPSec tunnel. When transmitting data based on the MPLS protocol, in one possible implementation, the MPLS header carries the actual sequence position, forwarding proof, and vector commitment of key nodes. 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 actual sequential position of key nodes, the forwarding proof, and the vector commitment are carried by the metadata field in the NSH.

[0448] In one possible implementation, the actual sequential position of the key node, the forwarding proof, and the vector commitment are carried in different fields in the same message header.

[0449] Exemplarily, data packet_i+1 includes an IPv6 extension header, wherein the IPv6 extension header includes a forwarding proof of forwarding node_i and the vector commitment. For example, the IPv6 extension header of data packet_i+1 includes an SRH, wherein the SRH includes a first TLV, a second TLV, and a third TLV, wherein the first TLV of the SRH includes the forwarding proof of forwarding node_i, and the second TLV of the SRH includes the vector commitment. The third TLV of the SRH includes the actual sequential position of the key node; or, the IPv6 extension header of the data packet _i+1 includes an APN header, the APN header includes an APN ID, and the APN ID includes the forwarding proof of the forwarding node _i and the vector commitment; or, the IPv6 extension header of the data packet _i+1 includes a DOH, the DOH includes a first TLV, a second TLV, and a third TLV, the first TLV of the DOH includes the forwarding proof of the forwarding node _i, the second TLV of the DOH includes the vector commitment, and the third TLV of the DOH includes the actual sequential position of the key node; or, the IPv6 extension header of the data packet _i+1 includes an HBH, the HBH includes a first TLV, a second TLV, and a third TLV, the first TLV of the HBH includes the forwarding proof of the forwarding node _i, the second TLV of the HBH includes the vector commitment, and the third TLV of the HBH includes the actual sequential position of the key node.

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

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

[0452] In some embodiments, after calculating a forwarding proof, each key node replaces the forwarding proof carried in the data packet header with the forwarding proof calculated by that node. For example, key node B receives data packet A carrying forwarding proof A. After calculating forwarding proof B, key node B replaces the forwarding proof carried in data packet A with forwarding proof B, thereby obtaining data packet B. Data packet B does not include forwarding proof A but includes forwarding proof B. Similarly, key node C receives data packet B carrying forwarding proof B. After calculating forwarding proof C, key node C replaces the forwarding proof carried in data packet A with forwarding proof C, thereby obtaining data packet C. Data packet C does not include forwarding proof B but includes forwarding proof C. By replacing the forwarding proof calculated by the previous node with the forwarding proof calculated by each key node, a data packet only needs to carry a single forwarding proof, avoiding the excessive data volume caused by the data packet needing to carry the forwarding proofs of each key node along the way, thereby saving data packet transmission overhead and bandwidth resources.

[0453] In other embodiments, after calculating and obtaining the forwarding proof, each key node adds the forwarding proof calculated by this node to the message header of the data message. For example, key node B receives data message A carrying forwarding proof A. After key node B calculates and obtains forwarding proof B, it adds forwarding proof B after forwarding proof A carried in the data message, thereby obtaining data message B. Data message B includes forwarding proof A and forwarding proof B. Similarly, key node C receives data message B carrying forwarding proof A and forwarding proof B. After key node C calculates and obtains forwarding proof C, it adds forwarding proof C after forwarding proof A and forwarding proof B carried in the data message, thereby obtaining data message C. Data message C includes forwarding proof A, forwarding proof B, and forwarding proof C. By each key node continuing to add its own forwarding proof based on the forwarding proof calculated by the previous node, the data message can carry the forwarding proof of each key node along the way, and can verify the identity and sequential position of each key node that the data message has passed, thereby enhancing its credibility.

[0454] The second method of transmitting the actual sequence position is to construct an independent message to notify the actual sequence position of the key nodes.

[0455] The first forwarding node generates a notification message, which carries the forwarding certificate of the first forwarding node and the sequence position of the first forwarding node in the actual forwarding path; the first forwarding node sends the notification message to the verification node.

[0456] In some implementations, the notification message is a management plane protocol message. For example, the notification message is a NETCONF message, which carries the forwarding certificate of the first forwarding node and the sequence position of the first forwarding node in the actual forwarding path.

[0457] In some embodiments, the notification message is a control plane protocol message. For example, the notification message is a control plane protocol message based on a Border Gateway Protocol Flow Spec (BGP Flow Specification, BGP Flow Spec or BGP FS), a Path Computation Element Protocol (PCEP), a BGP Monitoring Protocol (BGP Monitoring Protocol, BMP), a NetStream protocol, or a Border Gateway Protocol (BGP).

[0458] In some embodiments, the notification message is an application layer protocol message including a Hypertext Transfer Protocol (HTTP) message, wherein the payload field in the HTTP message includes the forwarding certificate of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path.

[0459] In some embodiments, the first forwarding node is the last key node in the expected forwarding path, and the second forwarding nodes include all key nodes in the expected forwarding path except the first forwarding node.

[0460] The present application provides three verification modes for forwarding proofs. The methods for determining and transmitting forwarding proofs vary depending on the verification mode. The following examples further illustrate these methods using the three verification modes. Both the real-time verification mode and the on-path verification mode are further subdivided into single-point and multi-point sub-modes. The endpoint verification mode has a multi-point mode instead of a single-point mode.

[0461] Verification mode 1: real-time verification (postcard) mode

[0462] The real-time nature of real-time verification refers to the time at which the forwarding proof is verified relative to the time at which the data packet is received. In real-time verification mode, each key node in the actual forwarding path calculates a forwarding proof as it processes a data packet and sends it to the verification node out-of-band, meaning it is not sent along the actual forwarding path of the service data. Verification nodes deployed outside the actual forwarding path verify the forwarding proof in real time; key nodes do not need to verify the forwarding proof.

[0463] The real-time verification mode specifically includes a verification mode for single-point forwarding proof (OP sub-mode for short) and a verification sub-mode for multi-point forwarding proof (MP sub-mode for short). When adopting the verification mode for single-point proof in the real-time verification mode, each key node calculates the single-point forwarding proof of this node and sends the single-point forwarding proof. When calculating the single-point forwarding proof, the identity information of the previous key node or multiple upstream key nodes is not required. When adopting the verification mode for multi-point proof in the real-time verification mode, each key node obtains the identity information of the upstream key node r_1 to the key node r_i-1 through control plane pre-distribution, data packets carrying business data, or other means.

[0464] When using real-time verification mode, the sequence positions used by key nodes to determine forwarding proofs and by verification nodes to verify forwarding proofs are the sequence positions in the expected forwarding path, such as 1, 2, 3, and 4. The sequence positions used by both are not the sequence positions in the actual forwarding path. The sequence positions of key nodes in the actual forwarding path do not participate in the calculation or verification of forwarding proofs. The sequence positions of key nodes in the actual forwarding path are used for evidence storage.

[0465] In some embodiments, when a real-time verification mode is adopted, whether a verification mode for single-point proof or a verification mode for multi-point proof is adopted, the key node sends the sequential position of the node in the actual forwarding path to the verification node to achieve record keeping of non-key nodes.

[0466] For example, please refer to Figure 3, which shows an architecture diagram of a trusted path network system provided by an embodiment of the present application. The system 10 shown in Figure 3 includes a controller, a key node, and a verification node. In the system 10 shown in Figure 3, the expected forwarding path passes through four key nodes. Key node 1 is the head node, key node 4 is the tail node, and key node 2 and key node 3 are both intermediate nodes. The verification node is connected to key node 1, key node 2, key node 3, and key node 4 in Figure 3 through a communication network. In some embodiments, the verification node is the controller in Figure 3. Optionally, the controller and the verification node in the system shown in Figure 3 are integrated on the same device. In other words, the controller not only performs the steps of obtaining vector commitment and sending vector commitment, but also performs the step of verifying the forwarding proof.

[0467] During the data transmission process performed by key node 1, if key node 1 is a key node, key node 1 constructs a new data message based on the payload data. The message header of the data message carries the trusted path identifier and path information. The path information carries the identity information of each key node in the expected forwarding path. The payload field of the data message carries the payload data. Key node 1 uses the open function to calculate the single-point forwarding proof OP_1 of this node; alternatively, key node 1 uses the batchopen function to calculate the multi-point forwarding proof MP_1 of this node; key node 1 obtains the sequential position of this node in the actual forwarding path; key node 1 sends the sequential position of this node in the actual forwarding path and the forwarding proof of this node to the verification node outside the actual forwarding path, and key node 1 forwards the data message to the second key node.

[0468] During the data transmission process performed by the i-th key node, the i-th key node receives the data packet _i from the previous key node. The message header of the data packet _i carries a trusted path identifier and path information. The i-th key node verifies the correctness of the source of the data packet _i. If the source verification of the data packet _i passes, the i-th key node calculates the forwarding proof of this node; and the i-th key node obtains the sequence position of this node in the actual forwarding path; the i-th key node sends the sequence position of this node in the actual forwarding path and the forwarding proof of this node to the verification node located outside the actual forwarding path, and the i-th key node forwards the data packet to the next key node i+1. In addition, if the source verification of the data packet _i fails, the i-th key node does not need to calculate the forwarding proof and discards the data packet _i.

[0469] During the real-time verification process performed by the verification node, the verification node receives the forwarding proof from the i-th key node and verifies the forwarding proof of the i-th key node based on the vector commitment.

[0470] When using a single-point forwarding proof, during the forwarding proof calculation process, the i-th key node uses its own identity information r_i and its ordinal position i in the expected forwarding path as input to calculate a single-point forwarding proof OP_i. The i-th key node sends the single-point forwarding proof OP_i and its ordinal position in the actual forwarding path to the verification node. Based on the input vector commitment C, the i-th key node's identity information r_i, the i-th key node's ordinal position i in the expected forwarding path, and the single-point forwarding proof OP_i calculated by the i-th key node, the verification node executes the verification function Verify(C,i,r_i,OP_i) in the vector commitment mechanism, verifying that the identity information of the i-th key node with ordinal position is r_i. Where C represents the vector commitment, i represents the ordinal position in the expected forwarding path, r_i represents the identity information of the i-th key node, and OP_i represents the single-point forwarding proof calculated by the i-th key node.

[0471] When using a multi-point forwarding proof, the i-th key node computes a multi-point forwarding proof MP_i using the identity information of each node from the first key node r_1 to the current node r_i and the sequential position of each node in the expected forwarding path from the first key node r_1 to the current node r_i as input. The i-th key node sends the multi-point forwarding proof MP_i, along with its own sequential position in the actual forwarding path, to a verification node located outside the actual forwarding path. The verification node then executes the batch verification function batch verify(C, B, r_B, MP_i) in the vector commitment mechanism, where B = (r_1, r_2, …, r_i), based on the input vector commitment C, the identity information r_1 to r_i of each key node from the first to the i-th key node, the sequential position i of each key node in the expected forwarding path, and the multi-point forwarding proof MP_i of the i-th key node. Where C represents the vector commitment, r_B represents the set of identity information of each node from the first key node r_1 to the current node r_i, B represents the set of sequential positions of each node from the first key node r_1 to the i-th key node r_i in the expected forwarding path, and MP_i represents the multi-point forwarding proof calculated by the i-th key node.

[0472] For example, when using real-time verification mode, whether for single-point or multi-point verification, a key node constructs a separate datagram during service data transmission. This datagram carries the node's actual sequential position and its forwarding proof, without carrying any service data. The key node then sends this datagram externally. For example, when service data is transmitted to the i-th key node, the datagram sent by the i-th key node includes the following content.

[0473] The real-time verification mode provided by this embodiment is that each key node that the data message passes through during the actual transmission process calculates the forwarding proof of this node and sends the forwarding proof of this node to the outside, so that the identity and sequential position of each key node that the data message actually passes through can be verified, thereby ensuring security hop by hop. In addition, since any key node can perform the calculation of the forwarding proof and send the forwarding proof after receiving the data message, the observer can obtain and verify the forwarding proof in real time. Compared with the end point verification mode, there is no need to wait until the data message is transmitted to the last key node before verification, realizing real-time transparent tracking of the data transmission process, and the attack window is smaller. In addition, since the forwarding proof and the sequential position in the actual forwarding path are sent to the external verification node (observer), the public audit of the forwarding proof and the sequential position in the actual forwarding path is supported. It can be seen that the real-time verification mode can significantly improve the security of the data transmission process.

[0474] Verification mode 2: Passport mode

[0475] In the on-path verification mode, when each key node i in the actual forwarding path processes a data message, the key node i calculates the forwarding proof p_i of this node and adds the forwarding proof to the data message transmitted on the path. Key node i sends data message _i+1, and data message _i+1 includes the forwarding proof p_i. Since the sent data message carries the forwarding proof, the forwarding proof is forwarded along with the data message to the next key node i+1, so that the next key node can verify the forwarding proof p_i. In addition, each key node i also acts as an observer. Before calculating its own forwarding proof p_i, key node i verifies the forwarding proof p_i-1 of the previous key node i-1, thereby reducing the risk of incorrect data message source. The forwarding proof p_i is, for example, a single-point proof OP or a multi-point proof MP.

[0476] The on-path verification mode specifically includes a verification mode for single-point forwarding proof (abbreviated as OP sub-mode) and a verification sub-mode for multi-point forwarding proof (abbreviated as MP sub-mode).

[0477] When using the single-point proof verification mode in the on-link verification mode, each key node calculates its own single-point forwarding proof OP_i and adds it to the data message, so that the single-point forwarding proof OP_i and the business data are transmitted to the next key node together. When calculating the single-point forwarding proof, the identity information of the previous key node or multiple upstream key nodes is not required.

[0478] When using the multi-point proof verification mode within the on-link verification mode, each key node obtains the identity information from the first key node r_1 to the previous key node r_i-1 through control plane pre-distribution, data packets carrying service data, or other means. Each key node calculates its own multi-point forwarding proof MP_i based on the identity information and sequential position of each node from the first key node r_1 to the current node, and adds the single-point forwarding proof MP_i to the data packet, transmitting the single-point forwarding proof MP_i along with the service data to the next key node.

[0479] Optionally, when adopting the in-path verification mode, regardless of whether the verification mode for single-point proof or the verification mode for multi-point proof is adopted, the first key node adds an actual sequence position list in the data message, and the actual sequence position list carried by each key node i in the data message adds the sequence position of this node in the actual forwarding path, so as to record the actual sequence position of each key node in the first half of the path that the data message has passed.

[0480] For example, referring to Figure 4 , forwarding node_2, forwarding node_3, and key node 4 are all verification nodes. Forwarding node_2 verifies the forwarding proof p_1 of key node 1. Forwarding node_3 verifies the forwarding proof p_2 of forwarding node_2. Key node 4 verifies the forwarding proof p_3 of forwarding node_3 in Figure 3.

[0481] During data transmission at key node 1, if key node 1 is a key node, key node 1 uses the open function to calculate its single-point forwarding proof OP_1; alternatively, key node 1 uses the batchopen function to calculate its multi-point forwarding proof MP_1. Key node 1 obtains its ordinal position in the actual forwarding path. Key node 1 constructs a new data packet based on the vector commitment, payload data, key node 1's forwarding proof, and key node 1's ordinal position in the actual forwarding path. The data packet's header carries a trusted path identifier, vector commitment, key node 1's forwarding proof, path information, and an actual ordinal position list. The path information carries the identity information of each key node in the expected forwarding path, and the data packet's payload field carries the payload data. The actual ordinal position list includes key node 1's ordinal position in the actual forwarding path.

[0482] During data transmission by the i-th key node, the i-th key node receives data packet _i from the (i-1)-th key node. The header of data packet _i carries a trusted path identifier, path information, and the forwarding proof of the (i-1)-th key node. The path information carries the identity information of each key node in the expected forwarding path. The i-th key node verifies the forwarding proof of the (i-1)-th key node carried in the data packet. If the forwarding proof of the (i-1)-th key node passes verification, the source verification of data packet _i passes. The i-th key node calculates the forwarding proof and replaces the forwarding proof of the previous key node carried in the header of data packet _i with the forwarding proof calculated by this node. In addition, the i-th key node adds its own sequence position in the actual forwarding path to the actual sequence position list carried by data packet _i, thereby obtaining data packet _i+1. Data packet _i+1 carries the payload data in data packet _i, the actual sequence position list, and the forwarding proof of the i-th key node. The i-th key node forwards the data message to the (i+1)-th key node. In addition, if the forwarding proof verification of the (i-1)-th key node fails, the i-th key node does not need to calculate the forwarding proof and discards the data message _i.

[0483] When using a single-point forwarding proof, in the process of verifying the forwarding proof of the previous key node, the i-th key node verifies the single-point forwarding proof OP_i-1 of the (i-1)th key node carried in the header of the data message based on the identity information of the (i-1)th key node and the sequential position of the (i-1)th key node in the expected forwarding path; in the process of calculating the forwarding proof of this node, the i-th key node uses the public identity r_i of this node and the sequential position i of this node in the expected forwarding path as input to calculate a single-point forwarding proof OP_i; the i-th key node uses the single-point forwarding proof OP_i to replace the single-point forwarding proof OP_i-1 of the previous key node carried in the header of the data message _i.

[0484] In the case of adopting multi-point forwarding proof, optionally, data message _i also includes the sequential position of each key node from the 1st key node to the i-th key node in the actual forwarding path. In the process of verifying the forwarding proof of the first half of the path, the i-th key node verifies the multi-point forwarding proof MP_i-1 of the (i-1)th key node carried by the data message based on the identity information of each key node from the 1st key node to the (i-1)th key node and the sequential position of each key node from the 1st key node to the (i-1)th key node in the expected forwarding path. In the process of calculating the forwarding proof of this node, the i-th key node uses the identity information of each node from the 1st key node r_1 to the current node r_i and the sequential position of each node from the 1st key node r_1 to the current node r_i in the expected forwarding path as input to calculate a multi-point forwarding proof MP_i; the i-th key node uses the multi-point forwarding proof MP_i to replace the multi-point forwarding proof MP_i-1 of the previous key node carried in the message header of data message _i.

[0485] When using the on-path verification mode, the key nodes use the sequence position in the expected forwarding path, such as 1, 2, 3, and 4, when determining the forwarding proof and verifying the forwarding proof of the previous key node. The sequence position used is not the sequence position in the actual forwarding path. The sequence position of the key node in the actual forwarding path does not participate in the forwarding proof calculation process or the forwarding proof verification process. The sequence position of the key node in the actual forwarding path is used for evidence storage.

[0486] Exemplarily, when adopting the on-path verification mode, regardless of whether the verification mode for single-point proof or the verification mode for multi-point proof is adopted, the key node adds the actual sequence position of the node and the forwarding proof of the node to the data message during the transmission of business data, and sends the data message including the business data, the actual sequence position of the node and the forwarding proof of the node to the next key node, so that the actual sequence position of the node and the forwarding proof of the node are transmitted along the forwarding path together with the business data. For example, when the business data is transmitted to the i-th key node, the data message sent by the i-th key node to the next key node contains the following content. For example, the message header of the data message is used to carry the actual sequence number and forwarding proof as shown below.

[0487] The on-path verification mode provided by this embodiment ensures hop-by-hop security by calculating the forwarding proof for each key node passed by the data packet during actual transmission and verifying the forwarding proof of the previous key node. This ensures the identity and sequential position of each key node passed by the data packet, thereby ensuring security on a hop-by-hop basis. Furthermore, since the forwarding proof is incorporated into the header of the service data packet, compared to constructing a separate data packet to transmit the forwarding proof, the computational and communication costs are moderate, and the protocol flow and complexity are moderate, making this a compromise solution.

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

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

[0490] Second, verify the integrity of the path. Since the single-point forwarding proof of each key node 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.

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

[0492] Fourth, the correctness of the key node's position can be verified. Since the forwarding proof of each key node is obtained based on identity information and sequential position, by verifying the single-point forwarding proof of each key node, it is possible to verify whether the key node forwards data packets in the expected sequential position.

[0493] Furthermore, by having each key node be responsible for verifying the multi-point forwarding proof of the key node in the first half, the benefits achieved include but are not limited to the following aspects.

[0494] 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 key 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.

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

[0496] 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 key 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.

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

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

[0499] In the endpoint verification mode, the tail node in the forwarding path also plays the role of an observer. The tail node obtains a forwarding certificate based on the relative position 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. The key 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.

[0500] During data transmission at key node 1, if key node 1 is a key node, key node 1 constructs a new data packet based on the vector commitment, payload data, and the sequence position of key node 1 in the actual forwarding path. The data packet header carries the trusted path identifier, vector commitment, path information, and the actual sequence position list, while the payload field of the data packet carries the payload data. The actual sequence position list includes the sequence position of key node 1 in the actual forwarding path.

[0501] During data transmission, the i-th key node, acting as an intermediate node, does not need to perform the forwarding proof calculation and forwarding proof verification process. Instead, the i-th key node verifies the source of the data message using methods other than forwarding proof verification. The i-th key node adds its sequence position in the actual forwarding path to the actual sequence position list carried by data message _i, and records its actual sequence position by maintaining the actual sequence position list.

[0502] The last key node (the tail node) receives data packet _N. Data packet _N includes a header carrying a trusted path identifier and path information P = (r_1, r_2, …, r_N). The path information carries the identity information of each key node in the expected forwarding path, where r_i represents the publicly verifiable identity of forwarding node i. When computing the forwarding proof, the last key node obtains a multi-point forwarding proof MP_N based on the identity information of each node from key node 1 to key node r_N and the sequential position of each key node from key node 1 to key node r_N in the expected forwarding path. When verifying the forwarding proof, the last key node obtains the multi-point forwarding proof MP_N, the vector commitment C, and the path information P = (r_1, r_2, …, r_N). The last key node verifies the multi-point forwarding proof MP_N using a batch verification function (batch verify) based on the vector commitment mechanism, the vector commitment C, the sequential position of each key node in the path information P in the expected forwarding path, and the identity information of each node in the path information P. It executes batch verify(C, MP_N, P), that is, verifies that the identity information of the key node at each sequential position i in the entire actual forwarding path is r_i. In addition, the last key node obtains and saves the actual sequential position list from the data message _N.

[0503] For example, when using endpoint verification mode, regardless of whether the verification mode is for single-point verification or multi-point verification, each key node adds its actual sequential position to the data packet carrying service data. This means that the data packet not only carries the service data but also the actual sequential position of each key node it has passed through. For example, when a data packet is transmitted to the i-th key node, the data packet includes the following content in addition to the service data.

[0504] The endpoint verification mode provided in this embodiment does not require calculation of the forwarding proof and verification of the forwarding proof at each key node in the forwarding path except the tail node. The forwarding proof and verification of the forwarding proof are only calculated once at the tail node. Therefore, the overall overhead of all key nodes in the forwarding path is relatively small.

[0505] In addition, 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 it is transmitted in the network.

[0506] Using the identity information and relative position of each key node in the forwarding path for verification is merely an example. Other implementations of this application support tracing and verifying key nodes within a certain range preceding the key node on the forwarding path. The verifier can flexibly specify the required tracing scope based on actual needs. Different key nodes can be responsible for verifying different parts of the forwarding path, providing more flexible and adjustable tracing capabilities. The following example uses verification of two or three key nodes preceding the forwarding key node as an example.

[0507] In another possible implementation, key node i verifies the forwarding proof based on the vector commitment, the identity information of the two key nodes preceding key node i in the forwarding path, and the relative positions of the two key nodes preceding key node i, thereby supporting the tracing and verification of the correctness of the two key nodes preceding this key node. For example, the third key node verifies the forwarding proof received by the third key node based on the vector commitment, the identity information of the first key node, the relative position of the first key node, the identity information of the second key node, and the relative position of the second key node; the fifth key node verifies the forwarding proof received by the fifth key node based on the vector commitment, the identity information of the third key node, the relative position of the third key node, the identity information of the fourth key node, and the relative position of the fourth key node.

[0508] In another possible implementation, key node i verifies the forwarding proof based on the identity information of the three key nodes preceding key node i in the forwarding path, the relative positions of the three key nodes preceding key node i, and the vector commitment, thereby supporting the tracing and verification of the correctness of the three key nodes preceding this key node. For example, the fourth key node verifies the forwarding proof received by the fourth key node based on the identity information of the first key node, the relative position of the first key node, the identity information of the second key node, the relative position of the second key node, the identity information of the third key node, the relative position of the third key node, and the vector commitment; the seventh key node verifies the forwarding proof received by the seventh key node based on the identity information of the fourth key node, the relative position of the fourth key node, the identity information of the fifth key node, the relative position of the fifth key node, the identity information of the sixth key node, the relative position of the sixth key node, and the vector commitment.

[0509] In one possible implementation, in response to determining that the forwarding proof carried by the data message fails verification, the key 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 key node finds that the forwarding proof carried by the data message fails verification, that is, the source of the data may have problems, such as the data message skips a node in the path or passes through an extra unspecified node before forwarding to this node, the key 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.

[0510] In one possible implementation, in response to determining that a forwarding proof carried by a data message fails verification, the key node outputs an alarm message, where the alarm message indicates that the forwarding proof fails verification. In one possible implementation, the key node notifies a network management system (NMS), an element management system (EMS), or a controller of the alarm message via a management plane protocol. For example, the key node sends a Network Configuration Protocol (NETCOF) message to the controller, where the NETCOF message carries the alarm message, where the NETCOF message indicates that the forwarding proof fails verification. In another example, the key node sends a Simple Network Management Protocol (SNMP) message to the controller, where the SNMP message carries the alarm message, where the SNMP message indicates that the forwarding proof fails verification. In another example, the key node sends an alarm message to the controller based on telemetry indicating that the forwarding proof fails verification. In another example, the key node sends an alarm message to the controller indicating that the forwarding proof fails verification based on representational state transfer (RESTful). For another example, a key node, based on a log management protocol, sends information indicating that the forwarding proof has failed verification to the controller in the form of a log. For example, the key node sends a system logging protocol (Syslog) message to the controller, and the Syslog message carries 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 key node outputs the alarm information using an alarm notification. The alarm notification can be sent via SMS, email, instant messaging tools, etc., so that the administrator or network security team receives it in a timely manner and takes appropriate countermeasures. In another possible implementation, the key node outputs the alarm information using a logging method. For example, key node_i records the information of data packet_i that failed verification in the system log. In yet another possible implementation, key node_i sends the alarm information to the controller. The controller provides a visual display of the alarm information so that the administrator can quickly identify the problem and take appropriate measures.

[0511] In one possible implementation, in response to determining that the forwarding proof passes verification, the key node further forwards the received data message.

[0512] KZG polynomial commitment is only one possible way to obtain vector commitment. It not only achieves the effects of forwarding proof and position binding, but also has the advantage of high efficiency. Vector commitments obtained by other means can also achieve the effects of forwarding proof and order binding.

[0513] In other possible implementations, fast Reed-Solomon interactive (FRI) commitments are used to obtain and verify commitments based on the identity information and relative positions of key nodes. FRI commitments are a commitment mechanism used to verify the integrity of polynomials in interactive proof systems. They can quickly verify whether a polynomial satisfies a set of constraints without having to calculate the entire polynomial term by term. 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.

[0514] Other possible implementations employ succinct non-interactive argument of knowledge (SNARK) commitments, which are based on the identities and relative positions of key nodes to obtain and verify commitments. 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.

[0515] In other possible implementations, scalable transparent arguments of knowledge (STARK) commitments are used based on the identity information and relative positions of key nodes to obtain forwarding proofs or vector commitments; or STARK commitments are used to verify forwarding proofs based on vector commitments. STARK is a zero-knowledge proof technology that does not require a trusted third party to set up and start. Therefore, STARK is more decentralized and distributed, reducing the impact of single points of failure on obtaining forwarding proofs or vector commitments, and also has higher security. In addition, STARK is post-quantum secure, so using STARK helps improve the forwarding proof's ability to resist quantum computing attacks and is more reliable in protecting the security of forwarding proofs and identity information. In addition, the forwarding proof generated based on STARK has a relatively small data size, which means that the proof can be transmitted with less storage space and also has advantages in verification efficiency. The next-hop key node or verification node can verify the validity of the forwarding proof in a relatively short time.

[0516] In other possible implementations, Bulletproofs are used to obtain proofs of forwarding or vector commitments based on the identity information and relative positions of key nodes; or 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.

[0517] In other possible implementations, RSA accumulators are used to obtain and verify commitments based on the identity information and relative positions of key 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.

[0518] Other possible implementations employ FC function commitments, obtaining and verifying commitments based on the identity and relative positions of key nodes. FC function commitments are a commitment mechanism that binds inputs to a function's computational results, allowing the results to be verified without exposing the inputs. FC function commitments can be implemented by combining a zero-knowledge proof system with a commitment mechanism. They can be used to protect computer privacy and verify the correctness of computational results.

[0519] In other possible implementations, Pedersen commitments are used to obtain and verify commitments based on the identities and relative positions of key 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.

[0520] Another possible implementation utilizes Merkle tree commitments, obtaining and verifying commitments based on the identity and relative positions of key 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.

[0521] In other possible implementations, Verkle tree commitments are used to obtain and verify commitments based on the identity and relative positions of key nodes. A Verkle tree commitment is a commitment mechanism used to bind multiple elements in a set into a non-binary tree structure. A Verkle tree uses 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.

[0522] 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, key node i-1, or it can be the aggregate signature of all nodes from node _1 to key 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 the same length as a single signature. Given the existence of a public key infrastructure (PKI), that is, the public identity of the node is known, key node i can verify the correctness of this signature.

[0523] In some other possible implementations, the source of the data message is verified based on the MAC tag: for example, the data message includes a MAC tag, and the key node i verifies the correctness of the MAC tag.

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

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

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

[0527] By including a trusted path identifier in the data packet header, key nodes can determine whether to calculate a forwarding proof based on the presence of the identifier. For example, if key node i determines that a data packet does not contain a trusted path identifier, key 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.

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

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

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

[0531] In another possible implementation, after the key node_i obtains the data message, the key node_i identifies the business type carried in the data message; in response to identifying that the data message carries data of a specific business type, the step of obtaining a forwarding certificate is executed, thereby realizing the forwarding certificate for the specific business. For example, in response to identifying that the data message contains a network service header (NSH) in the business function chain protocol, the key node_i determines that the data message carries data of the business function chain, and then executes the step of obtaining a forwarding certificate. For another example, the key 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 the target application, the step of obtaining a forwarding certificate is executed. By executing the step of obtaining a forwarding certificate for a specific business, the effects achieved include but are not limited to the following aspects.

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

[0533] Second, it simplifies configuration and reduces the possibility of configuration errors. Compared to static configuration methods that require key nodes to generate forwarding proofs for certain packets, key 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 key 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.

[0534] Third, save computing resources: When the data message does not carry data related to specific services, key nodes can determine that there is no need to perform forwarding proof calculations, thereby avoiding wasting computing resources on other data that does not require proof calculations, saving computing resources and time, and improving overall network performance and efficiency.

[0535] In another possible implementation, after receiving a data packet, key node_i, in response to recognizing that the data packet contains the identifier of each node in a specific tunnel, performs the step of obtaining a forwarding proof to verify whether the data packet is forwarded through the specific tunnel. For example, in an SRv6 scenario, key node_i performs the step of obtaining a forwarding proof in response to recognizing that the data packet carries a segment list. For another example, in an MPLS scenario, key node_i performs the step of obtaining a forwarding proof in response to recognizing that the data packet carries a label stack.

[0536] The following uses two examples in specific application scenarios to illustrate the above method.

[0537] Example 1: Service function chaining (SFC) trusted path protection mechanism based on KZG polynomial proof.

[0538] 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 (key node), the NSH in Example 1 is a specific example of a message header carrying a vector commitment and forwarding proof, and the SF_from in Example 1 is a specific example of the identity information of a key node. The KZG polynomial commitment is a specific example of a vector commitment.

[0539] A service function chain (SF) is an ordered collection of service functions that guides each service function to process traffic in an orderly and on-demand manner. SFs are primarily used in NFV virtual networks. As shown in Figure 6, network devices play different roles within the SF chain architecture depending on their functions. SF roles primarily include the service classifier (SC), service function (SF) node, service function forwarder (SFF) node, and SFC proxy node.

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

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

Claims

1. A method for obtaining a forwarding proof, characterized in that The method includes: A first forwarding node obtains a first data packet, and at least two key nodes corresponding to the first data packet include the first forwarding node. The key node is a forwarding node passed through in the expected forwarding path determined by the path planner for the first data packet; The first forwarding node obtains the sequential position of the first forwarding node in the expected forwarding path and the identity information of the first forwarding node. The sequential position of the first forwarding node in the expected forwarding path is different from the sequential position of the first forwarding node in the actual forwarding path of the first data packet. The identity information of the first forwarding node indicates the identity of the first forwarding node; The first forwarding node obtains a forwarding proof of the first forwarding node based on the sequential position of the first forwarding node in the expected forwarding path and the identity information of the first forwarding node. The forwarding proof of the first forwarding node is used to prove that the first forwarding node forwards the first data packet at the sequential position in the expected forwarding path.

2. The method according to claim 1, wherein The at least two key nodes further include a second forwarding node. The second forwarding node is a key node located upstream of the first forwarding node in the expected forwarding path. The first forwarding node obtaining the forwarding proof of the first forwarding node based on the sequential position of the first forwarding node in the expected forwarding path and the identity information of the first forwarding node includes: The first forwarding node obtains the forwarding proof of the first forwarding node based on the sequential position of the first forwarding node in the expected forwarding path, the identity information of the first forwarding node, the sequential position of the second forwarding node in the expected forwarding path, and the identity information of the second forwarding node. The identity information of the second forwarding node indicates the identity of the second forwarding node. The forwarding proof of the first forwarding node is used to prove that the first forwarding node and the second forwarding node are respectively in the corresponding sequential positions in the expected forwarding path.

3. The method according to claim 2, wherein The first forwarding node is the last key node in the expected forwarding path, and the second forwarding node includes all key nodes other than the first forwarding node in the expected forwarding path.

4. The method according to any one of claims 1 to 3, characterized in that, The method further includes: The first forwarding node obtains the sequential position of the first forwarding node in the actual forwarding path based on the first data packet; The first forwarding node sends the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path to a verification node.

5. The method according to claim 4, wherein The verification node includes a third forwarding node. The third forwarding node is a key node located downstream of the first forwarding node in the expected forwarding path. The first forwarding node sending the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path to the verification node includes: The first forwarding node obtains a second data packet based on the first data packet, the forwarding proof of the first forwarding node, and the sequential position of the first forwarding node in the actual forwarding path. The second data packet includes the payload of the first data packet, the forwarding proof of the first forwarding node, and the sequential position of the first forwarding node in the actual forwarding path; The first forwarding node sends the second data packet to the third forwarding node.

6. The method according to claim 5, characterized in that, The first data packet includes a first position list, and the first position list includes the sequential positions of the key nodes upstream of the first forwarding node in the expected forwarding path in the actual forwarding path. The second data packet includes a second position list, and the second position list includes the first position list and the sequential position of the first forwarding node in the actual forwarding path.

7. The method according to claim 5 or 6, characterized in that, The second data packet includes an Internet Protocol Version 6 (IPv6) extension header, and the IPv6 extension header includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path; or, The second data packet includes a Network Service Header (NSH), and the NSH includes a metadata field, and the metadata field includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path; or, The second data packet includes a Multi-Protocol Label Switching (MPLS) header, and the MPLS header includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path; or, The second data packet includes a Virtual Extensible LAN (VxLAN) header, and the VxLAN header includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path; or, The second data packet includes an Internet Protocol Security (IPsec) header, and the IPsec header includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path.

8. The method according to claim 7, wherein The IPv6 extension header includes a Segment Routing Header (SRH), and the SRH includes a Type-Length-Value (TLV), and the TLV of the SRH includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path; or, The IPv6 extension header includes an Application-Aware Network (APN) packet header, and the APN packet header includes an Application-Aware Network Identifier (APN ID), and the APN ID includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path; or, The IPv6 extension header includes a Destination Option Header (DOH), and the DOH includes a TLV, and the TLV of the DOH includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path; or, The IPv6 extension header includes a Hop-by-Hop Options header (HBH), the HBH includes TLVs, and the TLVs of the HBH include the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path.

9. The method according to claim 4, characterized in that, The first forwarding node sending the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path to the verification node includes: The first forwarding node generates an advertisement message, and the advertisement message includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path; The first forwarding node sends the advertisement message to the verification node.

10. The method according to claim 9, characterized in that, The advertisement message includes a Network Configuration Protocol (NETCONF) message, and the NETCONF message includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path; or, The advertisement message includes a Hypertext Transfer Protocol (HTTP) message, and the payload field in the HTTP message includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path.

11. The method according to any one of claims 1 to 10, characterized in that, The first data packet includes a segment list, the segment list includes the segment identifier (SID) of the first forwarding node, and the first forwarding node obtaining the sequential position of the first forwarding node in the expected forwarding path includes: The first forwarding node obtains the sequential position of the first forwarding node in the expected forwarding path based on the sequential position of the SID of the first forwarding node in the segment list.

12. The method according to any one of claims 1 to 10, characterized in that, The first data packet includes a path identifier, and the first forwarding node obtaining the sequential position of the first forwarding node in the expected forwarding path includes: The first forwarding node obtains the sequential position of the first forwarding node in the expected forwarding path based on the path identifier and the corresponding relationship saved by the first forwarding node, where the corresponding relationship includes the path identifier and the sequential position of the first forwarding node in the expected forwarding path.

13. The method according to any one of claims 1 to 10, characterized in that, Before the first forwarding node obtains the first data packet, the method further includes: The first forwarding node receives the sequential position of the first forwarding node in the expected forwarding path from the path planner.

14. The method according to any one of claims 1 to 13, characterized in that, The first forwarding node obtaining the first data packet includes: the first forwarding node receives the first data packet from a second forwarding node, where the second forwarding node is a key node upstream of the first forwarding node in the forwarding path, and the first data packet includes the forwarding proof of the second forwarding node; The method further includes: the first forwarding node verifying the forwarding proof of the second forwarding node based on a first vector commitment, the identity information of the second forwarding node, and the sequential position of the second forwarding node in the expected forwarding path, where the first vector commitment indicates the correspondence between the sequential positions of at least two key nodes in the expected forwarding path and the identities of the at least two key nodes, and the at least two key nodes include the second forwarding node.

15. The method according to claim 1, wherein The path planner is the source host that generates the payload data of the first data packet; or, the path planner is the first forwarding device in the expected forwarding path.

16. A method for verifying a forwarding proof, characterized in that, The method includes: The verification node obtains the forwarding proof of the first forwarding node, a first vector commitment, the identity information of the first forwarding node, and the sequential position of the first forwarding node in the expected forwarding path, where the first vector commitment indicates the correspondence between the sequential positions of at least two key nodes in the expected forwarding path and the identities of the at least two key nodes, the at least two key nodes include the first forwarding node, the identity information of the first forwarding node indicates the identity of the first forwarding node, and the forwarding proof of the first forwarding node is used to prove that the first forwarding node is in the sequential position of the first forwarding node in the expected forwarding path; The verification node verifies the forwarding proof of the first forwarding node based on the first vector commitment, the identity information of the first forwarding node, and the sequential position of the first forwarding node.

17. The method according to claim 16, characterized in that, The at least two key nodes further include a second forwarding node, where the second forwarding node is a key node upstream of the first forwarding node in the expected forwarding path, and the verification node verifying the forwarding proof of the first forwarding node based on the first vector commitment, the identity information of the first forwarding node, and the sequential position of the first forwarding node in the expected forwarding path includes: The verification node verifies the forwarding proof of the first forwarding node based on the first vector commitment, the sequential position of the first forwarding node in the expected forwarding path, the identity information of the first forwarding node, the sequential position of the second forwarding node in the expected forwarding path, and the identity information of the second forwarding node, where the identity information of the second forwarding node indicates the identity of the second forwarding node, and the forwarding proof of the first forwarding node is used to prove that both the first forwarding node and the second forwarding node are in the corresponding sequential positions in the expected forwarding path.

18. The method according to claim 16 or 17, characterized in that, The verification node obtaining the forwarding proof of the first forwarding node includes: The verification node receives the forwarding proof of the first forwarding node from the first forwarding node.

19. A verification method for forwarding proofs, characterized in that, The method further includes: The first forwarding node obtains a first data packet, and the first forwarding node is deployed at the boundary of the first autonomous system (AS). The first forwarding node obtains the forwarding proof of the verified AS based on the sequential position of the verified AS and the identity information of the verified AS, where the identity information of the verified AS indicates the identity of the verified AS. The first forwarding node verifies the forwarding proof of the verified AS based on a second vector commitment, the sequential position of the verified AS, and the identity information of the verified AS, where the second vector commitment indicates the correspondence between the identity information of each AS in the at least two ASs and the sequential position of each AS.

20. The method according to claim 19, wherein The verified AS includes at least one of the neighbor ASs of the first AS, the first AS, or each AS from the source AS to the first AS. The neighbor AS includes the previous AS of the first AS in the actual forwarding path of the first data packet and / or the next AS of the first AS in the reachable path of the destination IP address of the first data packet. The source AS is the AS communicating with the source host, and the source host is the device generating the payload data of the first data packet.

21. The method according to claim 19 or 20, characterized in that, The sequential position of the verified AS includes the expected sequential position of the verified AS or the actual sequential position of the verified AS. The expected sequential position of the verified AS is used to indicate the sequential relationship between the verified AS and the ASs passed through by the expected forwarding path of the first data packet, and the actual sequential position of the verified AS is used to indicate the sequential relationship between the verified AS and the ASs passed through by the actual forwarding path of the first data packet.

22. The method according to claim 19, wherein The verified AS includes the neighbor ASs of the first AS. The first data packet carries the actual sequential position of the first AS, and the actual sequential position of the verified AS is obtained based on the actual sequential position of the first AS and the sequential relationship between the first AS and the verified AS.

23. The method according to claim 19, wherein The verified AS includes the first AS, and the actual sequential position of the first AS is carried in the first data packet.

24. The method according to claim 19, wherein The AS list is carried in the first data packet, and the AS list includes the identity information of each AS passed through by the expected forwarding path of the first data packet. The expected sequential position of the verified AS is obtained based on the sequential position of the identity information of the verified AS in the AS list.

25. The method according to any one of claims 19 to 24, characterized in that The second vector commitment is carried in the first data packet.

26. The method according to claim 19, characterized in that The first data packet includes an Internet Protocol Version 6 (IPv6) extension header, and the sequential position of the verified AS, the identity information of the verified AS, and the second vector commitment are carried in the IPv6 extension header; or, The first data packet includes a Network Service Header (NSH), and the NSH includes a metadata field, and the sequential position of the verified AS, the identity information of the verified AS, and the second vector commitment are carried in the metadata field; or, The first data packet includes a Multi-Protocol Label Switching (MPLS) header, and the sequential position of the verified AS, the identity information of the verified AS, and the second vector commitment are carried in the MPLS header; or, The first data packet includes a Virtual eXtensible Local Area Network (VxLAN) header, in which the sequential position of the verified AS, the identity information of the verified AS, and the second vector commitment are carried; or, The first data packet includes an Internet Protocol Security (IPsec) header, in which the sequential position of the verified AS, the identity information of the verified AS, and the second vector commitment are carried.

27. The method according to claim 19, wherein The destination IP address of the first data packet includes a first IP address. Before the first forwarding node obtains the first data packet, the method further includes: The first forwarding node receives a routing protocol packet from the verified AS, in which the first IP address and the identity information of the verified AS are carried; The first forwarding node saves a first correspondence relationship, which includes the first IP address and the identity information of the verified AS; After the first forwarding node obtains the first data packet, the method further includes: The first forwarding node obtains the identity information of the verified AS based on the first IP address and the first correspondence relationship.

28. The method according to claim 19, wherein The first data packet carries a path identifier, which is used to identify the expected forwarding path. Before the first forwarding node obtains the first data packet, the method further includes: The first forwarding node receives an advertisement packet from the path planner, in which the path identifier, the sequential position of the verified AS, and the identity information of the verified AS are carried; The first forwarding node saves a second correspondence relationship, which includes the path identifier, the sequential position of the verified AS, and the identity information of the verified AS; After the first forwarding node obtains the first data packet, the method further includes: The first forwarding node obtains the sequential position of the verified AS and the identity information of the verified AS based on the path identifier and the second correspondence relationship.

29. An apparatus for obtaining a forwarding proof, characterized in that The device is disposed in the first forwarding node, and the device includes: An acquisition unit, configured to acquire a first data packet. At least two key nodes corresponding to the first data packet include the first forwarding node, and the key nodes are forwarding nodes passed through in the expected forwarding path determined by the path planner for the first data packet; acquire the sequential position of the first forwarding node in the expected forwarding path and the identity information of the first forwarding node. The sequential position of the first forwarding node in the expected forwarding path is different from the sequential position of the first forwarding node in the actual forwarding path of the first data packet, and the identity information of the first forwarding node indicates the identity of the first forwarding node; A processing unit, configured to obtain a forwarding proof of the first forwarding node based on the sequential position of the first forwarding node in the expected forwarding path and the identity information of the first forwarding node. The forwarding proof of the first forwarding node is used to prove that the first forwarding node forwards the first data packet at the sequential position in the expected forwarding path.

30. The device according to claim 29, characterized in that, The at least two key nodes further include a second forwarding node, which is a key node located upstream of the first forwarding node in the expected forwarding path. The first forwarding node obtains a forwarding proof of the first forwarding node based on the sequential position of the first forwarding node in the expected forwarding path and the identity information of the first forwarding node, including: The first forwarding node obtains a forwarding proof of the first forwarding node based on the sequential position of the first forwarding node in the expected forwarding path, the identity information of the first forwarding node, the sequential position of the second forwarding node in the expected forwarding path, and the identity information of the second forwarding node. The identity information of the second forwarding node indicates the identity of the second forwarding node. The forwarding proof of the first forwarding node is used to prove that the first forwarding node and the second forwarding node are respectively in the corresponding sequential positions in the expected forwarding path.

31. The device according to claim 30, characterized in that, The first forwarding node is the last key node in the expected forwarding path, and the second forwarding node includes all key nodes in the expected forwarding path other than the first forwarding node.

32. The device according to claim 31, characterized in that, The processing unit is further configured to obtain the sequential position of the first forwarding node in the actual forwarding path based on the first data packet. The apparatus further includes: a sending unit, configured to send the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path to a verification node.

33. The device according to claim 32, wherein The verification node includes a third forwarding node, which is a key node located downstream of the first forwarding node in the expected forwarding path. The processing unit is further configured to obtain a second data packet based on the first data packet, the forwarding proof of the first forwarding node, and the sequential position of the first forwarding node in the actual forwarding path. The second data packet includes the payload of the first data packet, the forwarding proof of the first forwarding node, and the sequential position of the first forwarding node in the actual forwarding path. The sending unit is configured to send the second data packet to the third forwarding node.

34. The apparatus according to claim 32, wherein The processing unit is further configured to generate an announcement packet, which includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path. The sending unit is configured to send the announcement packet to a verification node.

35. The device according to any one of claims 31 to 34, characterized in that The first data packet includes a segment list, and the segment list includes the segment identifier SID of the first forwarding node. The processing unit is configured to obtain the sequential position of the first forwarding node in the expected forwarding path based on the sequential position of the SID of the first forwarding node in the segment list.

36. The device according to any one of claims 31 to 35, characterized in that The first data packet includes a path identifier, and the processing unit is configured to obtain the sequential position of the first forwarding node in the expected forwarding path based on the path identifier and the corresponding relationship saved by the first forwarding node, where the corresponding relationship includes the path identifier and the sequential position of the first forwarding node in the expected forwarding path.

37. The device according to any one of claims 29 to 36, characterized in that The obtaining unit is configured to receive the first data packet from a second forwarding node, where the second forwarding node is a key node upstream of the first forwarding node in the forwarding path, and the first data packet includes a forwarding proof of the second forwarding node; The processing unit is further configured to verify the forwarding proof of the second forwarding node based on a first vector commitment, the identity information of the second forwarding node, and the sequential position of the second forwarding node in the expected forwarding path, where the first vector commitment indicates the corresponding relationship between the sequential positions of at least two key nodes in the expected forwarding path and the identities of the at least two key nodes, and the at least two key nodes include the second forwarding node.

38. A verification device for forwarding proofs, characterized in that, The apparatus includes: An obtaining unit, configured to obtain a forwarding proof of the first forwarding node, a first vector commitment, identity information of the first forwarding node, and the sequential position of the first forwarding node in the expected forwarding path, where the first vector commitment indicates the corresponding relationship between the sequential positions of at least two key nodes in the expected forwarding path and the identities of the at least two key nodes, the at least two key nodes include the first forwarding node, the identity information of the first forwarding node indicates the identity of the first forwarding node, and the forwarding proof of the first forwarding node is used to prove that the first forwarding node is in the sequential position of the first forwarding node in the expected forwarding path; A verification unit, configured to verify the forwarding proof of the first forwarding node based on the first vector commitment, the identity information of the first forwarding node, and the sequential position of the first forwarding node.

39. The device according to claim 38, wherein The at least two key nodes further include a second forwarding node, where the second forwarding node is a key node upstream of the first forwarding node in the expected forwarding path, and the verification unit is configured to verify the forwarding proof of the first forwarding node based on the first vector commitment, the sequential position of the first forwarding node in the expected forwarding path, the identity information of the first forwarding node, the sequential position of the second forwarding node in the expected forwarding path, and the identity information of the second forwarding node, where the identity information of the second forwarding node indicates the identity of the second forwarding node, and the forwarding proof of the first forwarding node is used to prove that both the first forwarding node and the second forwarding node are in the corresponding sequential positions in the expected forwarding path.

40. The device according to claim 38 or 39, characterized in that, The obtaining unit is configured to receive the forwarding proof of the first forwarding node from the first forwarding node.

41. A verification device for forwarding proofs, characterized in that, The apparatus is disposed at the first forwarding node, and the apparatus further includes: An obtaining unit, configured to obtain a first data packet, where the first forwarding node is deployed at the boundary of a first autonomous system (AS); A processing unit, configured to obtain a forwarding proof of the verified AS based on the sequential position of the verified AS and the identity information of the verified AS, where the identity information of the verified AS indicates the identity of the verified AS; The processing unit is further configured to verify the forwarding proof of the verified AS based on a second vector commitment, the sequential position of the verified AS, and the identity information of the verified AS, where the second vector commitment indicates the correspondence between the identity information of each AS in the at least two ASs and the sequential position of each AS.

42. The device according to claim 41, characterized in that, The verified AS includes a neighbor AS of the first AS. The first data packet carries the actual sequential position of the first AS, and the actual sequential position of the verified AS is obtained by the processing unit based on the actual sequential position of the first AS and the sequential relationship between the first AS and the verified AS.

43. The device according to claim 41, characterized in that, The verified AS includes the first AS, and the processing unit is configured to obtain the actual sequential position of the first AS carried in the first data packet.

44. The apparatus according to claim 41, wherein, The first data packet carries an AS list, where the AS list includes the identity information of each AS through which the expected forwarding path of the first data packet passes. The expected sequential position of the verified AS is obtained by the processing unit based on the sequential position of the verified AS in the AS list.

45. The device according to claim 41, characterized in that, The destination IP address of the first data packet includes a first IP address. The obtaining unit is further configured to receive a routing protocol packet from the verified AS, where the routing protocol packet carries the first IP address and the identity information of the verified AS; The processing unit is further configured to save a first correspondence, where the first correspondence includes the first IP address and the identity information of the verified AS; The obtaining unit is further configured to obtain the identity information of the verified AS based on the first IP address and the first correspondence.

46. The device according to claim 41, characterized in that, The first data packet carries a path identifier, where the path identifier is used to identify the expected forwarding path. The obtaining unit is further configured to receive an announcement packet from a path planning party, where the announcement packet carries the path identifier, the sequential position of the verified AS, and the identity information of the verified AS; The processing unit is further configured to save a second correspondence, where the second correspondence includes the path identifier, the sequential position of the verified AS, and the identity information of the verified AS; The obtaining unit is further configured to obtain the sequential position of the verified AS and the identity information of the verified AS based on the path identifier and the second correspondence.

47. A forwarding device, characterized in that, The forwarding device includes: a processor, where the processor is coupled to a memory, and at least one computer program instruction is stored in the memory. The at least one computer program instruction is loaded and executed by the processor to enable the forwarding device to implement the method according to any one of claims 1-28.

48. A computer-readable storage medium, characterized in that, At least one instruction is stored in the storage medium, and when the instruction runs on a computer, the computer is caused to execute the method according to any one of claims 1-28.

49. A computer program product, characterized in that, The computer program product includes one or more computer program instructions, and when the computer program instructions are loaded and run by a computer, the computer is caused to execute the method according to any one of claims 1-28.

Images