WO2025152913A1 - Method and apparatus for acquiring forwarding proof, and method and apparatus for verifying forwarding proof - Google Patents

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

This application claims the priority of 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 in this application.

Technical Field

The present application relates to the field of network security, and in particular to a method for obtaining a forwarding certificate, and a method and device for verifying a forwarding certificate.

Background Art

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

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

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.

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, where 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.

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 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 business data passing through the forwarding nodes when the path planner expects the business data to be 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.

In particular, when the sequence position of the forwarding node in the expected forwarding path is different from the sequence position of the forwarding node in the actual forwarding path, the forwarding proof is obtained by using the sequence position of the forwarding node in the expected forwarding path instead of the sequence position of the forwarding node in the actual forwarding path, so that the sequence position based on which the forwarding proof is obtained is consistent with the sequence position based on which the vector commitment is obtained, thereby achieving fault tolerance of path verification. For example, data packets are allowed to pass through some non-critical nodes (such as old equipment, equipment with weak capabilities, 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.

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

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

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.

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 the 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 the time and computing costs, improving the efficiency of verification, and making the verification more complete.

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 proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path to the verification node.

Since the key node sends the sequence position of the local end in the actual forwarding path to the verification node, the verification node can perceive the sequence position of the key node in the actual forwarding path, thereby realizing the recordability of non-key nodes. For example, the verification node determines that there is a non-key node between the two key nodes based on the discontinuity of the sequence position of two adjacent key nodes in the actual forwarding path. The verification node determines the number of non-key nodes between the two key nodes based on the difference in the sequence position of two adjacent key nodes in the actual forwarding path.

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.

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 a 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 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; the first forwarding node sends the second data packet to the third forwarding node.

Since the actual sequence position and the forwarding proof are carried in the same data message 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 transmission of the actual sequence position in an in-band manner. In the mode where the key node also serves as the verification node (observer), there is no need to construct independent data messages to transmit the actual sequence position and the forwarding proof respectively, so the overall transmission overhead of the actual sequence position and the 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 message, so the verification node is also more efficient in obtaining the actual sequence position of the key node and the forwarding proof of the key node.

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

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 nodes that have been passed but not recorded.

Based on the method provided in the first aspect, in some implementations, the second data message includes an Internet Protocol version 6 IPv6 extension header, and the IPv6 extension header includes a forwarding proof of the first forwarding node and a sequential position of the first forwarding node in the actual forwarding path. In an IPv6 scenario, by using the IPv6 extension header to carry the forwarding proof and the actual sequential position, it is supported to prove whether the data flow passes through the expected IPv6 nodes in the expected sequence.

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 a sequential position of the first forwarding node in the actual forwarding path.

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 (SF) in the expected sequence, and records whether the data flow passes through an unexpected SF, which helps each SF to process traffic in an orderly manner as needed.

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

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

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 proof 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 interconnections, 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.

Based on the method provided in the first aspect, in some implementations, the second data message includes an Internet Protocol security IPsec header, and the IPsec header includes a forwarding certificate of the first forwarding node and a sequential position of the first forwarding node in the actual forwarding path. The above method is applicable to a network scenario based on the IPsec protocol, and provides a function of verifying the source of data in the IPsec tunnel, so as to facilitate verification of whether the forwarding path through which the data message passes during actual forwarding matches the pre-planned IPsec tunnel.

Based on the method provided in the first aspect, in some implementations, 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 a sequential position of the first forwarding node in the actual forwarding path. The above method is applicable to SRv6 scenarios, and is convenient for verifying whether the forwarding path that the data message passes through during actual forwarding matches the pre-planned segment list.

Based on the method provided in the first aspect, in some implementations, 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 the actual forwarding path. The above method is applicable to the APN6 scenario, and is convenient for verifying whether the forwarding path that the data message passes through during actual forwarding matches the forwarding path pre-planned in the APN network.

Based on the method provided in the first aspect, in some implementations, the IPv6 extension header includes a destination options header DOH, the DOH includes a TLV, and the TLV of the DOH includes a forwarding proof of the first forwarding node and a sequential position of the first forwarding node in an actual forwarding path.

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

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.

By constructing independent messages to notify the actual sequence position of key nodes and the forwarding proof of key nodes, the verification node can infer whether there are non-key nodes in the actual forwarding path and the number of non-key nodes in the actual forwarding path based on the sequence position of the received key nodes in the actual forwarding path, thereby achieving the recordability of non-key nodes. In addition, since any key node can send the forwarding proof and the actual sequence position to the verification node after receiving the data message, the verification node can verify the forwarding proof and record the actual sequence 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 sequence position, thus achieving real-time transparent tracking of the data transmission process, and a smaller attack window.

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.

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

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.

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

Based on the method provided in the first aspect, in some embodiments, the first data packet includes a segment list 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.

The above method provides a fast and high-performance method for obtaining the expected sequence position based on the data plane. Since the forwarding node can obtain the expected sequence position based on the segment list carried in the received data message, 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 reducing the performance overhead caused by the forwarding node to look up the table to determine the expected sequence position.

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.

The above method provides a method for obtaining the expected sequence position by combining the path identifier carried in the data plane and the corresponding relationship provided by the control plane. Since the data message does not need to carry the expected sequence position of each key node, the overhead of data message transmission is further reduced on the basis of supporting path verification.

Based on the method provided in the first aspect, in some implementations, 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.

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, and 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.

Based on the method provided in the first aspect, in some implementations, the first forwarding node obtains a first data packet, including: the first forwarding node receives the first data packet from a second forwarding node, the second forwarding node is a key node located 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 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 the expected forwarding path, the first vector commitment indicating a correspondence between sequential positions of at least two key nodes in the expected forwarding path and identities of the at least two key nodes, and the at least two key nodes include the second forwarding node.

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, whether the previous forwarding node is the expected forwarding node, and support 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, so that network attacks in data packets can be discovered in time, reducing the risks caused by 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, improving the security of the network.

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.

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

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

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 indicating a correspondence between sequential positions of at least two key nodes in the expected forwarding path and 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; 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.

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

Furthermore, in many source address or centralized path calculation routing technologies, network attacks such as route hijacking, route injection, and traffic detour, or network device misconfiguration problems 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.

In particular, when the sequence position of the forwarding node in the expected forwarding path is different from the sequence position of the forwarding node in the actual forwarding path, the forwarding proof is obtained by using the sequence position of the forwarding node in the expected forwarding path instead of the sequence position of the forwarding node in the actual forwarding path, so that the sequence position based on which the forwarding proof is obtained is consistent with the sequence position based on which the vector commitment is obtained, thereby achieving fault tolerance of path verification. For example, data packets are allowed to pass through some non-critical nodes (such as old equipment, equipment with weak capabilities, 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.

Based on the method provided in the second aspect, in some implementations, 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, and 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:

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, and 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.

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

Based on the method provided in the second aspect, in some implementations, 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.

According to a third aspect, a method for verifying a forwarding proof is provided, the method also includes: 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.

Based on the identity information of the verified AS and the sequential position of the verified AS, the forwarding proof of the verified AS is obtained, and the forwarding proof of the verified AS is compared with the vector commitment, so as to determine whether the verified AS is the expected AS and/or 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 message is to pass through or the AS that has passed through belongs to the AS passed through in the planned expected path, thereby reducing the risk caused by the data message passing through an unexpected AS. For example, it reduces the risk of network transmission quality degradation caused by the data message passing through an AS whose network transmission quality does not meet the requirements (for example, the delay and packet loss rate do not meet the standards), or reduces the security risk caused by the data message passing through an AS whose network security does not meet the requirements (for example, an AS with security risks that has been identified).

Based on the method provided by 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 that communicates with the source host, and the source host is the device that generates the payload data of the first data packet.

By obtaining the forwarding proof of the next AS 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 data messages entering an unexpected AS.

By obtaining the forwarding proof of the previous AS 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.

Based on the method provided by 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, and 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.

By using the expected sequential position of the verified AS for path verification, an unexpected AS is allowed to 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.

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.

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.

The above method provides a fast and high-performance method for obtaining the actual sequence position of the AS based on the data plane. Since the forwarding node can obtain the actual sequence position of the verified AS based on the segment list carried in the received data message, 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 reducing the performance overhead caused by the forwarding node to look up the table to determine the expected sequence position.

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

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

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.

Since the AS list in the data message indicates each AS through which the expected forwarding path passes, it not only supports path verification based on the expected sequence position of the AS, but also realizes the 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.

Based on the method provided in the third aspect, in some implementation manners, the first data packet carries the second vector commitment.

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 by data packets, it reduces the storage resource overhead caused by the forwarding node to pre-save vector commitments, and also reduces the performance overhead caused by the forwarding node to determine the vector commitment table match.

Based on the method provided by the third aspect, in some implementations, based on the method provided by the third aspect, in some implementations, the first data message 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,

The first data message includes a network service message 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,

The first data message includes a multi-protocol label switching MPLS header, and the MPLS header carries the sequence position of the verified AS, the identity information of the verified AS, and the second vector commitment; or,

The first data message includes a virtualized extended local area network VxLAN header, and the VxLAN header carries the sequence position of the verified AS, the identity information of the verified AS, and the second vector commitment; or,

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

Based on the method provided in the third aspect, in some implementations, the destination IP address of the first data message includes the first IP address, and before the first forwarding node obtains the first data message, the method further includes: the first forwarding node receives a routing protocol message from the verified AS, the routing protocol message carries the first IP address and the identity information of the verified AS; the first forwarding node saves the first corresponding relationship, the first corresponding relationship includes the first IP address and the identity information of the verified AS;

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.

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

Based on the method provided in the third aspect, in some implementations, the first data message 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 message, the method further includes: the first forwarding node receives a notification message from the path planning party, 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;

After the first forwarding node obtains the first data message, the method further includes: the first forwarding node obtains the sequence position of the verified AS and the identity information of the verified AS based on the path identifier and the second corresponding relationship. 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.

In a fourth aspect, a device for obtaining a forwarding certificate is provided, the device being arranged at a first forwarding node, and the device comprising:

An acquisition unit is used to acquire a first data message, wherein at least two key nodes corresponding to the first data message 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 message; the sequential position of the first forwarding node in the expected forwarding path and the identity information of the first forwarding node are acquired, wherein 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 message, 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 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, wherein the forwarding proof of the first forwarding node is used to prove that the first forwarding node forwards the first data message at the sequential position in the expected forwarding path.

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, and a processing unit is used 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, 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.

Based on the device 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.

Based on the device provided in the fourth aspect, in some implementation modes, 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 message;

The device also includes: a sending unit, which is used 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.

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 also 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; the sending unit is used to send the second data packet to the third forwarding node.

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

Based on the device provided by the fourth aspect, in some embodiments, the second data packet includes an Internet Protocol version 6 IPv6 extension header, the IPv6 extension header includes a forwarding proof of the first forwarding node and a 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 a forwarding proof of the first forwarding node and a 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 a forwarding proof of the first forwarding node and a 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 a forwarding proof of the first forwarding node and a 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 a forwarding proof of the first forwarding node and a sequential position of the first forwarding node in the actual forwarding path.

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.

The IPv6 extension header includes an application-aware network APN message header, the APN message header includes an application-aware network identifier APN ID, the APN ID includes a forwarding certificate of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path.

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.

The IPv6 extension header includes a hop-by-hop options 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.

Based on the device provided in the fourth aspect, in some implementation modes, the processing unit is further used to generate a notification message, the notification message including 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 used to send a notification message to the verification node.

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 an actual forwarding path; or,

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.

Based on the device provided in the fourth aspect, in some embodiments, the first data message includes a segment list 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.

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.

Based on the device provided in the fourth aspect, in some implementations, the acquisition unit is further used to receive the sequential position of the first forwarding node in the expected forwarding path from the path planner.

Based on the device provided in the fourth aspect, in some implementation modes, the acquiring unit is configured to receive a first data message from a second forwarding node, where the second forwarding node is a key node located upstream of the first forwarding node in the forwarding path, and the first data message includes a forwarding certificate of the second forwarding node;

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 the sequential position of the second forwarding node in the expected forwarding path, wherein 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, and the at least two key nodes include the second forwarding node.

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

In a fifth aspect, a forwarding proof verification device is provided, the device comprising: an acquisition unit, used 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; a verification unit, used 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.

Based on the device provided in the fifth 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 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, and 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.

Based on the device provided in the fifth aspect, in some implementations, the acquisition unit is used to receive a forwarding certificate from the first forwarding node of the first forwarding node.

In a sixth aspect, a forwarding proof verification device is provided, the device is arranged at a first forwarding node, and the device further includes:

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

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;

The processing unit is further used to verify the forwarding proof of the verified AS based on the second vector commitment, the sequential position of the verified AS and the identity information of the verified AS, wherein 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.

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 that communicates with the source host, and the source host is a device that generates payload data of the first data packet.

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, and 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.

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.

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

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.

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

Based on the apparatus provided in the sixth aspect, in some implementations, the first data message 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,

The first data message includes a network service message 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,

The first data message includes a multi-protocol label switching MPLS header, and the MPLS header carries the sequence position of the verified AS, the identity information of the verified AS, and the second vector commitment; or,

The first data message includes a virtualized extended local area network VxLAN header, and the VxLAN header carries the sequence position of the verified AS, the identity information of the verified AS, and the second vector commitment; or,

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

Based on the device provided in the sixth aspect, in some implementations, the destination IP address of the first data message includes the first IP address, and the acquisition unit is further used to receive a routing protocol message from the verified AS, where the routing protocol message carries the first IP address and identity information of the verified AS;

The processing unit is further used to save the first corresponding relationship, where the first corresponding relationship includes the first IP address and the identity information of the verified AS;

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

Based on the device provided in the sixth aspect, in some implementation modes, the first data message carries a path identifier, the path identifier is used to identify the expected forwarding path, and the acquisition unit is further used to receive a notification message from the path planning party, the notification message carries the path identifier, the sequential position of the verified AS, and the identity information of the verified AS;

The processing unit is further used to save the second corresponding relationship, where the second corresponding relationship includes the path identifier, the sequential position of the verified AS, and the identity information of the verified AS;

The acquisition unit is further used to obtain the sequence position of the verified AS and the identity information of the verified AS based on the path identifier and the second corresponding relationship.

In the seventh aspect, a forwarding device is provided, which includes a processor, the processor is coupled to a memory, at least one computer program instruction is stored in the memory, and the at least one computer program instruction is loaded and executed by the processor, so that the forwarding device executes the method provided by the first aspect or any optional method of the first aspect, the method provided by the second aspect or any optional method of the second aspect, or the method provided by the third aspect or any optional method of the third aspect, and 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 by the first aspect or any optional method of the first aspect, the method provided by the second aspect or any optional method of the second aspect, or the method provided by the third aspect or any optional method of the third aspect, and the network interface is used to receive or send messages, which will not be repeated here.

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

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 aspect of the first aspect, the method provided by the second aspect or any optional aspect of the second aspect, or the method provided by the third aspect or any optional aspect of the third aspect.

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 executed by a computer, the computer executes the method provided by the first aspect or any optional aspect of the first aspect, the method provided by the second aspect or any optional aspect of the second aspect, or the method provided by the third aspect or any optional aspect of the third aspect.

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 aspect of the first aspect, the method provided by the second aspect or any optional aspect of the second aspect, or the method provided by the third aspect or any optional aspect of the third aspect.

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

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

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

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

FIG4 shows an architecture diagram of another trusted path network system provided in an embodiment of the present application;

FIG5 shows an architecture diagram of another trusted path network system provided in an embodiment of the present application;

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

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

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

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

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

11 is a schematic diagram of the structure of a device for obtaining a forwarding certificate provided in an embodiment of the present application;

12 is a schematic diagram of the structure of a verification device for forwarding proof provided in an embodiment of the present application;

13 is a schematic diagram of the structure of a device for obtaining a forwarding certificate provided in an embodiment of the present application;

FIG. 14 is a schematic diagram of the structure of a device provided in an embodiment of the present application.

DETAILED DESCRIPTION

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

The following is an explanation of some terminology concepts involved in the embodiments of the present application.

(1) Path Verification Mechanism

The path verification mechanism refers to a technology that supports verification of whether the actual transmission of business data is forwarded along the expected forwarding path. In some embodiments of the present application, the forwarding proof 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 proof 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, so as to realize the path verification mechanism. For example, if the forwarding proof 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 proof 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.

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 neighbor node of the current node, or/and 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 neighbor AS of the current AS, each AS passed by the upper half of the path, or/and 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.

In some embodiments, one of the two methods, a device-level path verification method and an AS-level path verification method, is selected to be executed. 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 according to the network deployment position 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.

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 different identity information and sequential position used as algorithm input data.

(2) Expected forwarding path

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 by performing path calculation based on the network topology. The expected forwarding path includes at least two forwarding nodes. For example, the expected forwarding nodes include 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 represented, for example, in the form of 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 represented, for example, by an MPLS label stack. In the scenario of SFC, the expected forwarding path is represented, for example, by a service function chain.

(3) Actual forwarding path

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 entered by the data message 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, B and C in the actual forwarding path, there are non-critical nodes A and B between key nodes A and B in the actual forwarding path, and there are non-critical nodes C between key nodes B and C in the actual forwarding path.

(4) Roles involved in the path verification mechanism

The path verification mechanism is usually implemented through the coordination of the path planner, the forwarding node, and the verification node. The path planner is used to determine the vector commitment, the forwarding node is used to determine the forwarding proof in the process of forwarding business data, and the verification node is used to compare the vector commitment with the forwarding proof for verification.

In some embodiments, the path planner, the forwarding node, and the verification node are physically separated. For example, the path planner is a controller, the forwarding node is a forwarding device such as a router or a switch, and the verification node is an auditing device, a destination host of business data, or a user device. In a possible implementation, the verification node is deployed outside the forwarding path. The verification node is separated from the forwarding node in the forwarding path and is set on different hardware devices. The verification node does not need to undertake the task of message forwarding.

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 on the same hardware device, which undertakes the task of forwarding the message and verifying the forwarding proof. In other words, the verification node is the forwarding node itself, and the forwarding node 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.

(5) Forwarding Node

A forwarding node is also called a forwarding device. A forwarding node refers to a device or a collection of multiple devices used to forward data. For example, a forwarding node is a network device, such as a switch, a router, or a firewall. For example, a forwarding node is a computing device, such as a server or a terminal. A forwarding node is a physical device or a virtual device.

(6) Path planning

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, and the source host refers to a device that generates a data message, for example, the path planner is a terminal or a server. In other embodiments, the path planner is the first forwarding device for a data message to enter a network, such as the first forwarding node in an expected forwarding path, such as a switch or a router. As an example, the path planner is the first forwarding device of the network entered by the data message. For example, the path planner is the entry device of the network entered by the data message.

(7) Key Nodes

A key node is a specific type of forwarding node. The term "key" is mainly defined based on the expected forwarding path. In this embodiment, the forwarding node in the expected forwarding path is called a key node, and the AS where the forwarding node in the expected forwarding path is located is called a key AS.

Key nodes are also called forwarding key nodes or expected nodes. Key nodes are forwarding nodes 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 usually support the ability to calculate forwarding proofs and/or the ability to verify forwarding proofs. For example, key nodes store configuration information related to the calculation of forwarding proofs and/or the verification of forwarding proofs, and activate the functions that enable the calculation of forwarding proofs and/or the verification of forwarding proofs. During the transmission of business data, when a data packet carrying business data arrives at a key node, the key node can calculate the forwarding proof.

A type of forwarding node opposite to the critical node is the 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 enable 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.

When arranging the expected forwarding path, the controller does not know in advance which non-critical nodes exist, nor does it arrange the non-critical nodes into the expected forwarding path. In the actual forwarding process, the critical nodes may decide to pass through these non-critical nodes on their own, 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 nodes A and B in the expected forwarding path are adjacent. However, when critical node A actually forwards data packets, critical node A does not forward data packets directly to critical node B, but forwards data packets to critical node B through a tunnel, which passes through non-critical nodes a and non-critical nodes b. Non-critical nodes a and non-critical nodes b are used to forward data packets 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.

(8) Forwarding path locking

Forwarding path locking is a technical effect that is expected to be achieved by the embodiments of the present application. Forwarding path locking means that during the actual transmission process, the 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 the business data. In some implementations of the present application, forwarding path locking specifically includes the effects of the correctness of the key node identity and the correctness of the key node sequence relationship.

The correctness of the key node identity refers to the match between the identity of the key nodes that the business data passes through during the actual transmission process and the identity of the key nodes 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.

The correctness of the key node sequence relationship is also called data forwarding in order, position locking or sequence position binding. The correctness of the key node sequence relationship means that the sequence relationship of each key node in the actual forwarding path is consistent with the sequence relationship of each key node in the expected forwarding path determined by the path planner, and the key nodes in the expected forwarding path cannot be skipped, or additional key nodes that do not appear in the expected forwarding path are passed. For example, the path planner expects that the business data will first pass through key node A, then key node B, and finally key node C. In the actual transmission process, the business data will also first pass through key node A, then key node B, and finally key node C, but it cannot pass through key node C first, then key node B, and finally key node A. It cannot skip key node B and directly reach 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 the vector commitment based on the sequential positions of N key nodes in the expected forwarding path, the forwarding node determines the 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, so that both the vector commitment and the forwarding proof are bound to the sequential positions of the key nodes. Based on this, only the forwarding proof determined by the correct sequential positions of the key nodes can pass the verification, and it is difficult for a third party to forge the correct forwarding proof due to the difficulty in obtaining the correct sequential positions of the key nodes, thereby achieving the correctness of the key node identity.

In some embodiments of the present application, a vector commitment is obtained by combining the sequence position of the key node and the identity information of the key node, so that the vector commitment is not only related to the identity information of the key node, but also to the sequence position of the key node. Therefore, when verifying the forwarding proof based on the vector commitment, the forwarding proof generated by satisfying the conditions of correct sequence relationship and correct identity information can pass the verification. Based on this, if the path planning party 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 by the correct identity information of the first key node and the correct sequence position (i) of the first key node, and the forwarding proof is difficult to be forged by others. On the contrary, if the business data skips the expected key node or passes through the extra unexpected key node during the actual forwarding process, 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, so the forwarding proof obtained at the downstream key node cannot pass the verification, so that the correctness of the key node identity and the correctness of the key node sequence relationship can be achieved at the same time.

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. In the case where the service 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 the 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 the verification. For another example, in the case of passing through extra unspecified nodes, an extra key node E is added to forwarding path 1, and 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, because the actual sequence position (5) and identity (D) on which forwarding proof 2 is based do not match, forwarding proof 2 also cannot pass verification.

(9) Fault Tolerance of Path Verification

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.

The fault tolerance of node-level path verification means that while achieving path locking, business data is allowed to pass through non-critical nodes during the actual transmission process, reducing the risk of critical nodes downstream of non-critical nodes interrupting business data transmission or outputting alarms due to failure of forwarding proof verification. 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 is the same as the sequential position of the corresponding critical node in the actual forwarding path in order for the forwarding proof verification to pass.

A typical application scenario where fault tolerance of non-critical nodes is required is when the business data passes through non-critical nodes during the actual forwarding process. For example, the order of at least two critical nodes that the business data is expected to pass through is the same as the order in which the at least two critical nodes actually forward the business data, and the expected sequence position of the at least two critical nodes is different from the sequence position of the at least two critical nodes actually forwarding the business data. For example, the actual forwarding path of the first data message has additional non-critical nodes compared to the expected forwarding path of the first data message.

As an example, critical node A and critical node B are adjacent in sequence in the expected forwarding path, but critical node A and critical node B establish a tunnel during the actual transmission of business data. Critical node A transmits business data to critical node B through a series of intermediate nodes in the tunnel, resulting in critical node A and critical node B being non-adjacent in sequence in the actual forwarding path.

For example, an expected forwarding path is a three-layer forwarding path composed of three-layer forwarding devices. In the three-layer forwarding path, key node B is the next forwarding node of key node A, and key node A actually transmits service data to key node B through a two-layer tunnel. The two-layer tunnel passes through one or more two-layer forwarding devices, resulting in that the sequence positions of key node A and key node B in the actual forwarding path are not adjacent. In the actual forwarding path, there is each two-layer forwarding device through which the two-layer tunnel passes between key node A and key node B.

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

The main reason why the key nodes downstream of the non-key nodes fail to verify the forwarding proof is that the path planner calculates the vector commitment based on the sequential position of the key nodes in the expected forwarding path. If the key node uses the sequential position of the key node in the actual forwarding path to calculate the forwarding proof, and uses the vector commitment and the sequential position of the key node in the actual forwarding path to verify the forwarding proof, when the sequential position of the key node in the actual forwarding path is different from the sequential position of the key node in the expected forwarding path (please refer to the following description for the reasons and scenarios for the different sequential positions), the sequential position based on which the vector commitment is calculated deviates from the sequential position based on which the forwarding proof is calculated, resulting in the key node failing to verify the forwarding proof based on the vector commitment.

In addition, since there is a certain degree of uncertainty about which forwarding nodes the actual transmission process of business data passes through, the path planner is usually unable to perceive the sequential position of the key nodes in the actual forwarding path, and the path planner is also unable 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.

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 interrupting business data transmission or outputting alarms due to failure to verify the forwarding proof based on vector commitment.

(10) The sequential position of key nodes in the expected forwarding path

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 (e.g., 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 messages 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 messages 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 messages compared to other forwarding nodes.

In some embodiments, the data form of the sequential position in the expected forwarding path is a sequence number (also called a serial number), and the sequence number representing the sequential position in the expected forwarding path is referred to as the expected sequence number below. For example, the expected sequence number is a positive integer. For example, the expected sequence number uses an ascending method 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.

For example, please refer to Figure 1, in which "A-1" indicates that the sequence position (expected sequence number) of key node A in the expected forwarding path is 1, "B-2" indicates that the sequence position (expected sequence number) of forwarding node B in the expected forwarding path is 2, and "C-3" indicates that the sequence position (expected sequence number) of 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 first data packet, forwarding node B forwards the second data packet, and forwarding node C forwards the third data packet.

Alternatively, the expected sequence number of each forwarding node is represented in descending order. The larger the expected sequence number of the forwarding node_i is, the closer the sequence position of the forwarding node_i is to the first forwarding node of the expected forwarding path, and the earlier the forwarding node_i performs data message forwarding compared to other forwarding nodes.

Of course, the sequential position of forwarding node_i in the expected forwarding path and the expected sequence number of forwarding node_i are not necessarily in a numerically equal relationship, and the sequential position of forwarding node_i in the expected forwarding path can also be calculated using the expected sequence number of forwarding node_i through a formula or table. Alternatively, the sequential position in the expected forwarding path can also be in other data forms besides the sequence number. As long as the data that can represent the sequential relationship between key nodes can be used as the sequential position in the expected forwarding path, this embodiment does not limit which data form the sequential position in the expected forwarding path uses.

In some implementations, the sequence position of the expected forwarding path is determined by the path planner during the path planning stage. For example, the path planner assigns a corresponding sequence position to each key node based on the path planning requirements to characterize the sequence relationship of forwarding data packets by each key node.

Regarding the use of the sequential position in the expected forwarding path, in some embodiments of the present application, the sequential position in the expected forwarding path is used to determine the vector commitment, the calculation of the forwarding proof, and the verification of the forwarding proof. For example, the control plane uses the sequential position of each key node in the expected forwarding path when determining the vector commitment and the forwarding plane uses the sequential position of each key node in the expected forwarding path when calculating the forwarding proof. The specific use of the sequential position in the expected forwarding path can be referred to the introduction of the subsequent method embodiments.

(11) Sequential position in the actual forwarding path

The sequence position in the actual forwarding path is used to characterize the sequence relationship between the nodes passed 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.

In some embodiments, the data form of the sequential position in the actual forwarding path is a sequence number (also called a serial number), and the sequence number representing the sequential position in the actual forwarding path is 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 method 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.

Regarding the purpose 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 in the process of forwarding the data message, 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 forwarding proof determined by the sequence position in the actual forwarding path and the vector commitment determined by the sequence position in the expected forwarding path due to the inconsistency between the sequence position in the actual forwarding path and the sequence position in the expected forwarding path, resulting in the forwarding proof determined by the sequence position in the actual forwarding path being unable to pass the verification and thus causing the 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 the fault tolerance of non-critical nodes. Of course, in the case where the fault tolerance of non-critical nodes does not need to be achieved, 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.

In some embodiments of determining the sequential position of the actual forwarding path, in a scenario applied to an Internet Protocol version 4 (IPv4) network, the sequential position of the actual forwarding path is determined based on TTL. As an example, a data message includes an IPv4 header, and the IPv4 header includes a time to live (TTL). The forwarding node_i identifies the value of the TTL and obtains the position i of the forwarding node_i on the forwarding path based on the value of the TTL. If the initial value of the TTL is k, since the value of the TTL decreases by 1 for each node passed, when the forwarding node_i receives a data message and identifies that the value of the TTL carried by the data message is n-i, the node_i determines that the node is the i-th node in the forwarding path. As an example, after the first forwarding node in the forwarding path receives the data message, the first forwarding node determines that the sequence position of the node in the actual forwarding path is 256-255=1 based on the TTL in the data message being 255. The first forwarding node updates the TTL in the data message from 255 to 254 and then forwards it to the second forwarding node. After the second forwarding node in the forwarding path receives the data message, the second forwarding node determines that the sequence position of the node in the actual forwarding path is 256-254=2 based on the TTL in the data message being 254. The second forwarding node updates the TTL in the data message from 254 to 253 and then forwards it to the third forwarding node. After the third forwarding node in the forwarding path receives the data message, the third forwarding node determines that the sequence position of the node in the actual forwarding path is 256-253=3 based on the TTL in the data message being 253, and so on.

In some embodiments of determining the sequential position of the actual forwarding path, in the scenario applied to the IPv6 network, the sequential position of the actual forwarding path is determined based on the hop limit. As an example, the data message includes an IPv6 message header (IPv6 header), the IPv6 message header includes hop limit, the forwarding node_i identifies the value of hop limit, and obtains the position i of the forwarding node_i on the forwarding path based on the value of hop limit. If the initial value of hop limit is k, since the value of hop limit decreases by 1 for each node passed, when the forwarding node_i receives the data message, it is identified that the value of hop limit carried by the data message is n-i, then the node_i determines that the node is the i-th node in the forwarding path. As an example, after the first forwarding node in the forwarding path receives the data message, 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 message is 255. The first forwarding node updates the hop limit in the data message from 255 to 254 and then forwards it to the second forwarding node. After the second forwarding node in the forwarding path receives the data message, the second forwarding node determines that the sequence position of this node in the actual forwarding path is 256-254=2 based on the hop limit in the data message is 254. The second forwarding node updates the hop limit in the data message from 254 to 253 and then forwards it to the third forwarding node. After the third forwarding node in the forwarding path receives the data message, the third forwarding node determines that the sequence position of this node in the actual forwarding path is 256-253=3 based on the hop limit in the data message is 253, and so on.

In some implementations of determining the sequential position of the actual forwarding path, in the scenario of SFC, the sequential 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 range is from 255 to 0, and the SI decreases by 1 every time a data message passes. After the forwarding node identifies the value of SI in the NSH, it can use the value of 256-SI as the sequential position of the node in the actual forwarding path.

(12) The difference between the sequence position of the expected forwarding path and the sequence position of the actual forwarding path

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

In some scenarios, because the actual forwarding path passes through one or more non-critical nodes, and these non-critical nodes are not arranged into the expected forwarding path by the path planning party, the sequence position of the forwarding node in the actual forwarding path is deviated from the sequence position of the forwarding node in the expected forwarding path. The sequence deviation between the sequence position of the forwarding node in the actual forwarding path and the sequence position of the forwarding node in the expected forwarding path represents the number of non-critical nodes located upstream of the critical node in the actual forwarding path.

For example, please refer to (a) in FIG. 1 , the sequence position of forwarding node B in the expected forwarding path is 2. Since there are key nodes A and forwarding node b upstream of forwarding node B in the actual forwarding path, key nodes A and forwarding node b are not 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 nodes 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. Since there are key nodes A, forwarding node b and forwarding node c upstream of forwarding node C in the actual forwarding path, key nodes A, forwarding node b and forwarding node c are not 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).

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 position of the first forwarding node in the actual forwarding path and the sequential position of 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 between the first forwarding node and the second forwarding node.

For example, please refer to (a) in Figure 1, the sequence positions of the key node A and the forwarding node B in the expected forwarding path are 1 and 2 respectively, and the sequence positions of the key node A and the forwarding node B in the expected forwarding path are continuous. Since two non-key nodes (node a and node b) are inserted between the key node A and the forwarding node B in the actual forwarding path, the sequence positions of the key node A and the forwarding node B in the actual forwarding path are 1 and 4 respectively, and the sequence positions of the key node A and the forwarding node B in the actual forwarding path are not continuous. The sequence position deviation of the key node A and the forwarding node B in the actual forwarding path represents the number of non-key nodes between the key node A and the forwarding node B.

For another example, the sequence positions of forwarding node B and forwarding node C in the expected forwarding path are 2 and 3 respectively, and the sequence positions of forwarding node B and forwarding node C in the expected forwarding path are continuous. Since a non-critical node (node c) is inserted between forwarding node B and forwarding node C in the actual forwarding path, the sequence positions of forwarding node B and forwarding node C in the actual forwarding path are 4 and 6 respectively, and the sequence positions of forwarding node B and forwarding node C in the actual forwarding path are not continuous. The sequence position deviation of forwarding node B and forwarding node C in the actual forwarding path represents the number of non-critical nodes between forwarding node B and forwarding node C.

In some embodiments, the sequence of at least two key nodes in the expected forwarding path is the same as the sequence of each key node in the actual forwarding path, and the sequence position of at least two key nodes in the expected forwarding path is different from the sequence position of each key node in the actual forwarding path. In other words, the sequence 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 sequence 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 sequence 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 sequence position (2) of forwarding node B in the expected forwarding path is different from the sequence position (4) of forwarding node B in the actual forwarding path, and the sequence position (3) of forwarding node C in the expected forwarding path is different from the sequence position (6) of forwarding node C in the actual forwarding path.

(13) Recordability of non-critical nodes

The recordability of non-critical nodes is a technical effect that is expected to be achieved by 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 a 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 critical nodes in the actual forwarding path. For example, based on the discontinuity of the sequential position of two adjacent critical nodes in the actual forwarding path recorded, it is determined that there are non-critical nodes between the two critical nodes. Based on the difference in the sequential position 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 position 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.

The recording position of non-critical nodes includes multiple implementations. In some embodiments, in the process of forwarding data messages, the critical node adds a list of sequential positions of the critical nodes in the actual forwarding path to the data message to achieve 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 that is independent of the data message and carries a list of sequential positions of the critical nodes in the actual forwarding path. In some further embodiments, the critical node saves the list of sequential positions of the critical nodes in the actual forwarding path in a locally saved log record.

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 2 non-key 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 1 non-key node between this node and the previous key node 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.

(14) Vector Commitment

For ease of 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 embodiment of the present application.

Vector commitment is a type of data obtained through cryptographic technology. Vector commitment is used to prove the correctness of the value and position of each piece of information in a set of ordered information (such as a vector, array, or list containing at least two elements), while supporting the hiding of the information, and usually does not need to expose the original content of the information. Specifically, vector commitment allows each piece of information in a set of ordered information to be committed and a corresponding proof to be generated, which other parties can verify to confirm the integrity of the ordered information. Vector commitment is often seen in zero-knowledge proofs. Vector commitment mainly includes three stages: commit, open, and verify.

The commitment phase refers to the calculation phase of the vector commitment. For example, entity A secretly selects N sequential information M = (m_1, m_2, ..., m_N) at one time, then calculates a commitment based on information M and makes the commitment public. The commitment contains the sequential relationship between information M and the N information inside information M, but the outside world cannot infer the plaintext of the N information through the commitment, nor can it infer the corresponding position of each information in the N information through the commitment. Usually after the commitment is calculated based on information M, entity A can no longer modify information M. The calculation of vector commitment can be achieved through the commitment function.

The opening phase refers to the proof calculation phase. The proof is used to prove the information at a specific location. Specifically, entity A calculates the opening proof (OP) and makes it public, thereby proving that the information promised at a certain location i is m_i. The proof calculation is implemented by the opening function. The opening function includes a single point opening function and a batch opening function.

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.

The batch open function means that entity A calculates a multi-proof (MP) at one time. The multi-proof is used to prove that the set formed by multiple information m_i is B, where each m_i is at its corresponding position i. Through the multi-proof, information at multiple positions can be verified at the same time. The computational complexity of multi-proof is usually higher than that of single-proof. The calculation method of multi-proof can refer to the following link.

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

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

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

Batch verification means that for multi-point open proofs, 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 what is declared in the open proof.

For a more detailed explanation of vector commitments, please 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.

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), and the information m_i in 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 vector commitment is order preservation, that is, the information m_i of the commitment and opening proof must be bound to the position i.

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. In order to distinguish 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. The device-level vector commitment is, for example, obtained based on the identity information of each forwarding node in the expected forwarding path and the sequential relationship of each forwarding node in the expected forwarding path. The AS-level vector commitment is, for example, obtained based on the identity information of each AS passed through in the expected forwarding path and the sequential relationship of each AS passed through by the expected forwarding path.

(15) KZG polynomial commitment

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

(16) Forwarding Proof

Embodiments of the present application relate to the application of forwarding proofs in device-level path verification and the application of forwarding proofs in AS-level path verification. In order to distinguish different forwarding proofs, the forwarding proof applied in device-level path verification is described by "first forwarding proof" or "device-level forwarding proof", and the forwarding proof applied in AS-level path verification is described by "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 a 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 a forwarding path. The forwarding proof includes a single-point forwarding proof (OP) and a multi-point forwarding proof (MP).

OP represents a forwarding proof related to a single forwarding node, which is used to prove that a single specific node forwards a data message at a specific sequential position corresponding to the specific node in the forwarding path. Alternatively, OP represents a forwarding proof related to a single AS, which is used to prove that a single specific AS forwards a data message at a specific sequential position corresponding to the specific node in the forwarding path.

MP (multi proof) represents a forwarding proof related to multiple forwarding nodes, which is used to prove that each node in a specific path forwards data packets at the corresponding sequential position. For example, for the expected forwarding path key node A→key node B→key node C→key node D, 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 MP includes the MP of path AB, the MP of path ABC, and the MP of path ABCD. Alternatively, MP represents a forwarding proof related to multiple ASs, which is used to prove that multiple ASs forward data packets at corresponding specific sequential positions in the forwarding path.

A method for obtaining a single-point forwarding certificate is to obtain the single-point forwarding certificate of the verified node 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.

The single-point forwarding proof of the verified node is used to prove that the verified node forwarded the data message A and the sequence position of the verified node is correct. Taking the verified node as key node A as an example, key node A obtains forwarding proof A based on the identity information of key node A, the sequence position of key node A in the expected forwarding path, and cryptographic parameters. Forwarding proof A is a single-point forwarding proof, and forwarding proof A is used to prove that key node A forwarded this data message in the expected sequence position. Optionally, key node A uses a single-point open function (open) to obtain single-point forwarding proof A, single-point forwarding proof A = open (i, r_i).

A method for obtaining a multi-point forwarding certificate is to obtain the multi-point forwarding certificate based on the sequential positions of at least two key nodes in an expected forwarding path and the identity information of at least two key nodes.

For example, the verified node obtains a first forwarding proof 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, and the first forwarding proof is used to prove that the verified node and the second forwarding node are respectively in corresponding sequential positions in the expected forwarding path.

Taking the verified node as key node i as an example, for example, key node i obtains 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, and forwarding proof p_i is used to prove that key node 1 forwards a data message at sequence position 1, key node 2 forwards a data message at sequence position 2... and key node i forwards this data message at sequence position i. Optionally, key node i uses a batch open function (batchopen) to obtain forwarding proof p_i, p_i = batchopen (r_1,..., r_i).

Whether it is 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, rather than the sequence position in the actual forwarding path. Taking Figure 1 as an example, the sequence position of the three key nodes used in determining and verifying the forwarding proof is the expected continuous sequence position 1, 2, 3, rather than the actual non-continuous sequence position 1, 4, 6. Since 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.

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 the single-point forwarding proof and the multi-point forwarding proof. In some embodiments, one of the single-point forwarding proof and the multi-point forwarding proof is used.

A method for obtaining a single-point forwarding certificate is to obtain the single-point forwarding certificate of the verified node 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.

The single-point forwarding proof of the verified node is used to prove that the verified node forwarded the data message A and the sequence position of the verified node is correct. Taking the verified node as key node A as an example, key node A obtains forwarding proof A based on the identity information of key node A, the sequence position of key node A in the expected forwarding path, and cryptographic parameters. Forwarding proof A is a single-point forwarding proof, and forwarding proof A is used to prove that key node A forwarded this data message in the expected sequence position. Optionally, key node A uses a single-point open function (open) to obtain single-point forwarding proof A, single-point forwarding proof A = open (i, r_i).

A method for obtaining a multi-point forwarding certificate is to obtain the multi-point forwarding certificate based on the sequential positions of at least two key nodes in an expected forwarding path and the identity information of at least two key nodes.

For example, the verified node obtains a first forwarding proof 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, and the first forwarding proof is used to prove that the verified node and the second forwarding node are respectively in corresponding sequential positions in the expected forwarding path.

Taking the verified node as key node i as an example, for example, key node i obtains 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, and forwarding proof p_i is used to prove that key node 1 forwards a data message at sequence position 1, key node 2 forwards a data message at sequence position 2... and key node i forwards this data message at sequence position i. Optionally, key node i uses a batch open function (batchopen) to obtain forwarding proof p_i, p_i = batchopen (r_1,..., r_i).

Whether it is 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, rather than the sequence position in the actual forwarding path. Taking Figure 1 as an example, the sequence position of the three key nodes used in determining and verifying the forwarding proof is the expected continuous sequence position 1, 2, 3, rather than the actual non-continuous sequence position 1, 4, 6. Since 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.

For the sake of simplicity, the embodiments of the present application sometimes use the form of "OP+underscore+position" to simplify the single-point forwarding proof calculated by a node at a specific sequential position. The form of "MP+underscore+position" is used to simplify the multi-point forwarding proof obtained by calculating a node at a specific sequential position, such as 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.

(17) Identity information of the forwarding node

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.

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 some other possible implementations, the identity information of the forwarding node_i is a publicly verifiable and unforgeable identity proof that can only be calculated by the forwarding node_i and can be verified by multiple parties. Exemplarily, the identity information of the forwarding node_i includes identity information encrypted based on the key of the forwarding node_i. Optionally, the identity information encrypted based on the key of the forwarding node_i is identity information encrypted based on the symmetric key of the forwarding node_i; or, the identity information encrypted based on the key of the forwarding node_i is identity information encrypted based on the private key of the forwarding node_i. By using the encrypted identity information to calculate the forwarding proof or verify the forwarding proof, the security and privacy of the calculation and verification of the forwarding proof are further improved due to the higher security and privacy of the identity information.

Exemplarily, the identity information of the forwarding node_i includes the address of the forwarding node_i. The address used as the identity information of the forwarding node_i is optionally the IP address of the forwarding node_i. For example, the address used as the identity information of the forwarding node_i is the IPv4 address of the forwarding node_i or the IPv6 address of the forwarding node_i. Alternatively, the address used as the identity information of the forwarding node_i is the media access control (MAC) address of the forwarding node_i.

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

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

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.

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

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

Exemplarily, the identity information of forwarding node_i includes the router ID of forwarding node_i.

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

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

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

Exemplarily, the identity information of the forwarding node _i includes a zero-knowledge (non-interactive zero-knowledge, NIZK) proof. Zero-knowledge is a cryptographic technique used to prove the truth 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.

Exemplarily, the identity information of the forwarding node _i includes the Sigma protocol proof. The Sigma protocol proof is an interactive protocol based on zero-knowledge proof. It allows a prover to prove that a statement is true in the interaction with the verifier without revealing the true information about the statement. In the Sigma protocol proof, the prover and the verifier interact in multiple rounds to achieve the purpose of mutual authentication. The prover tries to prove the authenticity of a statement to the verifier, while the verifier wants to confirm the authenticity of the statement and believes that the prover does know how to prove the statement. But the special nature of the protocol is that the prover cannot reveal the true information of the statement to the verifier, thereby protecting the privacy of the prover.

(18)segment list

The segment list is information used to indicate the expected forwarding path in the SRv6 scenario. The segment list includes a series of SIDs, each of which represents a node or link in the network. The segment list is arranged in reverse order, that is, the SIDs in the segment list are arranged in the order from the tail node to the 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.

(19) Time to live (TTL)

TTL is a field in the IPv4 header, which is used to limit the transmission time or number of hops of a datagram in the network. TTL is expressed as an integer. Each time a datagram passes through a forwarding node, TTL decreases by 1. When the TTL value decreases to 0, the datagram will be discarded and a timeout message will be returned to the source node. TTL is located in the 9th byte of the IPv4 header, which occupies one byte (8 bits) and is used to store the TTL value.

(20) Hop limit

In the IPv6 protocol, TTL is called hop limit, which is also carried in a field in the IPv6 header. Hop limit is equivalent to TTL in IPv4 and is used to limit the number of hops of a datagram in the network. The 7th byte of the IPv6 header occupies one byte (8 bits) to store the hop limit value.

(21) Autonomous system (AS)

AS refers to a group of network devices with the same routing policy, which are managed by the same entity. Each AS is assigned an AS number (autonomous system number) in the Internet, so that other network devices can find the corresponding AS based on the AS number. For the sake of simplicity, the embodiments of this application will use the form of "AS+number" to simplify the specific AS, such as an AS is simplified as AS1.

(22) AS identity information

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 the 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. Through the AS number, an AS can be uniquely identified 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.

(23) Autonomous system path (AS_path)

AS_path is a path attribute in the BGP protocol. AS_path is usually carried by BGP protocol messages. AS_path is used to record the ASs that are passed from the source AS to the destination AS. AS_path includes a series of AS numbers, which are used to describe all ASs that the BGP protocol message passes through from the source AS to the destination AS. A pair of adjacent ASs in AS_path represents two ASs with upstream and downstream relationships in the forwarding path. According to AS_path, the order relationship 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 AS_path, and the AS_path is [AS 3AS1AS 6], which means that the address prefix P1 is initiated by AS 6, then the address prefix P1 passes through AS1, and finally the address prefix P1 reaches AS 3. From AS_path, it can be determined that when forwarding a data message with a source address matching the address prefix P1, the order relationship between the three ASs 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, please refer to the description in Section 4.3 "Path Attributes" of RFC 4271.

(24)AS List

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 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 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 by the expected forwarding path, the second AS number in the AS list identifies the second AS passed by the expected forwarding path, and so on.

The following is an example of the application scenario of the device-level path verification method and the corresponding method flow.

Many source address or centralized 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 function of specifying a network path on the control plane. However, one challenge is that even if the source host or centralized controller specifies a path on the control plane, the source host or centralized controller cannot know whether the data packet 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 problems may cause the actual forwarding path on the data plane to deviate from the expected forwarding path on the control plane.

Among them, route hijacking attack refers to the attacker hijacking and/or diverting network traffic to network devices or ASs 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 inputting forged routing information into network devices such as routers, so that the forged routing information is propagated throughout the network. An attacker can change the routing path of the network through route injection, causing the traffic to be redirected to the path controlled by the attacker. Traffic detour refers to the attacker tampering with the configuration of the network device to detour the traffic from the expected path, causing the traffic to be redirected to the path specified by the attacker.

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.

In view of this, the trusted path mechanism (also called secure routing mechanism or path validation mechanism) came into being, which can solve the above problems, so that data packets can and can only be forwarded hop by hop according to the forwarding path planned by the path planner, and can provide publicly verifiable forwarding proof. A complete trusted path mechanism includes two technical parts: path locking mechanism and path validation mechanism, which can also be considered as the coordination of protocols and methods at the control plane and data plane levels.

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.

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

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

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

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 by the correct node when the data message is forwarded to the correct position on the forwarding path, so that the forwarding proof and the actual forwarding situation of the data message have strong binding, and the forwarding proof has public verifiability that is difficult to tamper with, thereby solving the problem of poor credibility of the proof due to the irrelevance of the forwarding proof to the position of the forwarding node on the forwarding path. The above-mentioned implementation method 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.

Although the above implementation method achieves absolute order preservation, the strictness of 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 forwarding proof, and does not allow any form of "forwarding data messages but not calculating forwarding proof" nodes in the actual forwarding path. However, in IP networks, there are a large number of weak or obsolete 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 forwarding proofs. This embodiment defines these forwarding nodes as non-critical nodes. Considering compatibility and availability, these non-critical nodes need to be fault-tolerant, for example, tolerating the insertion of non-critical nodes in the middle of critical nodes, or tolerating 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 locking mechanism of the forwarding path and the forwarding path verification mechanism support fault tolerance for non-critical nodes is the most important effect of this embodiment.

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 several effects expected to be achieved by the embodiments of this application.

Technical effect 1: Forwarding path locking

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 through the commitment function in the vector commitment technology based on the sequential position of each key node in the expected forwarding path and the identity information of each key node. 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.

In some implementations, each key node obtains the forwarding proof OP related to a single key node based on a single-point opening function when receiving data messages in sequence, and publishes the forwarding proof OP related to the single key node externally; the key node or the external verification node verifies the forwarding proof OP related to the single key node based on the single-point verification function, thereby verifying whether the order of a certain key node actually passed is consistent with the expected order of the key node. In another possible implementation, each key node obtains the forwarding proof MP related to multiple key nodes based on a multi-point opening function when receiving data messages in sequence, 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.

Technical Effect 2: Source Correctness

Source correctness refers to verifying the correctness of the source of the data message. Source correctness includes the correctness of the previous hop and the correctness of the first half of the path.

The correctness of the previous hop is, for example, when the key node i receives the data message _i, the key node i verifies the forwarding proof of the previous hop i-1 carried by the data message _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 message 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 message is correct.

The correctness of the upper half path, for example, is 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 upper 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 upper half path of the data packet is correct.

The following is an example of how to achieve source correctness.

The verification method for the correctness of the previous hop is to verify the single-point forwarding proof (OP) based on the location information of a single key node and the identity information of a single key node. For example, the data message 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 message 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, and k is a positive integer less than or equal to i.

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 message received by key node i carries the single-point forwarding proof generated by the previous hop node (node_i-1) of key node i, and the single-point forwarding proof is used to prove that node_i-1 forwards the data message at position i-1 on the forwarding path. Key node i verifies the single-point forwarding proof carried by the data message based on the vector commitment, the identity information of node_i-1, and the location information of node_i-1. Similarly, each hop node is responsible for verifying the single-point forwarding proof of the previous hop node.

Method 2 for the correctness of the first half of the path is to 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 the key node i carries the multi-point forwarding proof related to the key node_k and the key node_m. The key node i verifies the multi-point forwarding proof related to the key node_k and the key node_m based on the vector commitment, the identity information of the key node_k, the location information of the key node_k, the identity information of the key node_m and the location information of the key node_m. The key node_k is the upstream node of the key node i in the forwarding path, and the key node_m is the upstream node of the key node_k in the forwarding path. The multi-point forwarding proof is used to prove that the key node_k forwards the data message at position k on the forwarding path, and the key node_m forwards the data message at position m on the forwarding path. The multi-point forwarding proof is obtained based on the position k, the identity information of the key node_k, the position m and the identity information of the key node_m, k is a positive integer less than or equal to i, and m is a positive integer less than or equal to k.

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 the key node receives the data message, if it is determined that the message header of the data message contains a trusted path identifier, the forwarding proof carried by the data message is verified.

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 makes it public. If the forwarding proof carried by the data message fails the verification, the key node does not need to calculate the forwarding proof, for example, directly discards the data message.

Technical Effect 3: Computational Efficiency and Communication (Space) Efficiency

Computational efficiency and communication (space) efficiency refer to reducing the computation time of proof and the verification time of proof, and reducing the amount of data of additional proofs and/or parameters that need to be transmitted, while meeting security conditions. The computation time and verification time of proofs implemented in the embodiment of the present application are both constant-level time, and the amount of data of additional proofs is constant-level data, which is independent of the number of nodes N included in the forwarding path.

Vector commitment mechanism is a general term for a class of technologies, and vector commitment includes a variety of specific construction methods. Optionally, a method based on KZG polynomial commitment (kate-zaverucha-goldberg polynomial commitment) is used to obtain and verify commitments based on the identity information and location information of the forwarding node, thereby further reducing the time to obtain commitments, improving the efficiency of obtaining commitments, and avoiding the superlinear growth of the verification time of the forwarding proof as the number of nodes in the forwarding path increases, making the verification time of the forwarding proof as short as possible.

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

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

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

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

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

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

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

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

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

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

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

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

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.

Technical Effect 4: Fault Tolerance of Non-Critical Nodes

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

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.

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

There are two ways to implement the fault tolerance mechanism.

Fault-tolerance implementation method 1: In the commitment phase, a 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, so that the vector commitment binds the correspondence between the identity information and the sequential position. For example, each key node is mathematically represented by a binary tuple (x_i＝i, y_i＝r_i), where i is the expected sequence number of the key node in the expected forwarding path, and r_i is the identity information of the key node with the expected sequence number i in the expected forwarding path. The vector commitment is bound to the binary tuple (x_i＝i, y_i＝r_i) of each key node in the expected forwarding path.

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

The second implementation method of fault tolerance is that in the commitment stage, the correspondence between the identity information and the sequential position of the key node is no longer bound, but only the identity information of the key node 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 node 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 the key node i, and 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. And 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 message has passed through this key node, but cannot prove the correctness of the sequence position of the key node, resulting in some loss of position binding.

Technical Effect 5: Recordability of Non-Critical Nodes

Optionally, based on the first fault-tolerant implementation method, the key node records the sequence position of the node in the actual forwarding path during the process of forwarding data packets. Based on the recorded sequence position of the key node in the actual forwarding path, it can be inferred whether there are non-key nodes in the actual forwarding path and the number of non-key nodes in the actual forwarding path, thereby achieving the recordability of non-key nodes. In addition, since the sequence position of the actual forwarding path is recorded by the key node, it is not necessary to require the non-key node to perform additional actions other than forwarding, and the existence of the non-key node can be recorded indirectly, which has better compatibility.

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

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 the actual sequence position 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, whenever a data message passes through a key node, the actual sequence position list carried in the data message will increase the actual sequence position of a 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.

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

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.

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 up to 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.

For example, the expected forwarding path planned by the controller is ABCD, and the sequence positions corresponding to the key nodes A, B, C, and D are 1234 respectively. There is one non-key node between the key nodes A and B, two non-key nodes between the key nodes B and C, and two non-key nodes between the key nodes C and D. In this scenario, the key node A adds the sequence position (1) of the node in the actual forwarding path to the first table item in the actual sequence position list carried in the data message, the key node B adds the sequence position (3) of the node in the actual forwarding path to the second table item in the actual sequence position list carried in the data message, the key node C adds the sequence position (5) of the node in the actual forwarding path to the third table item in the actual sequence position list carried in the data message, and the key node D adds the sequence position (9) of the node in the actual forwarding path to the fourth table item 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.

In other embodiments, the non-critical node records the sequential position of the node in the actual forwarding path during the process of forwarding the data message, thereby achieving the recordability of the non-critical node. For example, 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. After receiving the data message, 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 message, adds the sequential position of the node in the actual forwarding path to the actual sequential position list carried by the data message, or sends the sequential position of the node in the actual forwarding path to the verification node.

Due to the use of vector commitment, the embodiment of the present application can achieve the technical effect 1 of key path binding and the source correctness of technical effect 2. Due to the use of polynomial commitment technology, the embodiment of the present application can achieve the technical effect 3 of computational efficiency and communication (space) efficiency.

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

The embodiments of the present application provide a general trusted path protection technology, which can realize the protection of the data plane forwarding path, so it can be applied to any scenario in any layer of the 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 in different protocol scenarios mainly lies in the differences in the message headers carrying commitments and forwarding certificates and the specific carrying locations. The following first describes the general trusted path protocol steps, functions and roles, and then explains the specific embodiments in different protocol scenarios.

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

The path planner is used to determine a network forwarding path in any of the network layers listed above. The 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). Among them, r_i is the publicly verifiable identity information of forwarding node i. After determining this forwarding path, the path planner needs to calculate the commitment C corresponding to this forwarding path. The path planner obtains the identity information of all forwarding nodes in the network in advance.

Optionally, the path planner performs remote attestation secret distribution, where the secret is the identity information of the forwarding node in ciphertext form. For example, the path planner sends the ciphertext of the identity information of the corresponding forwarding node to each of the N forwarding nodes in the expected forwarding path, so that the N forwarding nodes in the expected forwarding path determine the vector commitment based on the received ciphertext of the identity information.

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.

When each key node receives a data message with a trusted path identifier in the message header, it calculates a forwarding proof p_i and publishes the forwarding proof p_i to the verification node. p_i is, for example, a single-point proof (OP), which is used to prove that the key node r_i at position i forwarded the data message; p_i can also be a multi-point proof (MP), which is used to prove that the key nodes (r_1, r_2, ..., r_i) at positions i from 1 to i have forwarded the data message at the correct location.

A verification node is also called an observer. A verification node is, for example, any device that cares about the credibility of the forwarding path. The verification node is used to verify the forwarding proof calculated by the forwarding node based on the commitment C generated by the controller, the identity of the forwarding node, and the location of the forwarding node. In one possible implementation, the verification node is unbiased, that is, the observation and verification results of the verification node are the same as the output of the protocol in the correct case.

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

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 through which the actual forwarding path passes. Since the processing processes performed by different key nodes have commonalities, in order to simplify the description, the method shown in Figure 2 focuses on the processing process performed by two key nodes as an example. Of course, there may be three or more key nodes in the actual forwarding path, and the processing processes performed by more key nodes can refer to the processing processes performed by key node A or key node B.

Key node A and key node B are 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 node A and key node B in sequence.

The method shown in FIG2 involves a process of forwarding nodes processing data packets. In order to distinguish the description, "first data packet" is used to describe the data packet that serves as input data, and "second data packet" is used to describe the data packet that serves as output results. Both the first data packet and the second data packet carry business data. The destination of the second data packet includes multiple 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 program or operating system of the device and is processed by itself.

The method shown in FIG2 relates to an application scenario of how to achieve fault tolerance of non-critical nodes. For example, there is at least one non-critical node between at least two critical nodes in the actual forwarding path of the first data message. For example, the sequence of at least two critical nodes in the expected forwarding path of the first data message is the same as the sequence of the at least two critical nodes in the actual forwarding path of the first data message, and the sequence position of at least two critical nodes in the expected forwarding path is different from the sequence position of the at least two critical nodes in the actual forwarding path.

The method shown in FIG. 2 includes the following steps.

S210: The path planner determines an expected forwarding path.

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 P consisting of the identity information of each key node in the N key nodes and the sequential position of each key node in the N key nodes, where 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 a path selection step.

S220: The path planner determines a first vector commitment.

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.

In some embodiments, the input data used by the path planner in determining the vector commitment includes an expected forwarding path of length N, such as a vector P = (r_1, r_2, ..., r_N). The path planner uses the commitment function in the vector commitment mechanism to calculate a vector commitment C = commit(P) bound to the expected forwarding path P based on the identity information of each of the N key nodes and the sequential position of each of the N key nodes. The path planner outputs a commitment C of length k, where k is related to the security parameter lambda.

In a possible implementation, according to the verification algorithm of the vector commitment, if the verification result of the commitment C, position i, identity r_i and related auxiliary data for the forwarding proof is 1, it means that the forwarding proof has passed the verification. If the verification result of the commitment C, position i, identity r_i and related auxiliary data for the forwarding proof is 0, it means that the forwarding proof has not passed the verification. Auxiliary data is, for example, the cryptographic parameters based on which the commitment is calculated. S220 is also called a path commitment or path initialization step.

In one possible implementation, before forwarding a data message, the controller distributes the identity information and auxiliary data required for calculating the forwarding proof to each key node in the expected forwarding path, thereby achieving data pre-distribution. Auxiliary data, for example, is the cryptographic parameters based on which the vector commitment is calculated.

Optionally, the path planner also sends a first vector commitment to the verification node before forwarding the data message, so that the first vector commitment is delivered to the verification node by means of control plane pre-distribution. Alternatively, the path planner sends the first vector commitment to the first key node in the expected forwarding path, and the first key node in the expected forwarding path adds the first vector commitment to the data message, so that the first vector commitment is delivered to the verification node together with the service data.

S230, key node A obtains data message A.

Data message A carries service data. Optionally, data message A also carries a vector commitment, so that the verification node verifies the forwarding proof by obtaining the vector commitment carried in the data message.

Optionally, data packet A also carries a trusted path identifier, thereby triggering a determination process and/or a verification process of the forwarding certificate through the trusted path identifier.

The source of data message A includes many 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.

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

In a possible implementation, if key node A determines that the header of data message A carries a trusted path identifier, it executes the subsequent steps of obtaining forwarding proof based on identity information and sequence position. If key node A determines that the header of data message A does not carry a trusted path identifier, it does not need to execute the subsequent steps of obtaining forwarding proof based on identity information and sequence position, and forwards data message A to the next forwarding node. The trusted path identifier is used to indicate that data message A needs to be forwarded through a trusted path.

By including a trusted path identifier in the header of a data message, the forwarding node is supported to decide whether to calculate the forwarding proof based on the presence or absence of the identifier. For example, if key node A determines that the data message does not carry a trusted path identifier, key node A uses the original forwarding mechanism without calculating the forwarding proof.

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 the 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 a target application, the step of obtaining a forwarding certificate is executed.

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

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.

The verified node refers to the forwarding device that is the object of verification. The verified node includes but is not limited to the current node, the neighboring node of the current node, and each node from the first forwarding node to the current node. The sequence position of the verified node in the expected forwarding path is different from the sequence position of the key node A in the actual forwarding path of the data packet A. The identity information of the verified node indicates the identity of the key node A.

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 the 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 helps to verify whether this node is the expected forwarding node or whether the sequential position of this 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.

In some implementations, the verified node includes a neighbor node of the current node.

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 is helpful 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 message transmission to an unexpected forwarding node.

For another example, the verified node is the previous node of the current node. When the data message is transmitted to the key node B, the verified node is the key node A. The key node B obtains the sequence position of the key node A in the expected forwarding path and the identity information of the key node A. The key node B obtains the forwarding proof A based on the sequence position of the key node A in the expected forwarding path and the identity information of the key node A. By performing path verification on the next node, it is helpful 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 message transmission to an unexpected forwarding node.

For another example, the verified nodes include the current node and the previous node of the current node. When the data message is transmitted to the key node A, the verified nodes include the key node A and the previous node of the key node A (for example, the source host). The key node A obtains the forwarding proof A 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 previous node of the key node A in the expected forwarding path, and the identity information of the previous node of the key node A. Through the forwarding proof A, it can be verified whether the key node A and the previous node of the key node A both forward the data message in the expected sequential position. In this case, the key node A corresponds to the first forwarding node, and the previous node of the key node A corresponds to the second forwarding node.

In some embodiments, the verified node includes each node from the first forwarding node to the current node. For example, when the data message is transmitted to the key node B, the verified node includes the key node A and the key node B. The key node B obtains 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. The key node B obtains the forwarding proof A 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. By performing path verification on each node passed by the first half of the path, it is helpful to verify whether the data message passes through an unexpected forwarding node.

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.

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.

In some embodiments, a predetermined field of data message A carries the sequential position of the verified node in the expected forwarding path. For example, the header of data message A carries the sequential position of the verified node in the expected forwarding path. For example, the header of the data message 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.

In some embodiments, the key node A further processes the content of the predetermined field in the data message A to obtain the sequential position of the verified node in the expected forwarding path. For example, the message header of the data message A carries the path information, and the path information includes the identifier of each key node in the expected forwarding path. The arrangement order of the identifier of each key node in the path information matches the arrangement order of the identifiers of each key node in the expected forwarding path. The key node A determines the sequential position of the verified node in the expected forwarding path based on the sequential position of the identifier of the verified node in the path information.

For example, in some implementations of obtaining the sequential position in the SRv6 scenario, data packet A includes a segment routing header (SRH), the SRH includes a segment list (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 in 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 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 segment list[N].

In some implementations of obtaining the sequential position in the 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 the corresponding relationship saved 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 for 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, by pre-distribution of the control plane.

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, which saves the performance overhead and computing overhead of the forwarding device to obtain the sequential position in the expected forwarding path through table lookup matching, and also saves the storage space occupied in the forwarding device to obtain the sequential position in the expected forwarding path through table lookup matching.

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

The control plane pre-distribution method is mainly implemented based on the interaction between the path planner and the forwarding node. For example, in the process of 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 the key node A. The key node A receives the sequential position of the verified node in the expected forwarding path from the path planner.

In some embodiments, the action of sending the sequential position of the verified node in the expected forwarding path is implemented based on the 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 the key node A, and the management plane protocol message carries the sequential position of the verified node in the expected forwarding path. The key node A receives the management plane protocol message and obtains the sequential position of the node in the expected forwarding path carried by the management plane protocol message. For another example, the path planning direction sends control plane protocol messages such as border gateway protocol (BGP) messages, path computation element protocol (PCEP) messages, or border gateway protocol flow spec (BGP flow specification, referred to as BGP flow spec or BGP FS) to key node A, and 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 by the control plane protocol message. For another example, the path planning direction sends application layer protocol messages such as APN messages and hypertext transfer protocol (HTTP) messages to key node A, and the application layer protocol message carries the sequence position of the verified node in the expected forwarding path.

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 from the first key node to key node i in the expected forwarding path to key node i.

In other embodiments, the network administrator configures the sequential position of each key node on the expected forwarding path in advance. Optionally, in the case of using the MP mode to calculate the multi-point forwarding proof, the network administrator also configures the sequential position of each key node upstream of the key node on the expected forwarding path at each key node on the expected forwarding path. For example, the configuration information saved by key node i includes the relative position of each key node from key node 1 to key node i in the forwarding path, and key node i obtains the relative position of each key node from key node 1 to key node i from the configuration information.

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

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

In some implementations, a predetermined field of data message A carries the identity information of the verified node. For example, a header of data message A carries the identity information of the verified node. For example, the header of the data message includes a TLV or a reserved field, and the TLV or the reserved field carries the identity information of the verified node.

As an example, the verified node is key node A, the destination address field of the IP header of data message 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 message A.

For example, when the OP mode is used to calculate the single-point forwarding proof, data message A carries the identity information of key node A, and key node A obtains the identity information of the node carried by data message A in order to calculate OP. For another example, when the MP mode is used to calculate the multi-point forwarding proof, data message A also carries the identity information of the second forwarding node, and key node A also obtains the identity information of the second forwarding node carried by data message A in order to calculate MP.

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.

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.

For example, in the process of 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.

S250, key node A obtains a node-level forwarding certificate A based on the sequential position of the verified node in the expected forwarding path and the identity information of the verified node.

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.

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

For example, the verified node is the next node of the current node (critical node B). 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 based on forwarding proof A whether the data message will be sent to a node with the expected sequence and the expected correct identity.

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

Key node A sends forwarding proof A to the verification node, so that the verification node can verify the sequence position and identity of key node A based on forwarding proof A. Data message B carries the business data in data message A. By sending data message B to key node B, the business data is sent from this node to the next key node that the path planner expects to pass through.

In the case where the key node B also serves as a verification node, or the key node downstream of the key node B (such as the tail node at the end of the path) also serves as a 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 (such as 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.

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

S320, key node B receives data message B from key node A.

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

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.

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.

For example, the verified node is the current node (critical node B), and critical node B obtains a 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 forwarding proof B.

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.

For example, the verified nodes include the current node (key node B) and the previous node of the current node (key node A), and the key node B obtains forwarding proof B based on the sequence position of the key node A in the expected forwarding path, the identity information of the key node A, the sequence position of the key node B in the expected forwarding path, and the identity information of the key node B, so as to verify whether the key node A forwards the data message in the expected sequence position and whether the key node B forwards the data message in the expected sequence position based on the forwarding proof B. In this case, the key node B corresponds to the first forwarding node, and the key node A corresponds to the second forwarding node.

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

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 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 based on the forwarding proof B 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 expected order and whose identity is consistent with the expected correctness.

For example, the verified node is each node passed by the upper half of the path, and the key node B obtains 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.

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.

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

In some implementations of the key node B verifying the correctness of the source of the data message B, the key node B verifies whether the data message B comes from the key node A, and the key node A is the previous key node of the key node B in the expected forwarding path. For example, the key node B verifies the correctness of the single-point forwarding proof OP_i-1 of the key node A carried in the data message B according to the identity information of the key node A, the expected sequence position of the key node A, and the node-level vector commitment, thereby verifying whether the previous hop of the data message B is correct; for another example, the key node B verifies the correctness of the multi-point forwarding proof MP_i-1 of the key node A carried in the data message B according to the identity information of the key node A, the expected sequence position of the key node A, the identity information of the key node B, the expected sequence position of the key node B, and the node-level vector commitment, thereby verifying whether the forwarding path segment that the data message B has passed is correct. In addition, the data message source verification step can also adopt other aggregatable proof methods, such as a cryptographic aggregator (accumulator), an aggregatable signature or a MAC tag, etc.

In some implementations, a key node also serves as a verification node, for example, the verification node is a key node C, which is a key node located downstream of a key node B in the expected forwarding path, and the key node B obtains a data message C based on the received data message B and a forwarding proof B of the key node B, and the key node B sends a data message C to the key node C, and the data message C includes a payload of the data message B and a forwarding proof B of the key node B. In this case, the key node B corresponds to the first forwarding node, the key node C corresponds to the third forwarding node and corresponds to the verification node, the data message B corresponds to the first data message, and the data message C corresponds to the second data message.

S270, the verification node obtains the forwarding proof, 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. At least two key nodes include the verified node, the identity information of the verified node indicates the identity of the verified node, and the forwarding proof of the verified node is used to prove that the verified node is in the sequential position of the verified node in the expected forwarding path.

In one possible implementation, in S250 and S260, a forwarding proof related to a single verified node is obtained based on a single-point opening function, and in S270, a forwarding proof related to a single verified node is verified based on a single-point verification function, thereby implementing verification of the proof of a 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 opening function, thereby implementing one-time verification of multiple nodes of a path.

Of course, the three functions of commitment, opening, and verification are only examples of several 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, which is equivalent to the open function) is used to obtain forwarding proofs, and in S270, a verification calculation function (verify eval, which is equivalent to the verification function) is used to obtain forwarding proofs; for another example, in S250 and S260, a batch creation witness function (create witness batch, which is equivalent to the batch open function) is used to obtain multi-point forwarding proofs, and in S270, a batch verification calculation (verify eval batch, which is equivalent to the batch verification function) is used to verify multi-point forwarding proofs.

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.

In some implementations, 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.

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.

On the contrary, 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 do not match, the output result of the verification function is 0, then 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 sequential position of the verified node in the actual forwarding path does not meet the requirements of the expected forwarding path.

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.

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

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

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

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

Second, it helps to hide the path. Since 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, and it is also difficult to decrypt or reverse the vector commitment to obtain the identity information and expected sequence position of the key nodes, thereby hiding 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.

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

The method provided in this embodiment obtains the forwarding proof by combining the position of the forwarding node on the forwarding path and the identity of the forwarding node, thereby realizing the position binding of the forwarding proof. That is, the forwarding proof is not only related to the identity of the forwarding node, but also to the position of the forwarding node on the forwarding path. Therefore, the correct forwarding proof can be calculated by the correct node when the data message is forwarded to the correct position on the forwarding path, so that the forwarding proof and the actual forwarding situation of the data message are strongly bound. For example, if a node in the path is skipped 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.

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 interrupting business data transmission or outputting alarms due to failure to verify the forwarding proof based on vector commitment.

In some implementations, 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.

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.

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

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

Transmission mode 1 is equivalent to the in-band mode. For example, when a key node forwards a data message, it adds the sequence position of the node in the actual forwarding path to the data message, and forwards the data message containing the service data and the actual sequence position of the node, so that the actual sequence position of the node is transmitted to the next forwarding node of the key node along with the service data. For example, a data message includes a message header and a payload field encapsulated in the inner layer of the message header. The message header carries the actual sequence position of the key node, and the payload field carries the service data.

In some embodiments, the actual sequence position and the forwarding proof are transmitted to the verification node along with the business data. For example, the verification node is a key node B located downstream of the key node A in the expected forwarding path. The key node A obtains the data message B based on the data message A, the forwarding proof of the key node A, and the sequential position of the key node A in the actual forwarding path. The data message B includes the payload of the data message A, the forwarding proof of the key node A, and the sequential position of the key node A in the actual forwarding path. 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.

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

Since the actual sequence position and the forwarding proof are carried in the same data message 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 messages to transmit the actual sequence position and the forwarding proof respectively. Therefore, the overall transmission overhead of the actual sequence position and the 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 message. 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.

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.

The following is an example of the actual sequential position of key nodes, forwarding proof, and the position of vector commitment in the message.

In the case of transmitting data based on the IPv6 protocol, in a 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). For another example, the actual sequence position, forwarding proof and vector commitment of key nodes are carried through the hop-by-hop options header (HBH). For 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 three specific examples of IPv6 extension headers that can carry forwarding proof.

Optionally, the forwarding proof is carried by TLV in the IPv6 extension header. For example, the actual sequence position of the key node, the forwarding proof and the vector commitment are carried by TLV in SRH. For another example, the actual sequence position of the key node, the forwarding proof and the vector commitment are carried by TLV in HBH. For another example, the actual sequence position of the key node, the forwarding proof and the vector commitment are carried by TLV in DOH.

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

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.

Exemplarily, the data message _i+1 includes an IPv6 extension header, and the IPv6 extension header includes a forwarding proof of the forwarding node _i and the vector commitment. For example, the IPv6 extension header of the data message _i+1 includes an SRH, and the SRH includes a first TLV, a second TLV, and a third TLV, and the first TLV of the SRH includes the forwarding proof of the forwarding node _i, and the second TLV of the SRH includes the vector commitment. The third TLV of the SRH includes the actual sequential position of the key node; or, the IPv6 extension header of the data message _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 message _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 message _i+1 includes a 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.

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

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

In some embodiments, after calculating and obtaining the forwarding proof, each key node uses the forwarding proof calculated by the node to replace the forwarding proof carried in 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 uses forwarding proof B to replace the forwarding proof A carried in data message A, so as to obtain data message B, which does not include forwarding proof A but includes forwarding proof B. Similarly, key node C receives data message B carrying forwarding proof B. After key node C calculates and obtains forwarding proof C, it uses forwarding proof C to replace the forwarding proof B carried in data message A, so as to obtain data message C, which does not include forwarding proof B but includes forwarding proof C. By replacing the forwarding proof calculated by the previous node with each key node, the data message only needs to carry one forwarding proof, which avoids the data message from carrying too much data due to the need to carry the forwarding proof of each key node passed along the way, which helps to save the transmission overhead of the data message and the occupied bandwidth resources.

In other embodiments, after calculating and obtaining the forwarding proof, each key node adds the forwarding proof calculated by the 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 to obtain data message B, which 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 to obtain data message C, which includes forwarding proof A, forwarding proof B, and forwarding proof C. By each key node continuing to add the forwarding proof of the node on the basis of the forwarding proof calculated by the previous node, the data message can carry the forwarding proof of each key node passed along the way, and can verify the identity and sequential position of each key node that the data message has passed, so it is more credible.

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.

The first forwarding node generates a notification message, which carries the forwarding proof 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.

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

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 border gateway protocol flow spec (BGP flow specification, referred to as BGP flow spec or BGP FS), path computation element protocol (PCEP), BGP monitoring protocol (BGP monitoring protocol, BMP), network flow (netstream) protocol or border gateway protocol (BGP) and the like.

In some implementations, the notification message is an application layer protocol message, including 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.

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.

The embodiment of the present application provides three verification modes of forwarding proof. The determination method and transmission method of forwarding proof in different verification modes are different. The following further illustrates the determination method and transmission method of forwarding proof in combination with the three verification modes. Among them, the real-time verification mode and the on-path verification mode are further subdivided into two sub-modes: single-point and multi-point. The end point verification mode does not have a single-point mode but a multi-point mode.

Verification mode 1: real-time verification (postcard) mode

The real-time in real-time verification means that the time point of verifying the forwarding proof is real-time relative to the time point of receiving the data message. In the real-time verification mode, when each key node in the actual forwarding path processes the data message, the key node calculates a forwarding proof and sends the forwarding proof to the verification node in an out-of-band manner, that is, the single-point forwarding proof is not sent along the actual forwarding path of the business data itself. The verification node deployed outside the actual forwarding path verifies the forwarding proof in real time, and the key node does not need to verify the forwarding proof.

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.

When the real-time verification mode is adopted, when the key node determines the forwarding proof and the verification node verifies the forwarding proof, the sequence positions used by both are the sequence positions in the expected forwarding path, such as 1, 2, 3, 4, and the sequence positions used by both are not the sequence positions in the actual forwarding path. The sequence position of the key node in the actual forwarding path does not participate in the calculation process of the forwarding proof and the verification process of the forwarding proof. The sequence position of the key node in the actual forwarding path is used for evidence storage.

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 the record keeping of non-key nodes.

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 a head node, key node 4 is a 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 commitments and sending vector commitments, but also performs the steps of verifying the forwarding proof.

In the process of data transmission performed by key node 1, when 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, and 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; or, 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.

During the process of data transmission performed by the i-th key node, the i-th key node receives data message _i from the previous key node. The message header of data message _i carries a trusted path identifier and path information. The i-th key node verifies the correctness of the source of data message _i. If the source verification of data message _i passes, the i-th key node calculates the forwarding proof of this node; and the i-th key node obtains the sequential position of this node in the actual forwarding path; the i-th key node 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 the i-th key node forwards the data message to the next key node i+1. In addition, if the source verification of data message _i fails, the i-th key node does not need to calculate the forwarding proof and discards the data message _i.

During the process of the verification node performing real-time verification, 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.

In the case of adopting a single-point forwarding proof, in the process of calculating the forwarding proof, the i-th key node uses the identity information r_i of the node and the sequential position i of the node 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 the sequential position of the node in the actual forwarding path to the verification node. The verification node executes the verification function Verify(C,i,r_i,OP_i) in the vector commitment mechanism based on the input vector commitment C, the identity information r_i of the i-th key node, the sequential position i of the i-th key node in the expected forwarding path, and the single-point forwarding proof OP_i calculated by the i-th key node, that is, verifies that the identity information of the i-th key node with the sequential position is r_i. Where C represents the vector commitment, i represents the sequential 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.

In the case of adopting multi-point forwarding proof, in the process of calculating the forwarding proof, the i-th key node uses 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 from the first 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 sends the multi-point forwarding proof MP_i and the sequential position of the current node in the actual forwarding path to the verification node located outside the actual forwarding path. The verification node executes the batch verification function batch verify(C, B, r_B, MP_i) in the vector commitment mechanism based on the input vector commitment C, the identity information r_1 to r_i of each key node from the first key node to the i-th key node, the sequential position i of each key node from the first key node to the i-th key node in the expected forwarding path, and the multi-point forwarding proof MP_i of the i-th key node, where B＝(r_1, r_2, …, r_i). Where C represents 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.

For example, in the case of real-time verification mode, whether the verification mode for single-point proof or multi-point proof is adopted, the key node constructs an additional separate data message in the process of transmitting business data. The data message is used to carry the actual sequence position of the node and the forwarding proof of the node. The data message does not need to carry business data. The key node sends the data message to the outside. For example, when business data is transmitted to the i-th key node, the data message sent by the i-th key node to the outside includes the following content.

The real-time verification mode provided by this embodiment, since each key node along the way during the actual transmission of the data message calculates the forwarding proof of this node and sends the forwarding proof of this node to the outside, the identity and sequential position of each key node actually passed by the data message can be verified, so that security can be guaranteed 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, it is not necessary to wait until the data message is transmitted to the last key node for verification, so that real-time transparent tracking of the data transmission process is realized, 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.

Verification mode 2: Passport mode

In the on-path verification mode, when each key node i in the actual forwarding path processes a data message, 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 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 serves 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.

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

When adopting the verification mode for single-point proof in the on-line verification mode, each key node calculates the single-point forwarding proof OP_i of the node and adds the single-point forwarding proof OP_i 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.

In the case of adopting the verification mode for multi-point proof in the on-path verification mode, each key node learns 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 business data, or other means. Each key node calculates the multi-point forwarding proof MP_i of this node based on the identity information and sequential position of each node from the first key node r_1 to this node, and adds the single-point forwarding proof MP_i to the data packet, so that the single-point forwarding proof MP_i and the business data are transmitted to the next key node together.

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.

For example, please refer to Figure 4. Forwarding node_2, forwarding node_3 and key node 4 in Figure 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.

During the data transmission process performed by key node 1, when key node 1 is a key node, key node 1 uses the open function to calculate the single-point forwarding proof OP_1 of this node; or, key node 1 uses the batchopen function to calculate the multi-point forwarding proof MP_1 of this node; key node 1 obtains the sequence position of this node in the actual forwarding path; key node 1 constructs a new data message based on the vector commitment, the payload data, the forwarding proof of key node 1, and the sequence position of key node 1 in the actual forwarding path. The message header of the data message carries the trusted path identifier, the vector commitment, the forwarding proof of key node 1, the path information, and the actual sequence position list, the path information carries the identity information of each key node in the expected forwarding path, and the payload field of the data message carries the payload data. The actual sequence position list includes the sequence position of key node 1 in the actual forwarding path.

During the data transmission process performed by the i-th key node, the i-th key node receives data message _i from the (i-1)th key node. The message header of data message _i carries a trusted path identifier, path information, and a 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 by the data message. If the forwarding proof of the (i-1)th key node is verified, the source verification of data message _i is passed, the i-th key node calculates the forwarding proof, and uses the forwarding proof calculated by this node to replace the forwarding proof of the previous key node carried in the message header of data message _i. In addition, the i-th key node adds the sequence position of this node in the actual forwarding path to the actual sequence position list carried by data message _i, thereby obtaining data message _i+1. Data message _i+1 carries the payload data in data message _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.

When a single-point forwarding proof is adopted, 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.

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 upper half 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 this node r_i and the sequential position of each node from the 1st key node r_1 to this 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.

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

Exemplarily, in the case of adopting the on-path verification mode, whether adopting the verification mode for single-point proof or the verification mode for multi-point proof, 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.

The on-path verification mode provided by this embodiment calculates the forwarding proof of each key node passed by the data message during the actual transmission process, and verifies the forwarding proof of the previous key node, so that the identity and sequential position of each key node actually passed by the data message can be verified, so that security can be guaranteed hop by hop. In addition, since the forwarding proof is included in the message header of the service data message on-path, compared with constructing a data message separately to transmit the forwarding proof, the calculation and communication costs are moderate, and the protocol process and complexity are moderate, which is a compromise solution.

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.

First, further reduce the probability of deception and tampering. Specifically, since 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 deception, the 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, and improving the security of the network.

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, and each hop node on the entire forwarding path can be gradually verified to be in the correct position with almost no jumps or interruptions.

Third, privacy protection: Since the identity information and relative position 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 leakage of identity information and relative positions.

Fourth, the correctness of the position of the key node can be verified. Since the forwarding proof of each key node is obtained based on the 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 the data message in the expected sequential position.

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

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

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

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

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

Verification mode three, final_only mode

In the endpoint verification mode, the tail node in the forwarding path also serves as an observer. The tail node obtains a forwarding proof 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 proof. For example, please refer to Figure 5, which is a schematic diagram of a verification scenario of a forwarding proof 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.

In the process of data transmission performed by key node 1, when key node 1 is a key node, key node 1 constructs a new data message based on vector commitment, payload data, and the sequence position of key node 1 in the actual forwarding path. The message header of the data message carries the trusted path identifier, vector commitment, path information, and the actual sequence position list, and the payload field of the data message carries the payload data. The actual sequence position list includes the sequence position of key node 1 in the actual forwarding path.

During the data transmission process performed by the i-th key node as an intermediate node, the i-th key node does not need to perform the calculation process of the forwarding proof and the verification process of the forwarding proof. The i-th key node verifies the source of the data message in other ways besides verifying the forwarding proof. The i-th key node adds the sequence position of this node in the actual forwarding path to the actual sequence position list carried by the data message _i, and records the actual sequence position of this node by maintaining the actual sequence position list.

The last key node (tail node) receives data message _N, which contains a message 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. In the process of calculating the forwarding proof, the last key node obtains the 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. In the process of 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 according to the vector commitment mechanism, based on 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.

Exemplarily, in the case of adopting the endpoint verification mode, whether adopting the verification mode for single-point certification or the verification mode for multi-point certification, since each key node adds the actual sequence position of the node to the data message carrying the business data, the data message not only carries the business data, but also carries the actual sequence position of each key node that the data message has passed. Exemplarily, when the data message is transmitted to the i-th key node, the data message includes the following content in addition to the business data.

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 except the tail node in the forwarding path. 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.

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 when the forwarding proof is transmitted in the network.

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

In another possible implementation, key node i verifies the forwarding proof based on the vector commitment, the identity information of the two key nodes before key node i in the forwarding path, and the relative position of the two key nodes before key node i, thereby supporting the tracing and verification of the correctness of the two key nodes before the current 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.

In another possible implementation, key node i verifies the forwarding proof based on the identity information of the three key nodes before key node i in the forwarding path, the relative positions of the three key nodes before key node i, and the vector commitment, thereby supporting the tracing and verification of the correctness of the three key nodes before the 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.

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 from 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 proof data may have problems, such as the data message skips a node in the path or passes through an extra unspecified node before forwarding to this node, the 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.

In one possible implementation, in response to determining that the forwarding proof carried by the data message fails to pass verification, the key node outputs an alarm message, and the alarm message is used to indicate that the forwarding proof fails to pass verification. In one possible implementation, the key node notifies the alarm message to the network management system (NMS), the element management system (EMS) or the controller through the management plane protocol. For example, the key node sends a network configuration protocol (NETCOF) message to the controller, the NETCOF message carries the alarm message, and the NETCOF message indicates that the forwarding proof fails to pass verification. For another example, the key node sends a simple network management protocol (SNMP) message to the controller, the SNMP message carries the alarm message, and the SNMP message indicates that the forwarding proof fails to pass verification. For another example, the key node sends an alarm message indicating that the forwarding proof fails to pass verification to the controller based on telemetry. For another example, the key node sends an alarm message indicating that the forwarding proof fails to be verified to the controller based on the representational state transfer principle (RESTful). For another example, the key node sends information indicating that the forwarding proof fails to be verified to the controller in the form of a log based on the log management protocol. For example, the key node sends a system logging protocol (Syslog) protocol message to the controller, and the Syslog protocol message carries an alarm message indicating that the forwarding proof fails to be verified. Syslog is a standard UNIX system log management protocol used to send log information generated by a device or application to a remote server. In one possible implementation, the key node outputs the alarm message in the form of an alarm notification. The alarm notification can be sent through SMS, email, instant messaging tools, etc., so that the administrator or network security team can receive it in time and take corresponding countermeasures. In another possible implementation, the key node outputs the alarm message in the form of a log record. For example, the key node_i records the information of the data message_i that fails to be verified in the system log. In another possible implementation, the key node_i sends the alarm message to the controller. The controller provides a visual display of alarm information so that administrators can quickly identify problems and take measures.

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

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

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

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

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

In some other possible implementations, based on the identity information of key nodes and the relative positions of key nodes, Bulletproof is used to obtain forwarding proof or vector commitment; or Bulletproof is used to verify forwarding proof based on vector commitment. Bulletproof is a zero-knowledge proof technology. Bulletproof is a cryptographic primitive used in zero-knowledge proof to prove that a value satisfies a certain relationship without providing additional proof information. Bulletproof also does not require a trusted third party to set up and start, so it is more decentralized and distributed, reducing the impact of single point failures on obtaining forwarding proof or vector commitment, and also has higher security.

In some other possible implementations, RSA accumulators are used to obtain and verify commitments based on the identity information of key nodes and the relative positions of key nodes. RSA accumulators are a data structure used to accumulate the elements of a set into an accumulator so as to subsequently verify whether an element belongs to the set. Based on the RSA addition homomorphic property, RSA accumulators can verify whether a specific element is contained in an accumulator without disclosing the elements of the set.

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

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

In some other possible implementations, a merkle tree commitment is used to obtain and verify commitments based on the identity information of key nodes and the relative positions of key nodes. Merkle tree commitment is a commitment mechanism used to bind multiple elements in a set into a tree structure. The Merkle tree combines elements level by level through a hash function and generates a root hash, which is a commitment to the entire tree. In the verification phase, only some elements in the set and the hash values on the relevant paths need to be known to verify whether the element belongs to the tree.

In some other possible implementations, Verkle tree commitments are used to obtain and verify commitments based on the identity information of key nodes and the relative positions of key nodes. Verkle tree commitments are a commitment mechanism used to bind multiple elements in a set into a non-binary tree structure. Verkle tree commits the path from the root node to the leaf node in the tree through polynomial commitments and aggregates multiple paths. In the verification phase, only some elements in the set and the polynomial commitments on the relevant paths need to be known to verify whether the element belongs to the tree.

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

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.

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

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

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.

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

First, improve 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.

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

Third, save computing resources: When the trusted path identifier is not carried in the data message, the 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.

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

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

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

Third, save computing resources: When the data message does not carry data related to a specific business, the key node 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.

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

The above method is illustrated below with reference to two specific application scenarios.

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

In Example 1, the service function chain is a specific example of a forwarding path, the SF or SFC agent is a specific example of a forwarding node (key node), the NSH in Example 1 is a specific example of a message header carrying a vector commitment and a forwarding proof, and the SF_from in Example 1 is a specific example of the identity information of a key node. The KZG polynomial commitment is a specific example of a vector commitment.

The service function chain is an ordered set of service functions. The service function chain is used to guide each service function to process traffic in an orderly manner on demand. The service function chain is mainly used in NFV virtual networks. As shown in Figure 6, network devices play different roles in the entire service function chain system according to the different functions used. The roles of the service function chain mainly include classifier (SC), service function (SF) node, service function forwarder (SFF) node and SFC proxy (SFC proxy) node.

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.

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

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

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

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

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

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

NSH is a message header used to identify the SFC protocol. NSH meets a certain fixed format and leaves an extensible optional variable-length metadata (OVLM) data field. This embodiment implements the trusted path message header in OVLM.

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

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

As shown in (c) of Figure 7, the service path header includes a service index (SI) and a service path identifier (SPI). The SPI occupies 24 bits. The service index (SI) indicates the current position of the data message in the forwarding path, and the SI occupies 8 bits. The format of the service path header is shown in Figure 7. In a possible implementation, SF node _i obtains the value of the SI field carried by the service path header, uses the value of the SI field as the position _i of this node, and calculates the forwarding proof p_i of this node based on the position _i. Since the SI value range is from 255 to 0 and decreases by 1, x_i = 256-SI.

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

As shown in (d) in Figure 7, the context header is used to carry values related to the trusted path. The context header includes a commitment C and a forwarding proof p_i, etc. The context header includes a metadata class field, a type field, a length field, and a variable-length metadata field. Variable-length metadata is a variable-length field used to carry metadata related to a specific service or function. The length field is used to indicate the length of the variable-length metadata field. In some embodiments, data related to the trusted path is carried by a variable-length metadata field, for example, four types of data, namely, commitment, forwarding proof, identity information, and relative position, are carried by a variable-length metadata field.

In the business function chain scenario, the three forwarding proof verification modes described above include real-time verification (postcard) mode, on-path verification (passport) mode, and end-point verification (final_only) mode. In this embodiment, the single-point proof verification mode in the on-path verification mode with moderate efficiency and security is selected for analysis:

For the single-point proof verification mode in the path verification mode, the variable-length metadata field of each data packet carries a commitment, a forwarding proof, an identifier of the previous SF node, and a list of actual sequential positions. For example, the variable-length metadata field shown in (d) of FIG. 7 includes a commitment field, a P field, a SF_from field, and a real_index_list field, so that the format of the variable-length metadata field is as shown in the following table.

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

Pairable friendly curves are a type of elliptic curve group with specific mathematical properties that are suitable for pairing operations. In cryptography, pairing refers to mapping points on two elliptic curves to elements on a finite field. When using curve curve_ID = BLS-12381, elem_length = 48 bytes. In other words, both the commitment field and the P field are 48 bytes.

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

The SF_ident_length field is used to indicate the length of the SF_from field. The SF_from field is in bytes, for example.

The real_index_list field is used to carry the actual sequential position list. For example, the real_index_list field carries the sequential position of each SF node that is a key node in the forwarding path in the actual forwarding path. For example, the real_index_list field carries the TTL of each SF node that is a key node in the forwarding path.

The following example illustrates the steps performed by each node in the path verification mode in the SFC scenario.

The controller performs path calculation based on the network topology to determine a forwarding path of length N, which passes through N SF nodes in the service function chain. The forwarding path can be represented by a vector P = (r_1, r_2, ..., r_N), where r_i is the unique identifier of the SF node. The controller calculates the vector commitment based on the forwarding path.

Taking the KZG polynomial commitment as an example, the controller transforms the vector P into N two-dimensional coordinate points <(1,r_1),(2,r_2),…,(N,r_N)>. The controller uses the following formula (1) to calculate the Lagrange interpolation polynomial f(X) of these N points. In formula (1), x_i represents the relative position of SF node_i, and y_i represents the identity information of SF node_i.

The controller calculates the secret s using formula (2) to achieve secret initialization. In formula (2), g is the group generator.
s,s2],...,[s ^N ], where[s ⁱ ]＝ ^i*s ; Formula (2)

The controller uses formula (3) to calculate the polynomial commitment C = Commit(f(X)) based on the Lagrange interpolation polynomial f(X) and the secret s. Commitment C is a G1 group element with a length of 48 bytes. The controller sends the vector commitment to the first SF node in the forwarding path.

During the data transmission process of the first SF node, when the first SF node is a key node, the first SF node receives the vector commitment from the controller; the first SF node constructs a new data message based on the payload data. The payload field of the data message carries the payload data. The first SF node uses the open function to calculate the single-point forwarding proof OP_1 of this node using the following formula (4).
OP _i =p[f(x _i )=y _i ]=CT
Formula (4)

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

The new coefficient is determined by the following formula (6).
t _N-1 ＝f _N ；t _j ＝f _j+1 +x _i ·t _j+1
;Formula (6)

The first SF node uses the following formula (7) to calculate the single-point forwarding proof OP_1.
OP _i = [T _y (s)] ₁
;Formula (7)

The first SF node fills the single-point forwarding proof OP_1 into the field P of NSH, fills the identity information of the first SF node into the SF_from field in NSH, and fills the vector commitment C into the commitment field in NSH to obtain data message _2. The first SF node sends data message _2 to the second SF node.

During the data transmission performed by the i-th SF node, when the i-th SF node is a key node, SF node_i receives data message_i, and data message_i contains an NSH, which carries a trusted path identifier, the identity information r_i of the SF node_i currently processing this data message, the sequence position i of SF node_i in the expected forwarding path, and the single-point forwarding proof OP_i-1 of the previous SF node. The sequence position i of SF node_i in the expected forwarding path is obtained based on SI. SF node_i verifies the single-point forwarding proof OP_i-1 carried by the NSH of data message_i based on the identity information of the previous SF node_i-1 and the sequence position i of the previous SF node_i-1 in the expected forwarding path, thereby verifying the source of data message_i. The verification method is based on checking whether the pairing in the following formula (8) is established.

Formula (8) is the verification formula of the forwarding proof. e(G_1,G_2)->G_T is a public pairing function, g_1, g_2 are generators (both pre-distributed public parameters/functions), if SF node_i determines that the pairing in formula (8) does not hold, then it is determined that the single-point forwarding proof OP_i-1 of the previous SF node has failed the verification. If SF node_i determines that the pairing in formula (8) holds, SF node_i determines that the single-point forwarding proof OP_i-1 of the previous SF node has passed the verification.

If the single-point forwarding proof OP_i-1 of the previous SF node is verified, SF node _i uses the identity information r_i of this node and the sequence position i of this node in the expected forwarding path as input, and uses formula (4) to calculate a new single-point forwarding proof OP_i. SF node _i uses the single-point forwarding proof OP_i calculated by itself to replace the forwarding proof OP_i-1 of the previous SF node carried in the header of the data message.

In addition, SF node_i determines the sequential position of this node in the actual forwarding path. For example, SF node_i reads the TTL carried in the message header of the data message, and determines the sequential position of this node in the actual forwarding path based on the TTL; SF node_i fills the sequential position of this node in the actual forwarding path into the actual sequential position list carried by the NSH of the data message.

In addition, if the single-point forwarding certificate OP_i-1 of the previous SF node carried by the data message fails to pass the verification, SF node_i discards the data message or outputs an alarm message.

Example 2: Trusted Path Protection Mechanism for SRv6

The path indicated by the segment list in Example 2 is a specific example of a forwarding path. The node (SR node) corresponding to the SID in the segment list in Example 2 is a specific example of a forwarding node. The SID is a specific example of identity information. The SID of key node i is used to identify the identity of key node i. The SRH in Example 2 is a specific example of a message header carrying vector commitment and forwarding proof. SRv6 is a segment routing technology based on the IPv6 forwarding plane. SRv6 adds SRH to IPv6 messages. SRH includes the IPv6 address list segment list that records the forwarding path and optional TLV (Type-length-Value).

In some embodiments, SID is used to carry the sequential position of the key node in the expected forwarding path. As shown in Figure 8, SID includes a location (locator) field and a function (function) field. The locator field is used to carry the sequential position of the key node in the expected forwarding path. The locator field has a positioning function and provides IPv6 routing capabilities. The message is addressed and forwarded through the locator field. Based on the locator field in the SID of this node, the key node i uses the SRv6 protocol to calculate the sequential position of the key node i in the expected forwarding path.

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

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

SRv6, a flexible protocol that can carry path information and addresses of nodes in the path, is suitable for implementing the multi-point certification verification mode in the on-path verification mode and the multi-point certification verification mode in the endpoint verification mode.

Regarding the multi-point proof verification mode in the in-path verification mode, the difference from Example 1 is that in Example 1, the identifier of the previous node (SF_from) is added to the data message, while in Example 2, each data message already includes the identifier of the previous node (SID) in the segment list, so there is no need to add the identifier of the previous node (SID) in the TLV field. Specifically, a commitment field, a proof (P, specifically a multi-point proof) field, and a real_index_list field are added to the TLV in the SRH of the data message. Since the node identifier (SID) in SRv6 is an IPv6 address, and the length of the IPv6 address is 128 bits, there is no need to add an additional field in the message header to identify the length of the node identifier, so the message header format is as follows.

Commitment and forwarding proof (P) are both G1 group elements of a pairing Friendly Curve, so the byte length (elem_length) of one element is used to represent commitment and forwarding proof (P). In the case of using curve curve_ID = BLS-12381, the length of commitment and forwarding proof (P) is 48 bytes. The real_index_list field is used to carry the actual sequential position list. For example, the real_index_list field carries the sequential position of each SR node that is a key node in the forwarding path in the actual forwarding path. For example, the real_index_list field carries the TTL of each SR node that is a key node in the forwarding path.

The following example illustrates the steps that each node performs when applying the path verification mode in the SRv6 scenario.

The controller performs path calculation based on the network topology to determine a segment list of length N, which is used to represent the expected forwarding path. The segment list includes the SID of each SR node in the N SR nodes. The segment list can be represented by a vector P = (r_1, r_2, ..., r_N), where r_i is the SID of the SR node. The controller calculates the vector commitment based on the segment list. The controller sends the vector commitment to the key node 1 so that the key node 1 carries the vector commitment in the data message and passes it to each SR node along the way, thereby supporting each SR node to perform path verification using the vector commitment obtained from the data message. Alternatively, the controller sends the vector commitment to each SR node in the N SR nodes so that each SR node performs path verification using the vector commitment received from the controller.

During the data transmission performed by key node 1, when key node 1 is a key node, key node 1 receives a vector commitment from the controller; key node 1 constructs a new data message based on the payload data. The payload field of the data message carries the payload data. Key node 1 calculates the multi-point forwarding proof MP_1 of this node using the batchopen function. Key node 1 adds the forwarding proof MP_1 of this node to the P field in the TLV in the SRH. Key node 1 sends data message _2 to the second SR node. Data message _2 includes SRH, which includes a trusted path identifier and the forwarding proof of key node 1.

During the data transmission performed by the i-th SR node, the SR node_i receives a data message_i, and the data message_i includes an SRH, which carries a trusted path identifier, identity information of each SR node from the key node 1_1 to the i-th SR node_i as a key node, and the sequential position of each SR node from the key node 1_1 to the i-th SR node_i as a key node in the expected forwarding path. Exemplarily, the sequential position of each SR node from the key node 1_1 to the i-th SR node_i as a key node in the expected forwarding path is a positive integer 1, 2, 3... Exemplarily, the sequential position of the SR node in the expected forwarding path is obtained through the locator field in the SID. When the i-th SR node is a critical node, SR node _i verifies the multi-point forwarding proof MP_i-1 carried by the SRH of data message _i based on the identity information of each SR node from critical node 1_1 to the (i-1)-th SR node and the sequential position of each SR node from critical node 1_1 to the (i-1)-th SR node in the expected forwarding path, thereby verifying the source of data message _i.

If the multi-point forwarding proof MP_i-1 is verified, SR node_i obtains a multi-point forwarding proof MP_i using the identity information from key node 1_1 to node_i and the sequential position from node_1 to node_i in the expected forwarding path. The identity information from key node 1_1 to node_i and the sequential position from node_1 to node_i in the expected forwarding path are obtained from the segment list. SR node_i replaces the multi-point forwarding proof MP_i-1 carried in the header of data message_i with the new multi-point forwarding proof MP_i.

In addition, SR node_i determines the sequential position of the node in the actual forwarding path. For example, SR node_i reads the TTL carried in the message header of the data message, and determines the sequential position of the node in the actual forwarding path based on the TTL; SR node_i fills the sequential position of the node in the actual forwarding path into the actual sequential position list carried by the SRH of the data message.

In addition, if the multipoint forwarding certificate MP_i-1 of the previous SR node carried by the data message fails to pass the verification, the SR node _i discards the data message or outputs an alarm message.

In the SRv6 scenario, the end point verification mode can also be extended to obtain and verify the forwarding proof. Different from the on-path verification mode, after the controller determines the vector commitment, it directly passes the vector commitment to the tail node (the last SR node).

The tail node receives an SRv6 data message from the second-to-last SR node, and the tail node obtains the path information P = (r_1, r_2, ..., r_N) from the Segment List in the SRH of the SRv6 data message. Among them, r_i is the publicly verifiable identity information of the forwarding node. In this embodiment, the identity information of the forwarding node is SID. The tail node determines the offset of the SID of SR node_i compared to the SID of key node 1 to obtain the sequential position of SR node_i in the expected forwarding path. The tail node calculates a multi-point forwarding proof MP_N from node r_1 to r_N. The calculation method of MP is the same as above. In some embodiments, the tail node obtains the sequential position of the node in the actual forwarding path through TTL or other methods, fills the sequential position of the node in the actual forwarding path into the actual sequential position list carried by the data message, and forwards the actual sequential position list. According to the vector commitment mechanism, the tail node executes the batch verification function (batch verify) batch verify(C, MP_N, P) based on the vector commitment C, the sequential position of each node in the path P, and the identity information of each node in the path P to verify the multi-point forwarding proof MP_N, that is, to verify that the identity of the node at each position i in the entire path is r_i.

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

The above embodiments focus on describing the path verification at the node (device) level. The embodiments of the present application also provide a path verification method at the AS level. The application scenarios of the AS level path verification, the basic terminology concepts involved, and the method flow are illustrated below.

AS-level path verification is mainly used in cross-AS transmission scenarios. Cross-AS transmission scenarios refer to a data stream passing through multiple ASs during transmission. Among the multiple ASs that the data stream passes through, the AS that communicates with the source host of the data stream is usually called the source AS, the AS that communicates with the destination host of the data stream is usually called the destination AS, and the AS between the source AS and the destination AS is usually called the intermediate AS (Transit AS). For example, please refer to Figure 9, the data stream passes through AS100, AS200 and AS 300 during transmission, where AS100 is the source AS, AS200 is the intermediate AS, and AS 300 is the destination AS.

One or more forwarding nodes are usually deployed in an AS. The roles of forwarding nodes deployed at different locations in the AS are different.

The forwarding nodes deployed at the border of an AS are used to forward service data between ASs. The forwarding nodes deployed at the border of an AS are also called border network devices. For example, the forwarding nodes deployed at the border of an AS are ASBRs or PEs. The forwarding nodes deployed at the borders of different ASs usually communicate across ASs based on the BGP protocol. The forwarding nodes deployed at the border of an AS include the forwarding nodes deployed at the entrance of the AS and the forwarding nodes deployed at the exit of the AS.

The forwarding node deployed at the entrance of the AS is used to forward the service data from the outside of the AS to the inside of the AS. One or more forwarding nodes can be deployed at the entrance of an AS. The forwarding node deployed at the entrance of the AS is also called an entry node, such as an entry PE. For example, the entrance of AS100 is deployed with a forwarding node Q, and the forwarding node Q is used to forward the service data from the source host to the inside of AS100. The entrance of AS200 is deployed with a forwarding node B, and the forwarding node B is used to forward the service data from AS100 to the inside of AS200.

The forwarding node deployed at the exit of the AS is used to forward the service data from inside the AS to outside the AS. The forwarding node deployed at the exit of the AS is also called an exit node, for example, an exit PE. In some embodiments, when an AS has a neighbor relationship with multiple ASs, the forwarding node deployed at the exit of the AS is also used to select the next AS from multiple neighboring ASs of the AS after receiving the data message, and forward the service data to the forwarding node deployed by the selected AS. For example, key node A is used to select an AS from AS200 and AS 400 as the next AS to which the service data is to be transmitted.

The forwarding nodes deployed inside the AS are used to transmit data inside the AS. For example, forwarding node E is used to forward service data within AS 300.

In the cross-AS transmission scenario, it is necessary to verify whether the AS that the data message is about to pass through or has passed through belongs to the AS in the planned expected path, so as to reduce the risk caused by the data message passing through an unexpected AS. For example, it can reduce the risk of network transmission quality degradation caused by the data message passing through an AS whose network transmission quality does not meet the requirements (for example, the latency and packet loss rate do not meet the standards), or reduce the security risk caused by the data message passing through an AS whose network security does not meet the requirements (for example, an AS with security risks that has been identified).

In view of this, in some embodiments of the present application, based on the identity information of the verified AS and the sequential position of the verified AS, the forwarding proof of the verified AS is obtained, and the forwarding proof of the verified AS is compared with the vector commitment to determine whether the verified AS is the expected AS and/or whether the sequential position of the verified AS is the expected sequential position, thereby realizing AS-level path verification.

The verified AS includes but is not limited to the current AS, the neighbor AS of the current AS, the current AS and/or each AS from the source AS to the current AS. The neighbor AS of the current AS refers to an AS that has a neighbor relationship with the current AS (the AS to which the data message is currently transmitted). For example, the neighbor AS of the current AS includes the previous AS of the current AS in the forwarding path (also called the previous hop AS) or the next AS of the current AS in the forwarding path. For example, when the data message is transmitted to the key node A, the current AS is AS100, and the neighbor ASs of the current AS include AS200 and AS 400. For another example, when the data message is transmitted to the key node B, the current AS is AS200, the neighbor ASs of the current AS include AS200 and AS 400, and each AS from the source AS to the current AS includes AS100 and AS200. For another example, when the data packet is transmitted to the key node D, the current AS is AS 300, the neighboring ASs of the current AS include AS 200 and AS 400, and each AS from the source AS to the current AS includes AS 100, AS 200, and AS 300.

In some embodiments, the execution subject responsible for verifying the forwarding proof of the verified AS is a forwarding node located at the boundary of the current AS. The forwarding nodes at the boundary of the current AS include the forwarding nodes at the entrance of the current AS and the forwarding nodes at the exit of the current AS. Considering that the forwarding nodes at the boundary of the AS need to perform the behavior of forwarding business data between ASs, the forwarding proof of the verified AS by the forwarding nodes at the boundary of the AS improves the security of forwarding business data between ASs.

In some implementations, the forwarding node at the current AS egress is responsible for calculating the forwarding proof of the next AS of the current AS, and performing path verification on the next AS of the current AS based on the AS-level vector commitment. Performing path verification on the next AS of the current AS helps verify whether the AS that the data packet is about to enter is the expected AS specified by the path planner, thereby reducing the risk of route hijacking attacks.

In some embodiments, the forwarding node at the entrance of the current AS is responsible for calculating the forwarding proof of the previous AS of the current AS, and performing path verification on the previous AS of the current AS based on the AS-level vector commitment. By performing path verification on the previous AS of the current AS, it helps to verify whether the source AS of the data message is the expected AS specified by the path planner. For another example, the forwarding node at the entrance of the current AS is responsible for calculating the forwarding proof of the current AS, and performing path verification on the current AS based on the AS-level vector commitment. By performing path verification on the current AS, it helps to verify whether the AS where the data message is currently located is the expected AS specified by the path planner. By performing path verification on each AS from the source AS to the current AS, it helps to verify whether the data message has passed through an unexpected AS along the way in the upper half of the path.

Taking the verified AS as the next AS of the current AS as an example, the current forwarding node performs path verification based on the identity information of the selected AS and the sequential position of the selected AS in the process of selecting the next AS from multiple neighboring ASs of the current AS. If the verification fails, it can be determined that the selected AS is an unexpected AS, and a predetermined processing action is performed, such as reselecting the next AS from multiple neighboring ASs until the expected AS is selected, or terminating the forwarding of the data message and reporting to the management plane. Due to the use of the verification before forwarding method, the verification of the next AS is performed in advance before forwarding the data message from the current AS to the next AS, thereby reducing the risk caused by the data message entering the unexpected AS from the current AS. For example, the forwarding proof of the selected AS is determined based on the identity information of the selected AS and the sequential position of the selected AS, and the vector commitment is compared with the forwarding proof of the AS to verify whether the selected AS is the AS expected by the path planner.

For example, in the scenario shown in FIG. 9 , when planning the forwarding path, the path planner specifies that the data message passes through AS100, AS200, and AS 300. The expected order relationship between the ASs by the path planner is to first pass through AS100, then pass through AS200, and finally pass through AS 300. In other words, the expected order position of AS100 is 1, the expected order position of AS200 is 2, and the expected order position of AS 300 is 3. During the data message forwarding process, when the data message arrives at the key node A deployed at the exit of AS100, when the key node A selects the next AS from AS200 and AS 400, if the key node A selects AS200, the key node A first calculates the forwarding proof of AS200, and compares the forwarding proof of AS200 with the vector commitment to verify whether AS200 is the second AS. If the verification is successful, it is equivalent to determining that AS200 is the second AS, and then forwarding the data message to AS200. If the verification fails, it is equivalent to determining that AS200 is not the second AS, and an alarm message is output.

FIG10 is a flow chart of a path verification method provided by an embodiment of the present application. The method shown in FIG10 involves interaction between forwarding nodes deployed at the borders of multiple ASs. The method shown in FIG10 includes the following steps S410 to S480.

Step S410: The path planner determines the AS list.

Step S420: The path planner determines the AS-level vector commitment.

The AS-level vector commitment is a vector commitment at the AS level. The AS-level vector commitment indicates the correspondence between the sequential positions of at least two ASs in the expected forwarding path and the identities of at least two ASs. For example, the path planner calculates the AS-level vector commitment based on the identity information of each AS that the expected forwarding path passes through and the sequential position of each AS.

In some embodiments, the input data used by the path planner in determining the vector commitment includes an expected forwarding path of length M, such as a vector P = (r_1, r_2, ..., r_M). The path planner uses the commitment function in the vector commitment mechanism to calculate a vector commitment C = commit(P) bound to the expected forwarding path P based on the identity information of each AS in the M ASs and the sequential position of each AS in the M ASs. The path planner outputs a commitment C of length k, where k is related to the security parameter lambda.

Step S430: key node A obtains a first data message.

Step S440, key node A obtains the identity information of the verified AS and the sequence position of the verified AS.

In some implementations, the verified AS is the next AS of the current AS (AS200 where the key node A is located). For example, the verified AS is AS200 or AS 400 downstream of AS100. For another example, the verified AS is AS200 or AS 400 of AS100.

The sequential position of the authenticated AS includes the expected sequential position of the authenticated AS and the actual sequential position of the authenticated AS.

The expected sequential position of the verified AS indicates the sequential relationship between the verified AS and each AS that the expected forwarding path passes through. For example. The expected sequential position indicates the number of ASs that the verified AS passes through in the expected forwarding path. In some embodiments, the expected sequential position of the verified AS is the sequential position of the identity information of the verified AS in the AS list, and the AS list includes the identity information of the AS at each key node passed through in the expected forwarding path. By using the sequential position of the verified AS for path verification, it is allowed to insert an unexpected AS between two expected ASs in the actual forwarding path, thereby achieving AS-level fault tolerance.

The actual sequence position of the verified AS indicates the sequence relationship between the verified AS and each AS passed by the actual forwarding path. For example, the actual sequence position of the verified AS indicates the AS number that the verified AS passes through in the actual forwarding path. By using the actual sequence position of the verified AS, a more stringent AS-level path verification can be achieved.

How to obtain the identity information of the authenticated AS and the sequence position of the authenticated AS includes the following methods.

Method 1 for obtaining the identity information and/or expected sequence position of the authenticated AS: The sequence position and/or identity information of the authenticated AS is carried in the data message.

In some embodiments, the data message is extended to carry the identity information of the verified AS and/or the sequential position of the verified AS in the data message. For another example, the sequential position of the current AS is carried in the data message. The key node determines the expected sequential position of the verified AS based on the sequential position of the current AS and the sequential relationship between the current AS and the verified AS. For example, based on the sequential relationship between the current AS and the verified AS, the key node determines that the verified AS is the next AS of the current AS, and adds one to the sequential position of the current AS in the forwarding path to obtain the sequential position of the next AS in the forwarding path, and then performs path verification on the next AS. Exemplarily, the sequential position of AS100 carried in the data message is 1, and the key node A determines that AS200 to be verified is the next AS of AS100. Based on the sequential position of AS100 being 1, the key node A determines that the sequential position of AS200 is 1+1=2.

As an example, the data message carries an AS-level TTL, which is used to indicate the sequential position of the current AS in the forwarding path. For example, the AS-level TTL indicates the number of ASs that the data message has passed through during the transmission process. If the data message has currently passed through the kth AS, the value of the AS-level TTL is k. The key node determines the sequential position of the current AS based on the AS-level TTL carried in the data message, and then performs path verification on the current AS. For another example, the key node determines the expected sequential position of the next AS based on the sequential position of the current AS and the sequential relationship between the current AS and the next AS.

In some other implementations, the AS-level TTL indicates the sequential position of the next AS in the forwarding path. The key node determines the expected sequential position of the next AS based on the AS-level TTL carried in the data message, and then performs path verification for the next AS.

In some embodiments, the data message is extended to carry an AS list in the data message. The key node obtains the identity information of the verified AS and the expected sequential position of the verified AS based on the AS list in the data message. For example, the key node determines the expected sequential position of the verified AS based on the sequential position of the identity information of the verified AS in the AS list. Taking the verified AS as the current AS as an example, the key node determines the expected sequential position of the current AS based on the sequential position of the identity information of the current AS in the AS list. Taking the verified AS as the next AS as an example, the key node determines the expected sequential position of the next AS based on the sequential position of the identity information of the current AS in the AS list and the sequential relationship between the current AS and the next AS.

As an example, the first data message carries an AS list, and the key node A determines the expected sequence position of the identity information of AS200 in the AS list based on the sequence position of the identity information of AS200 in the AS list. For example, the first data message carries the AS list [AS 300AS200AS100], and the key node A determines that the sequence position of the identity information of AS200 is 2 based on the fact that AS200 ranks in the second position in the AS list [AS 300AS200AS100].

Method 2 for obtaining the identity information and/or expected sequence position of the authenticated AS: query the local routing table

In some embodiments, the local routing table of the key node A stores the corresponding relationship between the parameters of the AS where the next forwarding node of the node and the next forwarding node are located in the reachable path of the destination IP address of the data message. The parameters of the AS include the identity information of the AS and the expected sequential position of the AS. In the case where there are multiple reachable paths for a destination IP address, the routing table stores the corresponding relationship between the parameters of the AS where the next forwarding node of the node and the next forwarding node are located in each reachable path of the destination IP address. The key node A searches the routing table based on the destination IP address of the first data message to determine the identity information of the verified AS and the expected sequential position of the verified AS.

For example, the destination IP address of the first data message is 2.2.2.2 in Figure 9. The routing table includes the following content. After the key node A queries the following table based on the destination IP address 2.2.2.2 in the data message, it determines that the identity information of the verified AS is AS200 or AS400, and the expected sequence position of the AS is 2.

In other embodiments, the data message carries the identifier of the next forwarding node of the key node A in the expected forwarding path. The local routing table of the key node A stores the correspondence between the identifier of the forwarding node and the parameters of the AS where the identifier of the forwarding node is located. The key node A obtains the identifier of the next forwarding node carried by the first data message, and searches the routing table based on the identifier of the next forwarding node to determine the identity information of the verified AS and the expected sequential position of the verified AS. For example, the destination IP address field or SRH of the first data message carries the identifier of the forwarding node B. The key node A searches the routing table based on the identifier of the forwarding node B and determines that the verified AS is AS 200.

Regarding the process of obtaining the expected sequential position of the verified AS, in some embodiments, the key node determines the expected sequential position of the AS through the AS_path announced by the BGP protocol in the process of control plane route announcement. For example, in the process of announcing the IP address 2.2.2.2, the border network device in AS 300 sends BGP update message 1 to the border network device of AS 200, and BGP update message 1 includes the IP address 2.2.2.2 and AS_path 1, and AS_path 1 includes the AS number of AS 300. After receiving BGP update message 1, the border network device of AS 200 adds the AS number of AS 200 to AS_path 1 in BGP update message 1 to obtain BGP update message 2. BGP update message 2 includes the IP address 2.2.2.2 and AS_path 2, and AS_path 2 includes the AS number of AS 300 and the AS number of AS 200. The border network device of AS 200 sends BGP update message 2 to the border network device of AS 100. After receiving the message from the border network device of AS 200, the border network device of AS 100 adds the AS number of AS 100 to AS_path 2 in BGP update message 2 to obtain BGP update message 3. BGP update message 3 includes IP address 2.2.2.2 and AS_path 3. AS_path 3 includes the AS number of AS 300, the AS number of AS 200, and the AS number of AS 100. For example, AS_path 3 is expressed as [AS 300 AS 200 AS 100]. The border network device of AS 100 determines that the sequence position of AS 200 is 2 based on AS_path 3.

In other implementations, the identity information of the verified AS and the identity information of the verified AS are obtained by means of control plane pre-distribution. The control plane pre-distribution means include the interaction means between forwarding nodes and the interaction means between the path planner and the forwarding node.

The interaction mode between forwarding nodes is realized by, for example, forwarding nodes in different ASs interacting with each other through routing protocol messages. For example, a border network device deployed in a verified node generates and sends a routing protocol message to a first forwarding node, and the routing protocol message carries a first IP address and identity information of the verified AS; the routing protocol message is, for example, a BGP protocol message. The routing protocol message carries an NLRI field and a path attribute field, and the NLRI field carries the first IP address, and the path attribute field carries the identity information of the verified AS. The first forwarding node receives a routing protocol message from the verified AS; the first forwarding node obtains the first IP address and identity information of the verified AS carried in the routing protocol message. The first forwarding node saves a first corresponding relationship, and the first corresponding relationship includes the first IP address and identity information of the verified AS; after the first forwarding node obtains the first data message, the first forwarding node obtains the identity information of the verified AS based on the first IP address and the first corresponding relationship.

The way in which the path planner and the forwarding node interact, for example, includes the following steps.

Step 1: The path planner generates and sends a notification message to the first forwarding node. The notification message carries the path identifier, the sequence position of the verified AS, and the identity information of the verified AS.

As an example, the path planning direction sends a notification message to the border network device of each AS passed in the expected forwarding path, and the notification message carries the identity information of each AS passed by the expected forwarding path and the expected sequential position of each AS passed by the expected forwarding path.

Step 2: The first forwarding node receives a notification message from a path planning party.

Step three: The first forwarding node saves the second corresponding relationship, where the second corresponding relationship includes the path identifier, the sequence position of the verified AS, and the identity information of the verified AS.

For example, the first forwarding node saves the second correspondence in the local routing table. After the first forwarding node subsequently obtains the first data message, the first forwarding node obtains the sequence position of the verified AS and the identity information of the verified AS based on the path identifier and the second correspondence.

Method 3: Query the AS topology database to obtain the identity information and/or expected sequence position of the verified AS

For example, the key node queries the AS topology library based on the identifier of the AS where the node is located to obtain the identity information of the verified AS and the sequential position of the verified AS. The AS topology library is used to indicate the topological relationship between ASs. For example, the AS topology library includes the identity information and sequential position of a pair of ASs with neighbor relationships. The AS topology library can be any publicly available database of AS neighbor relationships. For example, the AS topology library is a database managed based on the resource public key infrastructure (RPKI). The AS topology library is, for example, an autonomous system provider authorization (ASPA) database, an internet routing registry (IRR) database, or a route origin authorization (ROA) database.

Step S450, key node A obtains an AS-level forwarding certificate based on the identity information of the verified AS and the sequence position of the verified AS.

Step S460, key node A verifies the AS-level forwarding proof based on the AS-level vector commitment, the identity information of the verified AS, and the sequential position of the verified AS.

Regarding the method for obtaining the AS-level vector commitment, in some implementations, the format of the data message is extended, and the first data message carries the AS-level vector commitment. For example, the first data message includes an IPv6 extension header, and the IPv6 extension header carries the AS-level vector commitment. For another example, the first data message includes an NSH, and the NSH carries the AS-level vector commitment. The carrying position of the AS-level vector commitment in the data message can refer to the carrying position of the first vector commitment in the data message.

In some embodiments, the verification node uses the verification function in the vector commitment mechanism to perform operations based on the first vector commitment, the identity information of the first forwarding node, the sequential position of the first forwarding node in the expected forwarding path, and the forwarding proof of the first forwarding node.

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

On the contrary, if the first vector commitment, the identity information of the first forwarding node, the sequence position of the first forwarding node in the expected forwarding path, and the forwarding proof of the first forwarding node do not match, the output result of the verification function is 0, then the forwarding proof of the first forwarding node is verified successfully, indicating that the first forwarding node is not the key node expected by the path planner (the expected forwarding path does not pass through the first forwarding node) or the sequence position of the first forwarding node in the actual forwarding path does not meet the requirements of the expected forwarding path.

Step S470: If the AS-level forwarding proof verification is passed, key node A forwards the first data message.

In some embodiments, when the data message carries the sequence position of the AS, the key node A also updates the sequence position of the AS in the process of forwarding the first data message, so that the next key node performs AS-level path verification based on the updated sequence position of the AS. For example, the first data message carries the sequence position of AS100, and if the forwarding proof of AS200 passes the verification, the key node A updates the sequence position of AS100 in the first data message to the sequence position of AS200 in the AS list to obtain the second data message; the key node A sends the second data message to the forwarding node B.

For example, the first data message carries the AS-level TTL, and the key node A also updates the AS-level TTL during the process of forwarding the first data message.

As an example, the expected forwarding path of a data packet passes through 5 ASs, and the header of the data packet includes a TTL field. Every time the data packet passes through an AS, the value of the TTL field in the header decreases by 1. For example, when the data packet passes through the first AS, the value carried by the TTL field in the header of the data packet is updated to 254, and when the data packet passes through the second AS, the value carried by the TTL field in the header of the data packet is updated to 253, and so on.

Step S480: If the AS-level forwarding proof verification fails, key node A performs a predetermined processing action.

The predetermined processing action includes at least one of reselecting the next hop AS, discarding the data packet, and/or outputting an alarm message. Reselecting the next hop AS means that when there are multiple reachable paths to the same destination IP address, different reachable paths reach the same destination AS through different ASs. If the originally selected AS does not pass the path verification, the key node reselects another AS from the next AS of the current AS in the multiple reachable paths. For example, the reachable paths of IP address 2.2.2.2 include AS 100→AS 200→AS 300 and AS 100→AS 400→AS 300. The current AS is AS 100. Key node A originally selected AS200 as the next AS from AS 200 and AS 400, but AS 200 path verification fails, then AS 400 is reselected from AS 200 and AS 400.

In some embodiments, the key node A also performs path verification on the reselected next-hop AS to determine whether the reselected next-hop AS is the expected AS and whether the sequence position of the reselected next-hop AS meets the requirements. For example, after the key node A reselects AS 400, it obtains the forwarding proof of AS 400 based on the identity information of AS 400 and the sequence position of AS 400, and verifies the forwarding proof of AS 400 based on the AS-level vector commitment, the identity information of AS 400, and the sequence position of AS 400.

The alarm information is used to indicate that the verified AS is illegal. For example, the alarm information includes the identity information of the verified AS and the sequence position of the verified AS. In some embodiments, the key node A sends the alarm information to the path planner. Exemplarily, if the forwarding proof of AS 200 and the forwarding proof of AS 400 are both not verified, the key node A discards the first data message and outputs the alarm information.

FIG11 is a schematic diagram of the structure of a forwarding proof acquisition device provided in an embodiment of the present application. Device 810 is, for example, provided at forwarding node A-1, forwarding node B-2, or forwarding node C-3 in FIG1. Device 810 is, for example, provided at key node 1, key node 2, key node 3, or key node 4 in FIG3. Device 810 is, for example, provided at key node 1, key node 2, key node 3, or key node 4 in FIG4. Device 810 is, for example, provided at key node 4 in FIG5. Device 810 is, for example, provided at SF node_2, SF node_2, or proxy forwarding node_3 in FIG6.

The device 810 includes an acquisition unit 811 and a processing unit 812. The device 810 is, for example, disposed at the key node A in FIG. 2 , and the acquisition unit 811 is used to execute S230 and S240 in the method shown in FIG. 2 ; the processing unit 812 is used to execute S250 in the method shown in FIG. 2 . Optionally, the device 810 also includes a sending unit 813, and the sending unit 813 is used to execute S260 in the method shown in FIG. 2 and to send data message B. The device 810 is also, for example, disposed at the key node B in FIG. 2 , and the acquisition unit 811 is used to execute S320 and S340 in the method shown in FIG. 2 ; the processing unit 812 is used to execute S350 in the method shown in FIG. 2 , and the sending unit 813 is used to execute S360 in the method shown in FIG. 2 .

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

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

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

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

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

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

Figure 12 is a structural diagram of a forwarding proof verification device 820 provided in an embodiment of the present application. The forwarding proof verification device 820 includes an acquisition unit 821 and a verification unit 822. The device 820 is, for example, arranged at the forwarding node A-1, the forwarding node B-2 or the forwarding node C-3 in Figure 1. The acquisition unit 821 is used to execute S270 in the method shown in Figure 2; the verification unit 822 is used to execute S280 in the method shown in Figure 2. The device 820 is, for example, arranged at the observer (verification node) in Figure 3. The device 820 is, for example, arranged at the key node 1, the key node 2, the key node 3 or the key node 4 in Figure 4. The device 820 is, for example, arranged at the key node 4 in Figure 5. The device 820 is, for example, arranged at the SF node_2, the SF node_2 or the proxy forwarding node_3 or the destination host in Figure 6.

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

Each unit in the verification device 820 of the forwarding certificate is fully or partially implemented by software, hardware, firmware or any combination thereof.

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

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

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

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

FIG13 is a schematic diagram of the structure of a forwarding proof verification device 830 provided in an embodiment of the present application. The device 830 is, for example, disposed at the forwarding node A, the forwarding node B-2, or the forwarding node C-3 in FIG9 . The forwarding proof verification device 830 includes an acquisition unit 831 and a processing unit 832. The acquisition unit 831 is used to execute the method S430 and S440 shown in FIG10 ; the processing unit 832 is used to execute S450 and S460 in the method shown in FIG10 .

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

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

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

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

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

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

14 is a schematic diagram of the structure of a device 900 provided in an embodiment of the present application. The device 900 includes at least one processor 901 , a memory 902 , and at least one network interface 903 .

In some embodiments, the device 900 is provided as a forwarding device (forwarding node). In other embodiments, the device 900 is provided as a computing device. The device 900 is, for example, a forwarding node A-1, a forwarding node B-2, or a forwarding node C-3 in FIG. 1. The device 900 is, for example, a key node 1, a key node 2, a key node 3, or a key node 4 in FIG. 3. The device 900 is, for example, a key node 1, a key node 2, a key node 3, or a key node 4 in FIG. 4. The device 900 is, for example, a key node 4 in FIG. 5. The device 900 is, for example, a SF node_2, a SF node_2, or a proxy forwarding node_3 in FIG. 6. The device 900 is, for example, a forwarding node A, a forwarding node B-2, or a forwarding node C-3 in FIG. 9.

The device 900 includes, for example, the key node A in Figure 2, the network interface 903 is used to execute S230 in the method shown in Figure 2, and the processor 901 is used to execute S240 and S250 in the method shown in Figure 2. The network interface 903 is used to execute S260 in the method shown in Figure 2 and send data message B.

The device 900 also includes the key node B in Figure 2, and the network interface 903 is used to execute S320 in the method shown in Figure 2. The processor 901 is used to execute S340 and S350 in the method shown in Figure 2, and the network interface 903 is used to execute S360 in the method shown in Figure 2.

The device 900 also includes the verification node in Figure 2, and the network interface 903 is used to execute S270 in the method shown in Figure 2. The processor 901 is used to execute S280 in the method shown in Figure 2.

The device 900 also includes the key node A in Figure 10, the processor 901 is used to execute S440, S450 and S460 in the method shown in Figure 10, and the network interface 903 is used to execute S430 in the method shown in Figure 10. The processor 901 is also used to instruct the network interface 903 to execute S470 or S480 in the method shown in Figure 10.

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

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

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

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

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

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

In some embodiments, the device 900 further includes an input-output interface 906. The input-output interface 906 is connected to the internal connection 904.

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

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

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

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

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

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

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

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

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

Claims (49)

A method for obtaining a forwarding certificate, characterized in that the method comprises: The first forwarding node acquires a first data message, wherein the at least two key nodes corresponding to the first data message include the first forwarding node, and the key node is a forwarding node passed in an expected forwarding path determined by a path planner for the first data message; The first forwarding node obtains, by the first forwarding node, a sequential position of the first forwarding node in the expected forwarding path and identity information of the first forwarding node, wherein 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 message, and the identity information of the first forwarding node indicates an 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. The method according to claim 1, characterized in that 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, 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, comprising: 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, 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. The method according to claim 2 is 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 except the first forwarding node. The method according to any one of claims 1 to 3, characterized in that the method further comprises: The first forwarding node obtains, based on the first data message, a sequential position of the first forwarding node in the actual forwarding path; The first forwarding node sends a forwarding certificate of the first forwarding node and a sequential position of the first forwarding node in the actual forwarding path to the verification node. The method according to claim 4, characterized in that 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, and the first forwarding node sends a forwarding certificate of the first forwarding node and a sequential position of the first forwarding node in the actual forwarding path to the verification node, comprising: The first forwarding node obtains a second data message based on the first data message, the forwarding proof of the first forwarding node, and the sequential position of the first forwarding node in the actual forwarding path, where the second data message includes the payload of the first data message, 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. The method according to claim 5 is characterized in that the first data packet 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 the second data packet 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. The method according to claim 5 or 6, characterized in that the second data message includes an Internet Protocol version 6 IPv6 extension header, and the IPv6 extension header includes a forwarding certificate of the first forwarding node and a sequential position of the first forwarding node in the actual forwarding path; or, The second data message includes a network service message header NSH, the NSH includes a metadata field, the metadata field includes a forwarding certificate of the first forwarding node and a sequential position of the first forwarding node in the actual forwarding path; or, The second data message 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; or, The second data message includes a virtualized extended local area network VxLAN header, and the VxLAN header includes a forwarding certificate of the first forwarding node and a sequential position of the first forwarding node in the actual forwarding path; or, The second data message includes an Internet Protocol security IPsec header, and the IPsec header includes a forwarding certificate of the first forwarding node and a sequential position of the first forwarding node in the actual forwarding path. The method according to claim 7, characterized in that 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 a sequential position of the first forwarding node in the actual forwarding path; or, The IPv6 extension header includes an application-aware network APN message header, the APN message header includes an application-aware network identifier APN ID, the APN ID includes a forwarding certificate of the first forwarding node and a sequential position of the first forwarding node in the actual forwarding path; or, 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; or, The IPv6 extension header includes a hop-by-hop options 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. The method according to claim 4, characterized in that 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 the verification node, comprising: The first forwarding node generates a notification message, wherein the notification message includes a forwarding certificate of the first forwarding node and a sequential position of the first forwarding node in the actual forwarding path; The first forwarding node sends the notification message to the verification node. The method according to claim 9, characterized in that 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 the actual forwarding path; or, 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. The method according to any one of claims 1 to 10, characterized in that the first data message includes a segment list 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, comprising: 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. The method according to any one of claims 1 to 10, characterized in that the first data message includes a path identifier, and the first forwarding node obtains the sequential position of the first forwarding node in the expected forwarding path, comprising: 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 stored by the first forwarding node, wherein the corresponding relationship includes the path identifier and the sequential position of the first forwarding node in the expected forwarding path. The method according to any one of claims 1 to 10, characterized in that before the first forwarding node obtains the first data message, the method further comprises: The first forwarding node receives a sequential position of the first forwarding node in the expected forwarding path from a path planner. The method according to any one of claims 1 to 13, characterized in that the first forwarding node obtains the first data message, comprising: the first forwarding node receives the first data message from a second forwarding node, the second forwarding node is a key node in the forwarding path that is located upstream of the first forwarding node, and the first data message includes a forwarding certificate 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 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 identities of the at least two key nodes, and the at least two key nodes include the second forwarding node. The method according to claim 1 is characterized in that the path planner is a source host that generates the payload data of the first data message; or, the path planner is the first forwarding device in the expected forwarding path. A method for verifying a forwarding certificate, characterized in that the method comprises: The verification node obtains a forwarding proof of the 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, 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 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 ordinal position of the first forwarding node. The method according to claim 16, characterized in that 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, and 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, comprising: 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 indicating 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 both in corresponding sequential positions in the expected forwarding path. The method according to claim 16 or 17, characterized in that the verification node obtains the forwarding certificate of the first forwarding node, comprising: The verification node receives a forwarding certificate of the first forwarding node from the first forwarding node. A method for verifying a forwarding certificate, characterized in that the method further comprises: The first forwarding node obtains the first data message, where the first forwarding node is deployed at the boundary of the first autonomous domain AS; The first forwarding node obtains a forwarding certificate of the verified AS based on the sequence 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, a sequential position of the verified AS, and identity information of the verified AS, wherein the second vector commitment indicates a correspondence between the identity information of each AS in the at least two ASs and a sequential position of each AS. The method according to claim 19 is characterized in that 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 an AS communicating with a source host, and the source host is a device that generates payload data of the first data packet. The method according to claim 19 or 20 is 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 AS through which the expected forwarding path of the first data packet passes, and 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. The method according to claim 19 is 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 based on the actual sequential position of the first AS and the sequential relationship between the first AS and the verified AS. The method according to claim 19 is characterized in that the verified AS includes the first AS, and the first data message carries the actual sequential position of the first AS. The method according to claim 19 is characterized in that 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. The method according to any one of claims 19 to 24, characterized in that the first data message carries the second vector commitment. The method according to claim 19, characterized in that the first data message includes an Internet Protocol version 6 (IPv6) extension header, wherein 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, The first data message includes a network service message header NSH, the NSH includes a metadata field, and the metadata field carries the sequence position of the authenticated AS, the identity information of the authenticated AS, and the second vector commitment; or, The first data message includes a multi-protocol label switching MPLS header, and the MPLS header carries the sequence position of the verified AS, the identity information of the verified AS, and the second vector commitment; or, The first data message includes a virtualized extended local area network VxLAN header, and the VxLAN header carries the sequence position of the verified AS, the identity information of the verified AS, and the second vector commitment; or, The first data message includes an Internet Protocol security IPsec header, and the IPsec header carries the sequence position of the authenticated AS, the identity information of the authenticated AS, and the second vector commitment. The method according to claim 19, wherein the destination IP address of the first data message includes a first IP address, and before the first forwarding node obtains the first data message, the method further comprises: The first forwarding node receives a routing protocol message from the verified AS, where the routing protocol message carries the first IP address and identity information of the verified AS; The first forwarding node stores a first corresponding relationship, where the first corresponding relationship includes the first IP address and identity information of the verified AS; After the first forwarding node obtains the first data message, the method further includes: The first forwarding node obtains the identity information of the authenticated AS based on the first IP address and the first corresponding relationship. The method according to claim 19, characterized in that the first data message carries a path identifier, the path identifier is used to identify the expected forwarding path, and before the first forwarding node obtains the first data message, the method further includes: The first forwarding node receives a notification message from a path planner, where the notification message carries the path identifier, the sequence position of the verified AS, and the identity information of the verified AS; The first forwarding node stores a second corresponding relationship, where the second corresponding relationship includes the path identifier, the sequence position of the verified AS, and the identity information of the verified AS; After the first forwarding node obtains the first data message, the method further includes: The first forwarding node obtains the sequence position of the verified AS and the identity information of the verified AS based on the path identifier and the second corresponding relationship. A device for obtaining a forwarding certificate, characterized in that the device is arranged at a first forwarding node, and the device comprises: an acquisition unit, configured to acquire a first data message, wherein the at least two key nodes corresponding to the first data message include the 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 message; acquire a sequential position of the first forwarding node in the expected forwarding path and identity information of the first forwarding node, wherein 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 message, and the identity information of the first forwarding node indicates an identity of the first forwarding node; A processing unit is used to obtain a 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, wherein 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. The device according to claim 29, characterized in that 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, 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, comprising: 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, 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. The device according to claim 30 is 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. The device according to claim 31, characterized in that the processing unit is further used to obtain the sequential position of the first forwarding node in the actual forwarding path based on the first data message; The device further includes: a sending unit, configured to send a forwarding certificate of the first forwarding node and a sequential position of the first forwarding node in the actual forwarding path to a verification node. The device according to claim 32 is characterized in that 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, and the processing unit is further used to obtain a second data message based on the first data message, 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 message including the payload of the first data message, 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 used to send the second data message to the third forwarding node. The device according to claim 32, characterized in that The processing unit is further configured to generate a notification message, wherein the notification message includes a forwarding certificate of the first forwarding node and a sequential position of the first forwarding node in the actual forwarding path; The sending unit is used to send the notification message to the verification node. The device according to any one of claims 31 to 34 is characterized in that the first data message includes a segment list 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. The device according to any one of claims 31 to 35 is characterized in that 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. The device according to any one of claims 29 to 36, characterized in that the acquisition unit is used to receive the first data message from a second forwarding node, the second forwarding node is a key node located upstream of the first forwarding node in the forwarding path, and the first data message includes a forwarding certificate 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, 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 identities of the at least two key nodes, the at least two key nodes including the second forwarding node. A verification device for forwarding proof, characterized in that the device comprises: an acquisition unit, configured to acquire a forwarding proof of the 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, wherein the first vector commitment indicates a correspondence between sequential positions of at least two key nodes in the expected forwarding path and 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 is 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 ordinal position of the first forwarding node. The device according to claim 38 is characterized in that the 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, and 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, and 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. The device according to claim 38 or 39 is characterized in that the acquisition unit is used to receive the forwarding certificate of the first forwarding node from the first forwarding node. A verification device for forwarding proof, characterized in that the device is arranged at a first forwarding node, and the device further comprises: An acquiring unit, configured to acquire a first data message, wherein the first forwarding node is deployed at a boundary of a first autonomous domain AS; 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; The processing unit is further used 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, wherein 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. The device according to claim 41 is 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. The device according to claim 41 is characterized in that the verified AS includes the first AS, and the processing unit is used to obtain the actual sequential position of the first AS carried in the first data packet. The device according to claim 41 is characterized in that 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 by the processing unit based on the sequential position of the identity information of the verified AS in the AS list. The device according to claim 41 is characterized in that the destination IP address of the first data message includes a first IP address, and the acquisition unit is further used to receive a routing protocol message from the verified AS, and the routing protocol message carries the first IP address and the identity information of the verified AS; The processing unit is further used to save a first corresponding relationship, where the first corresponding relationship includes the first IP address and the identity information of the verified AS; The acquisition unit is further configured to obtain the identity information of the authenticated AS based on the first IP address and the first corresponding relationship. The device according to claim 41 is characterized in that the first data message carries a path identifier, the path identifier is used to identify the expected forwarding path, and the acquisition unit is further used to receive a notification message from the path planning party, the notification message carries the path identifier, the sequential position of the verified AS, and the identity information of the verified AS; The processing unit is further used to save a second corresponding relationship, wherein the second corresponding relationship includes the path identifier, the sequential position of the verified AS, and the identity information of the verified AS; The acquisition unit is further configured to obtain 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. A forwarding device, characterized in that the forwarding device comprises: a processor, the processor is coupled to a memory, the memory stores at least one computer program instruction, and the at least one computer program instruction is loaded and executed by the processor so that the forwarding device implements the method described in any one of claims 1-28. A computer-readable storage medium, characterized in that at least one instruction is stored in the storage medium, and when the instruction is executed on a computer, the computer executes the method as described in any one of claims 1 to 28. A computer program product, characterized in that the computer program product comprises one or more computer program instructions, and when the computer program instructions are loaded and executed by a computer, the computer is caused to execute the method described in any one of claims 1 to 28.