Forwarding proof obtaining method and device and forwarding proof verification method and device
By combining the sequential location of the forwarding node and identity information to obtain forwarding proofs, the problem of insufficient credibility of forwarding proofs is solved, and fault tolerance and efficient verification of path verification are achieved to ensure that data packets are forwarded according to the expected path.
Patent Information
- Application Number
- CN202410067738.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-01-16
- Publication Date
- 2025-07-18
AI Technical Summary
The credibility of the existing forwarding certificate is insufficient, and it is impossible to effectively verify whether the data packet is forwarded one by one according to the specified path, and there is a risk of tampering or forging.
By combining the forwarding node's sequential position in the expected forwarding path and identity information to obtain forwarding proof, the verification node verifies forwarding proof based on vector commitment and identity information to ensure the correctness and integrity of the forwarding path.
It improves the credibility of forwarding proofs, reduces the risk of data packets skipping or passing through unexpected nodes during actual transmission, and realizes fault tolerance and efficient verification performance of path verification.
Smart Images

Figure CN120342949A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of network security, and particularly to a method for obtaining a forwarding proof, a method for verifying a forwarding proof, and an apparatus therefor. Background Art
[0002] A forwarding proof refers to a kind of data generated for verifying the forwarding situation of a data packet during the process of forwarding the data packet. The forwarding proof helps to reduce the probability that the data packet is tampered with or forged during the forwarding process, thereby improving the transmission security of the data packet.
[0003] Currently, if the data packet 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 obtained forwarding proof can still pass the verification with a certain probability in this scenario, indicating that the credibility of the forwarding proof is insufficient. Summary of the Invention
[0004] Embodiments of this application provide a method for obtaining a forwarding proof, a method for verifying a forwarding proof, and an apparatus therefor, which can improve the credibility of the forwarding proof. The technical solutions are as follows.
[0005] In a first aspect, a method for obtaining a forwarding proof is provided. A first forwarding node obtains a first data packet. At least two key nodes corresponding to the first data packet include the first forwarding node, and a key node is a forwarding node passed through in the expected forwarding path determined by the path planner for the first data packet; the first forwarding node obtains the sequential position of the first forwarding node in the expected forwarding path and the identity information of the first forwarding node. The sequential position of the first forwarding node in the expected forwarding path is different from the sequential position of the first forwarding node in the actual forwarding path of the first data packet, and the identity information of the first forwarding node indicates the identity of the first forwarding node; 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, 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.
[0006] 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 related not only 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 required to pass through during the transmission of service data expected by the path planner) and whether the sequential position of the forwarding node is correct (for example, whether the sequential relationship between forwarding nodes conforms to the sequential relationship of passing through forwarding nodes during the transmission of service data expected by the path planner). 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 by, the forwarding proof obtained based on the identity information and sequential position of the key node will not pass the verification because the identity information and sequential position of the key node no longer match, thereby improving the credibility of the forwarding proof.
[0007] In particular, in the case where the sequential position of the forwarding node in the expected forwarding path is different from the sequential position of the forwarding node in the actual forwarding path, since the forwarding proof is obtained using the sequential position of the forwarding node in the expected forwarding path instead of the sequential position of the forwarding node in the actual forwarding path, the sequential position based on which the forwarding proof is obtained is consistent with the sequential position based on which the vector commitment is obtained, thus achieving fault tolerance in path verification. For example, it allows data packets to pass through some non-critical nodes (such as old devices, devices with weak capabilities, or devices produced by third-party network manufacturers) during the actual transmission process, reducing the risk that critical nodes downstream of non-critical nodes will interrupt service data transmission or output alarms due to the failure of the forwarding proof verification.
[0008] Based on the method provided in the first aspect, in some embodiments, at least two key nodes further include a second forwarding node, where the second forwarding node is a key node upstream of the first forwarding node in the expected forwarding path. The first forwarding node obtains the forwarding proof of the first forwarding node based on the sequential position of the first forwarding node in the expected forwarding path and the identity information of the first forwarding node, including: the first forwarding node obtains the forwarding proof of the first forwarding node based on the sequential position of the first forwarding node in the expected forwarding path, the identity information of the first forwarding node, the sequential position of the second forwarding node in the expected forwarding path, and the identity information of the second forwarding node. The identity information of the second forwarding node indicates the identity of the second forwarding node, and the forwarding proof of the first forwarding node is used to prove that the first forwarding node and the second forwarding node are respectively in the corresponding sequential positions in the expected forwarding path.
[0009] Since the forwarding proof is obtained based on the expected sequential positions of multiple key nodes and the identities of the multiple key nodes, the obtained forwarding proof can verify whether each of the multiple key nodes is in the corresponding sequential position in the expected forwarding path at one time, improving the overall verification performance of the forwarding path by batch processing and saving the time for computing and verifying the proof. In addition, this method makes the time consumed for obtaining the forwarding proof hardly increase linearly with the increase in the number of key nodes, thus being more adaptable to large-scale networking and improving scalability.
[0010] Based on the method provided in the first aspect, in some embodiments, the first forwarding node is the last key node in the expected forwarding path, and the second forwarding node includes all key nodes other than the first forwarding node in the expected forwarding path.
[0011] By combining the sequential positions and identities of each node from the first key node to the local end in the forwarding path to obtain the forwarding proof, it is possible to verify the sequential positions and identity information of each key node that the message has passed through in the actual forwarding path at one time, reducing the time cost and computing cost, improving the verification efficiency, and making the verification more complete.
[0012] Based on the method provided in the first aspect, in some embodiments, the method further includes: the first forwarding node obtains the sequential position of the first forwarding node in the actual forwarding path based on the first data packet; the first forwarding node sends the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path to the verification node.
[0013] Since the key node sends the sequential position of its local end in the actual forwarding path to the verification node, the verification node can perceive the sequential position of the key node in the actual forwarding path, thereby realizing the recordability of non-key nodes. For example, if the verification node determines that the sequential positions of two adjacent key nodes in the actual forwarding path are not continuous, it determines that there is a non-key node between the two key nodes. The verification node determines the number of non-key nodes between two key nodes based on the difference between the sequential positions of the two adjacent key nodes in the actual forwarding path.
[0014] In addition, since the sequential position of the actual forwarding path is recorded by the key node, it is not necessary to require non-key nodes to perform additional actions other than forwarding, and the existence of non-key nodes can also be recorded indirectly, with better compatibility.
[0015] Based on the method provided in the first aspect, in some embodiments, the verification node includes a third forwarding node, and the third forwarding node is a key node located downstream of the first forwarding node in the expected forwarding path. 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, including: The first forwarding node obtains a second data packet based on the first data packet, the forwarding proof of the first forwarding node, and the sequential position of the first forwarding node in the actual forwarding path. The second data packet includes the payload of the first data packet, the forwarding proof of the first forwarding node, and the sequential position of the first forwarding node in the actual forwarding path; the first forwarding node sends the second data packet to the third forwarding node.
[0016] Since the actual sequential position and the forwarding proof are carried in the same data packet and sent to the key node downstream of the forwarding path, the actual sequential position of the key node is transmitted along with the service data, realizing the in-band transmission of the actual sequential position. In the mode where the key node also serves as the verification node (observer), there is no need to separately construct independent data packets to transmit the actual sequential position and the forwarding proof. Therefore, the overall transmission overhead of the actual sequential position and the forwarding proof is relatively small. The verification node can obtain both the actual sequential position of the key node and the forwarding proof of the key node by parsing one data packet. Therefore, the efficiency of the verification node in obtaining the actual sequential position of the key node and the forwarding proof of the key node is also relatively high.
[0017] Based on the method provided in the first aspect, in some embodiments, the first data packet includes a first position list, and the first position list includes the sequential positions of the key nodes located upstream of the first forwarding node in the expected forwarding path in the actual forwarding path. The second data packet includes a second position list, and the second position list includes the first position list and the sequential position of the first forwarding node in the actual forwarding path.
[0018] Since the list of the sequential positions of the key nodes upstream in the actual forwarding path is carried in the data packet, and each key node further adds its own sequential position in the actual forwarding path based on the list carried in the data packet, the data packet can carry the sequential positions of each key node that the data packet has passed through in the actual forwarding path. The actual sequential positions carried in the data packet are more complete, reducing the risk of missing the actual sequential positions of the key nodes that have passed through but not been recorded.
[0019] Based on the method provided in the first aspect, in some embodiments, the second data packet includes an Internet Protocol Version 6 (IPv6) extension header, and the IPv6 extension header includes a forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path. In the 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 stream passes through the expected IPv6 nodes in the expected order.
[0020] Based on the method provided in the first aspect, in some embodiments, the second data packet includes a Network Service Header (NSH), and the NSH includes a metadata field, and the metadata field includes a forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path.
[0021] In the Service Function Chaining (SFC) scenario, by using the NSH unique to the SFC scenario to carry the forwarding proof and the actual sequential position, it is supported to prove whether the data stream passes through the expected Service Functions (SFs) in the expected order, and to record whether the data stream passes through an unexpected SF, which helps each SF process traffic in an orderly manner according to requirements.
[0022] Based on the method provided in the first aspect, in some embodiments, 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 the sequential position of the first forwarding node in the actual forwarding path.
[0023] In the MPLS scenario, by using the MPLS header to carry the forwarding proof and the actual sequential position, it is supported to prove whether the data stream passes through the expected MPLS nodes in the expected order (such as the order indicated by the MPLS label stack), so as to be applicable to scenarios such as communication based on the MPLS protocol, and provides a mechanism for verifying the data source in the MPLS network, which is convenient for verifying whether the data packet is forwarded in sequence according to the order specified by the MPLS tunnel.
[0024] Based on the method provided in the first aspect, in some embodiments, the second data packet includes a Virtual eXtensible Local Area Network (VxLAN) header, and 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 the VxLAN scenario, it is applicable to scenarios such as virtualized networks based on the VxLAN protocol or cross-data center interconnection, and provides a function for verifying the data source in the VxLAN tunnel, which is convenient for verifying whether the data packet is forwarded in sequence according to the order specified by the VxLAN tunnel.
[0025] For the method provided in the first aspect, in some embodiments, the second data packet includes an Internet Protocol Security (IPsec) header, and the IPsec header includes a forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path. The above method is applicable to network scenarios based on the IPsec protocol, providing a function to verify the data source in the IPsec tunnel, facilitating verification of whether the forwarding path through which the data packet actually passes matches the pre-planned IPsec tunnel.
[0026] For the method provided in the first 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 above method is applicable to the SRv6 scenario, facilitating verification of whether the forwarding path through which the data packet actually passes matches the pre-planned segment list.
[0027] For the method provided in the first aspect, in some embodiments, the IPv6 extension header includes an Application-Aware Network (APN) packet header, the APN packet header includes an Application-Aware Network Identifier (APN ID), and the APN ID includes a forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path. The above method is applicable to the APN6 scenario, facilitating verification of whether the forwarding path through which the data packet actually passes matches the pre-planned forwarding path in the APN network.
[0028] For the method provided in the first aspect, in some embodiments, the IPv6 extension header includes a Destination Option Header (DOH), the DOH includes a TLV, and the TLV of the DOH includes a forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path.
[0029] For the method provided in the first aspect, in some embodiments, the IPv6 extension header includes a Hop-by-Hop Option Header (HBH), the HBH includes a TLV, and the TLV of the HBH includes a forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path.
[0030] For the method provided in the first aspect, in some embodiments, 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, including: the first forwarding node generates an advertisement packet, the advertisement packet includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path; the first forwarding node sends the advertisement packet to the verification node.
[0031] By constructing independent packets to announce the actual sequential positions of critical nodes and the forwarding proofs of critical nodes, verification nodes can infer whether there are non-critical nodes in the actual forwarding path and the number of non-critical nodes in the actual forwarding path based on the sequential positions of the received critical nodes in the actual forwarding path, thereby realizing the recordability of non-critical nodes. In addition, since any critical node can send the forwarding proof and the actual sequential position to the verification node after receiving the data packet, the verification node can verify the forwarding proof in real time and record the actual sequential position, without having to wait until the data packet is transmitted to the last critical node to verify the forwarding proof and record the actual sequential position, realizing real-time transparent tracking during the data transmission process, and having a smaller attack window.
[0032] Based on the method provided in the first aspect, in some embodiments, the announcement packet includes a Network Configuration Protocol (NETCONF) packet, and the NETCONF packet includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path.
[0033] The above method supports the scenario of transmitting the forwarding proof and the actual sequential position through the management plane protocol.
[0034] The announcement packet includes a Hypertext Transfer Protocol (HTTP) packet, and the payload field in the HTTP packet includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path.
[0035] The above method supports the scenario of transmitting the forwarding proof and the actual sequential position through the data plane protocol.
[0036] Based on the method provided in the first aspect, in some embodiments, the first data packet includes a segment list, and the segment list includes the Segment Identifier (SID) of the first forwarding node. 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.
[0037] The above method provides a fast and performance - good way to obtain the expected sequential position based on the data plane. Since the forwarding node can obtain the expected sequential position based on the segment list carried in the received data packet, there is no need to configure and save a large number of entries to determine the expected sequential position, thereby reducing the storage resource overhead caused by the forwarding node pre - saving the expected sequential position, and also reducing the performance overhead caused by the forwarding node looking up the table for matching to determine the expected sequential position.
[0038] 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 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.
[0039] The above method provides a way to obtain the expected sequential position by combining the path identifier carried in the data plane and the corresponding relationship provided by the control plane. Since the expected sequential position of each key node does not need to be carried in the data packet, the overhead of data packet transmission is further reduced on the basis of supporting path verification.
[0040] Based on the method provided in the first aspect, in some embodiments, before the first forwarding node obtains the first data packet, the method further includes: the first forwarding node receives the sequential position of the first forwarding node in the expected forwarding path from the path planner.
[0041] Since the path planner pre-distributes the sequential position in the expected forwarding path before forwarding the data packet, the forwarding node can also know the expected sequential position without the need to carry the expected sequential position of each key node in the data packet, thereby further reducing the overhead of data packet transmission on the basis of supporting path verification.
[0042] Based on the method provided in the first aspect, in some embodiments, the first forwarding node obtains the first data packet, including: the first forwarding node receives the first data packet from the second forwarding node, where the second forwarding node is a key node upstream of the first forwarding node in the forwarding path, and the first data packet includes the forwarding proof of the second forwarding node; the method further includes: the first forwarding node verifies the forwarding proof of the second forwarding node based on the first vector commitment, the identity information of the second forwarding node, and the sequential position of the second forwarding node in the expected forwarding path, and the first vector commitment indicates the corresponding relationship between the sequential positions of at least two key nodes in the expected forwarding path and the identities of at least two key nodes, and the at least two key nodes include the second forwarding node.
[0043] By verifying the forwarding proof of the previous forwarding node, it is possible to confirm whether the sequential position of the previous forwarding node is the expected sequential position, whether the previous forwarding node is the expected forwarding node, and support verifying the correctness of the source of the previous hop. In network attack scenarios such as route hijacking, route injection, and traffic bypassing, if an attacker redirects traffic to a path specified by the attacker, the forwarding proof cannot pass the verification, thus enabling timely detection of network attacks existing in the data packet and reducing the risk brought 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 node in the forwarding path disguising, deceiving, or tampering with the data packet and improving the security of the network.
[0044] Based on the method provided in the first aspect, in some embodiments, the path planner is the source host that generates the payload data of the first data packet; or, the path planner is the first forwarding device in the expected forwarding path.
[0045] The above method supports scenarios of source terminal path calculation or network-side head node path calculation, with a richer application scenario.
[0046] In a second aspect, a method for verifying a forwarding proof is provided. The method includes:
[0047] The verification node obtains the forwarding proof of the first forwarding node, 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. The first vector commitment indicates the correspondence between the sequential positions of at least two key nodes in the expected forwarding path and the identities of the at least two key nodes. The at least two key nodes include the first forwarding node. The identity information of the first forwarding node indicates the identity of the first forwarding node. The forwarding proof of the first forwarding node is used to prove that the first forwarding node is in the sequential position of the first forwarding node in the expected forwarding path. The verification node verifies the forwarding proof of the first forwarding node based on the first vector commitment, the identity information of the first forwarding node, and the sequential position of the first forwarding node.
[0048] Since the forwarding proof is verified by combining the vector commitment, the expected sequential positions of the key nodes, and the identity information of the key nodes, 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 by, the forwarding proof obtained based on the identity information of the key node and the sequential position of the key node will not pass the verification due to the mismatch between the identity information of the key node and the sequential position of the key node, thereby improving the credibility of the forwarding proof.
[0049] Furthermore, in many source address or centralized routing technologies, due to network attacks such as routing hijacking, routing injection, and traffic bypass, or problems with incorrect configuration of network devices, the actual forwarding path of the data plane may deviate from the expected forwarding path of the control plane. The above methods can verify whether the service data is forwarded according to the expected forwarding path during actual 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.
[0050] In particular, when the sequential position of the forwarding node in the expected forwarding path is different from the sequential position of the forwarding node in the actual forwarding path, since the forwarding proof is obtained based on the sequential position of the forwarding node in the expected forwarding path rather than the sequential position of the forwarding node in the actual forwarding path, the sequential position based on which the forwarding proof is obtained is consistent with the sequential position based on which the vector commitment is obtained, thus achieving fault tolerance in path verification. For example, it is allowed that the data packet passes through some non-critical nodes (such as old devices, devices with weak capabilities, or devices produced by third-party network manufacturers) during actual transmission, reducing the risk that the critical nodes downstream of the non-critical nodes interrupt the transmission of service data or output alarms due to failed verification of the forwarding proof.
[0051] Based on the method provided in the second aspect, in some embodiments, at least two critical nodes further include a second forwarding node, where the second forwarding node is a critical node located upstream of the first forwarding node in the expected forwarding path. The verification node verifies the forwarding proof of the first forwarding node based on the first vector commitment, the identity information of the first forwarding node, and the sequential position of the first forwarding node in the expected forwarding path, including:
[0052] 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 both the first forwarding node and the second forwarding node are in the corresponding sequential positions in the expected forwarding path.
[0053] Since the forwarding proof is verified based on the expected sequential positions of multiple critical nodes and the identities of multiple critical nodes, it is possible to verify whether multiple critical nodes are respectively in the corresponding sequential positions in the expected forwarding path at one time, improving the overall verification performance of the forwarding path by using batch processing and saving the time for computing and verifying the proof. In addition, this method makes the time consumed for obtaining the forwarding proof hardly increase linearly with the increase in the number of critical nodes, thus being more adaptable to large-scale networking and improving scalability.
[0054] Based on the method provided in the second aspect, in some embodiments, for a verification node to obtain a forwarding proof of a first forwarding node, it includes: the verification node receiving the forwarding proof of the first forwarding node from the first forwarding node.
[0055] In a third aspect, a method for verifying a forwarding proof is provided. The method further includes: a first forwarding node obtaining a first data packet, where the first forwarding node is deployed at the boundary of a first autonomous system (AS); the first forwarding node obtaining a forwarding proof of a verified AS based on the sequential position of the verified AS and the identity information of the verified AS, where the identity information of the verified AS indicates the identity of the verified AS; the first forwarding node verifying the forwarding proof of the verified AS based on a second vector commitment, the sequential position of the verified AS, and the identity information of the verified AS, where the second vector commitment indicates the correspondence between the identity information of each AS in at least two ASs and the sequential position of each AS.
[0056] Since the forwarding proof of the verified AS is obtained based on the identity information of the verified AS and the sequential position of the verified AS, and the forwarding proof of the verified AS is compared with the vector commitment, 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, realizing path verification at the AS level. In a cross-AS transmission scenario, it is possible to verify whether the AS that the data packet is to pass through or has passed through belongs to the ASs passed through in the planned expected path, reducing the risk caused by the data packet passing through an unexpected AS. For example, reducing the risk of a decline in network transmission quality caused by the data packet passing through an AS with unsatisfactory network transmission quality (such as unqualified delay and packet loss rate), or reducing the security risk caused by the data packet passing through an AS with unsatisfactory network security (such as an AS with identified security risks).
[0057] Based on the method provided in the third aspect, in some embodiments, the verified AS includes at least one of each AS among the neighbor AS of the first AS, the first AS, or the source AS to the first AS. The neighbor AS includes the previous AS of the first AS in the actual forwarding path of the first data packet and / or the next AS of the first AS in the reachable path of the destination IP address of the first data packet. The source AS is the AS communicating with the source host, and the source host is a device generating the payload data of the first data packet.
[0058] By obtaining the forwarding proof of the next AS and verifying the forwarding proof of the next AS, it is possible to verify in advance whether the sequential position and identity of the next AS to which the data packet may be forwarded are correct before actually forwarding the data packet, thereby reducing the security risk of business data transmission caused by the data packet entering an unexpected AS.
[0059] By obtaining the forwarding proof of the previous AS and verifying the forwarding proof of the previous AS, the security of the data packet in the cross-AS transmission scenario is enhanced by verifying whether the data packet comes from an AS with an unexpected sequential position or / and identity.
[0060] Based on the method provided by the third party, in some embodiments, the sequential position of the AS to be verified includes the expected sequential position of the AS to be verified or the actual sequential position of the AS to be verified. The expected sequential position of the AS to be verified is used to indicate the sequential relationship between the AS to be verified and the ASes passed by the expected forwarding path of the first data packet, and the actual sequential position of the AS to be verified is used to indicate the sequential relationship between the AS to be verified and the ASes passed by the actual forwarding path of the first data packet.
[0061] By using the expected sequential position of the AS to be verified for path verification, it is allowed to insert an unexpected AS between two expected ASes in the actual forwarding path, so as to achieve fault tolerance at the AS level on the basis of realizing path verification at the AS level.
[0062] By using the actual sequential position of the AS to be verified for path verification, it is possible to verify whether the identity and sequential position of each AS passed by the actual forwarding path are exactly the same as those of each AS passed by the expected forwarding path, so as to achieve more strict path verification at the AS level.
[0063] Based on the method provided by the third party, in some embodiments, the AS to be verified includes the 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 AS to be verified is obtained based on the actual sequential position of the first AS and the sequential relationship between the first AS and the AS to be verified.
[0064] The above method provides a fast and high-performance way to obtain the actual sequential position of an AS based on the data plane. Since the forwarding node can obtain the actual sequential position of the AS to be verified based on the segment list carried in the received data packet, there is no need to configure and save a large number of entries to determine the expected sequential position, thus reducing the storage resource overhead caused by the forwarding node pre-saving the expected sequential position, and also reducing the performance overhead caused by the forwarding node looking up the table for matching to determine the expected sequential position.
[0065] Based on the method provided by the third party, in some embodiments, the AS to be verified includes the first AS, and the first data packet carries the actual sequential position of the first AS.
[0066] Since the data packet carries the actual sequential position of the current AS, it is equivalent to the data packet carrying a TTL at the AS level. For example, whenever the data packet passes through an AS, the actual sequential position of the AS in the data packet is updated once. The forwarding node can know which AS the data packet is currently passing through based on the content of the packet header of the received data packet. Therefore, it not only supports strict path verification based on the actual sequential position of the AS, without requiring the data packet to carry the sequential positions of all the passed ASs in full, reducing the overhead of the data packet, but also has a relatively low implementation complexity.
[0067] Based on the method provided by the third party, in some embodiments, an AS list is carried in the first data packet. The AS list includes the identity information of each AS that the expected forwarding path of the first data packet passes through. The expected sequential position of the AS to be verified is obtained based on the sequential position of the identity information of the AS to be verified in the AS list.
[0068] Since each AS that the expected forwarding path passes through is indicated by the AS list in the data packet, it not only supports path verification based on the expected sequential position of the AS, but also realizes the fault tolerance of path verification at the AS level, and there is no need to configure and save a large number of entries to determine the expected sequential position. Therefore, it reduces the storage resource overhead caused by the forwarding node pre-saving the expected sequential position, and also reduces the performance overhead caused by the forwarding node looking up the table to determine the expected sequential position.
[0069] Based on the method provided by the third party, in some embodiments, a second vector commitment is carried in the first data packet.
[0070] The vector commitment is equivalent to a reference value used to compare with the forwarding proof when verifying the forwarding proof. Since the vector commitment is carried by the data packet, it reduces the storage resource overhead caused by the forwarding node pre-saving the vector commitment, and also reduces the performance overhead caused by the forwarding node looking up the table to match the vector commitment.
[0071] Based on the method provided by the third party, in some embodiments, based on the method provided by the third party, in some embodiments, the first data packet includes an Internet Protocol Version 6 (IPv6) extension header, and the IPv6 extension header carries the sequential position of the AS to be verified, the identity information of the AS to be verified, and the second vector commitment; or,
[0072] The first data packet includes a Network Service Header (NSH), and the NSH includes a metadata field, and the metadata field carries the sequential position of the AS to be verified, the identity information of the AS to be verified, and the second vector commitment; or,
[0073] The first data packet includes a Multiprotocol Label Switching (MPLS) header, which carries the sequential position of the AS to be verified, the identity information of the AS to be verified, and a second vector commitment; or,
[0074] The first data packet includes a Virtual Extensible Local Area Network (VxLAN) header, which carries the sequential position of the AS to be verified, the identity information of the AS to be verified, and a second vector commitment; or,
[0075] The first data packet includes an Internet Protocol Security (IPsec) header, which carries the sequential position of the AS to be verified, the identity information of the AS to be verified, and a second vector commitment.
[0076] Based on the method provided by the third party, in some embodiments, the destination IP address of the first data packet includes a first IP address. Before the first forwarding node obtains the first data packet, the method further includes: the first forwarding node receives a routing protocol packet from the AS to be verified, and the routing protocol packet carries the first IP address and the identity information of the AS to be verified; the first forwarding node saves a first correspondence relationship, which includes the first IP address and the identity information of the AS to be verified;
[0077] After the first forwarding node obtains the first data packet, the method further includes: the first forwarding node obtains the identity information of the AS to be verified based on the first IP address and the first correspondence relationship.
[0078] The above method supports the AS to be verified to pre - announce the identity information of this AS through the control plane.
[0079] Based on the method provided by the third party, in some embodiments, the first data packet carries a path identifier, which is used to identify the expected forwarding path. Before the first forwarding node obtains the first data packet, the method further includes: the first forwarding node receives an advertisement packet from the path planner, and the advertisement packet carries the path identifier, the sequential position of the AS to be verified, and the identity information of the AS to be verified; the first forwarding node saves a second correspondence relationship, which includes the path identifier, the sequential position of the AS to be verified, and the identity information of the AS to be verified;
[0080] After the first forwarding node obtains the first data packet, the method further includes: the first forwarding node obtains the sequential position of the AS to be verified and the identity information of the AS to be verified based on the path identifier and the second correspondence relationship. The above method supports the path planner to pre - announce the sequential position of the AS to be verified and the identity information of the AS to be verified.
[0081] In a fourth aspect, a device for obtaining a forwarding proof is provided. The device is disposed in the first forwarding node, and the device includes:
[0082] An acquisition unit is configured to acquire a first data packet. At least two key nodes corresponding to the first data packet include a first forwarding node. A key node is a forwarding node passed through in an expected forwarding path determined by a path planner for the first data packet. The acquisition unit is configured to acquire the sequential position of the first forwarding node in the expected forwarding path and the identity information of the first forwarding node. The sequential position of the first forwarding node in the expected forwarding path is different from the sequential position of the first forwarding node in the actual forwarding path of the first data packet. The identity information of the first forwarding node indicates the identity of the first forwarding node. A processing unit is configured to obtain a forwarding certificate of the first forwarding node based on the sequential position of the first forwarding node in the expected forwarding path and the identity information of the first forwarding node. The forwarding certificate of the first forwarding node is used to prove that the first forwarding node forwards the first data packet at the sequential position in the expected forwarding path.
[0083] Based on the apparatus provided in the fourth aspect, in some embodiments, at least two key nodes further include a second forwarding node. The second forwarding node is a key node located upstream of the first forwarding node in the expected forwarding path. The processing unit is configured to obtain a forwarding certificate of the first forwarding node based on the sequential position of the first forwarding node in the expected forwarding path, the identity information of the first forwarding node, the sequential position of the second forwarding node in the expected forwarding path, and the identity information of the second forwarding node. The identity information of the second forwarding node indicates the identity of the second forwarding node. The forwarding certificate of the first forwarding node is used to prove that the first forwarding node and the second forwarding node are respectively at the corresponding sequential positions in the expected forwarding path.
[0084] Based on the apparatus provided in the fourth aspect, in some embodiments, the first forwarding node is the last key node in the expected forwarding path, and the second forwarding node includes all key nodes other than the first forwarding node in the expected forwarding path.
[0085] Based on the apparatus provided in the fourth aspect, in some embodiments, the processing unit is further configured to obtain the sequential position of the first forwarding node in the actual forwarding path based on the first data packet.
[0086] The apparatus further includes: a sending unit configured to send the forwarding certificate of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path to a verification node.
[0087] Based on the apparatus provided in the fourth aspect, in some embodiments, the verification node includes a third forwarding node, where the third forwarding node is a key node downstream of the first forwarding node in the expected forwarding path. The processing unit is further configured to obtain a second data packet based on the first data packet, the forwarding proof of the first forwarding node, and the sequential position of the first forwarding node in the actual forwarding path. The second data packet includes the payload of the first data packet, the forwarding proof of the first forwarding node, and the sequential position of the first forwarding node in the actual forwarding path. The sending unit is configured to send the second data packet to the third forwarding node.
[0088] Based on the apparatus provided in the fourth aspect, in some embodiments, the first data packet includes a first position list, where the first position list includes the sequential positions of the key nodes upstream of the first forwarding node in the expected forwarding path in the actual forwarding path. The second data packet includes a second position list, where the second position list includes the first position list and the sequential position of the first forwarding node in the actual forwarding path.
[0089] Based on the apparatus provided in the fourth aspect, in some embodiments, the second data packet includes an Internet Protocol Version 6 (IPv6) extension header, where the IPv6 extension header includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path; or, the second data packet includes a Network Service Header (NSH), where the NSH includes a metadata field, and the metadata field includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path; or, the second data packet includes a Multi-Protocol Label Switching (MPLS) header, where the MPLS header includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path; or, the second data packet includes a Virtual Extensible LAN (VxLAN) header, where the VxLAN header includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path; or, the second data packet includes an Internet Protocol Security (IPsec) header, where the IPsec header includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path.
[0090] Based on the apparatus provided in the fourth aspect, in some embodiments, the IPv6 extension header includes a Segment Routing Header (SRH), where the SRH includes a Type-Length-Value (TLV), and the TLV of the SRH includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path.
[0091] The IPv6 extension header includes an Application-Aware Network (APN) packet header, where the APN packet header includes an Application-Aware Network Identifier (APNID), and the APN ID includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path.
[0092] The IPv6 extension header includes a Destination Options Header (DOH), and the DOH includes TLVs. The TLVs of the DOH include the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path.
[0093] The IPv6 extension header includes a Hop-by-Hop Options Header (HBH), and the HBH includes TLVs. The TLVs of the HBH include the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path.
[0094] Based on the apparatus provided in the fourth aspect, in some embodiments, the processing unit is further configured to generate an advertisement message, where the advertisement message includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path;
[0095] The sending unit is configured to send the advertisement message to a verification node.
[0096] Based on the apparatus provided in the fourth aspect, in some embodiments, the advertisement message includes a Network Configuration Protocol (NETCONF) message, and the NETCONF message includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path; or,
[0097] The advertisement message includes a Hypertext Transfer Protocol (HTTP) message, and the payload field in the HTTP message includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path.
[0098] Based on the apparatus provided in the fourth aspect, in some embodiments, the first data message includes a segment list, and the segment list includes the Segment Identifier (SID) of the first forwarding node. The processing unit is configured to obtain the sequential position of the first forwarding node in the expected forwarding path based on the sequential position of the SID of the first forwarding node in the segment list.
[0099] Based on the apparatus provided in the fourth aspect, in some embodiments, the first data message includes a path identifier, and the processing unit is configured to obtain the sequential position of the first forwarding node in the expected forwarding path based on the path identifier and the corresponding relationship saved by the first forwarding node. The corresponding relationship includes the path identifier and the sequential position of the first forwarding node in the expected forwarding path.
[0100] Based on the apparatus provided in the fourth aspect, in some embodiments, the obtaining unit is further configured to receive the sequential position of the first forwarding node in the expected forwarding path from a path planner.
[0101] Based on the apparatus provided in the fourth aspect, in some embodiments, an obtaining unit is configured to receive a first data packet from a second forwarding node, where the second forwarding node is a key node upstream of the first forwarding node in the forwarding path, and the first data packet includes a forwarding proof of the second forwarding node.
[0102] A processing unit is further configured to verify the forwarding proof of the second forwarding node based on the first vector commitment, the identity information of the second forwarding node, and the sequential position of the second forwarding node in the expected forwarding path. The first vector commitment indicates the correspondence between the sequential positions of at least two key nodes in the expected forwarding path and the identities of the at least two key nodes, and the at least two key nodes include the second forwarding node.
[0103] Based on the apparatus provided in the fourth aspect, in some embodiments, the path planner is a source host that generates the payload data of the first data packet; or, the path planner is the first forwarding device in the expected forwarding path.
[0104] In a fifth aspect, a verification apparatus for a forwarding proof is provided. The apparatus includes: an obtaining unit configured to obtain a forwarding proof of a first forwarding node, a first vector commitment, identity information of the first forwarding node, and the sequential position of the first forwarding node in the expected forwarding path. The first vector commitment indicates the correspondence between the sequential positions of at least two key nodes in the expected forwarding path and the identities of the at least two key nodes, the at least two key nodes 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 configured to verify the forwarding proof of the first forwarding node based on the first vector commitment, the identity information of the first forwarding node, and the sequential position of the first forwarding node.
[0105] Based on the apparatus provided in the fifth aspect, in some embodiments, the at least two key nodes further include a second forwarding node, where the second forwarding node is a key node upstream of the first forwarding node in the expected forwarding path. The verification unit is configured to verify the forwarding proof of the first forwarding node based on the first vector commitment, the sequential position of the first forwarding node in the expected forwarding path, the identity information of the first forwarding node, the sequential position of the second forwarding node in the expected forwarding path, and the identity information of the second forwarding node. The identity information of the second forwarding node indicates the identity of the second forwarding node, and the forwarding proof of the first forwarding node is used to prove that both the first forwarding node and the second forwarding node are in the corresponding sequential positions in the expected forwarding path.
[0106] Based on the apparatus provided in the fifth aspect, in some embodiments, the obtaining unit is configured to receive the forwarding proof of the first forwarding node from the first forwarding node.
[0107] In a sixth aspect, a verification device for forwarding proofs is provided. The device is disposed in a first forwarding node, and the device further includes:
[0108] An obtaining unit, configured to obtain a first data packet, where the first forwarding node is deployed at the boundary of a first autonomous system (AS);
[0109] A processing unit, configured to obtain a forwarding proof of the AS to be verified based on the sequential position of the AS to be verified and the identity information of the AS to be verified, where the identity information of the AS to be verified indicates the identity of the AS to be verified;
[0110] The processing unit is further configured to verify the forwarding proof of the AS to be verified based on a second vector commitment, the sequential position of the AS to be verified, and the identity information of the AS to be verified, where 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.
[0111] Based on the device provided in the sixth aspect, in some embodiments, the AS to be verified 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 or / and the next AS of the first AS in the reachable path of the destination IP address of the first data packet. The source AS is the AS communicating with the source host, and the source host is a device generating the payload data of the first data packet.
[0112] Based on the device provided in the sixth aspect, in some embodiments, the sequential position of the AS to be verified includes the expected sequential position of the AS to be verified or the actual sequential position of the AS to be verified. The expected sequential position of the AS to be verified is used to indicate the sequential relationship between the AS to be verified and the ASs passed by the expected forwarding path of the first data packet, and the actual sequential position of the AS to be verified is used to indicate the sequential relationship between the AS to be verified and the ASs passed by the actual forwarding path of the first data packet.
[0113] Based on the device provided in the sixth aspect, in some embodiments, the AS to be verified 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 AS to be verified is obtained based on the actual sequential position of the first AS and the sequential relationship between the first AS and the AS to be verified.
[0114] Based on the device provided in the sixth aspect, in some embodiments, the AS to be verified includes the first AS, and the actual sequential position of the first AS is carried in the first data packet.
[0115] Based on the apparatus provided in the sixth aspect, in some embodiments, an AS list is carried in the first data packet. 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 AS to be verified is obtained based on the sequential position of the AS to be verified in the AS list.
[0116] Based on the apparatus provided in the sixth aspect, in some embodiments, a second vector commitment is carried in the first data packet.
[0117] Based on the apparatus provided in the sixth aspect, in some embodiments, the first data packet includes an Internet Protocol Version 6 (IPv6) extension header, and the sequential position of the AS to be verified, the identity information of the AS to be verified, and the second vector commitment are carried in the IPv6 extension header; or,
[0118] the first data packet includes a Network Service Header (NSH), the NSH includes a metadata field, and the sequential position of the AS to be verified, the identity information of the AS to be verified, and the second vector commitment are carried in the metadata field; or,
[0119] the first data packet includes a Multi-Protocol Label Switching (MPLS) header, and the sequential position of the AS to be verified, the identity information of the AS to be verified, and the second vector commitment are carried in the MPLS header; or,
[0120] the first data packet includes a Virtual eXtensible Local Area Network (VxLAN) header, and the sequential position of the AS to be verified, the identity information of the AS to be verified, and the second vector commitment are carried in the VxLAN header; or,
[0121] the first data packet includes an Internet Protocol Security (IPsec) header, and the sequential position of the AS to be verified, the identity information of the AS to be verified, and the second vector commitment are carried in the IPsec header.
[0122] Based on the apparatus provided in the sixth aspect, in some embodiments, the destination IP address of the first data packet includes a first IP address. The obtaining unit is further configured to receive a routing protocol packet from the AS to be verified, and the first IP address and the identity information of the AS to be verified are carried in the routing protocol packet;
[0123] The processing unit is further configured to save a first correspondence, and the first correspondence includes the first IP address and the identity information of the AS to be verified;
[0124] The obtaining unit is further configured to obtain the identity information of the AS to be verified based on the first IP address and the first correspondence.
[0125] For the apparatus provided in the sixth aspect, in some embodiments, a path identifier is carried in the first data packet, and the path identifier is used to identify the expected forwarding path. The obtaining unit is further configured to receive an advertisement packet from a path planner, where the advertisement packet carries the path identifier, the sequential position of the AS to be verified, and the identity information of the AS to be verified;
[0126] The processing unit is further configured to save a second correspondence, where the second correspondence includes the path identifier, the sequential position of the AS to be verified, and the identity information of the AS to be verified;
[0127] The obtaining unit is further configured to obtain the sequential position of the AS to be verified and the identity information of the AS to be verified based on the path identifier and the second correspondence.
[0128] In a seventh aspect, a forwarding device is provided. The forwarding device includes a processor, the processor is coupled to a memory, and at least one computer program instruction is stored in the memory. The at least one computer program instruction is loaded and executed by the processor to enable the forwarding device to execute 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 network interface is used to receive or send packets. For the specific details of the forwarding device provided in the seventh aspect, reference may be made to 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 network interface is used to receive or send packets, which will not be elaborated here.
[0129] In an eighth aspect, a computing device is provided. The computing device includes a processor, the processor is coupled to a memory, and at least one computer program instruction is stored in the memory. The at least one computer program instruction is loaded and executed by the processor to enable the computing device to implement 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. For the specific details of the computing device provided in the eighth aspect, reference may be made to 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, which will not be elaborated here.
[0130] In a ninth aspect, a computer-readable storage medium is provided. At least one instruction is stored in the storage medium. When the instruction runs on a computer, the computer is enabled to execute 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.
[0131] In a tenth aspect, a computer program product is provided. The computer program product includes one or more computer program instructions. When the computer program instructions are loaded and run by a computer, the computer is caused to execute 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.
[0132] In an eleventh aspect, a chip is provided, including a memory and a processor. The memory is used for storing computer instructions, and the processor is used for calling and running the computer instructions from the memory to execute 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.
[0133] In a twelfth aspect, a network system is provided. The network system includes the device in the fourth aspect and the device in the fifth aspect. Description of the Drawings
[0134] Figure 1 is a schematic diagram of an application scenario provided by an embodiment of the present application;
[0135] Figure 2 is a schematic diagram of a path verification method provided by an embodiment of the present application;
[0136] Figure 3 shows an architecture diagram of a trusted path network system provided by an embodiment of the present application;
[0137] Figure 4 shows an architecture diagram of another trusted path network system provided by an embodiment of the present application;
[0138] Figure 5 shows an architecture diagram of yet another trusted path network system provided by an embodiment of the present application;
[0139] Figure 6 is a schematic diagram of an application scenario provided by an embodiment of the present application;
[0140] Figure 7 is a schematic diagram of a message format provided by an embodiment of the present application;
[0141] Figure 8 is a schematic diagram of a message format provided by an embodiment of the present application;
[0142] Figure 9 is a schematic diagram of a scenario of transmitting data streams between autonomous systems provided by an embodiment of the present application;
[0143] Figure 10 It is a flowchart of a path verification method provided by an embodiment of the present application;
[0144] Figure 11 It is a schematic structural diagram of an apparatus for obtaining a forwarding proof provided by an embodiment of the present application;
[0145] Figure 12 It is a schematic structural diagram of an apparatus for verifying a forwarding proof provided by an embodiment of the present application;
[0146] Figure 13 It is a schematic structural diagram of an apparatus for obtaining a forwarding proof provided by an embodiment of the present application;
[0147] Figure 14 It is a schematic structural diagram of a device provided by an embodiment of the present application. Detailed implementation manners
[0148] To make the objectives, technical solutions and advantages of the present application clearer, the following will further describe the embodiments of the present application in detail with reference to the accompanying drawings.
[0149] The following explains some term concepts related to the embodiments of the present application.
[0150] (1) Path verification mechanism
[0151] The path verification mechanism refers to a technology that supports verifying whether service data is forwarded along the expected forwarding path during actual transmission. In some embodiments of the present application, a forwarding proof of a verification object is obtained based on the identity information of the verification object and the sequential position of the verification object. Taking the vector commitment as reference data, 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, thereby implementing the path verification mechanism. For example, if the forwarding proof of the verification object passes, the forwarding node determines that the verification object is an object that the service 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 an object that the service 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.
[0152] In the embodiments of the present application, the verification objects include verification objects at the device (node) level and verification objects at the autonomous system (AS) level. The verification objects at the device level include at least one of the current node, the neighbor nodes of the current node, and / or each node passed by the upper-half path. The verification objects at the AS level include at least one of the current AS, the neighbor AS of the current AS, each AS passed by the upper-half path, and / or the next AS of the current AS. Correspondingly, 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 nodes based on the identity information of the forwarding nodes 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 ASs based on the identity information of the ASs and the sequential relationship between the ASs.
[0153] In some embodiments, one of the path verification method at the device level and the path verification method at the AS level is selectively executed. In some other embodiments, both the path verification method at the device level and the path verification method at the AS level are executed. For example, the path verification method required to be executed by the forwarding node is determined according to the network deployment location of the forwarding node. For example, the forwarding nodes inside the AS execute the path verification method at the device level. For example, the forwarding nodes inside the AS perform path verification for the previous hop node or the next hop node of the current node. The forwarding nodes at the AS boundary execute the path verification method at the AS level. For example, the forwarding nodes at the AS boundary perform path verification for the previous AS or the next AS of the current AS.
[0154] The term "current" mainly refers to the time when the data packet (service data) is obtained. For example, when the data packet 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 nodes of the current node refer to the nodes having a neighbor relationship with the current node (the node to which the data packet is currently transmitted). For example, the neighbor nodes of the current node include the previous node of the current node (also referred to as the previous hop node) or the next node of the current node. The main difference in the method flows executed for different verification objects lies in the differences in the identity information and sequential positions used as the input data of the algorithm.
[0155] (2) Expected forwarding path
[0156] An expected forwarding path refers to the forwarding path determined by the path planner before the data packet is forwarded. For example, the expected forwarding path is the forwarding path determined by the controller through path calculation based on the network topology. The expected forwarding path includes at least two forwarding nodes. For example, the expected forwarding nodes include key node 1 and the tail node. In some embodiments, the expected forwarding path further includes one or more intermediate nodes located between key node 1 and the tail node. The expected forwarding path is, for example, an end-to-end path. In the scenario of segment routing over IPv6 (SRv6) based on Internet Protocol Version 6 (IPv6), the expected forwarding path is, for example, represented in the form of a segment list, a candidate path (CP), or an SR policy. In the scenario of multi-protocol label switching (MPLS) or segment routing over multi-protocol label switching (SR-MPLS), the expected forwarding path is, for example, represented in the form of an MPLS label stack. In the scenario of SFC, the expected forwarding path is, for example, represented by a service function chain.
[0157] (3) Actual forwarding path
[0158] The actual forwarding path refers to the path actually traversed by the data packet during forwarding. For example, the actual forwarding path includes each device from the ingress device of the network where the data packet enters to the egress device of the network. In some scenarios provided in this application, there is at least one non-key node between two key nodes in the actual forwarding path. For example, please refer to (b) in the appendix Figure 1 There are key node A, key node B, and key node C in the actual forwarding path. There are non-key nodes a and non-key node b between key node A and key node B in the actual forwarding path, and there is non-key node c between key node B and key node C in the actual forwarding path.
[0159] (4) Roles involved in the path verification mechanism
[0160] The path verification mechanism is usually achieved through the collaborative cooperation of three entities: the path planner, the forwarding node, and the verification node. Among them, the path planner is used to determine the vector commitment, the forwarding node is used to determine the forwarding proof during the process of forwarding service data, and the verification node is used to compare the vector commitment with the forwarding proof for verification.
[0161] 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.
[0162] 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.
[0163] (5) Forwarding Node
[0164] 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.
[0165] (6) Path planning
[0166] 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.
[0167] (7) Key Nodes
[0168] 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 nodes existing in the expected forwarding path are called key nodes, and the AS where the forwarding nodes existing in the expected forwarding path are located is called the key AS.
[0169] A key node is also called a forwarding key node or an expected node. A key node is a forwarding node that the path planner designates that the service data needs to pass through during the forwarding process. The expected forwarding path determined by the path planner includes at least two key nodes. A key node usually supports the ability to calculate a forwarding proof or / and the ability to verify a forwarding proof. For example, a key node stores configuration information related to the calculation of a forwarding proof or / and the verification of a forwarding proof, and activates the function of calculating a forwarding proof or / and the verification of a forwarding proof. During the transmission of service data, when a data packet carrying the service data arrives at a key node, the key node can calculate a forwarding proof.
[0170] A type of forwarding node opposite to a key node is a non-key node. A non-key node is a forwarding node that the network path planner does not designate that the service data needs to pass through. A non-key node is not located in the expected forwarding path. A data packet may pass through one or more non-key nodes during actual forwarding. For example, a non-key node is a forwarding node that the actual forwarding path passes through more than the expected forwarding path. A non-key node usually does not support the calculation of a forwarding proof or / and the verification of a forwarding proof. Or, a non-key node supports but does not activate the calculation of a forwarding proof or / and the verification of a forwarding proof. Or, a non-key node supports but does not enable the activation of the calculation of a forwarding proof or / and the verification of a forwarding proof. A non-key node is, for example, an old device, a device with weak capabilities, or a device produced by a third-party network manufacturer. Another example is that a non-key node is a layer 2 switch.
[0171] When the controller orchestrates the expected forwarding path, it will not know in advance which non-key nodes exist and will not orchestrate non-key nodes into the expected forwarding path. During the actual forwarding process, it may be decided by the key node itself to pass through these non-key nodes, resulting in the actual forwarding path having these non-key nodes more than the expected forwarding path. For example, please refer to the appendix Figure 1 , the sequential positions of key node A and key node B in the expected forwarding path are adjacent. However, when key node A actually forwards a data packet, key node A does not directly forward the data packet to key node B, but forwards the data packet to key node B through a tunnel. Non-key node a and non-key node b are passed through in the tunnel. Non-key node a and non-key node b are used to forward the data packet from key node A to key node B. Due to the use of the tunnel forwarding method, the actual forwarding path has non-key node a and non-key node b more than the expected forwarding path.
[0172] (8) Forwarding path lock-in
[0173] The forwarding path lock-in is a technical effect expected to be achieved by the embodiments of the present application. The forwarding path lock-in means that the service data is actually forwarded hop by hop along the trusted path (expected forwarding path) pre-planned by the path planner during the actual transmission process, thereby improving the transmission security of the service data. In some embodiments of the present application, the forwarding path lock-in specifically includes the effects of the correctness of the key node identity and the correctness of the key node sequence relationship in these two aspects.
[0174] The correctness of the key node identity means that the identity of the key nodes passed by the service data during the actual transmission process matches the identity of the key nodes expected by the path planner. For example, the path planner expects the service data to pass through N key nodes, and the service data actually passes through these 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 nodes, and the verification node verifies the forwarding proof based on the vector commitment and the identity information of the key nodes, so that both the vector commitment and the forwarding proof are bound to the identity information of the key nodes. Based on this, the forwarding proof determined by using the correct identity information of the key nodes can pass the verification, and it is difficult for a third party to forge a correct forwarding proof because it is difficult to obtain the correct identity information of the key nodes, thereby achieving the correctness of the key node identity.
[0175] The correctness of the sequential relationship of key nodes is also known as the sequential data forwarding property, location locking property, or sequential location binding property. The correctness of the sequential relationship of key nodes means that the sequential relationship of each key node in the actual forwarding path is consistent with the sequential relationship of each key node in the expected forwarding path determined by the path planner, and it is not possible to skip the key nodes in the expected forwarding path or pass through additional key nodes that do not appear in the expected forwarding path. For example, if the path planner expects the service data to pass through key node A first, then through key node B, and finally through key node C, the service data should also pass through key node A first, then through key node B, and finally through key node C during actual transmission. It is not possible to pass through key node C first, then through key node B, and finally through key node A, nor can it 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, since 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, the vector commitment and the forwarding proof are both 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 a correct forwarding proof because it is difficult to obtain the correct sequential positions of the key nodes, thereby achieving the correctness of the key node identities.
[0176] In some embodiments of the present application, by combining the sequential positions of the key nodes and the identity information of the key nodes to obtain the vector commitment, the vector commitment is not only related to the identity information of the key nodes but also related to the sequential positions of the key nodes. Therefore, when verifying the forwarding proof based on this vector commitment, only the forwarding proof generated under the condition that the sequential relationship is correct and the identity information is correct can pass the verification. Based on this, if the path planner designates that the service data passes through the first key node and the i-th key node passed by the service data is the first key node, the correct forwarding proof p_i can be calculated only through the correct identity information of the first key node and the correct sequential position (i) of the first key node, and it is difficult for others to forge the forwarding proof. On the contrary, if the service data skips the expected key nodes or passes through redundant unexpected key nodes during actual forwarding, then when the service data is transmitted to the key node that is skipped or the downstream key node of the redundant key node, the sequential position of the downstream key node will be inconsistent with the expected sequential position. Therefore, the forwarding proof obtained at the downstream key node cannot pass the verification, thereby being able to achieve both the correctness of the key node identities and the correctness of the sequential relationship of the key nodes simultaneously.
[0177] For example, if the expected forwarding path is key node A → key node B → key node C → key node D, then the expected sequential position of key node A is 1, the expected sequential position of key node B is 2, the expected sequential position of key node C is 3, and the expected sequential position of key node D is 4. When 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 sequential position of key node A (1), the identity of key node B and the expected sequential position of key node B (2), the identity of key node C and the expected sequential position of key node C (3), or the identity of key node D and the expected sequential position of key node D (4) can pass the verification. If the expected key node C is skipped during the forwarding process and 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 the forwarding proof 2 based on the actual sequential position (3) and identity (D). Since the actual sequential position (3) and identity (D) on which the forwarding proof 2 is based do not match, the forwarding proof 2 cannot pass the verification. Another example is that when passing through redundant unspecified nodes, an extra key node E is added to the 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 sequential position (5) and identity (D) of key node D on the forwarding path 2 are used to calculate the forwarding proof 2 and the initially generated commitment is used for adjacent verification, since the actual sequential position (5) and identity (D) on which the forwarding proof 2 is based do not match, the forwarding proof 2 cannot pass the verification either.
[0178] (9) Fault tolerance of path verification
[0179] The fault tolerance of path verification is a technical effect expected to be achieved in the embodiments of this application. The fault tolerance of path verification includes node-level fault tolerance and AS-level fault tolerance.
[0180] The node-level fault tolerance of path verification means that while achieving path lock-in, it allows service data to pass through non-key nodes during actual transmission, reducing the risk that key nodes downstream of non-key nodes interrupt service data transmission or output alarms due to failed verification of forwarding proofs. In other words, it supports the existence of one or more key nodes between two key nodes in the actual forwarding path, without strictly requiring that the sequential position of each key node in the expected forwarding path is the same as the sequential position of the corresponding key node in the actual forwarding path for the forwarding proof to pass the verification.
[0181] A typical application scenario that requires fault tolerance for non-critical nodes is when business data passes through non-critical nodes during actual forwarding. 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 order positions of the at least two critical nodes are different from the order positions in which the at least two critical nodes actually forward the business data. For example, the actual forwarding path of the first data packet has additional non-critical nodes compared to the expected forwarding path of the first data packet.
[0182] As an example, critical node A and critical node B are adjacent in the expected forwarding path in terms of order position, but a tunnel is established between critical node A and critical node B during the actual transmission of business data. Critical node A transmits the business data to critical node B through a series of intermediate nodes in the tunnel, resulting in non-adjacent order positions of critical node A and critical node B in the actual forwarding path.
[0183] For instance, the expected forwarding path is a three-layer forwarding path composed of three-layer forwarding devices. In this three-layer forwarding path, critical node B is the next forwarding node after critical node A. However, critical node A actually transmits the business data to critical node B through a two-layer tunnel. The two-layer tunnel passes through one or more two-layer forwarding devices, resulting in non-adjacent order positions of critical node A and critical node B in the actual forwarding path. Each two-layer forwarding device passed through by the two-layer tunnel between critical node A and critical node B exists in the actual forwarding path.
[0184] Another example is that the expected forwarding path is an SRv6 path composed of SRv6 endpoint devices. In this SRv6 path, critical node B is the next SRv6 endpoint device after critical node A. However, critical node A actually transmits the business data to critical node B through an IP layer tunnel. The IP layer tunnel passes through one or more native IPv6 forwarding devices, resulting in non-adjacent order positions of critical node A and critical node B in the actual forwarding path. Each native IPv6 forwarding device passed through by the IP layer tunnel between critical node A and critical node B exists in the actual forwarding path.
[0185] The main reason why the key node downstream of the non-critical node fails to pass the forwarding proof verification is that the path planner calculates the vector commitment based on the sequential position of the key node in the expected forwarding path. If the key node calculates the forwarding proof using the sequential position of the key node in the actual forwarding path, 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 (for the reasons and scenarios of the different sequential positions, please refer to the description in the following text), there is a deviation between the sequential position based on which the vector commitment is calculated and the sequential position based on which the forwarding proof is calculated, resulting in the key node failing to pass the verification of the forwarding proof based on the vector commitment.
[0186] In addition, due to a certain degree of uncertainty about which forwarding nodes the service data actually passes through during the transmission process, the path planner usually cannot perceive the sequential position of the key node in the actual forwarding path, nor can the path planner perceive the existence of non-critical nodes in the actual forwarding path. Therefore, it is also difficult for the path planner to achieve fault tolerance by calculating the vector commitment using the sequential position of the key node in the actual forwarding path.
[0187] In view of this, in some embodiments of the present application, since the key node calculates the forwarding proof using the sequential position of the key node in the expected forwarding path, and uses the vector commitment and the sequential position of the key node in the expected forwarding path to verify the forwarding proof, 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. Therefore, the risk of interrupting the service data transmission or outputting an alarm due to the failure of the key node to pass the verification of the forwarding proof based on the vector commitment is reduced.
[0188] (10) The sequential position of the key node in the expected forwarding path
[0189] The sequential position of the key node in the expected forwarding path is also referred to as the expected sequential position, expected sequence, or relative sequential position of the key node. The sequential position of the key node in the expected forwarding path is used to characterize the sequential relationship between this key node and other key nodes in the expected forwarding path (such as the first key node). The sequential position of the key node in the expected forwarding path can also characterize the order of forwarding data packets by this key node compared to other key nodes in the expected forwarding path. For example, the smaller the sequential position of the key node in the 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 key node executes data packet forwarding earlier compared to other key nodes. On the contrary, the larger the sequential position of the key node in the expected forwarding path, it indicates that the sequential position of the key node is closer to the last forwarding node in the expected forwarding path, and the key node executes data packet forwarding later compared to other forwarding nodes.
[0190] In some embodiments, the data form of the sequential position in the expected forwarding path is a serial number (also referred to as a sequence number). Hereinafter, the serial number representing the sequential position in the expected forwarding path is simply referred to as the expected serial number. For example, the expected serial number is a positive integer. For example, the expected serial numbers are used in ascending order to represent the order from first to last. For instance, for an expected forwarding path passing through N key nodes, the expected serial number of the first key node is 1, the expected serial number of the second key node is 2, and so on. Each key node has an expected serial number that is 1 greater than the previous key node, and the expected serial number of the nth key node is N.
[0191] For example, please refer to Appendix Figure 1 , Appendix Figure 1 in which "A-1" represents that the sequential position (expected serial number) of key node A in the expected forwarding path is 1, "B-2" represents that the sequential position (expected serial number) of key node B in the expected forwarding path is 2, and "C-3" represents that the sequential position (expected serial number) of key node C in the expected forwarding path is 3. In other words, the order in which the three forwarding nodes planned by the controller forward data packets during the path planning stage is that key node A forwards the data packet first, key node B forwards the data packet second, and key node C forwards the data packet third.
[0192] Alternatively, the expected serial numbers of each forwarding node are used in descending order to represent the order from first to last. The larger the expected serial number of key node _i, the closer the sequential position of key node _i is to the first key node in the expected forwarding path, and key node _i executes data packet forwarding earlier compared to other key nodes.
[0193] Of course, the sequential position of key node _i in the expected forwarding path and the expected serial number of key node _i are not necessarily numerically equal. It is also possible to use a formula or a table to convert the expected serial number of key node _i into the sequential position of key node _i in the expected forwarding path. Or, the sequential position in the expected forwarding path can also adopt other data forms other than serial numbers. 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 is adopted for the sequential position in the expected forwarding path.
[0194] In some embodiments, the sequential position of the expected forwarding path is determined by the path planner during the path planning stage. For example, based on the requirements of path planning, the path planner assigns corresponding sequential positions to each key node to represent the sequential relationship of each key node forwarding data packets.
[0195] For the use of the sequential positions in the expected forwarding path, in some embodiments of the present application, the sequential positions in the expected forwarding path are used to determine the vector commitment, the calculation of the forwarding proof, and the verification of the forwarding proof. For example, both the control plane uses the sequential positions of each key node in the expected forwarding path when determining the vector commitment and the forwarding plane uses the sequential positions of each key node in the expected forwarding path when calculating the forwarding proof. The specific usage of the sequential positions in the expected forwarding path can refer to the introduction of the subsequent method embodiments.
[0196] (11) The sequential positions in the actual forwarding path
[0197] The sequential positions in the actual forwarding path are used to characterize the sequential relationship between each node passed in the actual forwarding path. The sequential position of a key node in the actual forwarding path is also referred to as the actual sequential position or the true sequential position of the key node.
[0198] In some embodiments, the data form of the sequential positions in the actual forwarding path is a serial number (also referred to as a sequence number). Hereinafter, the serial number characterizing the sequential positions in the actual forwarding path is simply referred to as the actual serial number. For example, the actual serial number is a positive integer. For example, the actual serial number uses an ascending order to represent the order from first to last. For instance, for an actual forwarding path passing through n forwarding nodes (including key nodes and non-key nodes), the actual serial number of the first forwarding node is 1, the actual serial number of the second forwarding node is 2, and so on. The actual serial number of each forwarding node is 1 greater than the actual serial number of the previous forwarding node, and the actual serial number of the nth forwarding node is n.
[0199] For the use of the sequential positions in the actual forwarding path, in some embodiments of the present application, the sequential positions in the actual forwarding path are used to achieve the recordability of non-key nodes. For example, the sequential positions in the actual forwarding path will be added to the data packet by the forwarding node. During the data packet forwarding process, the data packet carries the sequential positions in the actual forwarding path. In some embodiments of the present application, in order to avoid that due to the inconsistency between the sequential positions in the actual forwarding path and the sequential positions in the expected forwarding path, the forwarding proof determined using the sequential positions in the actual forwarding path does not match the vector commitment determined using the sequential positions in the expected forwarding path, resulting in the forwarding proof determined using the sequential positions in the actual forwarding path failing to pass the verification and thus causing transmission failure, the sequential positions in the actual forwarding path are 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-key nodes. Of course, in the case where the fault tolerance of non-key nodes does not need to be achieved, the sequential positions 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.
[0200] In some embodiments for determining the sequential position of the actual forwarding path, in the scenario applied to the Internet Protocol Version 4 (IPv4) network, the sequential position of the actual forwarding path is determined based on the TTL. As an example, the data packet includes an IPv4 header, and the IPv4 header includes the Time To Live (TTL). The forwarding node _i identifies the value of the TTL and obtains the position i of the forwarding node _i in 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 packet and identifies that the value of the TTL carried in the data packet is n - i, the node _i determines that this node is the i-th node in the forwarding path. As an example, after the first forwarding node in the forwarding path receives a data packet, based on the TTL in the data packet being 255, the first forwarding node determines that the sequential position of this node in the actual forwarding path = 256 - 255 = 1. The first forwarding node updates the TTL in the data packet 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 packet, based on the TTL in the data packet being 254, the second forwarding node determines that the sequential position of this node in the actual forwarding path = 256 - 254 = 2. The second forwarding node updates the TTL in the data packet 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 packet, based on the TTL in the data packet being 253, the third forwarding node determines that the sequential position of this node in the actual forwarding path
[0201] = 256 - 253 = 3, and so on.
[0202] 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 packet includes an IPv6 header, and the IPv6 header includes the hop limit. The forwarding node _i identifies the value of the hop limit and obtains the position i of the forwarding node _i in the forwarding path based on the value of the hop limit. If the initial value of the hop limit is k, since the value of the hop limit decreases by 1 for each node passed through, when the forwarding node _i receives a data packet and identifies that the value of the hop limit carried in the data packet is n - i, the node _i determines that this node is the i-th node in the forwarding path. As an example, after the first forwarding node in the forwarding path receives a data packet, based on the hop limit in the data packet being 255, the first forwarding node determines that the sequential position of this node in the actual forwarding path = 256 - 255 = 1. After updating the hop limit in the data packet from 255 to 254, the first forwarding node forwards it to the second forwarding node. After the second forwarding node in the forwarding path receives the data packet, based on the hop limit in the data packet being 254, the second forwarding node determines that the sequential position of this node in the actual forwarding path = 256 - 254 = 2. After updating the hop limit in the data packet from 254 to 253, the second forwarding node forwards it to the third forwarding node. After the third forwarding node in the forwarding path receives the data packet, based on the hop limit in the data packet being 253, the third forwarding node determines that the sequential position of this node in the actual forwarding path = 256 - 253 = 3, and so on.
[0203] In some embodiments of determining the sequential position of the actual forwarding path, in the scenario applied to 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 value range of SI is from 255 to 0, and the SI decreases by 1 for each data packet passed through. 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 this node in the actual forwarding path.
[0204] (12) The difference between the sequential position of the expected forwarding path and the sequential position of the actual forwarding path
[0205] The sequential position of forwarding node _i in the expected forwarding path may be the same as or different from its sequential position in the actual forwarding path. Whether the sequential position of forwarding node _i in the actual forwarding path is the same as its sequential position in the expected forwarding path mainly depends on whether there are non-critical nodes in the actual forwarding path.
[0206] In some scenarios, due to passing through one or more non-critical nodes in the actual forwarding path, and these non-critical nodes are not arranged by the path planner into the expected forwarding path, there is a deviation in the sequential position of the forwarding node in the actual forwarding path compared to its sequential position in the expected forwarding path. The sequential deviation between the sequential position of the forwarding node in the actual forwarding path and its sequential position in the expected forwarding path represents the number of non-critical nodes upstream of this critical node in the actual forwarding path.
[0207] For example, in the appendix Figure 1 uppercase letters (A, B, C) are used to identify critical nodes, and lowercase letters (a, b, c) are used to identify non-critical nodes. For example, please refer to the appendix Figure 1 In (a) of the appendix, the sequential position of critical node B in the expected forwarding path is 2. Since there are critical node A and non-critical node b upstream of critical node B in the actual forwarding path, and neither critical node A nor non-critical node b is arranged by the path planner into the forwarding path, the sequential position of critical node B in the actual forwarding path is 4. The difference between the sequential position of critical node B in the actual forwarding path (4) and its sequential position in the expected forwarding path (2) is 4 - 2 = 2, and 2 represents the number of non-critical nodes (critical node A and non-critical node b) upstream of critical node B. Another example, the sequential position of critical node C in the expected forwarding path is 3. Since there are critical node A, non-critical node b, and non-critical node c upstream of critical node C in the actual forwarding path, and neither critical node A, non-critical node b, nor non-critical node c is arranged by the path planner into the forwarding path, the sequential position of critical node C in the actual forwarding path is 6. The difference between the sequential position of critical node C in the actual forwarding path (6) and its sequential position in the expected forwarding path (3) is 6 - 3 = 3, and 3 represents the number of non-critical nodes (critical node A, non-critical node b, and non-critical node c) upstream of critical node C.
[0208] Since non-critical nodes may be inserted between different critical nodes in the actual forwarding path, two critical nodes that are consecutive in the expected forwarding path may not be consecutive 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 positions of the first forwarding node and the second forwarding node in the expected forwarding path are consecutive (e.g., the difference in sequential positions is 1). Since there is one or more non-critical nodes between the first forwarding node and the second forwarding node in the actual forwarding path, the sequential positions of the first forwarding node and the second forwarding node in the actual forwarding path are not consecutive. The deviation in 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.
[0209] For example, please refer to Figure 1 in (a). The sequential positions of critical node A and critical node B in the expected forwarding path are 1 and 2 respectively, and the sequential positions of critical node A and critical node B in the expected forwarding path are consecutive. Since two non-critical nodes (node a and node b) are inserted between critical node A and critical node B in the actual forwarding path, the sequential positions of critical node A and critical node B in the actual forwarding path are 1 and 4 respectively, and the sequential positions of critical node A and critical node B in the actual forwarding path are not consecutive. The deviation in the sequential positions of critical node A and critical node B in the actual forwarding path represents the number of non-critical nodes between critical node A and critical node B.
[0210] For another example, the sequential positions of critical node B and critical node C in the expected forwarding path are 2 and 3 respectively, and the sequential positions of critical node B and critical node C in the expected forwarding path are consecutive. Since one non-critical node (node c) is inserted between critical node B and critical node C in the actual forwarding path, the sequential positions of critical node B and critical node C in the actual forwarding path are 4 and 6 respectively, and the sequential positions of critical node B and critical node C in the actual forwarding path are not consecutive. The deviation in the sequential positions of critical node B and critical node C in the actual forwarding path represents the number of non-critical nodes between critical node B and critical node C.
[0211] In some embodiments, the order of at least two critical nodes in the expected forwarding path is the same as the order of each critical node in the actual forwarding path, and the sequential positions of at least two critical nodes in the expected forwarding path are different from the sequential positions of each critical node in the actual forwarding path. In other words, the order between at least two critical nodes is not disrupted, but non-critical nodes are inserted between different critical nodes. As a specific example, please refer to Figure 1In (a) thereof, the sequence of key node A, key node B, and key node C in the expected forwarding path is as follows: first is key node A, second is key node B, and last is key node C; please refer to the appendix Figure 1 In (b) thereof; the sequence of key node A, key node B, and key node C in the actual forwarding path is also the same: first is key node A, second is key node B, and last is key node C. However, the sequential position (2) of key node B in the expected forwarding path is different from the sequential position (4) of key node B in the actual forwarding path, and the sequential position (3) of key node C in the expected forwarding path is different from the sequential position (6) of key node C in the actual forwarding path.
[0212] (13) Recordability of non - key nodes
[0213] The recordability of non - key nodes is a technical effect expected to be achieved by the embodiments of the present application. The recordability of non - key nodes refers to the function of recording that a data packet has passed through a non - key node in the scenario where the data packet passes through a non - key node during the forwarding process. In some embodiments, the recordability of non - key nodes is achieved by recording the sequential positions of key nodes in the actual forwarding path. For example, based on the fact that the sequential positions of two adjacent key nodes in the recorded actual forwarding path are not continuous, it is determined that there is a non - key node between the two key nodes. Based on the difference between the sequential positions of two adjacent key nodes in the recorded actual forwarding path, the number of non - key nodes between the two key nodes is determined. For example, if the difference between the sequential positions of two adjacent key nodes in the recorded actual forwarding path is k, it is determined that there are (k - 1) non - key nodes between the two key nodes.
[0214] There are various implementation methods for the recording position of non - key nodes. In some embodiments, during the process of forwarding a data packet by a key node, a list of the sequential positions of the key node in the actual forwarding path is added to the data packet to achieve the recordability of non - key nodes. In other embodiments, the key node sends a packet independent of the data packet and carrying a list of the sequential positions of the key node in the actual forwarding path to achieve the recordability of non - key nodes. In still other embodiments, the key node saves a list of the sequential positions of the key node in the actual forwarding path in the local log record.
[0215] For example, please refer to the appendix Figure 1Among them, key node A, key node B, and key node C are three adjacent key nodes. Key node A adds the sequential position of this node in the actual forwarding path to the data packet as 1; key node B adds the sequential position of this node in the actual forwarding path to the data packet as 4; based on the difference between the sequential position of this node and the previous key node (key node A) in the actual forwarding path being 4 - 1 = 3, key node B determines that there are 2 non - key nodes between this node and the previous key node. Key node C adds the sequential position of this node in the actual forwarding path to the data packet as 6; based on the difference between the sequential position of this node and the previous key node (key node B) in the actual forwarding path being 6 - 4 = 2, key node C determines that there is 1 non - key node between this node and the previous key node.
[0216] (14) Vector Commitment
[0217] For ease of understanding, first, the general definition of "vector commitment" in cryptography will be explained below, and then it will be further explained in combination with the application scenario of the trusted path in the embodiments of this application.
[0218] A vector commitment is data obtained through cryptographic techniques. A vector commitment is used to prove the correctness of the values and positions 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 keeping the information hidden, and usually does not require exposing the original content of the information. Specifically, a vector commitment allows each piece of information in a set of ordered information to be committed and corresponding proofs to be generated, and other participating parties can verify the proofs to confirm the integrity of the ordered information. Vector commitments are usually seen in zero - knowledge proofs. A vector commitment mainly includes three stages: commitment, open, and verify.
[0219] The commitment stage is the calculation stage of the vector commitment. For example, entity A secretly selects N pieces of ordered information M=(m_1, m_2, …, m_N) at one time, and then calculates a commitment based on information M and makes the commitment public. The commitment contains information M and the sequential relationship between the N pieces of information inside information M, but the outside world cannot infer the plaintext of the N pieces of information from the commitment, nor can it infer what the position corresponding to each piece of the N pieces of information is. Usually, after calculating the commitment based on information M, entity A cannot modify information M anymore. The calculation of the vector commitment can be implemented through a commitment function.
[0220] The opening phase refers to the computational phase of the proof. The proof is used to prove the information at a specific position. Specifically, entity A computes an opening proof (OP) and publicly discloses the opening proof, thereby proving through the opening proof that the information committed to at a certain position i is m_i. The computation of the proof is achieved through the opening function. The opening function includes the single-point opening (open) function and the batch opening (batchopen) function.
[0221] The single-point opening (open) function means that entity A computes a single-point opening proof (OP) for a single position i. Through the single-point opening proof, it can be proved that the information at position i is m_i.
[0222] The batch opening function means that entity A computes a multi-point opening proof (MP) at one time. The multi-point opening proof is used to prove that the set formed by multiple information m_i is B, where each m_i is at its corresponding position i. Through the multi-point opening proof, the information at multiple positions can be verified simultaneously. The computational complexity of the multi-point proof is usually higher than that of the single-point proof. The computational method of the multi-point proof can be referred to [https: / / github.com / khovratovich / Kate / blob / 66aae66cd4e99db3182025c27f02e147dfa0c034 / Kate_amortized.pdf][KZG].
[0223] The verification phase refers to the verification phase of the proof. For example, the verifier uses the commitment and the opening proof to verify that the object initially committed or selected by entity A is indeed the information M. The verification is achieved through the verification function. The verification includes single-point verification and batch verification.
[0224] Single-point verification means that for a 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 what the single-point opening proof claims.
[0225] Batch verification means that for a multi-point opening proof, the verifier can use the commitment C, the multi-point opening proof MP_B, and the set B to verify whether the information at multiple positions is consistent with what the opening proof claims.
[0226] A more detailed explanation of vector commitments can be found in the paper "Constant-Size Commitments to Polynomials and Their Applications". The actual algorithms defined for vector commitments in the paper include, but are not limited to, setup, commit, open, create witness, verifyeval, create witness batch, verifyeval batch, etc.
[0227] In the application scenario of the embodiments of this application, vector commitments are used to prove the correctness of the identity information and sequential positions of forwarding nodes in the actual forwarding path. For example, taking the path planner as entity A in the vector commitment technology, using information M to represent the trusted path (expected forwarding path) P = (r_1, r_2, … r_i …, r_N), the information m_i in information M represents the identity information r_i of the key node i, where i is the expected sequence number of the key node in the expected forwarding path, and using set B to represent a certain segment of the trusted path (expected forwarding path), the proof in vector commitments is specifically a forwarding proof. The most important property of vector commitments is order preservation, that is, the committed and opened proof information m_i must have a binding relationship with position i.
[0228] The embodiments of this application relate to the application of vector commitments in device-level path verification and the application of vector commitments in AS-level path verification. To distinguish different vector commitments, the vector commitment applied in device-level path verification is described as "the first vector commitment" or "device-level vector commitment", and the vector commitment applied in AS-level path verification is described as "the second vector commitment" or "AS-level vector commitment". The device-level vector commitment is obtained, for example, 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 obtained, for example, based on the identity information of each AS passed through in the expected forwarding path and the sequential relationship of each AS passed through in the expected forwarding path.
[0229] (15) KZG Polynomial Commitment
[0230] KZG polynomial commitment is a specific construction method of a vector commitment mechanism with good properties. Polynomial commitment can commit to N points (such as N identity information) on a polynomial curve at one time, and prove and verify one or N points (such as N identity information) on this polynomial in constant time. Moreover, the size of the committed data and the size of each forwarding proof data are both constant O(1). In polynomial commitment, the information m_i is saved in the form of points (x_i, y_i), that is, the information M is transformed into <(x_1, y_1), (x_2, y_2), …, (x_N, y_N)>, where x_i = i and 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 for entity A to commit N pieces of information at one time, the time for others to calculate a single or multiple opening proofs, and the time for others to verify N pieces of information at one time are all sub-linear times (actually constant times).
[0231] (16) Forwarding proof
[0232] The embodiments of this application relate to the application of forwarding proofs in device-level path verification and the application of forwarding proofs in AS-level path verification. To distinguish different forwarding proofs, the forwarding proof applied in device-level path verification is described as "the first forwarding proof" or "the device-level forwarding proof", and the forwarding proof applied in AS-level path verification is described as "the second forwarding proof" or "the AS-level forwarding proof". The node-level forwarding proof is used to prove that a specific node forwards data packets at a specific sequential position in the forwarding path. The AS-level forwarding proof is used to prove that a specific AS forwards data packets at a specific sequential position in the forwarding path. The forwarding proof includes a single-point forwarding proof (OP) and a multi-point forwarding proof (MP).
[0233] OP represents a forwarding proof related to a single forwarding node, which is used to prove that a single specific node forwards data packets at the specific sequential position corresponding to this specific node in the forwarding path. Or, OP represents a forwarding proof related to a single AS, which is used to prove that a single specific AS forwards data packets at the specific sequential position corresponding to this specific node in the forwarding path.
[0234] MP (multi - proof) represents the forwarding proof related to multiple forwarding nodes, which is used to prove that each node in a specific path forwards data packets in the corresponding sequential position. For example, for the expected forwarding path of key nodes A → key node B → key node C → key node D, the OP includes the OP of key node A, the OP of key node B, the OP of key node C, and the OP of key node D, and the MP includes the MP of path AB, the MP of path ABC, and the MP of path ABCD. Alternatively, MP represents the forwarding proof related to multiple ASes, which is used to prove that multiple ASes forward data packets in the corresponding specific sequential positions in the forwarding path.
[0235] The acquisition method of the single - point forwarding proof: Obtain the single - point forwarding proof 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.
[0236] The single - point forwarding proof of the verified node is used to prove that the verified node has forwarded data packet A and the sequential 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 sequential 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 has forwarded this data packet in the expected sequential position. Optionally, key node A uses the single - point open function (open) to obtain single - point forwarding proof A, and single - point forwarding proof A = open(i, r_i).
[0237] The acquisition method of the multi - point forwarding proof: Obtain the multi - point forwarding proof based on the sequential positions of at least two key nodes in the expected forwarding path and the identity information of at least two key nodes.
[0238] For example, the verified node obtains the 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 the corresponding sequential positions in the expected forwarding path.
[0239] Taking the verified node as the key node i as an example, for instance, the key node i obtains the forwarding proof p_i based on the identity information of each node from key node 1 to key node i, the sequential positions of each key node from key node 1 to key node i in the expected forwarding path, and cryptographic parameters. The forwarding proof p_i is a multi-point forwarding proof, and the forwarding proof p_i is used to prove that key node 1 forwards the data packet at sequential position 1, key node 2 forwards the data packet at sequential position 2... and key node i forwards this data packet at sequential position i. Optionally, the key node i obtains the forwarding proof p_i by using a batch open function (batchopen), and p_i = batchopen(r_1,..., r_i).
[0240] Whether it is a single-point forwarding proof or a multi-point forwarding proof, the sequential positions used when determining the forwarding proof and verifying the forwarding proof are the sequential positions in the expected forwarding path, rather than the sequential positions in the actual forwarding path. Take Figure 1 as an example. The sequential positions of the three key nodes used when determining the forwarding proof and verifying the forwarding proof are the expected consecutive sequential positions 1, 2, and 3, rather than the actual non-consecutive sequential positions 1, 4, and 6. Since the sequential positions in the actual forwarding path do not participate in the process of determining the forwarding proof and verifying the forwarding proof, the risk of transmission interruption caused by determining the forwarding proof and verifying the forwarding proof based on the sequential positions in the actual forwarding path is reduced.
[0241] The forwarding proof of the verified node includes a single-point forwarding proof and a multi-point forwarding proof. The following respectively gives examples of the acquisition methods of the single-point forwarding proof and the multi-point forwarding proof. In some embodiments, one of the acquisition method of the single-point forwarding proof and the acquisition method of the multi-point forwarding proof is used.
[0242] The acquisition method of the single-point forwarding proof obtains the single-point forwarding proof 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 a single key node of the verified node.
[0243] The single-point forwarding proof of the verified node is used to prove that the verified node has forwarded the data packet A and the sequential position of the verified node is correct. Taking the verified node as the key node A as an example, the key node A obtains the forwarding proof A based on the identity information of the key node A, the sequential position of the key node A in the expected forwarding path, and cryptographic parameters. The forwarding proof A is a single-point forwarding proof, and the forwarding proof A is used to prove that the key node A has forwarded this data packet at the expected sequential position. Optionally, the key node A obtains the single-point forwarding proof A by using a single open function (open), and the single-point forwarding proof A = open(i, r_i).
[0244] The method for obtaining a multi-point forwarding proof obtains a multi-point forwarding proof based on the sequential positions of at least two key nodes in the expected forwarding path and the identity information of at least two key nodes.
[0245] For example, the node to be verified obtains a first forwarding proof based on the sequential position of the node to be verified in the expected forwarding path, the identity information of the node to be verified, the sequential position of the second forwarding node in the expected forwarding path, and the identity information of the second forwarding node. The identity information of the second forwarding node indicates the identity of the second forwarding node. The first forwarding proof is used to prove that the node to be verified and the second forwarding node are respectively in the corresponding sequential positions in the expected forwarding path.
[0246] Taking the node to be verified as the key node i as an example, for example, the key node i obtains a forwarding proof p_i based on the identity information of each node from key node 1 to key node i, the sequential position of each key node from key node 1 to key node i in the expected forwarding path, and cryptographic parameters. The forwarding proof p_i is a multi-point forwarding proof. The forwarding proof p_i is used to prove that key node 1 forwards the data packet at sequential position 1, key node 2 forwards the data packet at sequential position 2... and key node i forwards this data packet at sequential position i. Optionally, the key node i uses a batch open function (batchopen) to obtain the forwarding proof p_i, p_i = batchopen(r_1,..., r_i).
[0247] Whether it is a single-point forwarding proof or a multi-point forwarding proof, the sequential positions used when determining the forwarding proof and verifying the forwarding proof are the sequential positions in the expected forwarding path, rather than the sequential positions in the actual forwarding path. For example Figure 1 Taking it as an example, the sequential positions of the three key nodes used when determining the forwarding proof and verifying the forwarding proof are the expected consecutive sequential positions 1, 2, 3, rather than the actual non-consecutive sequential positions 1, 4, 6. Since the sequential positions in the actual forwarding path do not participate in the process of determining the forwarding proof and verifying the forwarding proof, the risk of transmission interruption caused by determining the forwarding proof and verifying the forwarding proof based on the sequential positions in the actual forwarding path is reduced.
[0248] For the sake of simplicity, in the following embodiments of the present application, sometimes the single-point forwarding proof calculated by a node at a specific sequential position is simplified and represented in the form of "OP + underscore + position". The multi-point forwarding proof obtained by a node at a specific sequential position is simplified and represented in the form of "MP + underscore + position". For example, OP_i represents the single-point forwarding proof calculated by the i-th key node in the actual forwarding path, and MP_i represents the multi-point forwarding proof calculated by the i-th key node on the forwarding path.
[0249] (17) Identity information of the forwarding node
[0250] The identity information of forwarding node _i is used to indicate the identity of forwarding node _i. The identity information of forwarding node _i is, for example, the identifier of forwarding node _i.
[0251] In some embodiments, the identity information of the forwarding node is publicly verifiable identity information. By using the publicly verifiable identity information to calculate and verify the forwarding proof, the difficulty of obtaining the identity information is reduced, and thus the complexity of calculating and verifying the forwarding proof based on the identity information is reduced. In some other possible implementation manners, the identity information of forwarding node _i is a publicly verifiable and non-forgeable identity proof that can only be calculated by forwarding node _i and verified by multiple parties. Exemplarily, the identity information of forwarding node _i includes the identity information encrypted based on the key of forwarding node _i. Optionally, the identity information encrypted based on the key of forwarding node _i is the identity information encrypted based on the symmetric key of forwarding node _i; or, the identity information encrypted based on the key of forwarding node _i is the identity information encrypted based on the private key of forwarding node _i. By using the encrypted identity information to calculate the forwarding proof or verify the forwarding proof, since the security and privacy of the identity information are higher, the security and privacy of calculating and verifying the forwarding proof are further improved.
[0252] Exemplarily, the identity information of forwarding node _i includes the address of forwarding node _i. The address used as the identity information of forwarding node _i is optionally the IP address of forwarding node _i. For example, the address used as the identity information of forwarding node _i is the IPv4 address of forwarding node _i or the IPv6 address of forwarding node _i. Or, the address used as the identity information of forwarding node _i is the media access control (MAC) address of forwarding node _i.
[0253] Exemplarily, the identity information of forwarding node _i includes the segment ID (SID) of forwarding node _i. SID is an identifier used in the SRv6 (segment routing over IPv6) network and is used to define a certain function or instruction in the network. The form of SID is an IPv6 address and has 128 bits. By using SID as the identity information to calculate and verify the forwarding proof, it is more applicable to the scenario of the SRv6 network. While realizing path binding, the SID carried in the SRv6 encapsulation can be reused, and there is no need to add an extra field in the packet to carry the identity information, which helps to simplify the packet format and reduce the overhead of transmitting packets.
[0254] 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 the identity information to calculate the forwarding proof and verify the forwarding proof, it is more applicable to the scenarios of MPLS networks or SR-MPLS networks. While achieving path binding, it can reuse the MPLS labels carried in MPLS encapsulation or SR-MPLS encapsulation, without the need to add extra fields in the packet to carry the identity information, thus helping to simplify the packet format and reduce the overhead of transmitting packets.
[0255] Exemplarily, the identity information of forwarding node _i includes the certificate of forwarding node _i. A certificate is a digital credential or an electronic document used to prove the identity or authority of a certain entity. The certificate is issued by a trusted third-party organization, such as a certificate authority (CA for short), and contains the identity information (such as a public key) used to verify and identify the specified entity. The certificate content includes the public key, the information of the certificate holder (such as name, organization, etc.) or the validity period of the certificate, etc. By using the certificate as the identity information to calculate the forwarding proof and verify the forwarding proof, since the authenticity and integrity of the certificate can be verified, it helps to reduce the risks caused by the tampering, eavesdropping or forgery of the identity information, and further improves the security and credibility of the forwarding proof.
[0256] Exemplarily, the identity information of forwarding node _i includes the key of forwarding node _i. For example, the identity information of forwarding node _i includes the public key of forwarding node _i. Another example is that the identity information of forwarding node _i includes the private key of forwarding node _i.
[0257] Exemplarily, the identity information of forwarding node _i includes the access control token of forwarding node _i. The access control token is a digital proof used to verify the access permission to protected resources. The access control token contains the authorization information and access permission information of the forwarding node. The access control token can be generated by the access control server and issued to the forwarding node. By using the access control token as the identity information to calculate the forwarding proof and verify the forwarding proof, since each forwarding node can verify the validity and permission of the access control token, the risks of identity information tampering and data leakage are reduced, thus further enhancing the security and credibility of the forwarding proof.
[0258] Exemplarily, the identity information of forwarding node _i includes the router ID of forwarding node _i.
[0259] Exemplarily, the identity information of forwarding node _i includes the host name of forwarding node _i.
[0260] 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 the identity information being tampered with and data being leaked is reduced, thereby further enhancing the security and credibility of the forwarding proof.
[0261] Exemplarily, the identity information of forwarding node _i includes a message authentication code (MAC) tag. The MAC tag is an authentication code used to verify the integrity and authenticity of a message. The MAC tag is a fixed-length value obtained by encrypting and calculating the message, thereby reducing the probability of the message being tampered with or forged during transmission. For example, forwarding node _i generates a MAC tag by operating on the shared key between forwarding node _i and other forwarding nodes on the forwarding path and the message content, and uses the MAC tag as the identity information to calculate the forwarding proof and verify the forwarding proof, thereby further reducing the probability of the forwarding proof being tampered with and forged, and enhancing the security and credibility of the forwarding proof.
[0262] Exemplarily, the identity information of forwarding node _i includes a 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. This proof allows the prover to show the verifier a proof of a certain fact without disclosing any other information related to that fact. The zero-knowledge proof used as the identity information is, for example, 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 the 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. At the same time, it supports the verification of the NIZK proof used as the 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.
[0263] Exemplarily, the identity information of forwarding node_i includes Sigma protocol proof. Sigma protocol proof is an interactive protocol based on zero-knowledge proof. It allows a prover to prove that a statement is true in the interaction with the verifier without revealing the real information about the statement. In the Sigma protocol proof, the prover and the verifier conduct multiple rounds of interaction to achieve the purpose of mutual authentication. The prover attempts to prove the authenticity of a statement to the verifier, while the verifier hopes to confirm the authenticity of the statement and believes that the prover does know how to prove the statement. But the special nature of the protocol is that the prover cannot disclose the real information of the statement to the verifier, thereby protecting the privacy of the prover.
[0264] (18)Segment list
[0265] 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.
[0266] (19) Time to live (TTL)
[0267] 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.
[0268] (20) Hop limit
[0269] In the IPv6 protocol, TTL is called hop limit, and the hop limit is also carried by a field in the IPv6 header. The hop limit is equivalent to the TTL in IPv4 and is used to limit the number of hops of data packets in the network. It is stored in the 7th byte of the IPv6 header, occupying one byte (8 bits), for storing the value of the hop limit.
[0270] (21) Autonomous system (AS)
[0271] An 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 autonomous system number (AS number) in the Internet so that other network devices can find the corresponding AS based on the AS number. For the sake of simplicity, in the following embodiments of this application, "AS + number" is used to simplify the representation of a specific AS. For example, an AS is simplified as AS1.
[0272] (22) Identity information of the AS
[0273] 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 autonomous system number (AS number) is also called the AS number or AS identifier. The AS number is a positive integer, and the value range of the AS number is usually from 1 to 65535. Each AS has a unique AS number. Through the AS number, an AS can be uniquely identified in the Internet. The secret value of the AS is the ciphertext data obtained by encrypting the AS number. For example, the secret value of the AS is obtained by encrypting the AS number based on the key preset in each forwarding device in the AS.
[0274] (23) Autonomous system path (AS_path)
[0275] The AS_path is a path attribute in the BGP protocol. The AS_path is usually carried by BGP protocol messages. The AS_path is used to record the ASs passed from the source AS to the destination AS. The AS_path includes a series of AS numbers, which are used to describe all the ASs that the BGP protocol message passes through from the source AS to the destination AS. A pair of adjacent ASs in the AS_path represents two ASs with an upstream and downstream relationship in the forwarding path. According to the AS_path, the sequential 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 an AS_path, and the AS_path is [AS 3 AS1 AS 6], indicating that the address prefix P1 is originated by AS 6, then the address prefix P1 passes through AS1, and finally the address prefix P1 reaches AS 3. From the AS_path, it can be determined that when forwarding a data packet whose source address matches the address prefix P1, the sequential relationship among the three ASs, AS 3, AS1, and AS 6, is first AS 6, then AS1, and finally AS 3. The detailed definition, format, and usage of the AS_path can be referred to the description in Section 4.3, "Path Attributes" of RFC4271.
[0276] (24) AS list
[0277] 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 located 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 among each AS passed through in the expected forwarding path. Taking the AS identity information as the AS number as an example. For example, the first AS number in the AS list identifies the first AS passed through in the expected forwarding path, the second AS number in the AS list identifies the second AS passed through in the expected forwarding path, and so on.
[0278] The application scenarios and corresponding method flows of the path verification method at the device level are illustrated below by examples.
[0279] The feature of many source address or centralized routing technologies is that the source host or the centralized controller can specify the network path passing through a series of specific network devices or virtualized network functions by itself. For example, both the SR technology and the SFC support the function of the control plane specifying the network path. However, one challenge is that even if the source host or the centralized controller specifies a certain path in the control plane, the source host or the centralized controller cannot know whether the data packet really strictly follows this path on the forwarding plane (data plane). For example, due to network attacks such as route hijack, route injection, and traffic detour, or problems with incorrect configuration of network devices, the actual forwarding path on the data plane may deviate from the expected forwarding path on the control plane.
[0280] Among them, a route hijack attack means that the attacker hijacks and / or diverts network traffic to a network device or AS controlled by the attacker for purposes such as eavesdropping, tampering, or interception. A route hijack attack is also known as a prefix hijack attack or an internet protocol (IP) hijack attack. Route injection refers to inputting forged routing information into network devices such as routers, so that the forged routing information spreads throughout the network. The 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 means that the attacker tampers 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.
[0281] In short, the problem that urgently needs to be solved is the inconsistency between the expected forwarding path determined by the control plane and the actual forwarding path on the data plane. This problem will cause technologies such as SR or SFC to lose the technical advantages originally claimed to be able to achieve path specification.
[0282] In view of this, the trusted path mechanism (or the secure routing mechanism or the path validation mechanism) came into being, which can solve the above problems, enabling the data packet to be forwarded hop by hop only along the forwarding path planned by the path planner, and can provide publicly verifiable forwarding proof. A complete trusted path mechanism includes two technical parts: the path locking mechanism and the path validation mechanism, which can also be considered as the cooperation of protocols and methods at two levels of the control plane and the data plane.
[0283] At present, a trusted path mechanism with strict security is still blank at home and abroad, and the existing trusted path mechanisms all have certain limitations in terms of security.
[0284] For example, if path locking is implemented by means of non-cryptographic traversal proof, for example, a field with an initial value is added to the header of the data packet by the key node 1, and then each passing forwarding node adds its identity information to this packet, that is, the identity information of all forwarding nodes is used as the forwarding proof. Since there is no strong binding relationship between the forwarding proof and the position of the forwarding node in the forwarding path, a strongly position-bound forwarding proof cannot be generated. For example, it is impossible to implement that the node at the i-th position in 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 packet 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, indicating that the credibility of the forwarding proof is insufficient. Moreover, even if the data packet carries the proofs of all nodes on this path, since the proof has nothing to do with the position of the forwarding node in the forwarding path, it cannot be guaranteed that the data is actually forwarded along this path. For example, the traversal proof may be added by a device outside the forwarding path after the packet forwarding is completed. In other words, there is no strong binding relationship between the forwarding proof and the actual packet forwarding situation, which allows the data packet to be forwarded arbitrarily and then a forged traversal proof to be attached. The traversal proof obtained at the end point is not credible.
[0285] Another example is that if path locking is implemented by means of cryptographic traversal vouchers, for example, each forwarding node establishes a key pair with the controller one by one, and then each routing node uses cryptography to generate an identity-bound proof and then transmits the proof. Although the problem of forgery has improved slightly, since the position of the forwarding node in the forwarding path is not considered when obtaining the forwarding proof, a strongly position-bound forwarding proof cannot be generated, resulting in the same problem as the non-cryptographic traversal proof method: the forwarding proof is disconnected from the actual forwarding situation of the data packet, there is no strong binding relationship, the data packet can be forwarded arbitrarily and then collude with the forwarding node to add a forged traversal proof at the tail node, resulting in the traversal proof obtained from the tail node being untrustworthy, and it cannot be guaranteed that it will be forwarded along the specified forwarding path during the transit process.
[0286] Based on the above problems, some embodiments of the present application provide a solution based on forwarding proof and vector commitment, which helps to solve the locking mechanism and forwarding path verification mechanism of the forwarding path in a trusted network.
[0287] In some embodiments, a forwarding proof is obtained based on the sequential position of a forwarding node in an actual forwarding path and the identity information of the forwarding node. The forwarding proof is verified based on 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 location binding property of the forwarding proof. That is, the forwarding proof is no longer only related to the identity of the forwarding node, but also related to the position of the forwarding node in the forwarding path, such that a correct forwarding proof can be calculated by a correct node only when the data packet is forwarded to the correct position on the forwarding path, making the forwarding proof strongly bound to the actual forwarding situation of the data packet, and making the forwarding proof have publicly verifiable property that is difficult to tamper with, thereby solving the problem that the credibility of the proof is poor because the forwarding proof is not related to the position of the forwarding node in the forwarding path. The above embodiments help to strictly lock the expected forwarding path planned by the path planner, and then verify whether the actual forwarding situation of the data packet strictly corresponds to this expected forwarding path.
[0288] Although the above embodiments achieve 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 the forwarding proof, and does not allow any form of node that "forwards the data packet but does not calculate the forwarding proof" to exist in the actual forwarding path. However, in the IP network, there are a large number of weak-capability or obsolete network devices, or devices produced by third-party network manufacturers that do not support the function. These forwarding nodes do not necessarily have subjective malicious attacks, but do not cooperate with the calculation of the forwarding proof. These forwarding nodes are defined as non-critical nodes in this embodiment. Considering compatibility and usability, it is necessary to tolerate these non-critical nodes. For example, tolerate non-critical nodes inserted among critical nodes, or tolerate transparent tunnels existing among critical nodes, and the transmission will not be interrupted due to passing through non-critical nodes. How to make the forwarding path locking mechanism and the forwarding path verification mechanism support fault tolerance for non-critical nodes is the main effect of this embodiment.
[0289] Optionally, how to make the forwarding path locking mechanism and the forwarding path verification mechanism support recordability for non-critical nodes is also the effect to be achieved in this embodiment. The technical means corresponding to several effects expected to be achieved in the embodiments of the present application are explained separately below.
[0290] Technical effect 1: Forwarding path locking property
[0291] In some embodiments, the critical path binding property is achieved through the cryptographic technique of vector commitment. This embodiment utilizes the order-preserving property of vector commitment to achieve the above technical effect 1. For example, in the commitment phase, the path control party obtains a vector commitment through the commitment function in the vector commitment technique based on the sequential position of each critical node and the identity information of each critical node in the expected forwarding path. In the opening phase, each critical node calculates a forwarding proof in sequence based on the sequential position of the critical node and the identity information of the critical node when receiving a data packet in sequence through the opening function in the vector commitment technique. The critical node or the verification node verifies the forwarding proof based on the vector commitment, the sequential position of the critical node, and the identity information of the critical node through the verification function in the vector commitment technique.
[0292] In some embodiments, each critical node obtains a forwarding proof OP related to a single critical node based on a single-point opening function when receiving a data packet in sequence, and publishes the forwarding proof OP related to the single critical node; the critical node or an external verification node verifies the forwarding proof OP related to the single critical node based on a single-point verification function, so as to verify whether the sequence of a certain actually passed critical node is consistent with the expected sequence of the critical node. In another possible implementation, each critical node obtains a forwarding proof MP related to multiple critical nodes based on a multi-point opening function when receiving a data packet in sequence, and verifies the forwarding proof MP related to multiple critical nodes based on a batch verification function, so as to verify at one time whether the sequences of multiple critical nodes are consistent with the expected sequences of the multiple critical nodes.
[0293] Technical effect 2: source correctness
[0294] Source correctness refers to verifying the correctness of the source of a data packet. Source correctness includes the correctness of the previous hop and the correctness of the upper half of the path.
[0295] For example, for the correctness of the previous hop, when critical node i receives data packet _i, critical node i verifies the forwarding proof of the previous hop i - 1 carried by data packet _i based on the vector commitment; if the verification of the forwarding proof of the previous hop i - 1 fails, it is determined that the previous hop of the data packet is incorrect; if the verification of the forwarding proof of the previous hop i - 1 passes, it is determined that the previous hop of the data packet is correct.
[0296] For example, for the correctness of the upper half of the path, when critical node i receives data packet _i, critical node i verifies the forwarding proof from the first node to the previous hop i - 1 carried by data packet _i based on the vector commitment; if the verification of the forwarding proof from the first node to the previous hop i - 1 fails, it is determined that the upper half of the path of the data packet is incorrect; if the verification of the forwarding proof from the first node to the previous hop i - 1 passes, it is determined that the upper half of the path of the data packet is correct.
[0297] Next, specific implementation methods for achieving source correctness are illustrated by examples.
[0298] For the verification method of the correctness of the previous hop, the one-point forwarding proof (OP) is verified based on the location information of a single key node and the identity information of a single key node. For example, the data packet received by key node i carries the one-point forwarding proof related to key node _k. Key node i verifies the one-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, and the one-point forwarding proof of key node _k is used to prove that node _k forwards the data packet at position k in the forwarding path. The one-point forwarding proof of key node _k is obtained based on position k and the identity information of key node _k, where k is a positive integer less than or equal to i.
[0299] Optionally, the key node verifies the one-point forwarding proof of the previous hop node, thereby achieving the verification of the correctness of the previous hop. For example, the data packet received by key node i carries the one-point forwarding proof generated by the previous hop node (node _i - 1) of key node i. The one-point forwarding proof is used to prove that node _i - 1 forwards the data packet at position i - 1 in the forwarding path. Key node i verifies the one-point forwarding proof carried by the data packet based on the vector commitment, the identity information of node _i - 1, and the location information of node _i - 1. By analogy, each hop node is responsible for verifying the one-point forwarding proof of the previous hop node.
[0300] The second method for the correctness of the upper half of the path: The multi-point forwarding proof (MP) is verified 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 packet received by key node i carries the multi-point forwarding proof related to key node _k and key node _m. Key node i verifies the multi-point forwarding proof related to key node _k and key node _m based on the vector commitment, the identity information of key node _k, the location information of key node _k, the identity information of key node _m, and the location information of key node _m. Key node _k is the upstream node of key node i in the forwarding path, and key node _m is the upstream node of key node _k in the forwarding path. The multi-point forwarding proof is used to prove that key node _k forwards the data packet at position k in the forwarding path and that key node _m forwards the data packet at position m in the forwarding path. The multi-point forwarding proof is obtained based on position k, the identity information of key node _k, position m, and the identity information of key node _m, where k is a positive integer less than or equal to i and m is a positive integer less than or equal to k.
[0301] Optionally, the trigger condition for verifying the forwarding proof carried in the data packet is that the data packet contains a trusted path identifier. For example, after receiving a data packet, if a key node determines that the packet header of the data packet contains a trusted path identifier, it verifies the forwarding proof carried in the data packet.
[0302] Optionally, the key node verifies the forwarding proof carried in the data packet. If the verification of the forwarding proof carried in the data packet passes, the key node calculates and discloses the forwarding proof. If the verification of the forwarding proof carried in the data packet fails, the key node does not need to calculate the forwarding proof, for example, directly discards the data packet.
[0303] Technical effect 3: Computational efficiency and communication (space) efficiency
[0304] Computational efficiency and communication (space) efficiency refer to reducing the calculation time of the proof and the verification time of the proof, and reducing the amount of data of additional proofs and / or parameters to be transmitted under the condition of meeting security. In the embodiments of the present application, both the calculation time of the proof and the verification time of the proof are of constant level, and the amount of data of the additional proof is of constant level, which is independent of the number N of nodes included in the forwarding path.
[0305] The vector commitment mechanism is a general term for a class of technologies, and vector commitment includes various specific construction methods. Optionally, the method based on KZG polynomial commitment (kate-zaverucha-goldberg polynomial commitment) is used to obtain and verify the commitment based on the identity information and location information of the forwarding node, so as to further reduce the time for obtaining the commitment, improve the efficiency of obtaining the commitment, and also avoid the verification time of the forwarding proof growing superlinearly as the number of nodes in the forwarding path increases, making the verification time of the forwarding proof as short as possible.
[0306] By using the KZG polynomial commitment method to obtain and verify commitments, since the KZG polynomial commitment has a constant-time computational complexity when calculating commitments and opening proofs, and is hardly affected by the number N of the committed information, 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. Therefore, constant-time proof calculation and verification time, and constant-size additional proof data size are achieved, which are independent of the number N of nodes included in the path. In other words, the time required to obtain a commitment and the time required to verify a commitment remain constant, and the data volume for forwarding proofs remains constant. The time required to obtain a commitment, the time required to verify a commitment, and the data volume for forwarding proofs do not increase with the growth of the length of the forwarding path. In the case of a complex network scale and a forwarding path including a huge number of nodes, commitments can still be obtained and verified quickly, thus greatly improving the efficiency of obtaining and verifying commitments.
[0307] The implementation details of the KZG polynomial commitment are specifically described in the embodiments. The KZG polynomial commitment is only one possible implementation method for obtaining vector commitments. It can not only achieve the effects of forwarding proofs and location binding, but also has the advantage of high efficiency. Vector commitments obtained by other methods can also achieve the effects of forwarding proofs and location binding.
[0308] In some other possible implementation methods, the fast reed-solomon interactive (FRI) commitment method is adopted to obtain and verify commitments based on the identity information and location information of the forwarding nodes. The FRI commitment is a commitment mechanism used to verify the integrity of polynomials in an interactive proof system. It can quickly verify whether a polynomial satisfies a set of constraints without computing the entire polynomial item by item. The FRI commitment is based on Reed-Solomon coding and an interactive proof protocol, and greatly reduces the complexity of verifying polynomials by constructing multiple small-scale Reed-Solomon codings and related proofs.
[0309] In some other possible implementation methods, the succinct non-interactive argument of knowledge (SNARK) commitment method is adopted to obtain and verify commitments based on the identity information and location information of the forwarding nodes. The SNARK commitment is a protocol used to prove the correctness of a calculation and that the input possessed by a party satisfies specific conditions. The SNARK proof is non-interactive, that is, the prover does not need to interact with the verifier, but only needs to generate a proof and send it to the verifier. The SNARK proof has compactness, with a very small proof size and relatively short verification time.
[0310] In some other possible implementation manners, based on the identity information of the forwarding node and the location information of the forwarding node, a scalable transparent arguments of knowledge (STARK) commitment method is adopted to obtain a forwarding proof or a vector commitment; or a STARK commitment method is adopted to verify the forwarding proof based on the vector commitment. STARK belongs to a zero-knowledge proof technology. STARK does not require a trusted third-party setup to start, so it is more decentralized and distributed, reducing the impact of a single point of failure on obtaining the forwarding proof or the vector commitment, and also has high security. In addition, STARK is post-quantum secure. Therefore, adopting STARK helps to improve the ability of the forwarding proof to resist quantum computing attacks and is more reliable in protecting the security of the forwarding proof and the identity information. In addition, the data volume of the forwarding proof generated based on STARK is relatively small, which means that the proof can be transmitted with less storage space and also has an advantage in verification efficiency. For example, the next-hop forwarding node or the verification node can verify the validity of the forwarding proof in a relatively short time.
[0311] In some other possible implementation manners, based on the identity information of the forwarding node and the location information of the forwarding node, a Bulletproof method is adopted to obtain a forwarding proof or a vector commitment; or a Bulletproof method is adopted to verify the forwarding proof based on the vector commitment. Bulletproof belongs to a zero-knowledge proof technology. Bulletproof is a cryptographic primitive used in zero-knowledge proofs to prove that a value satisfies a certain relationship without the need to provide additional proof information. Bulletproof also does not require a trusted third-party setup to start, so it is more decentralized and distributed, reducing the impact of a single point of failure on obtaining the forwarding proof or the vector commitment, and also has high security.
[0312] In some other possible implementation manners, an RSA accumulator method is adopted to obtain a commitment and verify the commitment 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 for subsequent verification of whether an element belongs to the set. Based on the RSA additive homomorphism property, the RSA accumulator can verify whether a specific element is included in the accumulator without disclosing the set elements.
[0313] In some other possible implementation manners, the FC function commitment method is adopted to obtain commitments and verify commitments based on the identity information of the forwarding node and the location information of the forwarding node. The FC function commitment is a commitment mechanism used to bind an input to the calculation result of a function, enabling the calculation result to be verified without exposing the input. The FC function commitment can be implemented by combining a zero-knowledge proof system and a commitment mechanism. It can be used to protect computer privacy and verify the correctness of calculation results.
[0314] In some other possible implementation manners, the Pedersen commitment method is adopted to obtain commitments and verify commitments based on the identity information of the forwarding node and the location information of the forwarding node. The Pedersen commitment is a commitment mechanism used to commit a numerical value or vector to a hidden value. The Pedersen commitment is based on the discrete logarithm problem, such that only the committer who knows the hidden value can verify the correctness of the commitment without exposing the actual numerical value.
[0315] In some other possible implementation manners, the Merkle tree commitment method is adopted to obtain commitments and verify commitments based on the identity information of the forwarding node and the location information of the forwarding node. The Merkle tree commitment is a commitment mechanism used to bind multiple elements in a set into a tree-like structure. The Merkle tree combines elements step by step through a hash function and generates a root hash, which is the commitment to the entire tree. In the verification phase, only by knowing some elements in the set and the hash values on the relevant paths can it be verified whether the elements belong to the tree.
[0316] In some other possible implementation manners, the Verkle tree commitment method is adopted to obtain commitments and verify commitments based on the identity information of the forwarding node and the location information of the forwarding node. The Verkle tree commitment is a commitment mechanism used to bind multiple elements in a set into a non-binary tree-like structure. The Verkle tree commits the paths from the root node to the leaf nodes in the tree through polynomial commitments and aggregates multiple paths. In the verification phase, only by knowing some elements in the set and the polynomial commitments on the relevant paths can it be verified whether the elements belong to the tree.
[0317] In some other possible implementation manners, the source of the data packet is verified based on an aggregate signature. For example, the data packet contains a digital signature. This signature can be the signature of the previous-hop node _i - 1 or the aggregate signature of all nodes _1 to node _i - 1 in the first half. The characteristic of the aggregate signature is that the aggregation result of infinitely many signatures is of the same length as that of one signature. Given the existence of a public key infrastructure (PKI), that is, the public identities of the nodes are known, node _i can verify the correctness of this signature.
[0318] In some other possible implementation manners, verify the source of the data packet based on the symmetric MAC tag: for example, the data packet contains a MAC tag, and node_i can verify the correctness of the MAC tag.
[0319] Technical effect 4: Fault tolerance of non-critical nodes
[0320] The fault tolerance of non-critical nodes does not conflict with the order-preserving verification described above, mainly for two reasons.
[0321] First, the order relationship between the critical nodes specified by the controller, such as Figure 1 the order relationship between critical node A, critical node B, and critical node C in
[0322] still needs to be implemented by means corresponding to the forwarding path lock-in.
[0323] The ways to implement the fault tolerance mechanism include the following two implementation manners.
[0324] Implementation manner 1 of fault tolerance: In the commitment stage, determine the vector commitment based on the identity information of each critical node in the expected forwarding path and the sequential position of each critical node in the expected forwarding path, so that the vector commitment binds the corresponding relationship between the identity information and the sequential position. For example, each critical node is mathematically represented by a binary tuple (x_i = i, y_i = r_i), where i is the expected serial number of the critical node in the expected forwarding path, and r_i is the identity information of the critical node with the expected serial number i in the expected forwarding path, and the vector commitment is bound to the binary tuple (x_i = i, y_i = r_i) of each critical node in the expected forwarding path.
[0325] In the forwarding stage, also calculate the forwarding proof based on the identity information r_i of the critical node and the sequential position i of the critical node in the expected forwarding path. Optionally, the calculated forwarding proof is MP instead of OP. MP is to calculate the forwarding proof of a section of the path, which is used to verify that all critical nodes in the first half of the actual forwarding path are in the relatively correct sequential positions. For example, the order relationship between all critical nodes in the first half of the actual forwarding path is consistent with the order relationship between all critical nodes in the first half of the expected forwarding path.
[0326] Implementation method of fault tolerance II. In the commitment stage, the correspondence between the identity information of key nodes and their sequential positions is no longer bound, but only the identity information of key nodes is bound. For example, a vector commitment is determined based on the identity information of each key node in the expected forwarding path, and the sequential positions of each key node in the expected forwarding path are not used when determining the vector commitment. This way of no longer using the sequential positions of key nodes is equivalent to mathematically transforming each forwarding node into a binary tuple (x_i = r_i, y_i = r_i), where r_i is the identity information of key node i, and both x and y in the binary tuple of the forwarding node are identity information and no longer include the sequential position i. 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, the forwarding proof of a single node can be calculated using OP, and the forwarding proof of multiple nodes in a path can also be calculated using MP. And when calculating the forwarding proof, the non-key nodes that may exist in the middle are ignored. However, the forwarding proof obtained in this way can only prove that the data packet has passed through this key node, but cannot prove the correctness of the sequential position of the key node, resulting in some loss of position binding.
[0327] Technical effect 5: Recordability of non-key nodes
[0328] Optionally, based on the first implementation method of fault tolerance, during the process of forwarding data packets, key nodes record their sequential positions in the actual forwarding path. Based on the recorded sequential positions of key nodes 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, so as to achieve the recordability of non-key nodes. In addition, since the sequential positions of the actual forwarding path are recorded by key nodes, it is not necessary to require non-key nodes to perform additional actions other than forwarding, and the existence of non-key nodes can also be recorded indirectly, with better compatibility.
[0329] In some embodiments, the structure of the data packet is extended, and a new list is added to the data packet to record the sequential positions of key nodes in the actual forwarding path. Hereinafter, this list will be referred to as the actual sequential position list (also referred to as the true sequence number list).
[0330] The actual sequence position list is used to record the sequence position of each key node in the actual forwarding path. In some embodiments, during the process of key node A forwarding a data packet, 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 packet. Key node A forwards the data packet 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. And so on. Whenever a data packet passes through a key node, the actual sequence position list carried in the data packet will increase by the actual sequence position of a key node. When the data packet 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 packet, the actual sequence position list carried in the data packet includes the actual sequence positions of each key node passed by the actual forwarding path.
[0331] Optionally, the arrangement order of the entries in the actual sequence list matches the sequence of key nodes in the actual forwarding path. For example, the first entry in the actual sequence list is used to record the sequence position of the first key node in the actual forwarding path; the second entry in the actual sequence list is used to record the sequence position of the second key node in the actual forwarding path; and so on. The i-th entry in the actual sequence list is used to record the sequence position of the i-th key node in the actual forwarding path.
[0332] 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 two adjacent entries represents the number of non-key nodes between the corresponding two key nodes.
[0333] Optionally, the length of the actual sequence position list is 1 byte multiplied by the path length n, that is, n bytes. Wherein, the path length is determined based on the number of key nodes passed by the actual forwarding path, and the path length n indicates that a total of n key nodes are passed in the actual forwarding path. 1 byte is used to store the sequence position of a key node in the actual forwarding path. Considering that 1 byte can store at most 256 values, and the maximum value of TTL (sequence position in the actual forwarding path) is 255, so 1 byte is sufficient to carry the sequence position of any key node in the actual forwarding path.
[0334] For example, the expected forwarding path planned by the controller is ABCD, and the sequential positions corresponding to key node A, key node B, key node C, and key node D are 1, 2, 3, and 4 respectively. There is 1 non-key node between key node A and key node B, 2 non-key nodes between key node B and key node C, and 2 non-key nodes between key node C and key node D. In this scenario, key node A adds the sequential position (1) of this node in the actual forwarding path to the first entry in the actual sequential position list carried in the data packet. Key node B adds the sequential position (3) of this node in the actual forwarding path to the second entry in the actual sequential position list carried in the data packet. Key node C adds the sequential position (5) of this node in the actual forwarding path to the third entry in the actual sequential position list carried in the data packet. Key node D adds the sequential position (9) of this node in the actual forwarding path to the fourth entry in the actual sequential position list carried in the data packet. The actual sequential position list carried in the data packet finally received by the destination host of the data packet is shown in the following table.
[0335] Actual sequence position list (stored as binary) 1 3 6 9
[0336] In some other embodiments, during the process of forwarding a data packet, the non-key node records the sequential position of this node in the actual forwarding path, so as to achieve the recordability of the non-key node. For example, there is one or more forwarding nodes in the actual forwarding path that do not support forwarding proof calculation or do not support forwarding proof verification, but support recording the sequential position of the actual forwarding path. After receiving the data packet, the forwarding node determines the sequential position of this node in the actual forwarding path based on the TTL or other fields in the data packet, adds the sequential position of this node in the actual forwarding path to the actual sequential position list carried in the data packet, or sends the sequential position of this node in the actual forwarding path to the verification node.
[0337] Due to the use of vector commitment, the embodiments of the present application can achieve technical effect 1 key path binding and technical effect 2 source correctness. Due to the use of polynomial commitment technology, the embodiments of the present application can achieve technical effect 3 computational efficiency and communication (space) efficiency.
[0338] The system architecture of the embodiments of the present application is illustrated below.
[0339] The embodiments of the present application provide a general trusted path protection technology, which can implement the protection of the data plane forwarding path, so it can be applied to any scenario that requires trusted path protection at any level of the computer network. For example, the link layer is applicable to Ethernet or MPLS protocols; the network layer is applicable to IPv4 or IPv6 protocols; the tunnel layer is applicable to SRv6, application-aware networking (APN), virtual extensible LAN (VxLAN), or Internet protocol security (IPSec); the service layer is applicable to service function chaining (SFC) protocols, etc. The main differences in different protocol scenarios lie in the message headers carrying commitments and forwarding proofs and their specific carrying positions. First, the general trusted path protocol steps, functions, and roles will be described below, and then specific embodiments in different protocol scenarios will be explained.
[0340] In any scenario that requires a trusted path, there are several roles: a path planner, forwarding nodes, and verification nodes.
[0341] The path planner is used to determine a network forwarding path in any of the above-listed network layers. This forwarding path can be represented by a vector P = (r_1, r_2,..., r_N) formed by the information of N forwarding nodes (or routing nodes). 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 in advance the identity information of all forwarding nodes in the network.
[0342] Optionally, the path planner performs remote attestation secret distribution, and the secret is the identity information of the forwarding nodes 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 can determine the vector commitment based on the received ciphertext of the identity information.
[0343] The forwarding nodes are further divided into critical nodes and non-critical nodes. For the concept definitions of critical nodes and non-critical nodes, please refer to the previous description.
[0344] 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.
[0345] 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.
[0346] Figure 2 It is a schematic diagram of a path verification method provided in an embodiment of the present application. Figure 2 The method shown is interactively executed by the path planner, the key node and the verification node.
[0347] Figure 2 The method shown 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. Figure 2 The method shown involves a data message processing process performed by multiple forwarding nodes along the actual forwarding path. Since the processing processes performed by different key nodes have commonalities, for the sake of simplicity, the attached Figure 2 The method shown focuses on the processing process performed by two key nodes as an example for explanation. Of course, there may be three or more key nodes in the actual forwarding path, and the processing process performed by more key nodes can refer to the processing process performed by key node A or key node B.
[0348] 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.
[0349] Figure 2The method shown involves the processing process of data packets by forwarding nodes. For the sake of distinction in description, the data packet serving as the input data is described as the "first data packet", and the data packet serving as the output result is described as the "second data packet". Both the first data packet and the second data packet carry service 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 this device for self - processing.
[0350] Figure 2 The method shown involves the application scenario of how to achieve the 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 packet. For example, the sequence order of at least two critical nodes in the expected forwarding path of the first data packet is the same as the sequence order of the at least two critical nodes in the actual forwarding path of the first data packet, and the sequential positions of the at least two critical nodes in the expected forwarding path are different from the sequential positions of the at least two critical nodes in the actual forwarding path.
[0351] Figure 2 The method shown includes the following steps.
[0352] S210, the path planner determines the expected forwarding path.
[0353] The expected forwarding path includes at least two critical nodes. For example, the path planner determines an expected forwarding path P=(r_1,r_2,…,r_N), where P is a vector composed of the identity information of each of the N critical nodes and the sequential position of each of the N critical nodes. Among them, r_i is the information of the publicly verifiable identity of the critical node, such as a certificate issued by a CA or an access token issued by an access control server, etc. S210 is also called the path selection step.
[0354] S220, the path planner determines the first vector commitment.
[0355] The first vector commitment indicates the correspondence between the sequential positions of at least two critical nodes in the expected forwarding path and the identities of the at least two critical nodes. For example, the path planner calculates the first vector commitment based on the identity information of each critical node and the sequential position of each critical node in the expected forwarding path.
[0356] In some embodiments, the input data used by the path planner to determine the vector commitment includes an expected forwarding path of length N, such as 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.
[0357] 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 the forwarding proof passes 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 the forwarding proof fails the verification. The auxiliary data is, for example, the cryptographic parameters based on which the commitment is calculated. S220 is also called the path commitment or path initialization step.
[0358] In a possible implementation, before forwarding the data packet, the controller distributes the identity information and auxiliary data required for calculating the forwarding proof to each key node in the expected forwarding path, so as to achieve data pre-distribution. The auxiliary data is, for example, the cryptographic parameters based on which the vector commitment is calculated.
[0359] Optionally, the path planner also sends the first vector commitment to the verification node before forwarding the data packet, so as to transfer the first vector commitment to the verification node through the control plane pre-distribution method. 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 packet, so that the first vector commitment is transferred to the verification node along with the service data.
[0360] S230, key node A obtains data packet A.
[0361] Data packet A carries service data. Optionally, data packet A also carries a vector commitment, so that the verification node can verify the forwarding proof by obtaining the vector commitment carried in the data packet.
[0362] Optionally, data packet A also carries a trusted path identifier, so as to trigger the determination process and / or verification process of the forwarding proof through the trusted path identifier.
[0363] The sources of data packet A include various situations. In some embodiments, all or part of the content of data packet A is received from the source host. For example, key node A is the ingress PE communicating with the source host. The source host generates service data and sends the service data to key node A. Key node A generates data packet A based on the service data from the source host and the vector commitment. Data packet A includes a header and a payload field. The header carries the vector commitment, and the payload field carries the service data. In other embodiments, all or part of the content of data packet A is generated by key node A itself. For example, key node A itself is the source host, and key node A generates data packet A through the application program or operating system of this device.
[0364] The following takes key node A as an example to illustrate the triggering conditions for subsequent determination of the forwarding proof.
[0365] In a possible implementation, if key node A determines that the header of data packet A carries a trusted path identifier, it performs the subsequent steps of obtaining the forwarding proof based on the identity information and the sequential position. If key node A determines that the header of data packet A does not carry a trusted path identifier, it does not need to perform the subsequent steps of obtaining the forwarding proof based on the identity information and the sequential position, and forwards data packet A to the next forwarding node. The trusted path identifier is used to indicate that data packet A needs to be forwarded through a trusted path.
[0366] By including a trusted path identifier in the header of the data packet, it supports the forwarding node 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 packet does not carry a trusted path identifier, key node A uses the original forwarding mechanism without the need to calculate the forwarding proof.
[0367] In another possible implementation, after key node A obtains the data packet, key node A identifies the service type carried in the data packet; in response to identifying that the data packet carries data of a specific service type, it performs the steps of obtaining the forwarding proof, thereby realizing the forwarding proof for the specific service. For example, in response to key node A identifying that the data packet includes a network service header (NSH) in the service function chain protocol, it determines that the data packet carries service function chain data, and then performs the steps of obtaining the forwarding proof. Another example is that key node A performs application identification on the payload data in the data packet to obtain the application type corresponding to the payload data. In response to the application type being the target application, it performs the steps of obtaining the forwarding proof.
[0368] In another possible implementation, after the key node A obtains the data packet, in response to identifying that the data packet contains the identifiers of each node in a specific tunnel, the key node A performs the step of obtaining a forwarding proof to verify whether the data packet is forwarded through the specific tunnel. For example, when applied to the SRv6 scenario, in response to identifying that the data packet carries a segment list, the key node A performs the step of obtaining a forwarding proof. Another example is that when applied to the MPLS scenario, in response to identifying that the data packet carries a label stack, the key node A performs the step of obtaining a forwarding proof.
[0369] S240, the key node A obtains the sequential position of the verified node in the expected forwarding path and the identity information of the verified node.
[0370] The verified node refers to a forwarding device that is the object of verification. The verified nodes include, but are not limited to, the current node, the neighbor nodes of the current node, and each node from the first forwarding node to the current node. The sequential position of the verified node in the expected forwarding path is different from the sequential 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.
[0371] In some embodiments, the verified node is the current node. For example, when the data packet is transmitted to the key node A, the verified node is the key node A. The key node A obtains the sequential position of the key node A in the expected forwarding path and the identity information of the key node A, and obtains a first forwarding proof based on the sequential 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 current node, it helps to verify whether the current node is the expected forwarding node or whether the sequential position where the current node is located is the expected sequential position. In particular, when the key node A is the first forwarding node or the source host, it helps to verify the correctness of the source of the data packet.
[0372] In some embodiments, the verified nodes include the neighbor nodes of the current node.
[0373] For example, the verified node is the next node of the current node. When the data packet is transmitted to the key node A, the verified node is the key node B. The key node A obtains 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 A obtains a forwarding proof A based on 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 the next node, it helps to verify whether the next node is the expected forwarding node or whether the sequential position where the next node is located is the expected sequential position, thereby reducing the risk of the data packet being transmitted to an unexpected forwarding node.
[0374] For another example, if the node to be verified is the previous node of the current node, when the data packet is transmitted to the key node B, the node to be verified is the key node A. The key node B obtains the sequential 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 sequential 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 helps to verify whether the next node is the expected forwarding node or whether the sequential position where the next node is located is the expected sequential position, thereby reducing the risk of the data packet being transmitted to an unexpected forwarding node.
[0375] For another example, the node to be verified includes the current node and the previous node of the current node. When the data packet is transmitted to the key node A, the node to be verified includes the key node A and the previous node of the key node A (such as 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 both the key node A and the previous node of the key node A forward the data packet at the expected sequential positions. 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.
[0376] In some embodiments, the node to be verified includes each node from the first forwarding node to the current node. For example, when the data packet is transmitted to the key node B, the node to be verified 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 in the upper half of the path, it helps to verify whether the data packet passes through an unexpected forwarding node.
[0377] There are many ways to obtain the sequential position of the node to be verified in the expected forwarding path. The following uses two implementation methods as examples for illustration.
[0378] Method 1 for obtaining the sequential position of the node to be verified in the expected forwarding path: Obtain the sequential position of the node to be verified in the expected forwarding path through the data packet carrying service data.
[0379] In some embodiments, a predetermined field of data packet A carries the sequential position of the verified node in the expected forwarding path. For example, the header of data packet A carries the sequential position of the verified node in the expected forwarding path. For example, the header of the data packet includes a type-length-value (TLV) or a reserved field, and the TLV or the reserved field carries the sequential position of the verified node in the expected forwarding path.
[0380] In some embodiments, the key node A further processes the content of the predetermined field in data packet A to obtain the sequential position of the verified node in the expected forwarding path. For example, the header of data packet A carries path information, and the path information includes the identifiers of each key node in the expected forwarding path. The arrangement order of the identifiers 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.
[0381] For example, in some embodiments of obtaining the sequential position in the SRv6 scenario, data packet A includes a segment routing header (SRH), the SRH includes a segment list, the segment list includes the SID of 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 key node A in the segment list. For example, if the SID of key node A is in the i-th entry in the segment list, it is determined that the sequential position of the verified node in the expected forwarding path is 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 of the key node A in the forwarding path based on the offset of the SID of the upstream node of the key node A compared to segment list [N].
[0382] In some embodiments of obtaining the sequential position in the SFC scenario, data packet A includes a path identifier, and the key node A obtains the path identifier carried in data packet A. The 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 the 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, the key node A looks up the corresponding relationship based on the path identifier to obtain the sequential position of the local 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 through the control plane.
[0383] Since the sequential position in the expected forwarding path is obtained through data packets, the sequential position in the expected forwarding path can be obtained relatively quickly, saving the performance overhead and computational overhead of the forwarding device to obtain the sequential position in the expected forwarding path through table lookup matching, and also saving the storage space occupied in the forwarding device for obtaining the sequential position in the expected forwarding path through table lookup matching.
[0384] Method 2 for obtaining the sequential position of the expected forwarding path: Obtain the sequential position in the expected forwarding path through the way of pre-distribution by the control plane.
[0385] The way of pre-distribution by the control plane is mainly realized through the interaction between the path planning party and the forwarding node. For example, during the process of determining the expected forwarding path, the path planning party determines the sequential position of the verified node in the expected forwarding path. The path planning party 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 planning party.
[0386] 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, in the path planning direction, the key node A sends management plane protocol messages such as network configuration protocol (NETCONF) messages, representational state transfer configuration (RESTCONF) messages, or simple network management protocol (SNMP) messages. The management plane protocol messages carry the sequential position of the verified node in the expected forwarding path. The key node A receives the management plane protocol messages and obtains the sequential position of this node in the expected forwarding path carried by the management plane protocol messages. Another example is that in the path planning direction, the key node A 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, abbreviated as BGP flow spec or BGP FS). The control plane protocol messages carry the sequential position of the verified node in the expected forwarding path. The key node A receives the control plane protocol messages and obtains the sequential position of this node in the expected forwarding path carried by the control plane protocol messages. Another example is that in the path planning direction, the key node A sends application layer protocol messages such as APN messages and hypertext transfer protocol (HTTP) messages. The application layer protocol messages carry the sequential position of the verified node in the expected forwarding path.
[0387] In other embodiments, the controller distributes the sequential positions of each key node upstream of each key node on the expected forwarding path to each key node on the expected forwarding path. For example, the controller sends the sequential positions of each key node from the first key node to key node i in the expected forwarding path to key node i.
[0388] In some other embodiments, the network administrator pre-configures the sequential position of each key node on the expected forwarding path at each key node on the expected forwarding path. Optionally, in the case of calculating the multi-point forwarding proof in the MP mode, the network administrator also configures the sequential position of each key node upstream of each 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 positions of each key node from key node 1 to key node i in the forwarding path, and key node i obtains the relative positions of each key node from key node 1 to key node i from the configuration information.
[0389] There are many ways to obtain the identity information of the node to be verified. The following uses two implementation methods as examples for illustration.
[0390] Method 1 for obtaining the identity information of the node to be verified: Obtain the identity information of the node to be verified through a data packet carrying service data.
[0391] In some embodiments, a predetermined field of data packet A carries the identity information of the node to be verified. For example, the packet header of data packet A carries the identity information of the node to be verified. For example, the packet header of the data packet includes a TLV or a reserved field, and the TLV or the reserved field carries the identity information of the node to be verified.
[0392] As an example, the node to be verified is key node A, and the destination address field of the IP header of data packet A includes the IP address of key node A. Key node A obtains the IP address of key node A from the destination address field of the IP header of data packet A.
[0393] For example, in the case of calculating the single-point forwarding proof in the OP mode, data packet A carries the identity information of key node A, and key node A obtains the identity information of its own node carried by data packet A for calculating OP. Another example is that in the case of calculating the multi-point forwarding proof in the MP mode, data packet 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 packet A for calculating MP.
[0394] For example, in some embodiments of obtaining the identity information of the node to be verified in the SRv6 scenario, data packet A includes an SRH, the SRH includes a segment list, and the segment list includes the SID of each node in the expected forwarding path. Key node A obtains the SID of the node to be verified carried by the segment list to obtain the identity information of the node to be verified.
[0395] Method 2 for obtaining the identity information of the node to be verified: Obtain the sequential position in the expected forwarding path through the pre-distribution method of the control plane.
[0396] 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.
[0397] S250. The key node A obtains the node-level forwarding proof A based on the sequential position of the verified node in the expected forwarding path and the identity information of the verified node.
[0398] The forwarding proof A is used to prove that the verified node is in the sequential position of the verified node in the expected forwarding path.
[0399] For example, if the verified node is the current node (key node A), the key node A obtains the device-level forwarding proof A based on the sequential position of the key node A in the expected forwarding path and the identity information of the key node A, so as to verify whether the key node A is in the expected sequence and whether the key node A is the expected node based on the forwarding proof A.
[0400] For example, if the verified node is the next node of the current node (key node B), the key node A obtains the forwarding proof A based on the sequential 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 data packet is to be sent to a node with an expected sequence and a correct expected identity based on the forwarding proof A.
[0401] S260. The key node A sends the forwarding proof A to the verification node and sends the data packet B to the key node B.
[0402] By sending the forwarding proof A to the verification node, the key node A facilitates the verification node to verify the sequential position and identity of the key node A based on the forwarding proof A. The data packet B carries the service data in the data packet A. By sending the data packet B to the key node B, the service data reaches the next key node expected by the path planner from this node.
[0403] When the verification node concurrently serves as the verification node at the key node B, or when a key node downstream of the key node B (such as the tail node at the end of the path) concurrently serves as the verification node, the forwarding proof and service data are carried, for example, by the same data packet. For example, the verification node is the key node B, and the key node B is a key node downstream of the key node A in the expected forwarding path. The key node A obtains the data packet B based on the service data carried in the data packet 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 packet B carries the service data carried in the data packet A. The packet header of the data packet B carries the forwarding proof of the verified node. The key node A sends the data packet 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 packet A corresponds to the first data packet, and the data packet B corresponds to the second data packet.
[0404] When the verification node is deployed outside the forwarding path, the key node A constructs a separate packet to carry the forwarding proof of the verified node. For example, the key node A generates a first packet, which is a control plane packet, a management plane packet, or a data packet, and the first packet carries the forwarding proof of the verified node. The key node A sends the first packet to the verification node.
[0405] S320, the key node B receives the data packet B from the key node A.
[0406] The key node B is a key node upstream of the key node A in the forwarding path. The key node B is an intermediate node or a tail node.
[0407] S340, the key node B obtains the sequential position of the verified node in the expected forwarding path and the identity information of the verified node.
[0408] S350, the key node B obtains the device-level forwarding proof B based on the obtained sequential position of the verified node in the expected forwarding path and the identity information of the verified node.
[0409] For example, the verified node is the current node (key node B), and the key node B obtains the device-level forwarding proof B based on the sequential 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 B forwards the data packet at the expected sequential position based on the forwarding proof B.
[0410] For example, the verified node is the previous node of the current node (key node A), and the key node B obtains the forwarding proof B based on the sequential position of the key node A in the expected forwarding path and the identity information of the key node A, so as to verify whether the data packet comes from a node in the expected sequence and with the correct identity based on the forwarding proof B.
[0411] For example, the node to be verified includes the current node (key node B) and the previous node of the current node (key node A). Key node B obtains forwarding proof B based on the sequential position of key node A in the expected forwarding path, the identity information of key node A, the sequential position of key node B in the expected forwarding path, and the identity information of key node B, so as to verify whether key node A forwards the data packet at the expected sequential position and whether key node B forwards the data packet at the expected sequential position based on forwarding proof B. In this case, key node B corresponds to the first forwarding node, and key node A corresponds to the second forwarding node.
[0412] For example, the node to be verified is the next node of the current node (key node C). 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 whether the data packet is to be sent to a node with an expected sequence and a correct expected identity based on forwarding proof B.
[0413] For example, the node to be verified includes the current node (key node B) and the next node of the current node (key node C). Key node B obtains forwarding proof B based on the sequential position of key node B in the expected forwarding path, the identity information of key node B, the sequential position of key node C in the expected forwarding path, and the identity information of key node C, so as to verify whether key node B forwards the data packet at the expected sequential position and whether the data packet is to be sent to a node with an expected sequence and a correct expected identity based on forwarding proof B.
[0414] For example, the node to be verified is each node passed by in the first half of the path. Key node B obtains forwarding proof B based on the sequential position of key node A in the expected forwarding path, the identity information of key node A, the sequential position of key node B in the expected forwarding path, and the identity information of key node B.
[0415] S360. Key node B sends forwarding proof B of key node B to the verification node and sends data packet C to key node C.
[0416] In some embodiments, key node B verifies the correctness of the source of data packet B. If the source correctness verification of data packet B passes, key node B further performs the subsequent determination process of the forwarding proof. If the source correctness verification of data packet B fails, key node B does not need to perform the subsequent determination process of the forwarding proof, and key node B can directly discard the data packet.
[0417] In some embodiments for verifying the correctness of the source of data packet B at key node B, key node B verifies whether data packet B is from key node A, where key node A is the previous key node of key node B in the expected forwarding path. For example, key node B verifies the correctness of the single-point forwarding proof OP_i-1 of key node A carried in data packet B based on the identity information of key node A, the expected sequential position of key node A, and the node-level vector commitment, so as to verify whether the previous hop of data packet B is correct; for another example, key node B verifies the correctness of the multi-point forwarding proof MP_i-1 of key node A carried in data packet B based on the identity information of key node A, the expected sequential position of key node A, the identity information of key node B, the expected sequential position of key node B, and the node-level vector commitment, so as to verify whether the forwarding path segment that data packet B has passed through is correct. In addition, other aggregatable proof methods can also be used in the data packet source verification step, such as a password accumulator, an aggregatable signature, or a MAC tag, etc.
[0418] In some embodiments, a key node also serves as a verification node. For example, the verification node is key node C, and key node C is a key node downstream of key node B in the expected forwarding path. Key node B obtains data packet C based on the received data packet B and the forwarding proof B of key node B, and key node B sends data packet C to key node C. Data packet C includes the payload of data packet B and the forwarding proof B of key node B. In this case, key node B corresponds to the first forwarding node, key node C corresponds to the third forwarding node and the corresponding verification node, data packet B corresponds to the first data packet, and data packet C corresponds to the second data packet.
[0419] S270, the verification node obtains the forwarding proof, the device-level vector commitment, the identity information of the node to be verified, and the sequential position of the node to be verified in the expected forwarding path.
[0420] At least two key nodes include the node to be verified. The identity information of the node to be verified indicates the identity of the node to be verified, and the forwarding proof of the node to be verified is used to prove that the node to be verified is in the sequential position of the node to be verified in the expected forwarding path.
[0421] In a 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, the forwarding proof related to a single verified node is verified based on a single-point verification function, thereby realizing the verification of the proof of a single node. In another possible implementation, in S250 and S260, a forwarding proof related to multiple verified nodes is verified based on a batch verification function, and in S270, a forwarding proof related to multiple verified nodes is obtained based on a multi-point opening function, thereby verifying multiple nodes of the path at one time.
[0422] Of course, the three functions of commitment, opening, and verification are only examples of several functions available for obtaining and verifying forwarding proofs. In another possible implementation, other types of functions in vector commitment are used to obtain and verify forwarding proofs. For example, in S250 and S260, a witness creation function (create witness, which is equivalent to the opening function) is used to obtain a forwarding proof, and in S270, a verification calculation function (verify eval, which is equivalent to the verification function) is used to verify the forwarding proof; another example is that in S250 and S260, a batch witness creation function (create witnessbatch, which is equivalent to the batch opening function) is used to obtain a multi-point forwarding proof, and in S270, a batch verification calculation (verify eval batch, which is equivalent to the batch verification function) is used to verify the multi-point forwarding proof.
[0423] S280, the verification node verifies the forwarding proof A or / and 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.
[0424] In some embodiments, the verification node performs operations using a verification function in the vector commitment mechanism 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.
[0425] 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 verification node determines that the forwarding proof of the verified node passes the verification, 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.
[0426] Conversely, if there is a mismatch among 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, and the output result of the verification function is 0, it means that the forwarding proof of the verified node passes the verification, 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.
[0427] For example, the verification node verifies the forwarding proof A from key node A based on the device-level vector commitment, the identity information of key node A, and the sequential position of key node A in the expected forwarding path, so as to determine whether the identity and sequential position of key node A meet the expectations.
[0428] Another example is that the verification node verifies the forwarding proof from key node B based on the device-level vector commitment, the identity information of key node B, and the sequential position of key node B in the expected forwarding path, so as to determine whether the identity and sequential position of key node B meet the expectations. Another example is that the verification node verifies the forwarding proof from key node B based on the device-level vector commitment, the identity information of key node A, the sequential position of key node A in the expected forwarding path, the identity information of key node B, and the sequential position of key node B in the expected forwarding path, so as to determine whether the identity and sequential position of key node A and the identity and sequential position of key node B both meet the expectations.
[0429] The benefits achieved by verifying the forwarding proof using vector commitment at least include the following aspects.
[0430] First, it helps to verify that the data is forwarded in sequence according to the order specified by the forwarding path.
[0431] Specifically, the vector commitment itself has position-binding properties, that is, it can reflect the binding relationship between the value of the information and the position of the information in the vector. Therefore, obtaining the vector commitment based on the identity information of the key node and the expected sequential position of the key node makes the vector commitment related to both the identity information and the expected sequential position of the key node. The vector commitment can reflect the corresponding relationship between the expected sequential position and the identity information of the key nodes on the forwarding path. Therefore, when verifying the forwarding proof based on the vector commitment, the identity information, the expected sequential position, and the forwarding proof can pass the verification only when they correspond to each other. The forwarding proof obtained when the identity information does not correspond to the expected sequential position will cause the verification to fail. In other words, only the key node i at the expected sequential position i can calculate the correct forwarding proof p_i, and it cannot be forged by others.
[0432] Second, it helps with path concealment. Since vector commitments are in ciphertext form, the identity information and expected sequential positions of the key nodes contained therein cannot be directly obtained from the vector commitments themselves, nor is it easy to decrypt the vector commitments or reverse-engineer the identity information and expected sequential positions of the key nodes, thereby concealing the identity information and expected sequential positions of the key nodes on the forwarding path, and thus enhancing the privacy and confidentiality of the identity information and expected sequential positions of the key nodes.
[0433] Third, it reduces the time to obtain commitments and the time to verify commitments, and improves the efficiency of obtaining commitments and the efficiency of verifying commitments. If the single-point commitment method is used, it is necessary to commit to the position of each node and the identity of each node one by one. Then, if the forwarding path includes n nodes, it will take n times the time to obtain commitments and verify commitments. By using the vector commitment method, it is allowed to commit to a forwarding path (equivalent to a vector) containing at least two nodes at once. Then, if the forwarding path includes n nodes, it may only take log n or a constant time to obtain commitments and verify commitments, thereby reducing the risk that the amount of committed data grows superlinearly as the number of nodes in the forwarding path increases, enabling the process of obtaining commitments and verifying commitments to be completed more quickly, which can greatly improve efficiency and is more applicable to the case where the forwarding path contains a large number of nodes. In addition, the single-point commitment method cannot bind the identity information and expected sequential positions of the key nodes, and other methods need to be used to achieve position binding, such as using a list to record the expected sequential positions, while vector commitments have the ability to bind positions and can directly bind multiple identity information to the corresponding expected sequential positions, thus simplifying the verification process.
[0434] For the method provided in this embodiment, since the forwarding proof is obtained by combining the position of the forwarding node on the forwarding path and the identity of the forwarding node, the position binding of the forwarding proof is achieved. That is, the forwarding proof is not only related to the identity of the forwarding node but also related to the position of the forwarding node on the forwarding path. Therefore, the data packet can calculate the correct forwarding proof only when it is forwarded to the correct position on the forwarding path by the correct node, making the forwarding proof strongly bound to the actual forwarding situation of the data packet. For example, if a node in the path is skipped during forwarding, or an extra unspecified node is passed by, the identity of the node and its position will no longer correspond to each other, so the forwarding proof obtained based on the identity and position of the node cannot pass the verification, thereby enhancing the credibility of the forwarding proof.
[0435] Further, since the key nodes in the expected forwarding path calculate the forwarding proof using their sequential positions in the expected forwarding path, and use vector commitments and the sequential positions of the key nodes in the expected forwarding path to verify the forwarding proof, the sequential positions based on which the vector commitments are calculated are the same as those based on which the forwarding proof is calculated, thereby achieving the fault tolerance of non-critical nodes. Therefore, the risk of interrupting the transmission of service data or outputting an alarm due to the failure of verifying the forwarding proof based on vector commitments is reduced.
[0436] In some embodiments, the key nodes not only send the forwarding proof of their own nodes to the verification nodes, but also send their sequential positions in the actual forwarding path to the verification nodes, so as to achieve the recordability of non-critical nodes.
[0437] For example, key node A obtains that the sequential position of the first forwarding node in the actual forwarding path is 1 based on data packet A; key node A sends the sequential position 1 to the verification node; key node B obtains that the sequential position of key node B in the actual forwarding path is 4 based on data packet B, and key node B sends the sequential position 4 to the verification node; key node C obtains that the sequential position of key node C in the actual forwarding path is 6 based on data packet C, and key node C sends the sequential position 6 to the verification node.
[0438] Regarding how to transmit the actual sequential positions of the key nodes to the verification nodes, this embodiment illustrates with two methods as examples.
[0439] Transmission method 1 of the actual sequential position: The actual sequential position of the key node is transmitted together with the service data
[0440] Transmission method 1 is equivalent to an in-band method. For example, during the process of forwarding a data packet, the key node adds its sequential position in the actual forwarding path to the data packet and forwards the data packet containing the service data and its actual sequential position, so that its actual sequential position is transmitted to the next forwarding node of the key node together with the service data. For example, the data packet includes a packet header and a payload field encapsulated inside the packet header, and the packet header carries the actual sequential position of the key node, and the payload field carries the service data.
[0441] In some embodiments, the actual sequence position and the forwarding proof are transmitted to the verification node together with the service data. For example, the verification node is the critical node B downstream of the critical node A in the expected forwarding path. The critical node A obtains the data packet B based on the data packet A, the forwarding proof of the critical node A, and the sequence position of the critical node A in the actual forwarding path. The data packet B includes the payload of the data packet A, the forwarding proof of the critical node A, and the sequence position of the critical node A in the actual forwarding path. The critical node A sends the data packet B to the critical node B. In this case, the critical node A corresponds to the first forwarding node, the critical node B corresponds to the third forwarding node, the data packet A corresponds to the first data packet, and the data packet B corresponds to the second data packet.
[0442] For another example, the verification node is the critical node C downstream of the critical node B in the expected forwarding path. The critical node B obtains the data packet C based on the data packet B, the forwarding proof of the critical node B, and the sequence position of the critical node B in the actual forwarding path. The data packet C includes the payload of the data packet B, the forwarding proof of the critical node B, the sequence position of the critical node A in the actual forwarding path, and the sequence position of the critical node B in the actual forwarding path. The critical node B sends the data packet C to the critical node C. In this case, the critical node B corresponds to the first forwarding node, the critical node C corresponds to the third forwarding node, the data packet B corresponds to the first data packet, and the data packet C corresponds to the second data packet.
[0443] Since the actual sequence position and the forwarding proof are carried in the same data packet and sent to the critical node downstream of the forwarding path, in the mode where the critical node also serves as the verification node (observer), there is no need to separately construct independent data packets to transmit the actual sequence position and the forwarding proof. Therefore, the overall transmission overhead of the actual sequence position and the forwarding proof is small. The verification node can obtain both the actual sequence position of the critical node and the forwarding proof of the critical node by parsing one data packet. Therefore, the efficiency of the verification node in obtaining the actual sequence position of the critical node and the forwarding proof of the critical node is also high.
[0444] In some embodiments, the data packet A includes a first position list, and the first position list includes the sequence positions of the critical nodes upstream of the first forwarding node in the expected forwarding path in the actual forwarding path. The data packet B includes a second position list, and the second position list includes the first position list and the sequence position of the first forwarding node in the actual forwarding path.
[0445] Next, an example is given of the carrying positions of the actual sequence position, the forwarding proof, and the vector commitment of the critical node in the message.
[0446] In the case of transmitting data based on the IPv6 protocol, in a possible implementation, the actual sequential position, forwarding proof, and vector commitment of the key nodes are carried by the IPv6 extension header. For example, the actual sequential position, forwarding proof, and vector commitment of the key nodes are carried by the segment routing header (SRH). Another example is that the actual sequential position, forwarding proof, and vector commitment of the key nodes are carried by the hop-by-hop options header (HBH). Another example is that the actual sequential position, forwarding proof, and vector commitment of the key nodes are carried by the destination options header (DOH). SRH, HBH, and DOH are specific examples of three IPv6 extension headers that can carry the forwarding proof.
[0447] Optionally, the forwarding proof is carried by the TLV in the IPv6 extension header. For example, the actual sequential position, forwarding proof, and vector commitment of the key nodes are carried by the TLV in the SRH. Another example is that the actual sequential position, forwarding proof, and vector commitment of the key nodes are carried by the TLV in the HBH. Another example is that the actual sequential position, forwarding proof, and vector commitment of the key nodes are carried by the TLV in the DOH.
[0448] In the case of transmitting data based on the APN6 protocol, in a possible implementation, the actual sequential position, forwarding proof, and vector commitment of the key nodes are carried by the APN packet header. For example, the actual sequential position, forwarding proof, and vector commitment of the key nodes are carried by the application-aware network identifier (APN ID) in the APN packet header. In the case of transmitting data based on the VxLAN protocol, in a possible implementation, the actual sequential position, forwarding proof, and vector commitment of the key nodes are carried by the VxLAN header, so as to be applicable to scenarios such as virtualized networks based on the VxLAN protocol or cross-data center interconnection, and provide the function of verifying the data source in the VxLAN tunnel. In the case of transmitting data based on the IPSec protocol, in a possible implementation, the actual sequential position, forwarding proof, and vector commitment of the key nodes are carried by the IPSec header, so as to be able to verify the data source and perform secure transmission 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 provides the ability to verify the data source in the IPSec tunnel. In the case of transmitting data based on the MPLS protocol, in a possible implementation, the actual sequential position, forwarding proof, and vector commitment of the key nodes are carried by the MPLS header. For example, the forwarding path includes, for example, a label switching path, and the nodes in the forwarding path are node_1, node_2...
[0449] Each node in Node_N includes the LSR in the label switching path, so as to realize the verification of the data source and secure transmission under the MPLS protocol. This method is applicable to 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 data source in the MPLS network. In the case of transmitting data based on the SFC protocol, in a possible implementation manner, the forwarding proof is carried by NSH. For example, the actual sequential position of the key node, the forwarding proof, and the vector commitment are carried in the metadata field of the NSH.
[0450] In a possible implementation manner, the actual sequential position of the key node, the forwarding proof, and the vector commitment are carried in different fields of the same packet header.
[0451] Exemplarily, the data packet _i + 1 includes an IPv6 extension header, and the IPv6 extension header includes the forwarding proof of the forwarding node _i and the vector commitment. For example, the IPv6 extension header of the data packet _i + 1 includes an SRH, and the SRH includes a first TLV, a second TLV, and a third TLV. The first TLV of the SRH includes the forwarding proof of the forwarding node _i, and the second TLV of the SRH includes the vector commitment. The third TLV of the SRH includes the actual sequential position of the key node; or, the IPv6 extension header of the data packet _i + 1 includes an APN packet header, and the APN packet header includes an APN ID, and the APN ID includes the forwarding proof of the forwarding node _i and the vector commitment; or, the IPv6 extension header of the data packet _i + 1 includes a DOH, and the DOH includes a first TLV, a second TLV, and a third TLV. The first TLV of the DOH includes the forwarding proof of the forwarding node _i, the second TLV of the DOH includes the vector commitment, and the third TLV of the DOH includes the actual sequential position of the key node; or, the IPv6 extension header of the data packet _i + 1 includes an HBH, and 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.
[0452] Exemplarily, data packet _i+1 includes NSH, the NSH includes a metadata field, and the metadata field includes the forwarding proof of forwarding node _i and the vector commitment; alternatively, data packet _i+1 includes an MPLS header, and the MPLS header includes the forwarding proof of forwarding node _i and the vector commitment; alternatively, data packet _i+1 includes a VxLAN header, and the VxLAN header includes the forwarding proof of forwarding node _i and the vector commitment; alternatively, data packet _i+1 includes an IPsec header, and the IPsec header includes the forwarding proof of forwarding node _i and the vector commitment.
[0453] By placing the forwarding proof and the vector commitment in the same packet header, it helps to simplify the format and structure of the packet. This eliminates the need for an additional header to separately carry the forwarding proof and the vector commitment, reducing the complexity and redundancy of the packet. In addition, placing the forwarding proof and the vector commitment in the same packet header can simplify the processing logic of the node for the packet. For example, after receiving data packet _i+1, node _i only needs to parse the packet header once to obtain the forwarding proof and the vector commitment information. In this way, the processing logic of node _i is clearer and more concise, reducing the complexity during the processing.
[0454] In some embodiments, after each key node calculates the forwarding proof, it uses the forwarding proof calculated by this node to replace the forwarding proof carried in the packet header of the data packet. For example, key node B receives data packet A carrying forwarding proof A. After key node B calculates forwarding proof B, it uses forwarding proof B to replace forwarding proof A carried in data packet A to obtain data packet B. Data packet B does not include forwarding proof A but includes forwarding proof B. Similarly, key node C receives data packet B carrying forwarding proof B. After key node C calculates forwarding proof C, it uses forwarding proof C to replace forwarding proof B carried in data packet A to obtain data packet C. Data packet C does not include forwarding proof B but includes forwarding proof C. By each key node replacing the forwarding proof calculated by the previous node, the data packet only needs to carry one forwarding proof, avoiding the situation where the data packet has a large data volume due to the need to carry the forwarding proofs of each key node passed along the way, which helps to save the transmission overhead of the data packet and the occupied bandwidth resources.
[0455] 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.
[0456] 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.
[0457] 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.
[0458] 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.
[0459] 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 BGPflow 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).
[0460] In some embodiments, the announcement message is an application layer protocol message. The announcement message includes a Hypertext Transfer Protocol (HTTP) message, and the payload field in the HTTP message includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path.
[0461] In some embodiments, the first forwarding node is the last critical node in the expected forwarding path, and the second forwarding node includes all critical nodes other than the first forwarding node in the expected forwarding path.
[0462] The embodiments of the present application provide three verification modes for the forwarding proof. The determination method and transmission method of the forwarding proof are different under different verification modes. The determination method and transmission method of the forwarding proof will be further illustrated with examples in combination with the three verification modes. Among them, the real-time verification mode and the along-path verification mode are further divided into two sub-modes: single-point and multi-point. The end-point verification mode does not have a single-point mode but has a multi-point mode.
[0463] Verification Mode 1, Real-time Verification (Postcard) Mode
[0464] The "real-time" in real-time verification means that the time point for verifying the forwarding proof is real-time relative to the time point when the data message is received. In the real-time verification mode, when each critical node in the actual forwarding path processes the data message, the critical node calculates a forwarding proof and sends the forwarding proof to the verification node in an out-of-band manner, that is, it does not send the single-point forwarding proof along the actual forwarding path of the service data itself. The verification node deployed outside the actual forwarding path verifies the forwarding proof in real-time, and the critical node does not need to verify the forwarding proof.
[0465] The real-time 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). In the case of adopting the verification mode for single-point proof in the real-time verification mode, each critical node calculates the single-point forwarding proof of its own node and sends the single-point forwarding proof. When calculating the single-point forwarding proof, the identity information of the previous critical node or multiple upstream critical nodes is not required. In the case of adopting the verification mode for multi-point proof in the real-time verification mode, each critical node obtains the identity information of upstream critical nodes r_1 to r_i-1 through pre-distribution on the control plane, in the data message carrying the service data, or other means.
[0466] 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 sequential positions used by both are the sequential positions in the expected forwarding path, such as 1, 2, 3, 4, and the sequential positions used by both are not the sequential positions in the actual forwarding path. The sequential 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 sequential position of the key node in the actual forwarding path is used for evidence storage.
[0467] In some embodiments, in the case of adopting the real - time verification mode, regardless of whether the verification mode for single - point proof or the verification mode for multi - point proof is adopted, the key node sends the sequential position of this node in the actual forwarding path to the verification node to achieve the recordability of non - key nodes.
[0468] For example, please refer to Figure 3 , Figure 3 which shows the architecture diagram of a trusted path network system provided by an embodiment of the present application. Figure 3 The shown system 10 includes a controller, key nodes, and verification nodes. Figure 3 In the shown system 10, the expected forwarding path passes through four key nodes. Key node 1 is the head node, key node 4 is the tail node, and key nodes 2 and 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 Figure 3 controller in Figure 3 . Optionally,
[0469] In the process of key node 1 performing data transmission, when key node 1 is a key node, key node 1 constructs a new data packet based on the payload data. The packet header of the data packet carries a trusted path identifier and path information. The path information carries the identity information of each key node in the expected forwarding path. The payload field of the data packet carries the payload data. Key node 1 calculates the single - point forwarding proof OP_1 of this node using the open function; or key node 1 calculates the multi - point forwarding proof MP_1 of this node using the batchopen function; 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 together to a verification node outside the actual forwarding path, and key node 1 forwards the data packet to the second key node.
[0470] During the process of data transmission at the i-th critical node, the i-th critical node receives the data packet _i from the previous critical node. The header of the data packet _i carries a trusted path identifier and path information. The i-th critical node verifies the correctness of the source of the data packet _i. If the source verification of the data packet _i passes, the i-th critical node calculates the forwarding proof of this node; moreover, the i-th critical node obtains the sequential position of this node in the actual forwarding path; the i-th critical node sends the sequential position of this node in the actual forwarding path and the forwarding proof of this node together to the verification node located outside the actual forwarding path, and the i-th critical node forwards the data packet to the next critical node i + 1. In addition, if the source verification of the data packet _i fails, the i-th critical node does not need to calculate the forwarding proof and discards the data packet _i.
[0471] During the process of real-time verification at the verification node, the verification node receives the forwarding proof from the i-th critical node and verifies the forwarding proof of the i-th critical node based on the vector commitment.
[0472] In the case of using a single-point forwarding proof, during the process of calculating the forwarding proof, the i-th critical node uses the identity information r_i of this node and the sequential position i of this node in the expected forwarding path as inputs to calculate a single-point forwarding proof OP_i; the i-th critical node sends the single-point forwarding proof OP_i and the sequential position of this node in the actual forwarding path together 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 critical node, the sequential position i of the i-th critical node in the expected forwarding path, and the single-point forwarding proof OP_i calculated by the i-th critical node, that is, verifies that the identity information of the node at the sequential position i 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 critical node, and OP_i represents the single-point forwarding proof calculated by the i-th critical node.
[0473] In the case of adopting multi-point forwarding proof, during the process of calculating the forwarding proof, 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 inputs 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 this node in the actual forwarding path to a verification node located outside the actual forwarding path. The verification node, based on the input vector commitment \(C\), the identity information \(r_1\) to \(r_i\) of each key node from the 1st key node to the \(i\)-th key node, the sequential position \(i\) of each key node from the 1st 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, executes the batch verification function \(batch verify(C,B,r_B,MP_i)\) in the vector commitment mechanism, where \(B=(r_1,r_2,\cdots,r_i)\). Here, \(C\) represents the vector commitment, \(r_B\) represents the set composed of the identity information of each node from the 1st key node \(r_1\) to this node \(r_i\), \(B\) represents the set composed of the sequential positions of each node from the 1st 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.
[0474] Exemplarily, in the case of adopting the real-time verification mode, regardless of whether the verification mode for single-point proof or the verification mode for multi-point proof is adopted, during the process of transmitting service data, the key node additionally constructs a separate data packet, which is used to carry the actual sequential position of this node and the forwarding proof of this node, and this data packet does not need to carry service data. The key node sends out this data packet. For example, when the service data is transmitted to the \(i\)-th key node, the data packet sent out by the \(i\)-th key node contains the following content.
[0475] Actual serial number of key node r_i Single-point forwarding proof OP_i or multi-point forwarding proof MP_i
[0476] In the real-time verification mode provided in this embodiment, since each key node passed by during the actual transmission process of the data packet calculates the forwarding proof of this node and sends the forwarding proof of this node externally, the identity and sequential position of each key node actually passed by the data packet can be verified, so the security can be guaranteed hop by hop. In addition, since any key node can calculate the forwarding proof and send the forwarding proof after receiving the data packet, the observer can obtain and verify the forwarding proof in real time. Compared with the end-point verification mode, there is no need to wait until the data packet is transmitted to the last key node for verification, realizing real-time and transparent tracking of the data transmission process, and the attack window is small. In addition, since the forwarding proof and the sequential position in the actual forwarding path are both sent to the external verification node (observer), public auditing 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.
[0477] Verification mode 2, Passport mode
[0478] In the Passport mode, when each key node i in the actual forwarding path processes the data packet, the key node i calculates the forwarding proof p_i of this node and adds the forwarding proof to the data packet passed along the way. The key node i sends the data packet_i+1, and the data packet_i+1 includes the forwarding proof p_i. Since the sent data packet carries the forwarding proof, the forwarding proof is forwarded along with the data packet to the next key node i+1 for the next key node to verify the forwarding proof p_i. Moreover, each key node i also serves as an observer. Before calculating its own forwarding proof p_i, the key node i verifies the forwarding proof p_i-1 of the previous key node i-1, thereby reducing the risk of incorrect data packet sources. The forwarding proof p_i is, for example, a single-point proof OP or a multi-point proof MP.
[0479] The Passport 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).
[0480] In the case of adopting the verification mode for single-point proof in the Passport mode, each key node calculates the single-point forwarding proof OP_i of this node and adds the single-point forwarding proof OP_i to the data packet, so that the single-point forwarding proof OP_i and the service 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.
[0481] In the case of the verification mode for multi-point proof in the in-band verification mode, each key node learns the identity information of the first key node r_1 to the previous key node r_i-1 through control plane pre-distribution, within the data packet carrying service 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 positions 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 service data are transmitted to the next key node together.
[0482] Optionally, in the case of adopting the in-band 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 a list of actual sequential positions to the data packet, and each key node i adds the sequential position of this node in the actual forwarding path to the list of actual sequential positions carried in the data packet, so as to record the actual sequential positions of each key node in the first half of the path that the data packet has passed through.
[0483] For example, please refer to Figure 4 , Figure 4 in which the forwarding node_2, forwarding node_3, and key node 4 are all verification nodes. The forwarding node_2 verifies the forwarding proof p_1 of the key node 1. The forwarding node_3 verifies the forwarding proof p_2 of the forwarding node_2. The key node 4 verifies Figure 3 the forwarding proof p_3 of the forwarding node_3 in
[0484] During the process of data transmission by the key node 1, when the key node 1 is a key node, the key node 1 uses the open function to calculate the single-point forwarding proof OP_1 of this node; alternatively, the key node 1 uses the batchopen function to calculate the multi-point forwarding proof MP_1 of this node; the key node 1 obtains the sequential position of this node in the actual forwarding path; the key node 1 constructs a new data packet based on the vector commitment, payload data, the forwarding proof of the key node 1, and the sequential position of the key node 1 in the actual forwarding path. The header of the data packet carries the trusted path identifier, vector commitment, the forwarding proof of the key node 1, path information, and the list of actual sequential positions. The path information carries the identity information of each key node in the expected forwarding path. The payload field of the data packet carries the payload data. The list of actual sequential positions includes the sequential position of the key node 1 in the actual forwarding path.
[0485] During the process of the i-th critical node performing data transmission, the i-th critical node receives the data packet_i from the (i - 1)-th critical node. The header of the data packet_i carries a trusted path identifier, path information, and the forwarding proof of the (i - 1)-th critical node. The path information carries the identity information of each critical node in the expected forwarding path. The i-th critical node verifies the forwarding proof of the (i - 1)-th critical node carried in the data packet. If the verification of the forwarding proof of the (i - 1)-th critical node passes, the source verification of the data packet_i passes. The i-th critical node calculates a forwarding proof and uses the forwarding proof calculated by this node to replace the forwarding proof of the previous critical node carried in the header of the data packet_i. In addition, the i-th critical node adds the sequential position of this node in the actual forwarding path to the list of actual sequential positions carried in the data packet_i, thereby obtaining the data packet_i+1. The data packet_i+1 carries the payload data in the data packet_i, the list of actual sequential positions, and the forwarding proof of the i-th critical node. The i-th critical node forwards the data packet to the (i + 1)-th critical node. In addition, if the verification of the forwarding proof of the (i - 1)-th critical node fails, the i-th critical node does not need to calculate a forwarding proof and discards the data packet_i.
[0486] In the case of adopting a single-point forwarding proof, during the process of verifying the forwarding proof of the previous critical node, the i-th critical node verifies the single-point forwarding proof OP_i-1 of the (i - 1)-th critical node carried in the header of the data packet based on the identity information of the (i - 1)-th critical node and the sequential position of the (i - 1)-th critical node in the expected forwarding path; during the process of calculating the forwarding proof of this node, the i-th critical node uses the public identity r_i of this node and the sequential position i of this node in the expected forwarding path as inputs to calculate a single-point forwarding proof OP_i; the i-th critical node uses the single-point forwarding proof OP_i to replace the single-point forwarding proof OP_i-1 of the previous critical node carried in the header of the data packet_i.
[0487] In the case of adopting multi-point forwarding proof, optionally, the data packet _i further includes the sequential positions of each key node from the 1st key node to the i-th key node in the actual forwarding path. During the process of verifying the forwarding proof of the upper half of the path, the i-th key node verifies the multi-point forwarding proof MP_i-1 of the (i-1)-th key node carried in the data packet based on the identity information of each key node from the 1st key node to the (i-1)-th key node and the sequential positions of each key node from the 1st key node to the (i-1)-th key node in the expected forwarding path. During the process of calculating the forwarding proof of the current node, the i-th key node uses the identity information of each node from the 1st key node r_1 to the current node r_i and the sequential positions of each node from the 1st key node r_1 to the current node r_i in the expected forwarding path as inputs 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 packet header of the data packet _i.
[0488] When adopting the in-path verification mode, the sequential positions used by the key node when determining the forwarding proof and verifying the forwarding proof of the previous key node are both the sequential positions in the expected forwarding path, such as 1, 2, 3, 4, and the sequential positions used are not the sequential positions in the actual forwarding path. The sequential 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, and the sequential position of the key node in the actual forwarding path is used for evidence storage.
[0489] Exemplarily, in the case of adopting the in-path verification mode, whether adopting the verification mode for single-point proof or the verification mode for multi-point proof, during the process of transmitting service data, the key node adds the actual sequential position of the current node and the forwarding proof of the current node to the data packet, and sends the data packet including the service data, the actual sequential position of the current node and the forwarding proof of the current node to the next key node, so that the actual sequential position of the current node and the forwarding proof of the current node are transmitted along the forwarding path together with the service data. For example, when the service data is transmitted to the i-th key node, the data packet sent by the i-th key node to the next key node contains the following content. For example, the packet header of the data packet is used to carry the following actual sequence number and forwarding proof.
[0490] Actual serial number of key node r_1 … Actual serial number of key node r_i-1 Single-point forwarding proof OP_i or multi-point forwarding proof MP_i
[0491] In the in-path verification mode provided in this embodiment, since each key node passed by during the actual transmission process of the data packet calculates the forwarding proof of this node and verifies the forwarding proof of the previous key node, the identity and sequential position of each key node actually passed by the data packet are verified, so the security can be guaranteed hop by hop. In addition, since the forwarding proof is incorporated into the packet header of the service data packet in-path, compared with constructing a separate data packet 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.
[0492] Furthermore, by having each key node 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.
[0493] First, the probability of deception and tampering is further reduced. 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 deceptive, the subsequent key nodes can immediately stop forwarding, thereby reducing the probability that any node in the forwarding path disguises, deceives, or tampers with the data packet, and improving the security of the network.
[0494] Second, the integrity of the verification path. Since the single-point forwarding proof of each key node in each hop is verified by the next hop, the risk of omitting the verification of the proof of a certain node in the forwarding path is reduced, and it is possible to gradually verify that each node in the entire forwarding path is in the correct position, with almost no jumps or interruptions.
[0495] Third, privacy protection: Since the identity information and relative position of other nodes outside the previous key node are not required when verifying 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, rather than to other key nodes outside the next key node, thereby protecting the privacy of the key nodes to a certain extent and reducing the risk of leakage of identity information and relative position.
[0496] Fourth, it is possible to verify the correct position of the key node. 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 packet in the expected sequential position.
[0497] Furthermore, by having each key node in each hop responsible for verifying the multi-point forwarding proof of the key nodes in the first half, the benefits achieved include but are not limited to the following aspects.
[0498] First, efficiency improvement: Compared with verifying the single-point forwarding proof for each node separately, the multi-point forwarding proof can verify the forwarding proofs of multiple key nodes at once. By leveraging the advantage of batch processing, it improves the overall verification performance of the forwarding path, saving the time for calculating and verifying the proofs.
[0499] Second, reduction in the number of verifications: By verifying the forwarding proofs of multiple key nodes, the actual number of verifications can be reduced. For example, for m key nodes on the forwarding path, m verifications are required when verifying the single-point forwarding proof for each key node; while by verifying the multi-point forwarding proof related to m nodes, m key nodes can be verified at once, and the number of verifications can be reduced to 1, thus reducing the overall number of verifications required for the forwarding path and accelerating the verification speed.
[0500] Third, better scalability: Since the multi-point forwarding proof method hardly linearly increases the time cost of calculating and verifying the proofs as the number of nodes in the forwarding path increases compared to the single-point forwarding proof method, even if the forwarding path contains more key nodes to be verified, it hardly causes a significant increase in the verification cost. Because the verification process has the efficiency advantage of batch processing, the overall performance can still remain at a high level.
[0501] Fourth, integrating the verification results of multiple key nodes. Similar to the effect of the single-point forwarding proof, the verification results of multiple key nodes on the forwarding path can be integrated, enabling the verification scope to cover the positions and identities of each key node on the entire forwarding path, thereby comprehensively verifying the entire forwarding path.
[0502] Verification mode three, final_only mode
[0503] In the final_only mode, the tail node in the forwarding path also acts as an observer. The tail node obtains the forwarding proof based on the relative positions 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 , Figure 5 which is a schematic diagram of the verification scenario of the forwarding proof in the final_only mode provided by an embodiment of this application. Figure 5 The scenario shown takes the forwarding path including 4 forwarding nodes as an example for illustration. Figure 5 The key node 4 in [[ ]] is a specific example of the tail node acting as the 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 then the second forwarding node in the forwarding path (such as the node_2 in [[ ]]) acts as the verification node. Or, the number of forwarding nodes in the forwarding path is dozens or hundreds, or even more. Figure 5
[0504] During the process of data transmission at Key Node 1, when Key Node 1 is a key node, Key Node 1 constructs a new data packet based on the vector commitment, payload data, and the sequential position of Key Node 1 in the actual forwarding path. The packet header of the data packet carries a trusted path identifier, a vector commitment, path information, and a list of actual sequential positions. The payload field of the data packet carries the payload data. The list of actual sequential positions includes the sequential position of Key Node 1 in the actual forwarding path.
[0505] During the process of data transmission at the i-th key node as an intermediate node, the i-th key node does not need to perform the calculation process and verification process of the forwarding proof. The i-th key node verifies the source of the data packet by other means than verifying the forwarding proof. The i-th key node adds the sequential position of this node in the actual forwarding path to the list of actual sequential positions carried by Data Packet _i, and records the actual sequential position of this node by maintaining the list of actual sequential positions.
[0506] The last key node (tail node) receives Data Packet _N. Data Packet _N contains a packet header that carries 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. During 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. During 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). According to the vector commitment mechanism, the last key node uses the batch verify function to verify the multi-point forwarding proof MP_N based on the vector commitment C, the sequential position of each key node in the expected forwarding path in the path information P, and the identity information of each node in the path information P, performing batch verify(C, MP_N, P), that is, verifying 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 list of actual sequential positions from Data Packet _N.
[0507] Exemplarily, in the case of adopting the end - point verification mode, whether it is the verification mode for single - point proof or the verification mode for multi - point proof, since each key node adds its actual sequential position in the data packet carrying the service data, the data packet not only carries the service data but also additionally carries the actual sequential position of each key node that the data packet has passed through. Exemplarily, when the data packet is transmitted to the i - th key node, in addition to the service data, the data packet also includes the following content.
[0508] Actual serial number of key node r_1 … Actual serial number of key node r_i-1
[0509] In the end - point verification mode provided by this embodiment, since each key node in the forwarding path except the tail node does not need to calculate the forwarding proof and verify the forwarding proof, and only the tail node calculates the forwarding proof and the verification of the forwarding proof at one time, the overall overhead of all key nodes in the forwarding path is relatively small.
[0510] In addition, since each hop node in the forwarding path does not need to send the forwarding proof to the verification node, it saves the overhead of generating and transmitting packets caused by the forwarding node for sending the forwarding proof, and also saves the bandwidth occupied when the forwarding proof is transmitted in the network.
[0511] Using the identity information and relative positions of each key node in the forwarding path for verification is only an example. In some other implementation manners of this application, it supports tracing and verifying key nodes within a certain range before this key node on the forwarding path. The verifier can flexibly specify the required tracing range according to actual needs, and different key nodes can be responsible for verifying different parts of the forwarding path, thus providing a more flexible and adjustable tracing ability. Here, an example of verifying two hops or three key nodes before the forwarding key node is used for illustration.
[0512] In another possible implementation manner, the key node i verifies the forwarding proof based on the vector commitment, the identity information of the two key nodes before the key node i in the forwarding path, and the relative positions of the two key nodes before the key node i, so as to support tracing and verifying the correctness of the two key nodes before this key node. For example, the third key node verifies the forwarding proof received by the third key node based on the vector commitment, the identity information of the first key node, the relative position of the first key node, the identity information of the second key node, and the relative position of the second key node; the fifth key node verifies the forwarding proof received by the fifth key node based on the vector commitment, the identity information of the third key node, the relative position of the third key node, the identity information of the fourth key node, and the relative position of the fourth key node.
[0513] In another possible implementation, the key node i verifies the forwarding proof based on the identity information of the three key nodes before the key node i in the forwarding path, the relative positions of the three key nodes before the key node i, and the vector commitment, so as to support tracing and verifying the correctness of the three key nodes before this key node. For example, the fourth key node verifies the forwarding proof received by the fourth key node based on the identity information of the first key node, the relative position of the first key node, the identity information of the second key node, the relative position of the second key node, the identity information of the third key node, the relative position of the third key node, and the vector commitment; the seventh key node verifies the forwarding proof received by the seventh key node based on the identity information of the fourth key node, the relative position of the fourth key node, the identity information of the fifth key node, the relative position of the fifth key node, the identity information of the sixth key node, the relative position of the sixth key node, and the vector commitment.
[0514] In one possible implementation, in response to determining that the forwarding proof carried by the data packet fails the verification, the key node discards the received data packet. By discarding the data packet whose forwarding proof fails the verification, it helps to block the further transmission of data with illegal sources and improve network security. Specifically, if the key node finds that the forwarding proof carried by the data packet fails the verification, it means that there may be a problem with the source of the data. For example, the data packet may have skipped nodes in the path or passed through redundant unspecified nodes before being forwarded to this node. The key node discards the data packet, thus preventing the data packet with a problem in the data source from being further transmitted from this node to the next node, quickly blocking the further spread of the data packet with a problem in the data source, reducing the probability of unauthorized data access and tampering, and reducing the possibility of network attacks, thereby improving network security.
[0515] In a possible implementation, in response to determining that the forwarding proof carried in the data packet fails the verification, the key node outputs an alarm message, which is used to indicate that the forwarding proof fails the verification. In a 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 (NETCONF) message to the controller. The NETCONF message carries the alarm message, and the NETCONF message indicates that the forwarding proof fails the verification. Another example is that 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 the verification. Another example is that the key node sends an alarm message indicating that the forwarding proof fails the verification to the controller based on telemetry. Another example is that the key node sends an alarm message indicating that the forwarding proof fails the verification to the controller based on the Representational State Transfer (RESTful) principle. Another example is that the key node sends the information indicating that the forwarding proof fails the verification 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) message to the controller. The Syslog message carries the alarm message indicating that the forwarding proof fails the verification. Syslog is a standard UNIX system log management protocol used to send log information generated by devices or applications to a remote server. In a possible implementation, the key node outputs the alarm message in the form of an alarm notification. The alarm notification can be sent via text message, email, instant messaging tool, etc., so that the administrator or the 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 log recording. For example, the key node_i records the information of the data packet_i with verification failure into the system log. In yet another possible implementation, the key node_i sends the alarm message to the controller. The controller provides a visual display of the alarm message so that the administrator can quickly discover the problem and take measures.
[0516] In a possible implementation, in response to determining that the forwarding proof passes the verification, the key node further forwards the received data packet.
[0517] The KZG polynomial commitment is only one possible implementation of obtaining vector commitments. It can not only achieve the effects of forwarding proof and position binding, but also has the advantage of high efficiency. Vector commitments obtained through other methods can also achieve the effects of forwarding proof and sequential binding.
[0518] In some other possible implementations, the fast reed-solomon interactive (FRI) commitment method is adopted to obtain and verify commitments based on the identity information of key nodes and the relative positions of key nodes. The FRI commitment is a commitment mechanism used to verify the integrity of polynomials in an interactive proof system. It can quickly verify whether a polynomial satisfies a set of constraints without computing the entire polynomial term by term. The FRI commitment is based on Reed-Solomon coding and an interactive proof protocol. By constructing multiple small-scale Reed-Solomon codings and related proofs, the complexity of verifying polynomials is greatly reduced.
[0519] In some other possible implementations, the succinct non-interactive argument of knowledge (SNARK) commitment method is adopted to obtain and verify commitments based on the identity information of key nodes and the relative positions of key nodes. The SNARK commitment is a protocol used to prove the correctness of a computation and that the input possessed by a party satisfies specific conditions. The SNARK proof is non-interactive, that is, the prover does not need to interact with the verifier, but only needs to generate a proof and send it to the verifier. The SNARK proof has compactness, the size of the proof is very small, and the verification time is relatively short.
[0520] In some other possible implementation manners, 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 adopted to obtain a forwarding proof or a vector commitment; or the STARK commitment method is adopted to verify the forwarding proof based on the vector commitment. STARK belongs to a zero-knowledge proof technology. STARK does not require a trusted third-party setup to start, so it is more decentralized and distributed, reducing the impact of a single point of failure on obtaining the forwarding proof or the vector commitment, and also has high security. In addition, STARK is post-quantum secure, so adopting STARK helps to improve the ability of the forwarding proof to resist quantum computing attacks and is more reliable in protecting the security of the forwarding proof and the identity information. In addition, the data volume of the forwarding proof generated based on STARK is relatively small, which means that the proof can be transmitted with less storage space and also has an advantage in verification efficiency. For example, the next-hop key node or the verification node can verify the validity of the forwarding proof in a relatively short time.
[0521] In some other possible implementation manners, based on the identity information of the key nodes and the relative positions of the key nodes, the Bulletproof method is adopted to obtain a forwarding proof or a vector commitment; or the Bulletproof method is adopted to verify the forwarding proof based on ...
Claims
1. A method for obtaining a forwarding proof, characterized in that The method includes: The first forwarding node obtains a first data packet. At least two key nodes corresponding to the first data packet include the first forwarding node. The key node is a forwarding node passed through in the expected forwarding path determined by the path planner for the first data packet. The first forwarding node obtains the sequential position of the first forwarding node in the expected forwarding path and the identity information of the first forwarding node. The sequential position of the first forwarding node in the expected forwarding path is different from the sequential position of the first forwarding node in the actual forwarding path of the first data packet. The identity information of the first forwarding node indicates the identity of the first forwarding node. The first forwarding node obtains a forwarding proof of the first forwarding node based on the sequential position of the first forwarding node in the expected forwarding path and the identity information of the first forwarding node. The forwarding proof of the first forwarding node is used to prove that the first forwarding node forwards the first data packet at the sequential position in the expected forwarding path.
2. The method according to claim 1, wherein The at least two key nodes further include a second forwarding node. The second forwarding node is a key node located upstream of the first forwarding node in the expected forwarding path. The first forwarding node obtaining the forwarding proof of the first forwarding node based on the sequential position of the first forwarding node in the expected forwarding path and the identity information of the first forwarding node includes: The first forwarding node obtains the forwarding proof of the first forwarding node based on the sequential position of the first forwarding node in the expected forwarding path, the identity information of the first forwarding node, the sequential position of the second forwarding node in the expected forwarding path, and the identity information of the second forwarding node. The identity information of the second forwarding node indicates the identity of the second forwarding node. The forwarding proof of the first forwarding node is used to prove that the first forwarding node and the second forwarding node are respectively in the corresponding sequential positions in the expected forwarding path.
3. The method according to claim 2, characterized in that The first forwarding node is the last key node in the expected forwarding path. The second forwarding node includes all key nodes other than the first forwarding node in the expected forwarding path.
4. The method according to any one of claims 1 to 3, characterized in that, The method further includes: The first forwarding node obtains the sequential position of the first forwarding node in the actual forwarding path based on the first data packet. The first forwarding node sends the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path to a verification node.
5. The method according to claim 4, 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. The first forwarding node sending the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path to the verification node includes: The first forwarding node obtains a second data packet based on the first data packet, the forwarding proof of the first forwarding node, and the sequential position of the first forwarding node in the actual forwarding path. The second data packet includes the payload of the first data packet, the forwarding proof of the first forwarding node, and the sequential position of the first forwarding node in the actual forwarding path; The first forwarding node sends the second data packet to the third forwarding node.
6. The method according to claim 5, wherein The first data packet includes a first position list. The first position list includes the sequential positions of the key nodes upstream of the first forwarding node in the expected forwarding path in the actual forwarding path. The second data packet includes a second position list. The second position list includes the first position list and the sequential position of the first forwarding node in the actual forwarding path.
7. The method according to claim 5 or 6, characterized in that, The second data packet includes an Internet Protocol version 6 (IPv6) extension header. The IPv6 extension header includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path; or, The second data packet includes a Network Service Header (NSH). The NSH includes a metadata field. The metadata field includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path; or, The second data packet includes a Multiprotocol Label Switching (MPLS) header. The MPLS header includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path; or, The second data packet includes a Virtual Extensible LAN (VxLAN) header. The VxLAN header includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path; or, The second data packet includes an Internet Protocol Security (IPsec) header. The IPsec header includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path.
8. The method according to claim 7, wherein The IPv6 extension header includes a Segment Routing Header (SRH). The SRH includes a Type-Length-Value (TLV). The TLV of the SRH includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path; or, The IPv6 extension header includes an Application-Aware Networking (APN) header. The APN header includes an Application-Aware Networking Identifier (APN ID). The APN ID includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path; or, The IPv6 extension header includes a Destination Options Header (DOH). The DOH includes a TLV. The TLV of the DOH includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path; or, The IPv6 extension header includes a Hop-by-Hop Options header (HBH), the HBH includes TLVs, and the TLVs of the HBH include the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path.
9. The method according to claim 4, wherein The first forwarding node sending the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path to the verification node includes: The first forwarding node generates an advertisement message, and the advertisement message includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path; The first forwarding node sends the advertisement message to the verification node.
10. The method according to claim 9, wherein The advertisement message includes a Network Configuration Protocol (NETCONF) message, and the NETCONF message includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path; or, The advertisement message includes a Hypertext Transfer Protocol (HTTP) message, and the payload field in the HTTP message includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path.
11. The method according to any one of claims 1 to 10, characterized in that, The first data packet includes a segment list, the segment list includes the segment identifier (SID) of the first forwarding node, and the first forwarding node obtaining the sequential position of the first forwarding node in the expected forwarding path includes: The first forwarding node obtains the sequential position of the first forwarding node in the expected forwarding path based on the sequential position of the SID of the first forwarding node in the segment list.
12. The method according to any one of claims 1 to 10, characterized in that The first data packet includes a path identifier, and the first forwarding node obtaining the sequential position of the first forwarding node in the expected forwarding path includes: The first forwarding node obtains the sequential position of the first forwarding node in the expected forwarding path based on the path identifier and the corresponding relationship saved by the first forwarding node, where the corresponding relationship includes the path identifier and the sequential position of the first forwarding node in the expected forwarding path.
13. The method according to any one of claims 1 to 10, characterized in that, Before the first forwarding node obtains the first data packet, the method further includes: The first forwarding node receives the sequential position of the first forwarding node in the expected forwarding path from the path planner.
14. The method according to any one of claims 1 to 13, characterized in that, The first forwarding node obtaining the first data packet includes: the first forwarding node receives the first data packet from a second forwarding node, the second forwarding node is a key node upstream of the first forwarding node in the forwarding path, and the first data packet includes the forwarding proof of the second forwarding node; The method further includes: the first forwarding node verifies the forwarding proof of the second forwarding node based on a first vector commitment, the identity information of the second forwarding node, and the sequential position of the second forwarding node in the expected forwarding path, where the first vector commitment indicates the correspondence between the sequential positions of at least two key nodes in the expected forwarding path and the identities of the at least two key nodes, and the at least two key nodes include the second forwarding node.
15. The method according to claim 1, characterized in that, The path planner is the source host that generates the payload data of the first data packet; or, the path planner is the first forwarding device in the expected forwarding path.
16. A verification method for forwarding proofs, characterized in that The method includes: The verification node obtains the forwarding proof of the first forwarding node, 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, where the first vector commitment indicates the correspondence between the sequential positions of at least two key nodes in the expected forwarding path and the identities of the at least two key nodes, the at least two key nodes include the first forwarding node, the identity information of the first forwarding node indicates the identity of the first forwarding node, and the forwarding proof of the first forwarding node is used to prove that the first forwarding node is in the sequential position of the first forwarding node in the expected forwarding path; The verification node verifies the forwarding proof of the first forwarding node based on the first vector commitment, the identity information of the first forwarding node, and the sequential position of the first forwarding node.
17. The method according to claim 16, wherein The at least two key nodes further include a second forwarding node, where the second forwarding node is a key node upstream of the first forwarding node in the expected forwarding path. 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 both the first forwarding node and the second forwarding node are in the corresponding sequential positions in the expected forwarding path.
18. The method according to claim 16 or 17, characterized in that, The verification node 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.
19. A verification method for forwarding proofs, characterized in that, The method further includes: The first forwarding node obtains a first data packet, and the first forwarding node is deployed at the boundary of the first autonomous system (AS). The first forwarding node obtains the forwarding proof of the verified AS based on the sequential position of the verified AS and the identity information of the verified AS, where the identity information of the verified AS indicates the identity of the verified AS. The first forwarding node verifies the forwarding proof of the verified AS based on a second vector commitment, the sequential position of the verified AS, and the identity information of the verified AS, where the second vector commitment indicates the correspondence between the identity information of each AS in the at least two ASs and the sequential position of each AS.
20. The method according to claim 19, wherein The verified AS includes at least one of the neighbor AS of the first AS, the first AS, or each AS from the source AS to the first AS. The neighbor AS includes the previous AS of the first AS in the actual forwarding path of the first data packet and / or the next AS of the first AS in the reachable path of the destination IP address of the first data packet. The source AS is the AS communicating with the source host, and the source host is the device generating the payload data of the first data packet.
21. The method according to claim 19 or 20, characterized in that, The sequential position of the verified AS includes the expected sequential position of the verified AS or the actual sequential position of the verified AS. The expected sequential position of the verified AS is used to indicate the sequential relationship between the verified AS and the ASs passed by the expected forwarding path of the first data packet, and the actual sequential position of the verified AS is used to indicate the sequential relationship between the verified AS and the ASs passed by the actual forwarding path of the first data packet.
22. The method according to claim 19, wherein The verified AS includes the 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.
23. The method according to claim 19, wherein The verified AS includes the first AS, and the first data packet carries the actual sequential position of the first AS.
24. The method according to claim 19, wherein The first data packet carries an AS list, and the AS list includes the identity information of each AS passed by the expected forwarding path of the first data packet. The expected sequential position of the verified AS is obtained based on the sequential position of the identity information of the verified AS in the AS list.
25. The method according to any one of claims 19 to 24, characterized in that The first data packet carries the second vector commitment.
26. The method according to claim 19, wherein The first data packet includes an Internet Protocol Version 6 (IPv6) extension header, and the IPv6 extension header carries the sequential position of the verified AS, the identity information of the verified AS, and the second vector commitment; or, The first data packet includes a Network Service Header (NSH), and the NSH includes a metadata field, and the metadata field carries the sequential position of the verified AS, the identity information of the verified AS, and the second vector commitment; or, The first data packet includes a Multi-Protocol Label Switching (MPLS) header, and the MPLS header carries the sequential position of the verified AS, the identity information of the verified AS, and the second vector commitment; or, The first data packet includes a Virtual eXtensible Local Area Network (VxLAN) header, and the VxLAN header carries the sequential position of the verified AS, the identity information of the verified AS, and the second vector commitment; or, The first data packet includes an Internet Protocol Security (IPsec) header, and the IPsec header carries the sequential position of the verified AS, the identity information of the verified AS, and the second vector commitment.
27. The method according to claim 19, wherein The destination IP address of the first data packet includes a first IP address. Before the first forwarding node obtains the first data packet, the method further includes: The first forwarding node receives a routing protocol packet from the verified AS, and the routing protocol packet carries the first IP address and the identity information of the verified AS; The first forwarding node saves a first correspondence relationship, and the first correspondence relationship includes the first IP address and the identity information of the verified AS; After the first forwarding node obtains the first data packet, the method further includes: The first forwarding node obtains the identity information of the verified AS based on the first IP address and the first correspondence relationship.
28. The method according to claim 19, wherein The first data packet carries a path identifier, and the path identifier is used to identify the expected forwarding path. Before the first forwarding node obtains the first data packet, the method further includes: The first forwarding node receives an advertisement packet from the path planner, and the advertisement packet carries the path identifier, the sequential position of the verified AS, and the identity information of the verified AS; The first forwarding node saves a second correspondence relationship, and the second correspondence 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 packet, the method further includes: The first forwarding node obtains the sequential position of the verified AS and the identity information of the verified AS based on the path identifier and the second correspondence relationship.
29. An apparatus for obtaining a forwarding proof, characterized in that The device is disposed in the first forwarding node, and the device includes: An obtaining unit, configured to obtain a first data packet. At least two key nodes corresponding to the first data packet include the first forwarding node, and the key nodes are forwarding nodes passed through in the expected forwarding path determined by the path planner for the first data packet; obtain the sequential position of the first forwarding node in the expected forwarding path and the identity information of the first forwarding node. The sequential position of the first forwarding node in the expected forwarding path is different from the sequential position of the first forwarding node in the actual forwarding path of the first data packet, and the identity information of the first forwarding node indicates the identity of the first forwarding node; A processing unit, configured to obtain a forwarding proof of the first forwarding node based on the sequential position of the first forwarding node in the expected forwarding path and the identity information of the first forwarding node. The forwarding proof of the first forwarding node is used to prove that the first forwarding node forwards the first data packet at the sequential position in the expected forwarding path.
30. The device according to claim 29, wherein The at least two key nodes further include a second forwarding node, which is a key node located upstream of the first forwarding node in the expected forwarding path. The first forwarding node obtains a forwarding proof of the first forwarding node based on the sequential position of the first forwarding node in the expected forwarding path and the identity information of the first forwarding node, including: The first forwarding node obtains a forwarding proof of the first forwarding node based on the sequential position of the first forwarding node in the expected forwarding path, the identity information of the first forwarding node, the sequential position of the second forwarding node in the expected forwarding path, and the identity information of the second forwarding node. The identity information of the second forwarding node indicates the identity of the second forwarding node. The forwarding proof of the first forwarding node is used to prove that the first forwarding node and the second forwarding node are respectively in the corresponding sequential positions in the expected forwarding path.
31. The device according to claim 30, characterized in that, The first forwarding node is the last key node in the expected forwarding path, and the second forwarding node includes all key nodes other than the first forwarding node in the expected forwarding path.
32. The device according to claim 31, characterized in that, The processing unit is further configured to obtain the sequential position of the first forwarding node in the actual forwarding path based on the first data packet. The apparatus further includes: a sending unit, configured to send the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path to a verification node.
33. The device according to claim 32, wherein The verification node includes a third forwarding node, which is a key node located downstream of the first forwarding node in the expected forwarding path. The processing unit is further configured to obtain a second data packet based on the first data packet, the forwarding proof of the first forwarding node, and the sequential position of the first forwarding node in the actual forwarding path. The second data packet includes the payload of the first data packet, the forwarding proof of the first forwarding node, and the sequential position of the first forwarding node in the actual forwarding path. The sending unit is configured to send the second data packet to the third forwarding node.
34. The apparatus according to claim 32, wherein The processing unit is further configured to generate an announcement packet, which includes the forwarding proof of the first forwarding node and the sequential position of the first forwarding node in the actual forwarding path. The sending unit is configured to send the announcement packet to a verification node.
35. The device according to any one of claims 31 to 34, characterized in that, The first data packet includes a segment list, and the segment list includes the segment identifier SID of the first forwarding node. The processing unit is configured to obtain the sequential position of the first forwarding node in the expected forwarding path based on the sequential position of the SID of the first forwarding node in the segment list.
36. The device according to any one of claims 31 to 35, characterized in that, The first data packet includes a path identifier, and the processing unit is configured to obtain the sequential position of the first forwarding node in the expected forwarding path based on the path identifier and the corresponding relationship saved by the first forwarding node, where the corresponding relationship includes the path identifier and the sequential position of the first forwarding node in the expected forwarding path.
37. The device according to any one of claims 29 to 36, characterized in that, The obtaining unit is configured to receive the first data packet from a second forwarding node, where the second forwarding node is a key node upstream of the first forwarding node in the forwarding path, and the first data packet includes a forwarding proof of the second forwarding node; The processing unit is further configured to verify the forwarding proof of the second forwarding node based on a first vector commitment, the identity information of the second forwarding node, and the sequential position of the second forwarding node in the expected forwarding path, where the first vector commitment indicates the corresponding relationship between the sequential positions of at least two key nodes in the expected forwarding path and the identities of the at least two key nodes, and the at least two key nodes include the second forwarding node.
38. A verification device for forwarding proofs, characterized in that The apparatus includes: An obtaining unit, configured to obtain a forwarding proof of the first forwarding node, a first vector commitment, identity information of the first forwarding node, and the sequential position of the first forwarding node in the expected forwarding path, where the first vector commitment indicates the corresponding relationship between the sequential positions of at least two key nodes in the expected forwarding path and the identities of the at least two key nodes, the at least two key nodes include the first forwarding node, the identity information of the first forwarding node indicates the identity of the first forwarding node, and the forwarding proof of the first forwarding node is used to prove that the first forwarding node is in the sequential position of the first forwarding node in the expected forwarding path; A verification unit, configured to verify the forwarding proof of the first forwarding node based on the first vector commitment, the identity information of the first forwarding node, and the sequential position of the first forwarding node.
39. The device according to claim 38, wherein, The at least two key nodes further include a second forwarding node, where the second forwarding node is a key node upstream of the first forwarding node in the expected forwarding path, and the verification unit is configured to verify the forwarding proof of the first forwarding node based on the first vector commitment, the sequential position of the first forwarding node in the expected forwarding path, the identity information of the first forwarding node, the sequential position of the second forwarding node in the expected forwarding path, and the identity information of the second forwarding node, where the identity information of the second forwarding node indicates the identity of the second forwarding node, and the forwarding proof of the first forwarding node is used to prove that both the first forwarding node and the second forwarding node are in the corresponding sequential positions in the expected forwarding path.
40. The device according to claim 38 or 39, characterized in that, The obtaining unit is configured to receive the forwarding proof of the first forwarding node from the first forwarding node.
41. A verification device for forwarding proofs, characterized in that, The apparatus is disposed at the first forwarding node, and the apparatus further includes: An obtaining unit, configured to obtain a first data packet, where the first forwarding node is deployed at the boundary of a first autonomous system (AS); A processing unit, configured to obtain a forwarding proof of the verified AS based on the sequential position of the verified AS and the identity information of the verified AS, where the identity information of the verified AS indicates the identity of the verified AS. The processing unit is further configured to verify the forwarding proof of the verified AS based on a second vector commitment, the sequential position of the verified AS, and the identity information of the verified AS, where the second vector commitment indicates the correspondence between the identity information of each AS in the at least two ASs and the sequential position of each AS.
42. The device according to claim 41, characterized in that, The verified AS includes a neighbor AS of the first AS. The first data packet carries the actual sequential position of the first AS. The actual sequential position of the verified AS is obtained by the processing unit based on the actual sequential position of the first AS and the sequential relationship between the first AS and the verified AS.
43. The device according to claim 41, characterized in that, The verified AS includes the first AS. The processing unit is configured to obtain the actual sequential position of the first AS carried in the first data packet.
44. The device according to claim 41, wherein The first data packet carries an AS list, where the AS list includes the identity information of each AS through which the expected forwarding path of the first data packet passes. The expected sequential position of the verified AS is obtained by the processing unit based on the sequential position of the verified AS in the AS list.
45. The device according to claim 41, characterized in that, The destination IP address of the first data packet includes a first IP address. The obtaining unit is further configured to receive a routing protocol packet from the verified AS, where the routing protocol packet carries the first IP address and the identity information of the verified AS. The processing unit is further configured to save a first correspondence, where the first correspondence includes the first IP address and the identity information of the verified AS. The obtaining unit is further configured to obtain the identity information of the verified AS based on the first IP address and the first correspondence.
46. The device according to claim 41, characterized in that, The first data packet carries a path identifier, where the path identifier is used to identify the expected forwarding path. The obtaining unit is further configured to receive an announcement packet from a path planner, where the announcement packet carries the path identifier, the sequential position of the verified AS, and the identity information of the verified AS. The processing unit is further configured to save a second correspondence, where the second correspondence includes the path identifier, the sequential position of the verified AS, and the identity information of the verified AS. The obtaining unit is further configured to obtain the sequential position of the verified AS and the identity information of the verified AS based on the path identifier and the second correspondence.
47. A forwarding device, characterized in that, The forwarding device includes: a processor, which is coupled to a memory. At least one computer program instruction is stored in the memory and is loaded and executed by the processor to enable the forwarding device to implement the method according to any one of claims 1-28.
48. A computer-readable storage medium, characterized in that, At least one instruction is stored in the storage medium, and when the instruction runs on a computer, the computer is caused to execute the method according to any one of claims 1-28.
49. A computer program product, characterized in that, The computer program product includes one or more computer program instructions, and when the computer program instructions are loaded and run by a computer, the computer is caused to execute the method according to any one of claims 1-28.
Citation Information
Cited By
Method and apparatus for acquiring forwarding proof, and method and apparatus for verifying forwarding proof
WO2025152913A1