Verification method, device and system for cross-domain segment routing

Abstract

The one or more embodiments of the specification provide a verification method, device and system for cross-domain segment routing. The method comprises: receiving a first data packet sent by a user equipment; performing first hash calculation on a segment routing header of the first data packet to obtain a data digest; matching the data digest with an authorization key recorded in a first field of the segment routing header; wherein the authorization key is pre-configured based on an authorized path of the user equipment; and if the matching is successful, determining that a forwarding path recorded in the segment routing header is the same as the authorized path of the user equipment in the segment routing network. The method realizes accurate verification of the forwarding path of the data packet in the cross-domain segment routing scenario, solves the defect that the prior art cannot verify the matching of the tenant authorized path, and provides basic security protection for cross-trustedomain data transmission.

Description

Technical Field

[0001] This specification relates to one or more embodiments in the field of network technology, and in particular to a verification method, apparatus and system for cross-domain segmented routing. Background Technology

[0002] In recent years, Segment Routing over IPv6 (SRv6) has been introduced into Software-Defined Wide Area Network (SD-WAN) architectures for control and forwarding logic, thereby enhancing the flexibility and accuracy of cross-regional traffic engineering. With the development of artificial intelligence, breaking through the trusted domain limitations of SRv6 will promote the evolution of new applications such as embodied intelligence, intelligent assistants, and AR / VR. However, extending SRv6 to the customer-controlled edge (e.g., Customer Premises Equipment (CPE)) introduces new security challenges due to the exposure of SRv6 functionality. In SRv6, each packet carries a segment list that encodes its forwarding path. When untrusted endpoints are allowed to build or modify this list, the source routing mechanism becomes an attack surface. In practice, this behavior allows malicious edge devices to bypass security features, hijack traffic, or gain unauthorized access to services.

[0003] The relevant path verification methods only confirm whether the data packets follow the expected forwarding path, but cannot detect unauthorized SRv6 behavior or access to policy-restricted service functions. Summary of the Invention

[0004] In view of the above, one or more embodiments of this specification provide the following technical solutions: According to a first aspect of one or more embodiments of this specification, a verification method for cross-domain segmented routing is proposed, applied to a first network node, the first network node being an edge routing device in a segmented routing network for receiving external data, the method comprising: Receive the first data packet sent by the user equipment; Perform a first hash calculation on the segmented routing header of the first data packet to obtain a data digest; The data digest is matched with the authorization key recorded in the first field of the segmented routing header; wherein the authorization key is pre-configured based on the authorized path of the user equipment. If a match is successful, it is determined that the forwarding path recorded in the segmented routing header is the same as the authorized path of the user equipment within the segmented routing network.

[0005] According to a second aspect of one or more embodiments of this specification, a verification method for cross-domain segmented routing is proposed, applied to a second network node, the second network node being an edge routing device of the segmented routing network used for forwarding data packets outwards, the method comprising: The second network node receives the second data packet, which is a data packet sent by the user equipment and then forwarded to the second network node after being verified by the first network node; The remaining number of segments in the forwarding path of the second data packet is compared with the value recorded in the second field of the segment routing header of the second data packet; if they are the same, it means that the second data packet is normal; if they are different, it means that the second data packet is abnormal.

[0006] According to a third aspect of one or more embodiments of this specification, a verification apparatus for cross-domain segmented routing is provided, comprising: The sampling module is used to receive the first data packet sent by the user equipment; The compression module is used to perform a first hash calculation on the segmented routing header of the first data packet to obtain a data digest; The verification module is used to match the data digest with the authorization key recorded in the first field of the segmented routing header; wherein the authorization key is pre-configured based on the authorized path of the user equipment; if the match is successful, it is determined that the forwarding path recorded in the segmented routing header is the same as the authorized path of the user equipment in the segmented routing network.

[0007] According to a fourth aspect of one or more embodiments of this specification, a verification apparatus for cross-domain segmented routing is provided, comprising: The receiving module is used to receive the second data packet; The filtering module is used to compare the number of remaining segments in the forwarding path of the second data packet with the value recorded in the second field of the segment routing header of the second data packet; if they are the same, it means that the second data packet is normal; if they are different, it means that the second data packet is abnormal.

[0008] According to a fifth aspect of one or more embodiments of this specification, a verification system for cross-domain segmented routing is proposed. The verification system includes a server, a first network node, and a second network node. The server is used to send verification-related configurations to the first network node and the second network node. The first network node is used to implement the verification method for cross-domain segmented routing described in the first aspect, and the second network node is used to implement the verification method for cross-domain segmented routing described in the second aspect.

[0009] In the above embodiments, by performing a first hash calculation on the segmented routing header of the first data packet at the entry node receiving external data to generate a data digest, and matching it with the authorization key configured based on the user equipment's authorized path, accurate verification of the forwarding path of the data packet is achieved in the cross-domain segmented routing scenario. This solves the defect of existing technologies that cannot verify the matching of tenant authorized paths and provides basic security for cross-trusted domain data transmission. Attached Figure Description

[0010] Figure 1 This is a schematic diagram of the architecture of a cross-domain segmented routing communication system provided in an exemplary embodiment.

[0011] Figure 2 This is one of the flowcharts illustrating a verification method for cross-domain segmented routing provided in an exemplary embodiment.

[0012] Figure 3 This is a schematic diagram of the structure of a segmented routing header provided in an exemplary embodiment.

[0013] Figure 4 This is a schematic diagram of a hash calculation based on SipHash provided in an exemplary embodiment.

[0014] Figure 5 This is a second flowchart illustrating an exemplary embodiment of a verification method for cross-domain segmented routing.

[0015] Figure 6 This is the third flowchart illustrating an exemplary embodiment of a verification method for cross-domain segmented routing.

[0016] Figure 7 This is a schematic diagram of an exemplary embodiment of a verification system for cross-domain segmented routing.

[0017] Figure 8 This is a schematic diagram of an exemplary embodiment of a verification method for cross-domain segmented routing.

[0018] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an exemplary embodiment.

[0019] Figure 10 This is one of the block diagrams of a verification device for cross-domain segmented routing provided in an exemplary embodiment.

[0020] Figure 11 This is a second block diagram of an exemplary embodiment of a verification device for cross-domain segmented routing. Detailed Implementation

[0021] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this manual are all information and data authorized by the user or fully authorized by all parties. The collection, use and processing of related data shall comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals shall be provided for users to choose to authorize or refuse.

[0022] In modern networks, deploying multiple data centers and branch offices across multiple geographical regions has become a standard solution. Traditional wide area networks (WANs) are based on static configurations and lack adaptability to dynamic needs. Software-defined wide area networks (SD-WANs), derived from software-defined networking (SDN), have gained significant attention as a solution to overcome these limitations. In recent years, segment routing over IPv6 (SRv6) has been introduced into SD-WAN architectures for control and forwarding logic, thereby enhancing the flexibility and accuracy of cross-regional traffic engineering.

[0023] Since the advent of IPv4, networks have encountered difficulties in attempting to operate beyond the trusted domain edge. This has prevented users from immediately enjoying the benefits of network improvements. With the development of artificial intelligence, breaking through the trusted domain limitations of SRv6 will promote the evolution of new applications such as embodied intelligence, intelligent assistants, and AR / VR. However, extending SRv6 to the customer-controlled edge (e.g., CPE) introduces new security challenges due to the exposure of SRv6 functionality. In SRv6, each packet carries a fragment list that encodes the segmented path it forwards. When untrusted endpoints are allowed to build or modify this list, the source routing mechanism becomes an attack surface. In practice, this behavior allows malicious edge devices to bypass security features, hijack traffic, or gain unauthorized access to services.

[0024] Related path verification methods only confirm whether packets follow the expected forwarding path, but cannot detect unauthorized SRv6 behavior or access to policy-restricted service functions. In SD-WAN, Virtual Private Networks (VPNs) are used to differentiate between different tenants, each of which is isolated and assigned an authorized path. Segment Routing Header (SRH) verification methods focus on verifying the correctness of the segment list, but cannot guarantee tenant identity.

[0025] In view of this, this specification proposes a verification method for cross-domain segmented routing. The server pre-assigns an authorization key to the user equipment based on its authorized path, enabling the user equipment to carry this authorization key in the data packets it sends. The ingress node of the segmented routing network (e.g., VPN) verifies the segmented routing header of the data packets received from the outside, calculates the corresponding data digest, and matches it with the authorization key. If a match is found, it indicates that the forwarding path recorded in the data packet is the user equipment's authorized path.

[0026] In implementation, the first network node (entry node) receives the first data packet sent by the user equipment to the segmented routing network; performs a first hash calculation on the segmented routing header of the first data packet to obtain a data digest; matches the data digest with the authorization key of the user equipment; and determines whether the forwarding path of the first data packet is the authorized path of the user equipment based on the matching result.

[0027] In the above technical solution, by performing a first hash calculation on the segmented routing header (SRH) of the first data packet in the ingress node to generate a data digest and matching it with the pre-configured authorization key, accurate verification of the forwarding path in the cross-domain segmented routing scenario is achieved, solving the defect of not being able to verify the matching of tenant authorization paths and providing basic security for cross-trusted domain data transmission.

[0028] To enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in this specification will be clearly and completely described below with reference to the accompanying drawings in the embodiments of this application.

[0029] Figure 1This is a schematic diagram of the architecture of a cross-domain segmented routing communication system provided in an exemplary embodiment. The communication system includes: user equipment 10, segmented routing network 20, core network 30, and server 40, etc. The segmented routing network 20 can be an SRv6-based trusted domain, such as a VPN used by the user equipment. The user equipment 10 can specifically be a CPE located outside the trusted domain. The user equipment 10 can forward its sent data packets to other user equipment or the core network 30 through the segmented routing network 20. The segmented routing network 20 can consist of multiple network nodes, specifically including: a first network node 21 for receiving external data and a second network node 22 for forwarding data to the outside world; the first network node 21 and the second network node 22 can be referred to as edge network nodes of the segmented routing network, such as routing devices located at the edge of the segmented routing network. Agents can be deployed on the edge network nodes (first network node 21 and second network node 22) of the segmented routing network. The server 40 can generate relevant configuration parameters based on the verification policy and sampling configuration set by the operator, and distribute them to the agents deployed on the first and second network nodes, which then execute the verification method based on the configuration parameters. Since other network nodes (such as intermediate routing devices) do not need to be aware of the verification method disclosed herein, there is no need to deploy an agent on other network nodes.

[0030] Please see Figure 2 , Figure 2 This is an exemplary embodiment of a verification method for cross-domain segmented routing, applied to a first network node, which is an edge routing device in a segmented routing network used to receive external data. The method includes the following steps: S201, Receive the first data packet sent by the user equipment.

[0031] In one implementation, the first network node, as the entry node of the segmented routing network, can receive the first data packet sent from a user equipment (such as a CPE) outside the trusted domain.

[0032] S202. Perform a first hash calculation on the segmented routing header of the first data packet to obtain a data digest.

[0033] In one implementation, after receiving the first data packet, the first network node can extract the segmented routing header of the first data packet and perform a first hash calculation on the segmented routing header to calculate a data digest.

[0034] In one implementation, the segmented routing header of the first data packet can be as follows: Figure 3 The variable-length SRH format shown is based on a traditional SRH extension: Traditional SRH may include the following fields: Next Header, Header Length, Routing Type, Left, Last Entry, Flags, Tag, and Segment List {segment[0], ..., segment[N]}; The newly added extended field (Type-Length-Value, TLV) may include: The type can be used to indicate the function of this extended field; Length can be used to indicate the length of this extended field; Tags; And the first field used to store the authorization key; The second field is used to represent the validation result (Pass).

[0035] In one implementation, the scope of the first hash calculation on the segmented routing header may include the entire variable-length SRH, or it may only be performed on the segment list field and extended field portion of the segmented routing header.

[0036] The first hash calculation scheme can be set according to actual needs, such as SipHash algorithm, BLAKE2B algorithm, Poly1305 algorithm, etc.

[0037] S203. Match the data digest with the authorization key recorded in the first field of the segmented routing header.

[0038] The authorization key can be pre-configured by the server based on the authorization path of the user's device.

[0039] In one implementation, the server can generate an authorization key based on the user device and the segmented routing network (such as a VPN) that provides services to it, and then distribute it to the user device.

[0040] For example, the server can generate a unique authorization key for each user device-segmented routing network pair (such as a CPE-VPN pair); For example, if a user equipment has multiple different authorized paths in a segmented routing network, the server can generate a unique authorization key for the user equipment-authorized path pair based on the different authorized paths.

[0041] In one implementation, the server can periodically update the authorization key, for example, by periodically updating the authorization key based on a preset time window (such as one day or half a day).

[0042] In one implementation, the server can generate the authorization key for the user device based on the authorization path of the user device through a first hash calculation, that is, obtain the authorization key corresponding to the authorization path.

[0043] In one implementation, when the user equipment sends the first data packet, it may record the authorization key in the first field of the extended field in the segmented routing header of the first data packet.

[0044] In one implementation, after performing a first hash calculation on the segmented routing header of the first data packet to obtain a data digest, the first network node can match the data digest with the authorization key extracted from the first field of the segmented routing header. For example, the data digest can be compared with the authorization key to determine whether they are the same, similar, or partially the same.

[0045] S204. If the match is successful, it is determined that the forwarding path recorded in the segmented routing header is the same as the authorized path of the user equipment in the segmented routing network.

[0046] In one implementation, based on the matching result between the calculated data digest and the extracted authorization key, it can be determined whether the forwarding path recorded in the segmented routing header is an authorized path for the user equipment within the segmented routing network. If the match is successful (for example, the data digest is the same as the authorization key), it can be determined that the forwarding path recorded in the segmented routing header is the authorized path of the user equipment in the segmented routing network, that is, the first data packet used the authorized path, and it can be determined that the verification is successful. If the match fails (e.g., the data digest is different from the authorization key), it can be determined that the forwarding path recorded in the segmented routing header is different from the authorized path of the user equipment in the segmented routing network. That is, the first data packet did not use the authorized path in the segmented routing network (e.g., an unauthorized path or an authorized path in another segmented routing network), which may be abnormal and can be judged as a verification failure.

[0047] For example, CPE1's authorized path in VPN1 is R1, and its authorized path in VPN2 is R2. The server can configure an authorization key Key1 for CPE1-VPN1 and an authorization key Key2 for CPE1-VPN2. If the first network node R1 in VPN1 receives a data packet P1 (including Key1 and the forwarding path R3) sent by CPE1, it performs a first hash calculation on the segmented routing header of P1 to obtain a data digest, and matches the data digest with Key1. If the match is successful, it can be determined that R3 is R1; if the match is unsuccessful, it means that R3 is different from R1, and may be an unauthorized path or R2.

[0048] In the above embodiments, by performing a first hash calculation on the segmented routing header of the first data packet at the entry node receiving external data to generate a data digest, and matching it with the authorization key configured based on the user equipment's authorized path, accurate verification of the forwarding path of the data packet is achieved in the cross-domain segmented routing scenario. This solves the defect of existing technologies that cannot verify the matching of tenant authorized paths and provides basic security for cross-trusted domain data transmission.

[0049] In one implementation, the first hash calculation uses a common hash function, such as MD5, SHA-1, SHA-256, etc.; or a key hash function, such as SipHash, HMAC, poly1305, etc. In the following embodiments, key hash functions are used as examples for illustration.

[0050] In one implementation, the server may pre-send configuration parameters required for executing the verification method to the agents deployed at each first network node. These configuration parameters may include an encoded key for hash calculation. Upon receiving the first data packet, the first network node may determine a hash key for the first hash calculation based on the pre-configured encoded key and time information associated with the first data packet. Then, based on this hash key, it performs a first hash calculation on the segmented routing header of the first data packet to obtain a data digest.

[0051] The time information associated with the first data packet can be used to indicate the time when the first data packet was received (i.e., the current time), or to indicate the time when the user equipment sent the first data packet, etc.

[0052] For example, the first network node can determine the hash key used for the first hash calculation based on a pre-configured encoding key and a first timestamp, wherein the first timestamp is used to indicate the first time window in which the first data packet is received.

[0053] In one implementation, the server can configure different encoding keys for different user devices.

[0054] In one implementation, the server can configure different encoding keys for different user equipment-segmented routing network pairs (such as CPE-VPN pairs).

[0055] In one implementation, the server can configure different encoding keys for the authorization paths of different user devices.

[0056] In one implementation, the server can periodically update the encoding key, for example, by periodically updating the encoding key based on a preset time window (such as one day or half a day).

[0057] In the above embodiments, by using a key hash function and combining it with the time information of the first data packet, the key for each hash calculation is dynamic, which effectively resists replay attacks, makes up for the risk that fixed keys are easily cracked, and further improves the security of cross-domain verification.

[0058] In one implementation, due to potential network delays and clock skew from the sending to the receiving of the first data packet, the authorization key recorded in the received first data packet may have expired (i.e., the time window corresponding to the authorization key is earlier than the time window in which the packet was received). Therefore, when performing the first hash calculation on the segmented routing header, two pieces of time information can be combined: a first timestamp and a second timestamp. The first timestamp represents the first time window in which the first data packet was received, and the second timestamp represents the time window preceding the first time window.

[0059] The first network node determines a first hash key based on the encoding key and a first timestamp; then, based on the first hash key, it performs a first hash calculation on the segmented routing header of the first data packet to obtain a first data digest; additionally, the first network node determines a second hash key based on the encoding key and a second timestamp; then, based on the second hash key, it performs a first hash calculation on the segmented routing network of the first data packet to obtain a second data digest; the first and second data digests are then matched with the authorization key recorded in the first field of the segmented routing header: if the authorization key carried by the first data packet matches the first or second data digest, it can be determined that the forwarding path recorded in the segmented routing header is an authorized path of the user equipment within the segmented routing network, that is, the first data packet used an authorized path, and the verification can be determined to be successful; if the authorization key carried by the first data packet fails to match both the first and second data digests, it can be determined that the forwarding path recorded in the segmented routing header is different from the authorized path of the user equipment within the segmented routing network, that is, the first data packet did not use an authorized path within the segmented routing network (e.g., an unauthorized path or an authorized path of another segmented routing network), which may be abnormal, and the verification can be determined to be unsuccessful.

[0060] In the above embodiments, by using a dual-window mechanism of a first time window and a second time window, corresponding hash keys are generated and two data digests are calculated to match the authorization key carried in the first data packet. This significantly improves the fault tolerance and reliability of cross-domain verification and avoids verification errors caused by network latency or device clock skew.

[0061] In one implementation, since the segmented routing header of the variable-length SRH format has an unfixed length, in order to improve the efficiency of the first hash calculation, the segmented routing header of the first data packet can be divided into several data segments; based on the hash key, the first hash calculation is performed on each data segment to obtain a hash value corresponding to each data segment; then the hash values ​​corresponding to several data segments are merged (e.g., bitwise XOR; merging, etc.) to obtain a data digest.

[0062] The method for dividing the segmented routing header can be set according to actual needs. For example, a fixed length of data segments can be preset, and multiple data segments can be extracted from the segmented routing header based on this fixed length. If the last data segment does not reach the fixed length, it can be padded in a certain way (such as padding with 0s). Alternatively, the number of segments n can be preset, and the segmented routing header can be divided into n equal parts based on the number of segments n.

[0063] like Figure 4 As shown, by parsing the segmented routing header of the first data packet, the segmented routing header is divided into n equal parts to obtain the data segments: First data segment ( ); Second data segmentation ( ); ... The nth data segment ( ).

[0064] Each data segment is processed in parallel by a SipHash unit. SipHash unit 1 processes the first data segment to obtain a hash value V1; SipHash unit 2 processes the second data segment to obtain a hash value V2; ...; SipHash unit n processes the nth data segment to obtain a hash value V. n The hash values ​​obtained from each SipHash unit are merged (e.g., XORed) and finally aggregated into a fixed-length data digest.

[0065] In the above embodiments, by dividing the SRH into several data segments and performing SipHash calculations in parallel through multiple independent SipHash units and fusing hash values ​​to generate a data digest, the data segmentation design reduces the difficulty of hardware parsing, eliminates the need to reserve maximum length resources, reduces device storage and computing overhead, and adapts to the performance requirements of high-speed cross-domain networks.

[0066] Please see Figure 5 , Figure 5 This is an exemplary embodiment providing a verification method for cross-domain segmented routing, and... Figure 3 As shown, step S201 may be included after step S211.

[0067] Step S211: Based on the network identifier of the first data packet and the time information related to the first data packet, perform probability sampling calculation to determine whether to verify the first data packet according to the probability sampling calculation result.

[0068] In one implementation, after receiving the first data packet, the first network node can first perform probability sampling calculation on the first data packet, and determine whether to verify the first data packet based on the probability sampling calculation result.

[0069] In one implementation, the first network node can perform probability sampling calculations based on the network identifier of the first data packet and the time information associated with the first data packet. The network identifier can be a VPN Segment Identifier (VPNSID), used to uniquely associate a user identity in a segmented routing network; the time information associated with the first data packet can be used to indicate the time the first data packet was received (i.e., the current time), or to indicate the time the user equipment sent the first data packet, etc. For example, the first network node can perform probability sampling calculations based on the VPNSID and the first timestamp of the first data packet.

[0070] The probability sampling calculation method can be set according to actual needs: In one implementation, a random number can be generated based on the VPNSID and a first timestamp, and compared with a set threshold. If the number is greater than or equal to the threshold, the sampling condition is met, and the first data packet can be verified; otherwise, the first data packet is not verified.

[0071] In one implementation, a second hash calculation can be performed on the network identifier of the first data packet and the time information associated with the first data packet; the hash value of the second hash calculation is matched with a preset sampling mask used to represent the sampling rate; based on the matching result, it is determined whether to verify the first data packet.

[0072] The matching method between the hash value calculated by the second hash and the sampling mask can be set according to actual needs. For example, it can be compared bit by bit to determine whether they are the same or partially the same.

[0073] In one implementation, the hash value calculated by the second hash can be ANDed with the sampling mask, and it can be determined whether the result of the AND operation satisfies the predicted sampling conditions. The sampling conditions may include: the lower k bits of the AND operation result are all zero; where k is a positive integer.

[0074] If the lower k bits of the sum operation result are all zero, it indicates a successful match, and the above verification process can be performed on the first data packet; otherwise, there is no need to verify the first data packet.

[0075] In one implementation, the second hash calculation may employ a common hash calculation different from the first hash calculation; or it may employ the same key hash calculation as the first hash calculation, such as SipHash.

[0076] In one implementation, the configuration parameters sent by the server to the first network node may include parameters related to probability sampling calculation, such as configuration related to the second hash calculation (e.g., encoding key), sampling mask, etc.

[0077] The first hash calculation and the second hash calculation can use the same encoding key or different encoding keys; no specific restrictions are imposed here.

[0078] In one implementation, different sampling masks can be configured for different user equipment.

[0079] In one implementation, in order to ensure the basic communication needs of the first network node, the sampling mask can be adjusted based on the traffic of the segmented routing network to ensure that the sampling rate of the first network node is reduced under high traffic conditions.

[0080] In one implementation, the server can adjust the sampling mask based on the traffic of the segmented routing network and send the updated configuration parameters to the first network node.

[0081] In one implementation, a traffic estimator can be integrated into the first network node to adjust the sampling mask, i.e., the sampling rate, based on the estimated traffic.

[0082] For example, a Count-Min sketch (CM-sketch) estimator can be integrated into the first network node to estimate the frequency of each VPNSID unbiasedly using the Count-Min algorithm. Based on the estimated network traffic, the sampling mask of each VPNSID can be dynamically adjusted, that is, the sampling rate of each flow can be adjusted.

[0083] In the above embodiments, after receiving data packets, the ingress node calculates probability sampling based on network identifier and time information, and selectively initiates the verification process for some data packets through the sampling mechanism, which greatly reduces the processing load of the edge routing device. Especially in high-traffic cross-domain scenarios, it can avoid the decline in forwarding performance caused by the overload of verification tasks.

[0084] Please see Figure 6 , Figure 6This is an exemplary embodiment of a verification method for cross-domain segmented routing, applied to a second network node, which is an edge routing device in a segmented routing network used to forward data packets outwards. The method includes: S601, The second network node receives the second data packet, which is the data packet sent by the user equipment and forwarded to the second network node after being verified by the first network node.

[0085] In one implementation, after the first network node determines to initiate the verification process for the first data packet based on the probability sampling calculation result of the first data packet, it can perform a first hash calculation on the first data packet and match the calculated data digest with the authorization key carried by the first data packet. If the match is successful, the second field (Pass field) in the segmented routing header used to indicate the verification result is set to 0. If the match is unsuccessful, the second field of the segmented routing header is set to the remaining number of segments L of the forwarding path of the first data packet, which is the Left field in the segmented routing header of the first data packet.

[0086] After being verified by the first network node, the first data packet will continue to be forwarded as the second data packet to the second network node through the forwarding path within the segmented routing network.

[0087] S602. Compare the remaining number of segments in the forwarding path of the second data packet with the value recorded in the second field of the segmentation routing header of the second data packet; if they are the same, it means that the second data packet is normal; if they are different, it means that the second data packet is abnormal.

[0088] In one implementation, the second network node parses the received second data packet, determines the remaining number M of the forwarding path of the second data packet (which can be obtained by extracting the Left field in the segment routing header of the second data packet), and extracts the value recorded in the second field of the segment routing header of the second data packet (which can be 0 or L). The remaining number of segments M is compared with the value recorded in the second field. If the two are the same, the second data packet is considered normal; if the two are different, the second data packet is considered abnormal.

[0089] For example, if the remaining number of segments M in the forwarding path of the second data packet is 0 and the value recorded in the second field is 0, it means that the first network node's verification result for the first data packet is successful, and the forwarding path carried by the first data packet is a complete authorized path, and the second data packet verification is successful. If the remaining number of segments M in the forwarding path of the second data packet is L and the value recorded in the second field is L, it means that although the first network node's verification result for the first data packet is unsuccessful, the reason is that the forwarding path carried by the first data packet is not the authorized path in the current segmented routing network, and it cannot be determined that the forwarding path has been tampered with (such as segment insertion or segment deletion), and the second data packet verification is successful. If the remaining number of segments M in the forwarding path of the second data packet is different from the value recorded in the second field, it can be considered that the forwarding path carried by the first network node may have been tampered with, and the second data packet verification fails.

[0090] If the second data packet is determined to be abnormal, mitigation or reporting actions can be triggered.

[0091] In the above embodiments, a second field is set in the segmented routing header of the data packet to represent the verification result of the ingress node. This allows the ingress node to reset the second field based on the verification result when verifying the data packet. As a result, the egress node can complete the final filtering of the data packet by comparing the number of remaining segments carried by the data packet and the value of the second field. The forwarding path carried by the data packet can be determined by comparing the fields alone, ensuring the rapid processing of the egress node and effectively blocking the flow of tampered data packets out of the trusted domain network.

[0092] Figure 7 This is an exemplary embodiment of an authentication system for cross-domain segmented routing. The authentication system includes a server 70, a first network node 71, and a second network node 72. The server 70 is used to send authentication-related configurations to the first network node 71 and the second network node 72. The first network node 71 can be used to implement, for example... Figures 2-5 The verification method for cross-domain segmented routing shown herein, wherein the second network node 72 is used to implement, as follows: Figure 6 The verification method for cross-domain segmented routing is shown.

[0093] The first network node 71 may include a sampling module 711, a compression module 712, and a verification module 713; the second network node 72 may include a filtering module 721.

[0094] The sampling module 711 selects a portion of data packets for verification through a probability sampling mechanism, reducing the processing load; the compression module 712 is used to compress variable-length SRHs into fixed-length data digests, improving hardware processing efficiency; the verification module 721 and the filtering module 721 can be used to ensure the integrity and authenticity of the forwarding path carried by the data packets through key verification and downstream filtering.

[0095] The sampling module 711 may include a probabilistic sampling submodule and an adaptive control submodule. The probabilistic sampling submodule is used to achieve uniform random sampling through a second hash calculation and a sampling mask to ensure fairness; the adaptive control module can estimate the flow using a Count-Min plot and dynamically adjust the sampling rate (sampling mask) according to the flow to ensure that the total sampling cost does not exceed the budget.

[0096] The compression module 712 can convert variable-length SRHs into fixed-length data digests, supports hardware-friendly parallel processing, and integrates dynamic key management (periodic updates to the authorization key) to prevent replay attacks.

[0097] The compression module 712 may include a hierarchical compression submodule and a key management submodule. The hierarchical compression submodule can divide the SRH into multiple data segments, process them in parallel using SipHash units, and output a fused data digest. The key management submodule can generate a dynamic key (a hash key for SipHash) based on a preset time window, and tolerate time offsets through a dual-window strategy to ensure the timeliness and security of the data digest.

[0098] Please see Figure 8 , Figure 8 This is a schematic diagram illustrating an exemplary embodiment of a verification method for cross-domain segmented routing. For example... Figure 8 The complete technical solution of this disclosure is illustrated with an example.

[0099] This disclosed technical solution is completed collaboratively by a collective server and agents deployed on edge routing devices (ingress and egress nodes) in a segmented routing network. The server receives verification policies and sampling configurations from operations personnel, generates relevant keys and verification parameters, and distributes them to agents on each router. The agents selectively process data packets at the ingress node based on a pre-configured sampling rate and perform filtering at the egress node; simultaneously, without altering standard SRv6 forwarding behavior, they embed verification metadata using the SRH's TLV field to form the information required for subsequent auditing and security analysis.

[0100] During the initialization phase, the server assigns a unique authorization key to each CPE-VPN pair for subsequent digest verification. Simultaneously, the server distributes runtime configuration parameters, including the sampling rate and the encoding key used for compression. The agent is exclusively deployed on the SRv6 border routing devices at the ingress and egress points, and intermediate routers in the backbone network do not need to be aware of this disclosed technical solution, thereby supporting incremental deployment across heterogeneous network domains.

[0101] The sampling and filtering process employs a distributed verification mechanism. For example... Figure 8As shown, upon receiving a cross-domain SRv6 data packet, the ingress node initiates a probabilistic sampling process. The sampling module extracts the VPNSID and first timestamp of the data packet, generates a fixed-length data digest using a key hash function, and then performs an AND operation with a configurable sampling mask. The data packet is selected to initiate the verification process only if the result of the AND operation meets a preset sampling condition (e.g., the lower k bits are zero).

[0102] To adaptively control sampling overhead, a CM-sketch estimator is integrated at the ingress node for unbiased estimation of the frequency for each VPNSID. The sampling rate for each flow is dynamically adjusted based on the estimated traffic, ensuring that the sampling rate is reduced for high-traffic flows.

[0103] For the selected data packets, SRH compression is performed to generate a fixed-length verification digest, such as... Figure 3 As shown, the compression unit divides the variable-length SRH SID and key control fields into n data segments, each of which is processed in parallel by an independent SipHash unit. SipHash, a key hash function based on 64-bit modulo addition, fixed bit shifting, and bitwise XOR, has its output efficiently computed in hardware. The outputs of all SipHash units are aggregated into a fixed-length data digest via XOR operation, which is highly sensitive to any bit modifications or changes in the order of the SRH.

[0104] To prevent replay attacks, a dynamic key management mechanism is introduced. The key can consist of an encoded key (e.g., a 96-bit fixed key) and a timestamp (e.g., 32 bits), forming a 128-bit SipHash key. The timestamp is based on the current time T (reception time) and a predefined time window size. The calculations show that, to tolerate network latency and clock skew, the verification algorithm employs a dual-window strategy: except for the current time window... In addition to the SipHash key in the first time window, it also accepts the key from the previous time window. The SipHash key for the second time window. Verification is successful only if the authorization key (first field Key) carried in the data packet matches the data digest calculated using any candidate SipHash key.

[0105] The downstream selection process is completed at the egress node. For packets entering the verification process, the ingress node reads the Left field (remaining segment count L) of the packet's SRH and performs verification of the packet's forwarding path. If the verification passes, the Pass field (second field) in the SRH TLV extension is set to 0; otherwise, the Pass field is set to L. This TLV contains Type, Length, Pass, Tag, and Key fields, and its structure is designed to ensure it is not processed by unknown devices and maintains backward compatibility. After the packet is forwarded to the egress node along the normal path, the filtering module retrieves the final Pass field and compares it with the current Left field of the SRH. If they are equal, the path is considered complete; if they do not match, it indicates that the path may have been tampered with (such as segment insertion or deletion), and mitigation or reporting actions are triggered.

[0106] To reduce the telemetry and aggregation pressure on the server side, a selective result reporting mechanism is adopted. The filtering module of the egress node only retains the verification results of legitimate VPNs and sends valid verification reports back to the server. The server aggregates these distributed reports, performs aggregation analysis, security auditing, and anomaly detection, and finally outputs a security posture map including path violations and suspected attack sources.

[0107] By evaluating the bandwidth overhead of different verification schemes, the bandwidth increment caused by each scheme under 3-hop, 5-hop, and 10-hop network paths was analyzed. Traditional schemes, based on passport-based path verification (PPV) and enhanced path integrity check (EPIC), introduce extremely high overhead, resulting in a bandwidth increase of up to 50GB in the 10-hop scenario. In contrast, the framework proposed in this disclosure achieves the lowest bandwidth overhead in all test scenarios, with a total bandwidth increment of only 3% under the 10-hop condition. Compared with existing baseline technologies, the proposed framework reduces bandwidth overhead by up to 70% while maintaining complete path verification capabilities.

[0108] Regarding verification accuracy, this disclosure constructs a complete attack test suite to test the system. XOR-based verification schemes cannot effectively detect segment reordering attacks, while the truncated hash-based message authentication code (HMAC) scheme exhibits verification blind spots when the SID outside the prefix range changes. In contrast, the framework proposed in this disclosure successfully identified all path tampering attempts in the test suite, achieving 100% verification accuracy. These results demonstrate that this system, while significantly reducing bandwidth overhead, provides comprehensive protection against various types of path tampering attacks, confirming its high reliability and security in practical deployments.

[0109] Figure 9 This is a schematic structural diagram of a device provided in an exemplary embodiment. Please refer to... Figure 9 At the hardware level, the device includes a processor 902, an internal bus 904, a network interface 906, memory 908, and non-volatile memory 910, and may also include other hardware required for its functions. One or more embodiments of this specification can be implemented in software, for example, the processor 902 reads the corresponding computer program from the non-volatile memory 910 into memory 908 and then runs it. Of course, besides software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution entity of the following processing flow is not limited to individual logic units, but can also be hardware or logic devices.

[0110] Please refer to Figure 10 The verification device for cross-domain segmented routing can be applied to, for example... Figure 9 The device shown implements the technical solution of this specification. The verification device for cross-domain segmented routing may include: a sampling module 1001, a compression module 1002, and a verification module 1003.

[0111] The sampling module 1001 is used to receive a first data packet sent by a user equipment; the compression module 1002 is used to perform a first hash calculation on the segmented routing header of the first data packet to obtain a data digest; the verification module 1003 is used to match the data digest with the authorization key recorded in the first field of the segmented routing header; wherein the authorization key is pre-configured based on the authorization path of the user equipment; if the match is successful, it is determined that the forwarding path recorded in the segmented routing header is the same as the authorization path of the user equipment in the segmented routing network.

[0112] Please refer to Figure 11The verification device for cross-domain segmented routing can be applied to, for example... Figure 9 The device shown implements the technical solution described in this specification. The verification device for cross-domain segmented routing may include a receiving module 1101 and a filtering module 1102.

[0113] The receiving module 1101 is used to receive the second data packet; the filtering module 1102 is used to compare the remaining number of segments in the forwarding path of the second data packet with the value recorded in the second field of the segment routing header of the second data packet; if they are the same, it means that the second data packet is normal; if they are different, it means that the second data packet is abnormal.

[0114] Based on the same concept as the methods described above, this specification also provides an electronic device, including: a processor; a memory for storing processor-executable instructions; wherein the processor performs the steps of the method as described in any of the above embodiments by executing the executable instructions.

[0115] Based on the same concept as the methods described above, this specification also provides a computer-readable storage medium having computer instructions stored thereon that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0116] Based on the same concept as the methods described above, this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

Claims

1. A verification method for cross-domain segmented routing, characterized in that, Applied to a first network node, which is an edge routing device in a segmented routing network for receiving external data, the method includes: Receive the first data packet sent by the user equipment; A first hash calculation is performed on the segmented routing header of the first data packet to obtain a data digest, including: determining a hash key for the first hash calculation based on a pre-configured encoding key and time information related to the first data packet; wherein, the time information includes a first timestamp and a second timestamp, the first timestamp being used to represent a first time window in which the first data packet was received, and the second timestamp being used to represent the previous time window of the first time window; the hash key for the first hash calculation includes a first hash key corresponding to the first timestamp and a second hash key corresponding to the second timestamp; the first hash calculation is performed on the segmented routing header of the first data packet based on the first hash key and the second hash key respectively to obtain a first data digest corresponding to the first hash key and a second data digest corresponding to the second hash key, which are used as the data digest; The first data digest and the second data digest are respectively matched with the authorization key recorded in the first field of the segmented routing header; wherein the authorization key is pre-configured based on the authorized path of the user equipment; If a match is successful, it is determined that the forwarding path recorded in the segmented routing header is the same as the authorized path of the user equipment within the segmented routing network.

2. The method according to claim 1, characterized in that, The first hash calculation includes the SipHash hash calculation.

3. The method according to claim 2, characterized in that, The first hash calculation is performed on the segmented routing header of the first data packet to obtain a data digest, including: The segmented routing header is divided into several data segments; Based on the hash key, SipHash hash calculation is performed on the several data segments to obtain hash values ​​corresponding to the several data segments respectively; The hash values ​​corresponding to the aforementioned data segments are merged to obtain a data digest.

4. The method according to claim 1, characterized in that, After receiving the first data packet sent by the user equipment that needs to traverse the segmented routing network, the method further includes: Based on the network identifier of the first data packet and the time information associated with the first data packet, a probability sampling calculation is performed to determine whether to verify the first data packet based on the probability sampling calculation result.

5. The method according to claim 4, characterized in that, The probability sampling calculation based on the network identifier of the first data packet and the time information associated with the first data packet includes: A second hash calculation is performed on the network identifier of the first data packet and the time information associated with the first data packet; The hash value calculated by the second hash is matched with a preset sampling mask used to represent the sampling rate; Based on the matching results, determine whether to verify the first data packet.

6. The method according to claim 5, characterized in that, The step of matching the hash value calculated by the second hash with a preset sampling mask used to represent the sampling rate includes: The hash value calculated by the second hash is then summed with the sampling mask. Determine if the lower k bits of the result of the sum operation are all zero; if so, the match is successful.

7. The method according to claim 5, characterized in that, The method further includes: The sampling mask is adjusted based on the traffic of the segmented routing network.

8. The method according to claim 7, characterized in that, The traffic of the segmented routing network is estimated using the Count-Min algorithm.

9. The method according to claim 1, characterized in that, The method further includes: If a match is successful, the second field of the segmented routing header is set to 0; if a match is unsuccessful, the second field of the segmented routing header is set to the remaining number of segments in the forwarding path of the first data packet.

10. A verification method for cross-domain segmented routing, characterized in that, Applied to a second network node, which is an edge routing device in a segmented routing network used for forwarding data packets outwards, the method includes: The second network node receives the second data packet, which is a data packet sent by the user equipment and forwarded to the second network node after being verified by the first network node; the value recorded in the second field of the segmented routing header of the second data packet is entered by the first network node based on the verification result of the first data packet, and the verification result is determined by the first network node based on the matching result between the calculated data digest and the authorization key pre-configured based on the authorization path of the user equipment; The remaining number of segments in the forwarding path of the second data packet is compared with the value recorded in the second field of the segment routing header of the second data packet; if they are the same, it means that the second data packet is normal; if they are different, it means that the second data packet is abnormal. The data digest generation process includes: Based on the pre-configured encoding key and the time information associated with the first data packet, a hash key for the first hash calculation is determined; the time information includes a first timestamp and a second timestamp, the first timestamp is used to represent the first time window in which the first data packet is received, the second timestamp is used to represent the previous time window of the first time window, and the hash key for the first hash calculation includes a first hash key corresponding to the first timestamp and a second hash key corresponding to the second timestamp; Based on the first hash key and the second hash key respectively, a first hash calculation is performed on the segmented routing header of the first data packet to obtain a first data digest corresponding to the first hash key and a second data digest corresponding to the second hash key, which are used as the data digest.

11. A verification device for cross-domain segmented routing, characterized in that, include: The sampling module is used to receive the first data packet sent by the user equipment; A compression module is used to perform a first hash calculation on the segmented routing header of the first data packet to obtain a data digest, including: determining a hash key for the first hash calculation based on a pre-configured encoding key and time information related to the first data packet; wherein the time information includes a first timestamp and a second timestamp, the first timestamp is used to represent a first time window in which the first data packet is received, and the second timestamp is used to represent the previous time window of the first time window; the hash key for the first hash calculation includes a first hash key corresponding to the first timestamp and a second hash key corresponding to the second timestamp; and performing a first hash calculation on the segmented routing header of the first data packet based on the first hash key and the second hash key respectively to obtain a first data digest corresponding to the first hash key and a second data digest corresponding to the second hash key, which are used as the data digest; The verification module is used to match the first data digest and the second data digest with the authorization key recorded in the first field of the segmented routing header, respectively; wherein the authorization key is pre-configured based on the authorized path of the user equipment; if the match is successful, it is determined that the forwarding path recorded in the segmented routing header is the same as the authorized path of the user equipment in the segmented routing network.

12. A verification device for cross-domain segmented routing, characterized in that, include: The receiving module is used to receive a second data packet, which is a data packet sent by the user equipment and forwarded to the second network node after being verified by the first network node; The value recorded in the second field of the segmented routing header of the second data packet is entered by the first network node based on the verification result of the first data packet. The verification result is determined by the first network node based on the matching result between the calculated data digest and the authorization key pre-configured based on the authorization path of the user equipment. The filtering module is used to compare the number of remaining segments in the forwarding path of the second data packet with the value recorded in the second field of the segment routing header of the second data packet; If they are the same, it means that the second data packet is normal; If they are different, it indicates that the second data packet is abnormal; The data digest generation process includes: Based on the pre-configured encoding key and the time information associated with the first data packet, a hash key for the first hash calculation is determined; the time information includes a first timestamp and a second timestamp, the first timestamp is used to represent the first time window in which the first data packet is received, the second timestamp is used to represent the previous time window of the first time window, and the hash key for the first hash calculation includes a first hash key corresponding to the first timestamp and a second hash key corresponding to the second timestamp; Based on the first hash key and the second hash key respectively, a first hash calculation is performed on the segmented routing header of the first data packet to obtain a first data digest corresponding to the first hash key and a second data digest corresponding to the second hash key, which are used as the data digest.

13. A verification system for cross-domain segmented routing, characterized in that, The verification system includes a server, a first network node, and a second network node. The server is used to send verification-related configurations to the first network node and the second network node. The first network node is used to implement the verification method for cross-domain segmented routing as described in any one of claims 1-9, and the second network node is used to implement the verification method for cross-domain segmented routing as described in claim 10.

Images