Route verification method and device, equipment and storage medium

Abstract

A route verification method, device and equipment and a storage medium are disclosed, and relate to the technical field of communication. The method comprises the following steps: introducing credibility information to define a credibility level for route verification data; and verifying route information based on the route verification data carrying the credibility information. The credibility information is used to describe the credibility of the route verification data.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to routing verification methods, apparatus, devices, and storage media. Background Technology

[0002] Security attacks based on Border Gateway Protocol (BGP) routing are frequent in communication networks. For example, some Internet Service Providers (ISPs) may maliciously attack routing information to capture user traffic, thereby eavesdropping on user traffic, or redirect user traffic to malicious networks by announcing false routing information.

[0003] To ensure the security of user traffic, the industry has introduced a BGP route verification mechanism on top of the BGP protocol. This involves using route verification data to verify route information. If the route information matches the data in the route verification data, the route information is verified, and the data packet is forwarded to the destination device based on the verified route information. Conversely, if the route information fails verification, the route information is discarded, and the data packet can be forwarded to the destination device using other route information.

[0004] However, the routing verification data in related technologies comes from multiple sources, and routing verification data from different sources may lead to inconsistent routing verification results, resulting in conflicting routing verification results and low accuracy of routing verification. Summary of the Invention

[0005] This application provides a route verification method, apparatus, device, and storage medium, which improves the accuracy of route verification.

[0006] To achieve the above objectives, this application adopts the following technical solution:

[0007] Firstly, a route verification method is provided, which is applied to a network device. The method includes: verifying route information based on trusted route verification data carrying trust information.

[0008] Among them, the credibility information is used to describe the credibility of the routing verification data.

[0009] The solution provided in this application introduces the concept of trustworthiness in the process of verifying routing information. By considering the trustworthiness of the routing verification data during the routing verification process, the verification strategy for routing information is optimized. This can avoid the problem of conflicting routing verification results caused by routing verification data with different trustworthiness levels, and improve the accuracy of routing verification.

[0010] One possible implementation involves the server sending multiple routing verification data sets carrying trust information to the network device. Trusted routing verification data consists of routing verification data whose trust information meets certain criteria. By setting conditions, trusted routing verification data is filtered out to verify the routing information. Based on the trust information, high-quality trusted routing verification data can be quickly identified, improving the efficiency of trusted routing verification data selection and enhancing the user experience.

[0011] Among them, conditions can be set according to the needs of network devices, and the conditions corresponding to different network devices can be the same or different.

[0012] Another possible implementation involves the credibility information satisfying the following conditions: the credibility information indicates the highest level of credibility. Selecting the route verification data with the highest level of credibility for route verification can yield more accurate route verification results, improving the accuracy of route verification; at the same time, since only the route verification data with the highest level of credibility is used, the route verification process is faster and the route verification efficiency is higher.

[0013] Another possible implementation involves satisfying the following conditions for the credibility information: the credibility level indicated by the credibility information is greater than or equal to a credibility threshold. By setting a credibility threshold, high-quality routing verification data can be filtered out, while less reliable or unknown-source routing verification data can be excluded, thereby improving the accuracy and reliability of the entire routing verification process.

[0014] Another possible implementation is that trusted route verification data is obtained by configuring trust information in route verification data. Trust information configured at different locations within a set of route verification data indicates the degree of trustworthiness of different content within the data. By configuring trust information at different locations within the route verification data, the degree of trustworthiness of content at different locations changes, thereby enabling fine-grained management of trusted route verification data. This allows users to more precisely control and manage trusted route verification data according to their actual needs.

[0015] Another possible implementation involves linking the credibility information to the source of the routing verification data, with different sources providing different levels of credibility. Routing verification data from different network areas or service providers may have varying degrees of reliability. By differentiating credibility, the most reliable data source can be selected for routing verification data. Furthermore, when anomalies occur in the routing verification results, the source of the routing verification data can be quickly located based on its credibility information, allowing for priority checks on whether the data source is abnormal.

[0016] Another possible implementation is that the credibility information of the route verification data indicates the credibility level from high to low as follows: locally registered route verification data, global route verification data, and route verification data based on local data inference.

[0017] Another possible implementation, the route verification method provided in this application, further includes: receiving a route verification data set from a server, the route verification data set including trusted route verification data. The server uniformly configures the trust information for the route verification data, and during route information verification, the trusted route verification data to be used in this route verification is selected from the route verification data set issued by the server. The server uniformly configures the trust information for the route verification data, simplifying the trust information configuration process and avoiding the process of configuring the route verification data on each network device, thus improving configuration efficiency.

[0018] Another possible implementation involves receiving a set of route verification data from the server. Specifically, the network device receives the route verification data set based on the Route Authentication Data Synchronization (RPKI-to-router protocol, RTR). The server synchronizes the route verification data set carrying trust information to the network device via the RTR protocol. The RTR protocol can efficiently and securely synchronize route verification data between the server and multiple network devices, improving the transmission efficiency between the server and network devices.

[0019] Another possible implementation, the routing verification method provided in this application, further includes: if the routing information verification is complete, reporting the verification result and routing information corresponding to the routing information to the server, wherein the verification result includes the credibility information corresponding to the trusted routing verification data. After the routing information verification is completed, the network device reports the verification result and routing information to the server so as to statistically analyze the verification results, quantity, etc. of the routing information, and at the same time help users perform more detailed routing security monitoring and analysis.

[0020] Another possible implementation involves reporting the verification result and routing information corresponding to the routing information to the server. Specifically, this can be achieved by updating the verification result to the first field of the data unit; adding the routing information to the second field of the data unit; and then sending the data unit to the server. The first and second fields are different. The first field can be a reserved field, a newly created field, or a newly created type-length-value (TLV) field. When reporting the verification result and routing information to the server, the original reserved field can be modified to store the verification result including the credibility information, a simple operation requiring no additional steps. Alternatively, a new TLV field can be added to store the verification result including the credibility information, allowing for more flexible expansion and adjustment of the data unit structure. Users can choose different reporting methods according to their actual needs, improving the user experience.

[0021] Another possible implementation is that the above data unit adopts the Border Gateway Monitoring Protocol (BGP, BMP), and the first field includes either the path status field or the reason code field.

[0022] Another possible implementation, the routing verification method provided in this application, further includes: a network device receiving a data packet. Upon receiving the data packet, the device determines the verification result of the routing information guiding the packet's transmission, and the corresponding handling strategy based on the trustworthiness of the trusted routing verification data; different verification results and trustworthiness levels of the routing verification data correspond to different handling strategies; if the handling strategy indicates forwarding, the data packet is forwarded according to the routing information. By taking trustworthiness information into account when forwarding data packets, the network device makes the data packet handling strategy more flexible and better adaptable to network transmission needs. Similarly, the flexible handling strategy is closer to the actual transmission situation of the data packets, improving the transmission efficiency of the data packets.

[0023] Secondly, a route verification method is provided, which is applied to a server. The method includes: acquiring route verification data; and sending a set of route verification data to a network device. The set of route verification data includes trusted route verification data used to verify route information. The trusted route verification data carries trust information, which describes the degree of trustworthiness of the route verification data.

[0024] The solution provided in this application configures the trust information of the route verification data after the server obtains it, enabling the route verification data to carry trust information. This configured trust information is then sent to the network devices. This allows the network devices to incorporate trust information when verifying route information, thus avoiding conflicts in route verification results caused by different trust information corresponding to trusted route verification data in different network devices, thereby improving the accuracy of route verification. Furthermore, the server uniformly configures the trust information for the route verification data, simplifying the configuration process and avoiding the need for configuration on each network device, thus improving configuration efficiency.

[0025] One possible implementation of the routing verification method provided in this application further includes: receiving routing information and verification results from a network device, wherein the verification results include credibility information corresponding to the trusted routing verification data, and the routing information and verification results are sent by the network device after the routing information verification is completed. The routing verification process helps to identify and eliminate abnormal routing information, thereby improving network stability; furthermore, verified routing information ensures that data packets can reach their destination along the correct path, improving network reachability and connectivity.

[0026] Another possible implementation, the routing verification method provided in this application, further includes: configuring credibility information on the routing verification data to obtain trusted routing verification data. The credibility information configured at different locations within the routing verification data indicates the credibility level of different content within the data. By configuring credibility information at different locations within the routing verification data, the credibility level of content at different locations changes, thereby achieving fine-grained management of trusted routing verification data. This allows users to more precisely control and manage trusted routing verification data according to their actual needs.

[0027] Another possible implementation involves linking the credibility information to the source of the routing verification data; different sources of routing verification data have different credibility levels. Routing verification data from different network areas or service providers may have varying degrees of reliability. By differentiating credibility, the most reliable data source can be selected for routing verification data.

[0028] Another possible implementation is that trusted route verification data is obtained by configuring route verification data based on one or more of the following methods: simplified local internet number resource management with the RPKI (SLURM), JavaScript object notation (JSON), or extensible markup language (XML).

[0029] Another possible implementation is that the credibility information of the route verification data indicates the credibility level from high to low as follows: locally registered route verification data, global route verification data, and route verification data based on local data inference.

[0030] Another possible implementation involves sending a route verification data set to the network devices. Specifically, this can be achieved by sending the route verification data set to the network devices based on the RTR protocol. The server synchronizes the route verification data set to the network devices via the RTR protocol, which enables efficient and secure synchronization of route verification data between the server and multiple network devices.

[0031] Thirdly, a route verification device is provided, comprising: a receiving module and a verification module. Wherein:

[0032] The verification module is used to verify routing information based on trusted routing verification data that carries trustworthiness information. The trustworthiness information describes the degree of trustworthiness of the routing verification data.

[0033] One possible implementation is that the server sends multiple routing verification data carrying trust information to the network device. The trusted routing verification data is the routing verification data whose trust information meets the conditions.

[0034] Among them, conditions can be set according to the needs of network devices, and the conditions corresponding to different network devices can be the same or different.

[0035] Another possible implementation is that the credibility information must satisfy the following conditions: the credibility information indicates the highest level of credibility.

[0036] Another possible implementation is that the credibility information must meet the following conditions: the credibility level indicated by the credibility information is greater than or equal to the credibility threshold.

[0037] Another possible implementation is that trusted route verification data is obtained by configuring trust information in route verification data; the trust information configured in different locations in a route verification data is used to indicate the trustworthiness of different contents in the route verification data.

[0038] Another possible implementation is that the credibility information is related to the source of the route verification data, and the credibility information of the route verification data from different sources is different.

[0039] Another possible implementation is that the credibility information of the route verification data indicates the credibility level from high to low as follows: locally registered route verification data, global route verification data, and route verification data based on local data inference.

[0040] In another possible implementation, the receiving module described above is also used to receive a set of route verification data from the server, which includes trusted route verification data.

[0041] In another possible implementation, the aforementioned receiving module is also used by the network device to receive a set of route verification data based on the RTR protocol.

[0042] In another possible implementation, the route verification device provided in this application further includes a sending module. The sending module is used to report the verification result and the route information to the server if the route information verification is complete. The verification result includes the credibility information corresponding to the trusted route verification data.

[0043] In another possible implementation, the aforementioned sending module is also used to update the verification result to the first field of the data unit; add routing information to the second field of the data unit; and send the data unit to the server; wherein the first field and the second field are different, the first field is a reserved field or a newly created TLV field.

[0044] Another possible implementation is that the data unit uses the Border Gateway Monitoring Protocol (BMP), and the first field includes either the path status field or the reason code field.

[0045] In another possible implementation, the receiving module described above is also used to receive data packets. The verification module described above is also used to determine the verification result of the routing information and the handling strategy corresponding to the trustworthiness of the trusted routing verification data; different verification results and trustworthiness of the routing verification data correspond to different handling strategies; the sending module described above is also used to forward data packets according to the routing information if the handling strategy indicates to perform forwarding.

[0046] The routing verification device provided in the third aspect is used to execute the routing verification method provided in the first aspect or any possible implementation of the first aspect. The technical effects corresponding to any implementation of the third aspect can be referred to the technical effects corresponding to any implementation of the first aspect, and will not be repeated here.

[0047] Fourthly, a route verification device is provided, comprising: an acquisition module and a sending module. Wherein:

[0048] The acquisition module is used to obtain route verification data.

[0049] The sending module is used to send a set of route verification data to the network device. The set of route verification data includes trusted route verification data, which is used to verify the routing information. The trusted route verification data is route verification data carrying trust information, which describes the trustworthiness of the route verification data.

[0050] In one possible implementation, the routing verification device provided in this application further includes a receiving module. The receiving module is used to receive routing information and verification results from a network device. The verification results include credibility information corresponding to the trusted routing verification data. The routing information and verification results are sent by the network device after the routing information verification is completed.

[0051] Another possible implementation is to configure credibility information at different locations in a route verification data set, which is used to indicate the credibility level of different contents in the route verification data set.

[0052] Another possible implementation is that the credibility information is related to the source of the route verification data, and the credibility information of the route verification data from different sources is different.

[0053] Another possible implementation is that the credibility information of the route verification data indicates the credibility level from high to low as follows: locally registered route verification data, global route verification data, and route verification data based on local data inference.

[0054] In another possible implementation, the aforementioned sending module is also used to send a set of route verification data to network devices based on the RTR protocol. The server synchronizes the set of route verification data to the network devices via the RTR protocol, which can efficiently and securely synchronize route verification data between the server and multiple network devices.

[0055] The routing verification device provided in the fourth aspect is used to execute the routing verification method provided in the second aspect or any possible implementation of the second aspect. The technical effects corresponding to any implementation of the fourth aspect can be referred to the technical effects corresponding to any implementation of the second aspect, and will not be repeated here.

[0056] Fifthly, a network device is provided, comprising: a processor and a memory, wherein the memory stores at least one computer program, the at least one computer program being loaded and executed by the processor to implement the routing verification method as described in the first aspect or any possible implementation thereof.

[0057] In a sixth aspect, a server is provided, comprising: a processor and a memory, wherein the memory stores at least one computer program, the at least one computer program being loaded and executed by the processor to implement the routing verification method as described in the second aspect above or any possible implementation thereof.

[0058] In a seventh aspect, a computer-readable storage medium is provided, wherein at least one computer program is stored in the computer-readable storage medium, and the at least one computer program is loaded and executed by a processor to implement the routing verification method as described in any of the implementations of the first or second aspect above.

[0059] Eighthly, a computer program product is provided, comprising a computer program or instructions, which, when executed by a processor, implement the routing verification method as described in any of the implementations of the first or second aspect above.

[0060] Ninthly, embodiments of this application provide a chip system including at least one processor and at least one interface circuit. The at least one interface circuit is used to perform transceiver functions and send instructions to the at least one processor. When the at least one processor executes the instructions, the at least one processor executes to implement the routing verification method as described in any of the first or second aspects above.

[0061] The solutions provided in aspects five through nine above are used to implement the methods provided in aspect one or two above, and their specific implementations will not be described in detail here. The technical effects corresponding to any implementation of the solutions provided in aspects five through nine above can be found in the technical effects corresponding to any implementation of any implementation in aspect one or two above, and will not be described in detail here.

[0062] It should be noted that any of the possible implementations of any of the above aspects can be combined, provided that the solutions do not contradict each other. Attached Figure Description

[0063] Figure 1 This is a schematic diagram of a network scenario provided by an exemplary embodiment;

[0064] Figure 2 This is a schematic diagram of the architecture of a computer system provided in an exemplary embodiment of this application;

[0065] Figure 3 This is a flowchart of a route verification method provided in an exemplary embodiment of this application;

[0066] Figure 4 This is a flowchart of another route verification method provided in an exemplary embodiment of this application;

[0067] Figure 5 This is a flowchart of another route verification method provided in an exemplary embodiment of this application;

[0068] Figure 6 This is a schematic diagram of a route verification method provided in an exemplary embodiment of this application;

[0069] Figure 7 This is a schematic diagram of the structure of an IPv4 packet provided in an exemplary embodiment of this application;

[0070] Figure 8 This is a schematic diagram of the structure of a protocol data unit provided in an exemplary embodiment of this application;

[0071] Figure 9 This is a schematic diagram of the structure of a BMP provided in an exemplary embodiment of this application;

[0072] Figure 10 This is a schematic diagram of the structure of a route verification device provided in an exemplary embodiment of this application;

[0073] Figure 11 This is a schematic diagram of the structure of a route verification device provided in another exemplary embodiment of this application;

[0074] Figure 12 This is a schematic diagram of the structure of a computer device provided in an exemplary embodiment of this application. Detailed Implementation

[0075] In the embodiments of this application, in order to clearly describe the technical solutions of the embodiments of this application, the terms "first" and "second" are used to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and the terms "first" and "second" are not necessarily different. The technical features described by "first" and "second" have no sequential or size order.

[0076] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner to facilitate understanding.

[0077] In the embodiments of this application, at least one can also be described as one or more, and multiple can be two, three, four or more, and this application does not impose any restrictions.

[0078] Furthermore, the network architecture and scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0079] To facilitate understanding, the following explanations are provided for several terms used in this application.

[0080] In communication networks, routing refers to the process of transmitting data packets from a source address to a destination address.

[0081] Routing information refers to data used to determine the path a data packet takes from its source address to its destination address. This information typically includes the following key components: destination address, next-hop address, port, and metric. The destination address is the final address the data packet is destined for, such as an Internet Protocol (IP) address. The next-hop address is the address of the next network device the data packet must traverse before reaching its final destination. The port is the network port from which the data packet should be sent out. The metric is a standard used to select the path, such as hop count, bandwidth, delay, load, and cost.

[0082] Border Gateway Protocol (BGP) is a routing protocol used to exchange routing information between different autonomous systems (AS) in a communication network. BGP is one of the core protocols of the Internet, enabling different network operators and service providers to interconnect and allowing data packets to be transmitted between different networks worldwide.

[0083] Route verification data typically refers to various data and information used during the routing process to ensure the accuracy and security of routing information. Route verification data helps network administrators and network devices verify the source, path, and validity of routing information. The main purposes of verification are: preventing malicious route injection, such as preventing attackers from advertising false routes to achieve traffic capture or network disruption attacks; and ensuring the integrity of routing information, preventing tampering during transmission.

[0084] It should be noted that all information (including but not limited to device information, personal information of the target), data (including but not limited to data used for analysis, stored data, and displayed data), and signals involved in this application have been authorized by the target or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the routing information and trust information involved in this application were obtained with full authorization.

[0085] The Internet is a vast network of interconnected networks connected by a common set of protocols called BGP. It relies on an inter-domain routing system to ensure network connectivity, service availability, and service reliability. However, in the current climate, security attacks targeting the inter-domain routing system are constantly occurring, such as route capture, route leakage, and malicious tampering. Figure 1 Taking the network scenario shown as an example, when a user accesses server 20 through terminal 10, under normal circumstances, the user traffic will pass through network devices belonging to AS1 and network devices belonging to AS3, and finally reach server 20. However, if an external Internet Service Provider (ISP) belonging to AS100 launches a malicious attack, hijacking the user traffic to the external AS100 and sending it around before sending it to server 20, this would eavesdrop on or tamper with the user traffic.

[0086] An ISP can provide one or more ASs, each with an AS number. An AS can include multiple network devices, and these network devices can initiate routing information advertisements to each other. The AS number of the AS where the network device that initiates the routing information is located can be called the origin AS number of the routing prefix included in the routing information. In other words, the network device that initiates the routing information is located in the AS identified by the origin AS number.

[0087] Optionally, the routing prefix is ​​a prefix of the network address of the network device. For example, when the network device uses IPv4 for communication, the routing prefix is ​​a prefix of the IPv4 address. When the network device uses IPv6 for communication, the routing prefix is ​​a prefix of the IPv6 address.

[0088] To prevent eavesdropping or tampering with user traffic, the current mainstream solution in the industry is to introduce a route verification mechanism on top of the BGP protocol. This mechanism sends route verification data to network devices such as routers and switches. The data is then compared with the information carried in the routing information to verify its legitimacy. Based on the verified routing information, user traffic is guided for forwarding, thus preventing eavesdropping or tampering.

[0089] The network devices establish a connection with the server 20. The server 20 synchronizes the obtained routing verification data to each network device. After receiving the routing verification data, the network devices establish a database on their local machines to store the routing verification data.

[0090] When ISPs publish routing information, they include information such as the originating AS number, routing prefix, inter-AS relationships, and AS keys. When a network device receives routing information published by another network device, it matches this information with entries in the routing verification data database to verify the legitimacy of the received routing information. For example, by matching the originating AS number and routing prefix in the routing information with those in the routing verification data, the origin of the routing information is verified; by matching the inter-AS relationships in the routing information with those in the routing verification data, it ensures that only ASs with correct relationships can transmit routing information; and by matching the unique keys corresponding to the AS in the routing information with those in the routing verification data, the authenticity of the routing information is confirmed, ensuring it has not been captured or tampered with.

[0091] Optionally, route verification data can come from multiple sources. Currently, the main sources include: globally authoritative data, regional data, local private repositories, and inference repositories. Globally authoritative data, namely Resource Public Key Infrastructure (RPKI) data, is primarily maintained by the five Regional Internet Registries (RIRs). These five RIRs are also the organizations that manage and allocate IP addresses and AS numbers. Regional data refers to route verification databases maintained in a specific region, such as databases provided by research institutions or third-party companies. This type of data has regional characteristics and its coverage may not be as wide as globally authoritative data, but it is relatively more complete. Local private repositories are data maintained by the local network through local registration. They generally cover a certain range of the network and are relatively accurate, reliable, and complete. Inference repositories are regional or global route verification databases obtained through mathematical methods, including machine learning methods. This type of data can cover the entire internet and can be used to supplement data completeness when other repositories are incomplete or unavailable, but it does not guarantee 100% reliability.

[0092] However, the credibility of route verification data varies across different sources. For example, locally registered data has the highest credibility, while globally authoritative and regional (including third-party) data has relatively lower credibility, and local knowledge base inference has even lower credibility. Current mainstream route verification solutions merge data from all sources, without distinguishing data source or credibility during transmission and use. This leads to problems such as low accuracy in route verification, and post-verification processing may either incorrectly block legitimate routes or incorrectly allow illegitimate routes.

[0093] For example, suppose the route verification data includes local registration data and inference data. Local registration data is manually registered based on actual network conditions and is highly reliable, while inference data is generated using machine learning and may have a certain probability of misjudgment, making it relatively less reliable. In this case, mixing the two types of data, if both are considered reliable, inaccurate route verification data could lead to the blocking of legitimate routing information, causing internet outages and network incidents. If the data is not trusted (because it includes inference data), the only options are to lower the route priority or not perform any operations that affect routing decisions (e.g., only monitoring without affecting routing), which might prevent the interception of illegal routes.

[0094] Therefore, the accuracy of current mainstream route verification schemes is low. The post-verification processing may either incorrectly block legitimate routes or incorrectly allow illegitimate routes. Moreover, route verification data from different sources may lead to inconsistent route verification results, resulting in conflicts.

[0095] Based on this, this application provides a route verification method. By configuring credibility information on the route verification data, upon receiving route information, the method verifies the route information based on the credible route verification data carrying the credibility information. The solution provided in this application introduces the concept of credibility during the route information verification process, considers the credibility of the route verification data, optimizes the route information verification strategy, avoids conflicts in route verification results caused by route verification data with different credibility information, and improves the accuracy of route verification.

[0096] The solutions provided by the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0097] The solution provided in this application can be applied to Figure 2 An example of a computer system. (e.g.) Figure 2 As shown, the computer system includes a server 201 and network devices. The network devices include a first network device 202, a second network device 203, and a third network device 204. The first network device 202 and the second network device 203 belong to different ASes; the first network device 202 belongs to AS1, and the second network device 203 belongs to AS2. The first network device 202 and the third network device 204 belong to the same AS. For the first network device 202, the second network device 203 is an external BGP neighbor, and the third network device 204 is an internal BGP neighbor.

[0098] Server 201 can communicate with network devices via wired or wireless means. First network device 202 communicates with second network device 203 via BGP. First network device 202 also communicates with third network device 204 via BGP.

[0099] Optionally, server 201 can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides cloud computing services such as cloud database, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery network (CDN), and big data and other basic cloud computing services.

[0100] Optionally, a network device refers to a device with data routing capabilities. Network devices include, but are not limited to, at least one of the following: router, multilayer switch, gateway, wireless access points (WAPs), virtual router, and software-defined networking (SDN) controller. This application embodiment does not specifically limit this definition.

[0101] Understandably, in some cases, network devices can also act as servers. That is, in addition to performing route verification functions, network devices can directly obtain, manage, and configure route verification data without needing to obtain route verification data from an external server.

[0102] Optionally, server 201 can synchronize routing verification data to all network devices directly or indirectly connected to server 201, or it can synchronize routing verification data to specified network devices. For example, after collecting routing verification data, server 201 synchronizes the routing verification data to first network device 202, second network device 203, and third network device 204. After receiving the routing verification data, first network device 202, second network device 203, and third network device 204 store the routing verification data.

[0103] When a network device receives routing information from another network device, it can verify the routing information based on stored routing verification data to determine its validity. For example, when the first network device 202 receives routing information from the second network device 203, the first network device 202 can verify the routing information based on the routing verification data to determine its validity. If the first network device 202 determines that the routing information has passed verification, it can store the routing information.

[0104] This application provides a route verification method, which can be executed by a network device. Before executing the route verification method provided in this application, the network device interacts with a server to obtain trusted route verification data, so that the network device can execute the route verification method. The server can be... Figure 2 The illustrated computer system includes server 201, and this method can be performed by a network device. For example, the network device could be... Figure 2 Any one of the first network device 202, the second network device 203, and the third network device 204 shown in the diagram.

[0105] Figure 3 This is a flowchart illustrating a route verification method provided in an embodiment of this application. This process is used by network devices to obtain trusted routing data. Figure 3 As shown, the route verification method may include:

[0106] Step 302: The server obtains route verification data.

[0107] The source of the route verification data has been described above and will not be repeated here. This application does not limit the specific process by which the server obtains the route verification data.

[0108] In some embodiments, the server obtains route verification data in the following ways: the server receives route verification data imported from different sources, or the server registers locally to obtain route verification data, or the server downloads route verification data from a route verification data database in a public network.

[0109] Step 304: The server sends a set of routing verification data to the network device.

[0110] The route verification dataset includes trusted route verification data, which is used to verify route information.

[0111] Trusted route verification data is route verification data that carries trust information, which describes the degree of trustworthiness of the route verification data.

[0112] For example, the credibility information is related to the source of the route verification data, and the credibility information of route verification data from different sources is different.

[0113] The credibility information carried in the trusted routing verification data can be marked by at least one of the following: numerical value, identifier, data source information, and information carrying the data source, but is not limited thereto. The embodiments of this application do not specifically limit this.

[0114] Optionally, the credibility information can be information obtained based on the source of the route verification data, or it can be the source information of the route verification data directly.

[0115] For example, trust information is represented by symbols. Trusted route verification data with a high level of trust is labeled as "High", "H", or "High". Trusted route verification data with a low level of trust is labeled as "Low", "L", or "Low".

[0116] Trustworthiness information is represented by data source information. Trusted route verification data from locally registered sources is labeled "Locally Registered". Trusted route verification data from global sources is labeled "Global".

[0117] Trustworthiness information is represented numerically. The trustworthiness of trusted route verification data is marked as "1", "2", and "3" from highest to lowest.

[0118] Optionally, the credibility information of the route verification data indicates the credibility level from high to low as follows: locally registered route verification data, global route verification data, and route verification data based on local data inference.

[0119] In some embodiments, the server configures trust information on routing verification data from different sources to obtain routing verification data carrying the trust information, which is then used as trusted routing verification data. The server then sends the routing verification data set to the network device.

[0120] Specifically, by adding credibility information to the route verification data, route verification data carrying credibility information is obtained. The credibility information, added at different locations, indicates the credibility level of different content within the route verification data. For example, if a JSON file includes values ​​of type `Filters`, type `Assertions`, and other types, and the credibility information is configured within a value of type `Filters` or type `Assertions`, then that credibility information indicates the credibility level of that type of JSON file. If the credibility information is configured at the end of the JSON file and not within a value of type `Filters` or type `Assertions`, then that credibility information indicates the credibility level of the entire JSON file.

[0121] In some embodiments, the way the server sends the route verification data set to the network device in step 302 may include at least one of the following methods, but is not limited thereto:

[0122] Method 1: The server actively sends a set of routing verification data to the network device.

[0123] For example, the server periodically sends a set of route verification data to the network device. Or, it sends a set of route verification data to the network device when the route verification data in the server is updated.

[0124] Method 2: After receiving a route verification data retrieval request from a network device, the server sends a set of route verification data to the network device. For example, the network device can specify the type of route verification data in its request, and the server will send the corresponding set of route verification data to the network device based on the request.

[0125] In some embodiments, the server sends a set of route verification data to the network device based on the RTR protocol.

[0126] For example, after the server establishes a connection with the network device, the server actively sends a set of route verification data to the network device through the RTR protocol; or, after the server establishes a connection with the network device, the server receives a route verification data request from the network device, and in response to the route verification data request, the server sends a set of route verification data to the network device through the RTR protocol.

[0127] Step 306: The network device receives a set of routing verification data from the server.

[0128] For example, after the server sends a set of route verification data to the network device based on the RTR protocol, the network device receives the set of route verification data from the server and stores the set of route verification data.

[0129] After the network device stores the route verification data set, the network device can execute the route verification method provided in this application to verify the route information based on the trusted route verification data in the route verification data set. Figure 4 This is a flowchart illustrating another route verification method provided in an exemplary embodiment of this application. The method can be executed by a network device. For example, the network device can be... Figure 2 The diagram illustrates any one of the first network device 202, the second network device 203, and the third network device 204. It is understood that the process of verifying routing information on each network device is similar. Therefore, for ease of understanding, the following description uses one network device as an example to illustrate the process of verifying routing information. For detailed procedures, please refer to the description of the embodiments below.

[0130] It should be understood that Figure 3 The process of indicating, and Figure 4 The illustrated process can be performed separately or in combination, and this application embodiment does not limit this.

[0131] like Figure 4 As shown, the routing verification method provided in this application embodiment may include:

[0132] Step 402: The network device receives routing information sent by other network devices.

[0133] Other network devices may be devices belonging to the same AS as this network device, or devices belonging to a different AS. This application embodiment does not specifically limit this.

[0134] In some embodiments, a network device sends a routing information request to another network device, and the other network device responds to the routing information request by sending all or part of the routing information to the network device; or, other network devices actively send all or part of the routing information to the network device, but are not limited thereto, and the embodiments of this application do not specifically limit this.

[0135] In some embodiments, the network device receives routing information sent by other network devices in the following ways: when the network device and other network devices are adjacent, the other network devices periodically send all or part of the routing information to the network device; or, when the network device and other network devices belong to the same AS, the other network devices periodically send all or part of the routing information to the network device; when the distance between the network device and other network devices is less than a distance threshold, the other network devices periodically send all or part of the routing information to the network device; however, this is not limited to these embodiments, and the embodiments of this application do not specifically limit this.

[0136] For example, routing information includes several key parts such as destination address, next-hop address, port, and metric. For instance, the information content of a single routing entry is shown in Table 1.

[0137] Table 1 contains routing information.

[0138] Destination address Next hop address port metric 192.168.1.0 10.0.0.2 eth0 1

[0139] Based on this routing information, the guided routing path is as follows: a data packet destined for 192.168.1.0 should first be sent through port eth0 to the next-hop address: 10.0.0.2, where the metric value is 1. After reaching 10.0.0.2, the next routing information will then guide the routing process.

[0140] For example, suppose there are two ASs, AS100 and AS200, which exchange routing information via BGP. The following is a routing message advertised by AS100 to AS200: Destination network address prefix network: 192.0.2.0 / 24, next hop address next hop: 192.0.2.1, AS path: 100, local preference attribute: 100, community attribute community: NO_EXPORT.

[0141] In this configuration, 192.0.2.0 / 24 represents the destination network address prefix, and 24 is the prefix length. 192.0.2.1 indicates the next-hop IP address to which the packet should be sent before leaving AS100 and entering AS200. The AS Path is used to prevent routing loops and specifies the list of ASes that must be traversed to reach the destination network address prefix. Since the routing information has just been sent from AS100, the AS Path only includes AS100. The Internal attribute is used within AS100 to select the best path among multiple exit points. Higher values ​​indicate higher priority. The Community attribute indicates that this routing information should not be advertised to other autonomous systems. For example, it may be desirable to prevent certain internal networks from being known to external networks.

[0142] Step 404: The network device verifies the routing information based on the trusted routing verification data.

[0143] Specifically, the network device first obtains a route verification data set, which includes one or more sets of trusted route verification data. Before verifying the route information, the trusted route verification data used for verification is obtained from the route verification data set.

[0144] In one possible implementation, the trusted route verification data used for verification is the route verification data that meets the conditions in the route verification data set.

[0145] This condition is used to filter out routing verification data that meets the routing verification requirements of network devices.

[0146] For example, the condition could be: highest level of credibility, or credibility level greater than or equal to a credibility threshold. The content of the condition can be configured according to actual needs, and this application embodiment does not limit this.

[0147] For example, different network devices can be configured with different conditions, and different services performed by the same network device can correspond to different conditions.

[0148] For example, the route verification data with the highest level of trust indicated by the trust information is used as trusted route verification data for route information verification. Network devices verify route information based on trusted route verification data. For instance, the trust information indicated by the trust information carried in each route verification data is obtained, sorted, and then filtered according to the level of trust indicated by the trust information to obtain trusted route verification data.

[0149] For example, route verification data whose credibility level indicated by the credibility information is greater than or equal to the credibility threshold can be used as trusted route verification data for verification. Network devices verify route information based on trusted route verification data. For instance, the credibility level indicated by the credibility information carried in each route verification data can be obtained and sorted, and the route verification data can be filtered according to the credibility threshold to obtain trusted route verification data.

[0150] In another possible implementation, the trusted route verification data used for verification is all the route verification data in the route verification data set.

[0151] For example, all route verification data carrying trust information in the route verification dataset are considered trusted route verification data. Weights are assigned to these trusted data based on the trustworthiness indicated by the trust information; for instance, higher trustworthiness results in higher weights. The route information is then verified based on the trusted route verification data and their corresponding weights. For instance, if the route verification dataset contains five route verification data points, all five are considered trusted for route verification. Their respective weights are determined based on the trustworthiness indicated by the trust information. Finally, the verification results of these five data points and their corresponding weights are combined to obtain the final result for the route information, which is then used as the verification result for the route information.

[0152] The weight value is used to determine the proportion of the verification result of trusted route verification data in the overall verification result.

[0153] The following describes how network devices obtain routing verification data sets, which may include, but are not limited to, the following two methods:

[0154] Method A: The network device obtains a set of routing verification data from the server.

[0155] Method A corresponds to step 304 above, including method one and method two in step 304 above.

[0156] In one possible implementation, in method A, the server actively sends a set of route verification data to the network device. The network device receives the set of route verification data from the server and selects trusted route verification data from the set of route verification data for verification.

[0157] In another possible implementation, the network device sends a route verification data retrieval request to the server. Based on the route verification data retrieval request, the server sends a set of route verification data to the network device. The network device then selects trusted route verification data from the set of route verification data for verification.

[0158] Method B: The network device obtains a route verification data set from other nearby network devices. The network device then selects trusted route verification data from the route verification data set for verification. For example, after the first network device obtains the route verification data set, it synchronizes trusted route verification data (which can be the route verification data set itself or the trusted route verification data selected by the first network device for verification) to the second network device.

[0159] In this case, the first network device is directly or indirectly connected to the second network device, or the first network device and the second network device have historical communication.

[0160] In some embodiments, the process of verifying routing information can be divided into inbound routing information verification and outbound routing information verification, depending on the direction of routing information transmission.

[0161] For example, assume the current network device is the first network device, and the other network devices are the second network devices. When the first network device receives routing information sent by the second network device, the first network device can verify the routing information based on trusted routing verification data to determine whether the routing information is valid. This process can be called: inbound routing information verification. Optionally, if the first network device determines that the routing information has passed verification, the first network device can store the routing information.

[0162] It should be noted that after the first network device verifies the routing information from the second network device, it stores the routing information locally. However, if the routing information includes an originating AS number, the first network device may incorrectly modify the originating AS number in the locally stored routing information due to routing policy or software issues. Therefore, before sending the routing information to the third network device, the first network device can verify the routing information again; this process can be called outbound routing information verification. In other words, the first network device can perform outbound routing information verification not only on the routing information from the second network device but also on the routing information from the second network device.

[0163] Optionally, when the first network device receives routing information sent by the second network device, it may not verify the validity of the routing information but instead store it. Then, before sending the routing information to the third network device, the first network device may verify the routing information based on trusted routing verification data to confirm its validity. That is, the first network device does not perform inbound routing information verification on the routing information from the second network device, but instead performs outbound routing information verification.

[0164] In summary, the solution provided in this embodiment proposes a route verification method. After receiving route information, it verifies the route information based on trusted route verification data carrying trustworthiness information. The solution provided in this application introduces the concept of trustworthiness level during the route verification process by configuring trustworthiness information on the route verification data. By considering the trustworthiness level of the route verification data during route verification, the verification strategy for route information is optimized. This avoids conflicts in route verification results caused by route verification data with different trustworthiness levels, thereby improving the accuracy of route verification.

[0165] Furthermore, after the routing information is verified, when a network device receives data transmitted based on that routing information, it can use that routing information to forward the data. For example... Figure 5 As shown, the routing verification method provided in this application embodiment further includes:

[0166] Step 406: The network device receives the data packet; the network device determines the verification result of the routing information and the handling strategy corresponding to the credibility of the trusted routing verification data; if the handling strategy indicates to perform forwarding, the data packet is forwarded according to the routing information.

[0167] Different handling strategies are corresponding to different verification results and the degree of credibility of routing verification data.

[0168] Optionally, the handling strategy includes at least one of the following, but is not limited thereto, and the embodiments of this application do not specifically limit it:

[0169] (i) If the verification result of the routing information fails, but the credibility of the trusted route verification data is higher than the first threshold, or the credibility is high, the routing information is discarded, and the data packet can be forwarded through other routing information or the forwarding of the data packet can be rejected. For example, if the verification result of the routing information fails, but the credibility of the trusted route verification data is high, it indicates that the verification result is relatively reliable, therefore, the routing information is discarded.

[0170] (ii) If the verification result of the routing information fails, but the credibility of the trusted route verification data is lower than the first threshold but higher than the second threshold, or the credibility is medium, the handling strategy is to perform forwarding, but with a reduced priority. In other words, although the verification result of the routing information fails, if the credibility of the verification result is moderate, the routing information will be stored, but its usage priority will be reduced. For example, if the verification result of the routing information fails, but the credibility of the trusted route verification data is medium, it indicates that the credibility of the verification result is moderate. Therefore, the routing information will be stored, but its usage priority will be reduced when forwarding data packets.

[0171] (iii) If the verification result of the routing information fails, but the credibility of the trusted route verification data is lower than the second threshold, or the credibility is low, the handling strategy is to perform forwarding. That is, although the verification result of the routing information fails, if the credibility of the verification result is poor, the routing information will be stored, a prompt message will be displayed, and the data packet will be forwarded normally. For example, if the verification result of the routing information fails, but the credibility of the trusted route verification data is low, it indicates that the verification result is not very reliable. Therefore, the routing information will be stored, and the routing information can be used for data packet forwarding.

[0172] (iv) If the verification result of the routing information is unknown (i.e., no verification result), but the credibility of the trusted routing verification data is higher than the first threshold, or if the credibility is high, the routing information shall be discarded and the data packet may be forwarded through other routing information or the data packet may be refused to be forwarded.

[0173] (v) If the verification result of the routing information is unknown, but the credibility of the trusted route verification data is lower than the first threshold but higher than the second threshold, or the credibility is medium, the handling strategy is to perform forwarding, but reduce the priority. For example, if the verification result of the routing information is no verification result, but the credibility of the trusted route verification data is medium, it indicates that the credibility of the verification result is average. Therefore, the routing information is stored, but the priority of using the routing information is reduced when forwarding data packets.

[0174] (vi) If the verification result of the routing information is unknown, but the credibility of the trusted route verification data is lower than the second threshold, or the credibility is low, the handling strategy is to perform forwarding. For example, if the verification result of the routing information is no verification result, but the credibility of the trusted route verification data is low, it indicates that the verification result is not very reliable. Therefore, the routing information is stored and can be used for packet forwarding.

[0175] (vii) If the verification result of the routing information is successful, but the credibility of the trusted route verification data is higher than the first threshold, or the credibility is high, the handling strategy is to perform forwarding or prioritize forwarding. In other words, if the verification result of the routing information is successful and the credibility of the verification result is high, the routing information is stored and used preferentially during routing. For example, if the verification result of the routing information is successful and the credibility of the trusted route verification data is high, it indicates that the verification result is relatively reliable; therefore, the data packet is forwarded normally or prioritized for forwarding.

[0176] (viii) If the verification result of the routing information is successful, but the credibility of the trusted route verification data is lower than the first threshold but higher than the second threshold, or the credibility is medium, then the handling strategy is to perform forwarding. That is to say, if the verification result of the routing information is successful and the credibility of the verification result is moderate, then the routing information is stored. For example, if the verification result of the routing information is successful and the credibility of the trusted route verification data is moderate, it indicates that the credibility of the verification result is moderate. Therefore, the routing information is stored, and when forwarding data packets, the routing information is used normally for forwarding data packets.

[0177] (ix) If the verification result of the routing information is successful, but the credibility of the trusted route verification data is lower than the second threshold, or the credibility is low, the handling strategy is to perform forwarding but reduce the priority. In other words, although the verification result of the routing information is successful, if the credibility of the verification result is poor, the handling strategy is to perform forwarding but reduce the priority. For example, if the verification result of the routing information is successful, but the credibility of the trusted route verification data is medium, it indicates that the credibility of the verification result is average. Therefore, the routing information is stored, but the priority of using the routing information is reduced when forwarding data packets.

[0178] Furthermore, after the routing information verification is complete, the network device can send the verified routing information and verification result back to the server. For example... Figure 5 As shown, the routing verification method provided in this application embodiment further includes:

[0179] Step 408: If the routing information verification is complete, report the verification result and routing information corresponding to the routing information to the server.

[0180] For example, after the network device verifies the routing information, it reports the verification result and the routing information to the server. The server receives the verification result and routing information from the network device. The verification result includes the credibility information corresponding to the trusted route verification data. By reporting the verification result, the server can statistically analyze the verification results and quantity of routing information, and also help users perform more detailed routing security monitoring and analysis.

[0181] The routing information and verification results are sent by the network device after the routing information verification is completed.

[0182] Optionally, when uploading the verification result and routing information, the network device updates the first field of the data unit with the verification result; adds the routing information to the second field of the data unit; and sends the data unit to the server. The first field and the second field are different. The first field is a reserved field or a newly created type-length-value TLV field. Optionally, the first field includes: a path status field or a reason code field.

[0183] The data unit may be a BMP, but is not limited thereto, and the embodiments of this application do not specifically limit it.

[0184] In other words, the verification results can be uploaded by modifying the values ​​of the reserved fields to store the verification results; or, a new TLV field can be created to store the verification results.

[0185] In some embodiments, if the routing information verification is complete, the network device reports the verification result corresponding to the routing information to the server. The verification result includes the credibility information corresponding to the trusted routing verification data, which can also be described as: the verification result inherits the credibility information corresponding to the trusted routing verification data. The credibility information included in the verification result may be the same as or different from the credibility information in the trusted routing verification data; that is, the credibility information included in the verification result is obtained by combining the credibility information in the trusted routing verification data and the verification result.

[0186] For example, when verifying trusted routing information based on high-confidence data, the credibility information included in the verification result is H+ credibility level if the verification result is passed; when verifying trusted routing information based on medium-confidence data, the credibility information included in the verification result is H credibility level if the verification result is passed; and when verifying trusted routing information based on low-confidence data, the credibility information included in the verification result is H- credibility level.

[0187] When the verification result of the routing information is unknown, the credibility information included in the verification result based on high-credibility trusted routing information verification data is: M + credibility level; when the verification result of the routing information is unknown, the credibility information included in the verification result is: M credibility level; when the verification result of the routing information is unknown, the credibility information included in the verification result is: M - credibility level.

[0188] When verifying trusted routing information based on high-confidence data, the credibility information included in the verification result is L + credibility level when the verification result fails; when verifying trusted routing information based on medium-confidence data, the credibility information included in the verification result is L credibility level when the verification result fails; and when verifying trusted routing information based on low-confidence data, the credibility information included in the verification result is L - credibility level.

[0189] The credibility levels are ranked from highest to lowest as follows: H+ credibility level > H credibility level > H- credibility level > M+ credibility level > M credibility level > M- credibility level > L+ credibility level > L credibility level > L- credibility level.

[0190] Figure 6 This is a schematic diagram of a route verification method provided in an exemplary embodiment of this application. The method is executed by a network device. For example, the network device can be... Figure 2 Any one of the first network device 202, the second network device 203, and the third network device 204 shown in the diagram.

[0191] like Figure 6 As shown, the routing verification method provided in this application embodiment may include: (1) a routing verification data acquisition stage 60, (2) a routing verification data synchronization stage 61, (3) a routing information verification stage based on trusted routing data, and (4) a verification result reporting stage 62. That is, server 602 acquires routing verification data 601 from different sources. After configuring trust information on the routing verification data 601, server 602 synchronizes the routing verification data set with configured trust information to network device 603. After receiving the synchronized routing verification data set, network device 603 verifies the routing information 604 sent by other network devices based on the trusted routing verification data in the routing verification data set, and reports the verification result to server 602. The above stages will be described in detail below.

[0192] (1) Route verification data acquisition stage.

[0193] Trusted route verification data is obtained by configuring trust information on route verification data from different sources. The trust information configured in different locations within a set of route verification data indicates the degree of trustworthiness of different content within the route verification data.

[0194] For example, using a simple Linux utility for resource management (Simplified Local Internet Number Resource Management with the RPKI, SLURM), a JSON file is used to configure the trust information of route verification data. The trusted route verification data obtained in this way is the locally registered route verification data. This method supports three types of route verification data: route origin authorization (ROA), border gateway protocol security (BGPsec), and autonomous system provider authorization (ASPA).

[0195] For example, credibility information can be configured in the value of the Filters type in a JSON file. The code is shown below, where the bolded portion represents the configured credibility information. As can be seen from the code, the current credibility information is configured in a local position within "prefixFilters" in the Filters type value. Therefore, the credibility information "M" is only used to indicate the credibility of a local position in the route verification data, that is, to indicate the credibility of {"prefix":"192.0.2.0 / 24", "comment":"AllVRPs encompassed by prefix"}.

[0196] The code is as follows:

[0197] "prefixFilters": [

[0198] {

[0199] "prefix":"192.0.2.0 / 24",

[0200] "trustLevel":"M",

[0201] "comment":"All VRPs encompassed by prefix"

[0202] }

[0203] {"asn":64496,

[0204] "comment":"All VRPs matching ASN"

[0205] }

[0206] {"prefix":"198.51.100.0 / 24",

[0207] "asn":64497,

[0208] "comment":"All VRPs encompassed by prefix,matching ASN"

[0209] }]

[0210] For example, configure confidence information in the Assertions type value in a JSON file. The code is shown below, where the bolded portion represents the configured confidence information. As the code shows, the current confidence information is configured in a local position within "prefixAssertions" in the Assertions type value. Therefore, the confidence information "H" is only used to indicate the confidence level of a local position in the route verification data, specifically, to indicate the confidence level of {"asn":64496, "prefix": "198.51.100.0 / 24", "comment": "My other important route"}. The code is as follows:

[0211] "prefixAssertions": [

[0212] {

[0213] "asn":64496,

[0214] "prefix":"198.51.100.0 / 24",

[0215] "trustLevel":"H",

[0216] "comment":"My other important route"

[0217] }

[0218] {"asn":64496.

[0219] "prefix":"2001:DB8: / 32",

[0220] "maxPrefixLength":48,

[0221] "comment":"My other important de-aggregated routes"

[0222] }]

[0223] In some embodiments, the credibility of the global content of the route verification data can also be indicated based on the configuration location of the credibility information in the route verification data.

[0224] For example, the code below configures global credibility information for the entire Filters and the entire Assertions in a JSON file. The contents of "prefixFilters" and "prefixAssertions" are not shown. The code is as follows:

[0225] {"slurmVersion":2,

[0226] "validationOutputFilters":{

[0227] "aspaFilters":[],

[0228] "bgpsecFilters":[],

[0229] "prefixFilters":[…],

[0230] "trustLevel"M

[0231] }

[0232] {"locallyAddedAssertions":{

[0233] "aspaAssertions":[],

[0234] "bgpsecAssertions":[],

[0235] "prefixAssertions":[...],

[0236] "trustLevel"H

[0237] }

[0238] For example, the credibility information is related to the source of the route verification data, and the credibility information of route verification data from different sources is different.

[0239] Optionally, the reliability of the route verification data, indicated from highest to lowest, is as follows: locally registered route verification data, global route verification data, and route verification data inferred from local data. Locally registered route verification data is manually registered based on actual network conditions and has a high degree of reliability. However, route verification data inferred from local data uses machine learning and may have a certain probability of misjudgment, resulting in a very low degree of reliability. Global route verification data has a wide coverage and relatively complete data, placing it in the middle in terms of reliability.

[0240] (2) Routing verification data synchronization stage.

[0241] For example, after configuring trust information for the route verification data, the network device receives a set of route verification data from the server, which includes trusted route verification data.

[0242] Optionally, the network device receives a set of route verification data based on the RTR protocol. For example, the RTR protocol may be RFC6810, RFC8210, or draft-ietf-sidrops-8210bis-15, but is not limited thereto, and the embodiments of this application do not specifically limit it.

[0243] The process of synchronizing route verification data is as follows: (a) Establishing a connection. The network device establishes a connection with the server. (b) Requesting data. The network device sends a request to the server, requesting specific route verification data, all route verification data, or updated route verification data. (c) Data transmission. In response to the request, the server sends the set of route verification data to the network device.

[0244] The RTR protocol supports various types of Protocol Data Units (PDUs) carrying trusted route verification data. There are currently three versions of the RTR protocol, represented by 0-2. As the RTR protocol version increases, the number of supported PDU types also increases.

[0245] Table 2 shows the functions corresponding to the PDU types supported by the RTR protocol versions.

[0246] Table 2 shows the functions corresponding to the PDU types supported by the RTR protocol version.

[0247]

[0248]

[0249] In some embodiments, during the route verification data synchronization phase, trusted route verification data is carried in the first PDU of the RTR protocol through reserved fields or newly added fields. Optionally, the first PDU includes at least one of IPv4 Prefix PDU, IPv6 Prefix PDU, Router Key PDU, and ASPAPDU, but is not limited thereto, and the embodiments of this application do not specifically limit it.

[0250] For example, the server sends messages to the network device via a PDU of the RTR protocol, taking an IPv4 Prefix PDU as an example, such as... Figure 7 As shown in Figure (a), this message is route verification data without trust information. The fields included in this message are described in order as follows:

[0251] Protocol Version 1: The version number of the communication protocol between the server and the network device, occupying 1 byte. This value will increment as new fields are added in the future.

[0252] PDU Type4 (Protocol Data Unit Type 4): This is the type of the message, occupying 1 byte, indicating that the message is an IPv4 type message.

[0253] Zero: A padding field with a value of 0, occupying 2 bytes. This field is usually set to 0 and reserved for future use.

[0254] Length: Indicates the length of the entire message, which is fixed at 20 bytes.

[0255] Flags: 1 byte, set bit by bit. Bit 0 is currently in use, and the remaining 7 bits are unused. Bit 0 can be 0 or 1. When bit 0 is 0, it means the message is published. When bit 0 is 1, it means the message is withdrawn.

[0256] Prefix Length: 1 byte.

[0257] Max Length: 1 byte.

[0258] Zero: A padding field with a value of 0, occupying 1 byte. This field is usually set to 0 and reserved for future use.

[0259] IPv4 Prefix: This field occupies 4 bytes and can be used to carry the routing prefix.

[0260] Autonomous System Number: This field occupies 4 bytes and can carry the origin AS number.

[0261] After configuring the trustworthiness of the route verification data, since the trusted route verification data carries trustworthiness information, the packets at this point need to have an additional space added to store the trustworthiness information. For example... Figure 7 As shown in Figure (b), the increased data volume of routing verification data due to the addition of trustLevel (TL) information is stored by utilizing the Zero portion of the original message, which has a value of 0. This means that the trustLevel information is stored within the Zero portion of the original message. By utilizing the Zero portion of the original message, trustLevel information is carried without increasing the overall message length.

[0262] In some embodiments, during the route verification data synchronization phase, the network device may also request route verification data with specified trust information, which is carried in the second PDU of the RTR protocol through reserved fields or newly added fields. For example, the network device requests trusted route verification data from a locally registered source from a server. Optionally, the second PDU includes at least one of the following: Serial Notify PDU, Serial Query PDU, Reset Query PDU, Cache Response PDU, End of Data PDU, Cache Reset PDU, and Error Report PDU, but is not limited thereto, and the embodiments of this application do not specifically limit this.

[0263] For example, a network device requests route verification data specifying trust information from a server. The server sends a message to the network device via a PDU of the RTR protocol, such as... Figure 8 Figure (a) shows a Reset Query PDU, which is route verification data carrying specified trust information. The fields included in this message are: Protocol Version 1, PDU Type 2, Zero, and Length. This message carries the specified trust information in a manner similar to an IPv4 Prefix PDU. It utilizes the Zero portion (value 0) of the original message to store the increased data volume of the route verification data resulting from adding the specified trust information; that is, it stores the specified trust information. By utilizing the Zero portion of the original message, it carries the specified trust information without increasing the overall message length. Figure 8Figure (b) shows the Cache Response PDU, which is route verification data carrying specified trust information. The fields included in this message are: ProtocolVersion1, PDU Type8, Zero, and Length. The way this message carries the specified trust information is similar to that of the IPv4 Prefix PDU. It utilizes the Zero portion (value 0) in the original message to store the increased data volume of the route verification data due to the addition of the specified trust information; that is, it stores the specified trust information. By utilizing the Zero portion in the original message, it carries the specified trust information without increasing the overall message length.

[0264] (3) Routing information verification stage based on trusted routing data.

[0265] For example, after receiving the route verification data set synchronized by the server, the network device selects the route verification data that meets the conditions from the route verification data set as trusted route verification data to verify the routing information.

[0266] In some embodiments, network devices not only need to verify routing information but also need to forward data packets. Therefore, if a network device needs to verify the legitimacy of each routing information it receives, the network device may be under considerable pressure. Thus, in some cases, an external verification device can be used; that is, the process of verifying the legitimacy of routing information can be deployed on verification devices such as controllers, network management systems, or centralized analysis devices.

[0267] When a network device receives routing information, it sends it to an authentication device, which then verifies the legitimacy of the routing information. The authentication device then sends the verification result back to the network device. The authentication process is similar to the network device's verification process, and the way the network device processes the routing information based on the verification result is also similar to the network device's process of verifying and then processing the routing information based on the verification result.

[0268] In some embodiments, based on the above description, the routing information obtained by the network device may be inbound routing information or outbound routing information. The processing method for this routing information will differ depending on its direction and the verification result. These cases will be explained below.

[0269] In the first case, the routing information is for the inbound direction.

[0270] This routing information comes from other network devices, or in other words, from external neighboring network devices. If the routing information passes verification, the network device can store it. If the routing information fails verification, the network device discards it, or, if the routing information fails verification, stores it but sets its priority to a low priority.

[0271] Optionally, if the routing information fails verification, it indicates that the routing information may be captured or forged, resulting in relatively low security. Although the routing information is stored, higher-priority routing information can be selected during route selection, thereby guiding the forwarding of user traffic while preventing user traffic from being captured or monitored.

[0272] Of course, if the routing information fails verification, discarding the routing information directly can more directly prevent user traffic from being captured or monitored.

[0273] In the second case, the routing information is for outbound routes.

[0274] This routing information is the route information sent by this network device to other network devices, or in other words, the route information sent to internal neighboring network devices. Thus, if the routing information is verified, the network device sends it to other network devices so that the other network devices can store the routing information and then use it to forward data packets.

[0275] Based on the above description, when a network device receives incoming routing information, it may choose not to verify the information but instead store it. Alternatively, the network device may store the routing information only after successfully verifying it. That is, the routing information stored locally by the network device may be verified or unverified. Regardless of whether the routing information stored locally by the network device has been verified, if it is confirmed that the routing information has been verified before sending it to other network devices, the routing information can be sent directly to those devices.

[0276] (4) Verification result reporting stage.

[0277] For example, the network device sends the authentication result and routing information to the server via the BMP, such as... Figure 9 As shown, the fields included in this BMP are described in order as follows:

[0278] type (protocol type): The type of this BMP, occupying 16 bits.

[0279] length: Identifies the length of the entire BMP, which is fixed at 2 bytes.

[0280] index: Used to indicate the sequence number of the BMP, fixed at 2 bytes.

[0281] Path status: This field indicates the status of the route and is 4 bytes long, such as active or inactive.

[0282] Reason code: This field indicates the reason for the route verification result and is 2 bytes long.

[0283] When uploading verification results, there are two methods: First, the network device can update the first field in the BMP (Browser Management Platform), specifically the path status or reason code field. In other words, it can modify the value of the path status or reason code field to carry the verification result. Second, the network device can create a new TLV field on top of the BMP to store the verification result.

[0284] For example, different values ​​in Path Status correspond to different verification results. For instance, if the field value is 0x00000301, the corresponding verification result is rov-invalid-high. This verification result means that the verification result is invalid and has a high degree of credibility. In other words, the routing information is invalid, and this result is obtained using highly credible routing verification data.

[0285] The field value is 0x00000304, and the corresponding verification result is rov-valid-low. This verification result means that the verification result is valid, but the level of confidence is low. That is, the routing information is valid, and this result is obtained using low-confidence routing verification data.

[0286] It should be noted that the values ​​for the path status field or reason code field can be those assigned by IANA through official channels or custom values; this application embodiment does not impose specific limitations on this. For example, Table 3 shows the correspondence between the path status field values ​​and the verification results.

[0287] Table 3 shows the correspondence between the field values ​​of path status and the verification results.

[0288] Field value Verification results 0x00000001 Invalid: Invalid 0x00000002 Best: Best 0x00000004 Non-selected: Not selected 0x00000008 Primary: main 0x00000010 Backup: a spare 0x00000020 Non-installed: Not installed 0x00000040 Best-external: Best external 0x00000080 Add-Path: Add a path 0x00000100 Filtered in inbound policy: filtered by inbound policy 0x00000200 Filtered in outbound policy: filtered by outbound policy 0x00000400 Invalid ROV: Invalid route origin verification 0x00000800 stale: obsolete data 0x00001000 Suppressed: Data suppression

[0289] For example, Table 4 shows the correspondence between the values ​​of the "reason code" field and the verification results. Different field values ​​correspond to different reasons for the route verification results.

[0290] Table 4 shows the correspondence between the field values ​​of the reason code and the verification results.

[0291]

[0292]

[0293] After performing route verification based on trusted route verification data, network devices can forward corresponding data packets based on the verification results and the trustworthiness level corresponding to the trusted route verification data. The following section will describe the data packet sending phase in detail.

[0294] In summary, the solution provided in this embodiment proposes a route verification method. By introducing the concept of trustworthiness at each stage of route verification and considering the trustworthiness of trusted route verification data, it can differentiate data from multiple source route verification data sources, providing differentiated verification results and handling strategies. This avoids the problems of overly strict or lenient route verification and handling caused by using consistently high or low trustworthiness. The method optimizes the verification strategy for route information, the verification result reporting strategy, and the data packet handling strategy, thereby improving the accuracy of route verification.

[0295] The foregoing mainly describes the solution provided in this application. Accordingly, this application also provides a route verification device for implementing the above-described method embodiments.

[0296] In some embodiments, the routing verification device includes hardware structures and / or software modules corresponding to the execution of each function in order to achieve the above-described functions. Those skilled in the art will readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0297] This application embodiment can divide the routing verification device into functional modules according to the above method embodiment. For example, each function can be divided into a separate functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0298] In some embodiments, this application provides a route verification device, which is used to implement the functions of the route verification device in the above-described route verification method embodiments. For example... Figure 10 The diagram shows the structure of the route verification device. The route verification device may include a receiving module 1001, a verification module 1002, and a sending module 1003.

[0299] The receiving module 1001 is used to perform... Figure 4 The illustrated method includes step 402. Verification module 1002 is used to perform... Figure 4 The illustrated method includes step 404. The sending module 1003 is used to perform this operation. Figure 5 The illustrated method includes step 408.

[0300] In some embodiments, this application provides a route verification device, which is used to implement the functions of the route verification device in the above-described route verification method embodiments. For example... Figure 11 The diagram shows the structure of the route verification device. The route verification device may include an acquisition module 1101, a sending module 1102, and a receiving module 1103.

[0301] The acquisition module 1101 is used to perform the operation of acquiring route verification data. The sending module 1102 is used to perform... Figure 3 The illustrated method includes step 302. The receiving module 1103 is used to perform this operation. Figure 3 The illustrated method includes step 304.

[0302] like Figure 12 As shown, the computer device provided in this application embodiment may include a processor 1201, a bus 1202, a communication interface 1203, and a memory 1204. The processor 1201, the memory 1204, and the communication interface 1203 communicate with each other via the bus 1202. It should be understood that this application does not limit the number of processors and memories in the computer device.

[0303] Bus 1202 can be a PCI bus, an Extended Industry Standard Architecture (EISA) bus, or a UB bus, etc. Buses can be divided into address buses, data buses, control buses, etc. For ease of representation, Figure 12 The bus 1202 may be represented by a single line, but this does not mean that there is only one bus or one type of bus. The bus 1202 may include a path for transmitting information between various components of a computer device (e.g., memory 1204, processor 1201, communication interface 1203).

[0304] Processor 1201 may include any one or more processors such as CPU, graphics processing unit (GPU), microprocessor (MP), or digital signal processor (DSP).

[0305] The memory 1204 may include volatile memory, such as random access memory (RAM). The processor 1201 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0306] The communication interface 1203 uses transceiver modules, such as, but not limited to, network interface cards and transceivers, to enable communication between computer devices and other devices or communication networks.

[0307] The memory 1204 stores executable program code, which the processor 1201 executes to implement the functions of the routing verification device or the CPU core in the aforementioned method embodiments. That is, the memory 1204 stores information for executing the aforementioned routing verification method.

[0308] In another aspect, a computer-readable storage medium is provided, wherein at least one computer program is stored in the computer-readable storage medium, and the at least one computer program is loaded and executed by a processor to implement the routing verification method provided in the above-described method embodiments.

[0309] On the other hand, a computer program product is provided, which includes a computer program or instructions that, when executed by a processor, implement the routing verification method described above.

[0310] In another aspect, a chip system is provided, including at least one processor and at least one interface circuit, wherein the at least one interface circuit is used to perform transceiver functions and send instructions to the at least one processor, and when the at least one processor executes the instructions, the at least one processor executes to implement the routing verification method as described above.

[0311] The method steps in this embodiment can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Alternatively, the ASIC can reside in a computer device. Of course, the processor and storage medium can also exist as discrete components in the computer device.

[0312] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed on a computer, the processes or functions described in the embodiments of this application are performed entirely or partially. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user equipment, or other programmable device. The computer program or instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, the computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; it can also be an optical medium, such as a digital video disc (DVD); or it can be a semiconductor medium, such as a solid-state drive (SSD). The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method of route verification, characterized by, The method is applied to a network device, and the method includes: The routing information is verified based on trusted routing verification data; the trusted routing verification data is routing verification data carrying trust information, which is used to describe the degree of trustworthiness of the routing verification data.

2. The method of claim 1, wherein, The trusted route verification data is route verification data that meets the trust information conditions.

3. The method of claim 2, wherein, The conditions include: the credibility level indicated by the credibility information is the highest; or, the credibility level indicated by the credibility information is greater than or equal to the credibility threshold.

4. The method according to any one of claims 1 to 3, characterized in that, The trusted route verification data is obtained by configuring trust information in the route verification data; the trust information configured at different locations in a route verification data is used to indicate the degree of trustworthiness of different contents in the route verification data.

5. The method according to any one of claims 1 to 4, characterized in that, The credibility information is related to the source of the routing verification data, and the credibility information of routing verification data from different sources is different.

6. The method according to claim 5, characterized in that, The credibility information of routing verification data from different sources differs, including: The credibility information of the following route verification data indicates the level of credibility from highest to lowest as follows: locally registered route verification data, global route verification data, and route verification data based on local data inference.

7. The method according to any one of claims 1 to 6, characterized in that, The method further includes: Receive a set of route verification data from the server, the set of route verification data including the trusted route verification data.

8. The method according to claim 7, characterized in that, The receiving of the route verification data set from the server includes: receiving the route verification data set based on the Route Verification Data Synchronization (RTR) protocol.

9. The method according to any one of claims 1 to 8, characterized in that, The method further includes: If the routing information verification is completed, the verification result corresponding to the routing information and the routing information are reported to the server. The verification result includes the credibility information corresponding to the trusted routing verification data.

10. The method according to claim 9, characterized in that, The step of reporting the verification result corresponding to the routing information and the routing information to the server includes: The verification result is updated to the first field of the data unit; the routing information is added to the second field of the data unit, and the data unit is sent to the server; the first field is different from the second field; the first field is a reserved field, a newly created field, or a newly created type-length-value TLV field.

11. The method according to claim 10, characterized in that, The data unit uses the Border Gateway Monitoring Protocol (BMP), and the first field includes either a path status field or a reason code field.

12. The method according to any one of claims 1 to 11, characterized in that, The method further includes: Receive data packets; Determine the verification result of the routing information and the corresponding handling strategy based on the credibility level of the trusted routing verification data; different verification results and the credibility level of the routing verification data correspond to different handling strategies; If the handling policy indicates that forwarding should be performed, the data packet is forwarded according to the routing information.

13. A route verification method, characterized in that, The method is applied to a server, and the method includes: Obtain route verification data; A set of route verification data is sent to the network device. The set of route verification data includes trusted route verification data, which is used to verify the route information. The trusted route verification data is the route verification data carrying trust information, which is used to describe the trustworthiness of the route verification data.

14. The method according to claim 13, characterized in that, The method further includes: The system receives routing information and verification results from a network device. The verification results include credibility information corresponding to the trusted routing verification data. The routing information and verification results are sent by the network device after the routing information verification is completed.

15. The method according to claim 13 or 14, characterized in that, Credibility information configured at different locations in a route verification data set is used to indicate the degree of credibility of different content within the route verification data.

16. The method according to any one of claims 13 to 15, characterized in that, The method further includes: The trusted route verification data is obtained by configuring the route verification data based on one or more of the following methods: Simplified Local Internet Number Resource Management (SLURM), JavaScript Object Notation (JSON), or Extensible Markup Language (XML).

17. The method according to any one of claims 13 to 16, characterized in that, The credibility information is related to the source of the routing verification data, and the credibility information of routing verification data from different sources is different.

18. The method according to claim 17, characterized in that, The credibility information of routing verification data from different sources differs, including: The credibility information of the following route verification data indicates the level of credibility from highest to lowest as follows: locally registered route verification data, global route verification data, and route verification data based on local data inference.

19. The method according to any one of claims 13 to 18, characterized in that, The step of sending a set of route verification data to the network device includes: Based on the RTR protocol, the routing verification data set is sent to the network device.

20. A route verification device, characterized in that, The device includes: The verification module is used to verify the routing information based on trusted routing verification data; the trusted routing verification data is routing verification data carrying trust information, which describes the trustworthiness of the routing verification data.

21. A route verification device, characterized in that, The device includes: The acquisition module is used to obtain route verification data; The sending module is used to send a set of route verification data to the network device. The set of route verification data includes trusted route verification data, which is used to verify the routing information. The trusted route verification data is the route verification data carrying trust information, which is used to describe the trustworthiness of the route verification data.

22. A network device, characterized in that, The network device includes a processor and a memory, wherein the memory stores at least one computer program, and the at least one computer program is loaded and executed by the processor to implement the routing verification method as described in any one of claims 1 to 12.

23. A server, characterized in that, The server includes a processor and a memory, the memory storing at least one computer program, the at least one computer program being loaded and executed by the processor to implement the routing verification method as described in any one of claims 13 to 19.

24. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one computer program, which is loaded and executed by a processor to implement the routing verification method as described in any one of claims 1 to 19.

25. A computer program product, characterized in that, The computer program product includes a computer program or instructions that, when executed by a processor, implement the routing verification method as described in any one of claims 1 to 19.

Images