Routing source verification deployment recommendation method and system based on routing betweenness

Abstract

The invention discloses a routing source verification deployment recommendation method and system based on routing betweenness, and the method comprises the steps: S1, constructing an Internet routing system knowledge graph model through employing a routing data set disclosed in a network; s2, selecting an analyzed route prefix, obtaining a route propagation range based on the model, and constructing a network service sub-graph; s3, based on the network service sub-graph, simulating various prefix hijacking scenes in combination with routing information provided by the knowledge graph; and S4, giving a whole network routing source verification deployment recommendation scheme for protecting the network service subgraph by using a recommendation algorithm based on routing betweenness. The system is used for executing the method. The method has the advantages of simple principle, wide application range, good effect and the like.

Description

Technical Field

[0001] The present invention mainly relates to the field of Internet security technology, and particularly refers to a routing source verification deployment recommendation method and system based on betweenness centrality of routes. Background Art

[0002] On the Internet, there is an ongoing game between normal routes and malicious routes. Autonomous systems use the Border Gateway Protocol (BGP) to build an AS-level routing network, forming a BGP routing table that provides each AS with a specific routing path to a particular prefix. However, the 2023 Threat Landscape Report of the European Union Agency for Cybersecurity (ENISA) points out that BGP hijacking and BGP route leaks are still prevalent and continue to pose significant security threats. These security issues are mainly manifested as prefix hijacking incidents. The Google hijacking incident in 2017, the Amazon hijacking incident in 2018, and the KlaySwap hijacking incident in 2022 have all had a wide impact and caused considerable economic losses.

[0003] To address security issues such as prefix hijacking on the Internet, RPKI was proposed in 2008. RPKI participates in the game as a third party and aims to become an important support for normal service routes. ROA and ROV are closely coordinated processes. In RPKI, the certificate structure reflects the distribution of Internet address resources. Resources are initially distributed by IANA to Regional Internet Registries (RIRs), which then distribute them to Local Internet Registries (LIRs), and finally to their customers. On the RIPENCC website, daily summaries of ROAs from 5 RIR trust anchors are provided. After the ROA is published, AS border routers must perform ROV to achieve the protection effect. Given the current rapid growth of ROA, studying ROV deployment strategies is a very attractive topic. Currently, there has been a large amount of research work on measuring the deployment of ROV, and it has been found that the current deployment rate of ROV in the Internet is still not high, and there are still deficiencies in protection capabilities.

[0004] To study the ROV protection strategy for specific prefixes, it is crucial to understand the routing propagation among ASes. Through BGP routing, one can learn the AS to which a prefix belongs and the route to that AS. Currently, BGP routing data is mainly obtained from monitoring points distributed across the Internet. Route Views and RIPE RIS have the largest BGP monitoring systems in the industry and provide the most comprehensive and authoritative BGP monitoring data. The two projects mainly collect BGP Update messages and BGP RIB (Routing Information Base) data and make them publicly available on their respective websites. Based on these publicly available datasets, the CAIDA project obtains information such as business relationships between ASes, prefix ownership relationships, and AS organizational ownership relationships through corresponding inference algorithms and makes the results public. These publicly available datasets have been recognized by the academic community, and a large number of researchers have conducted extensive network research based on them, such as routing source authentication deployment measurement, AS hidden relationship inference, etc.

[0005] Betweenness is a mathematical concept in graph theory. Node betweenness refers to the proportion of the number of shortest paths between two vertices passing through a node in an undirected graph to the total number of shortest paths. Based on this idea, the concept of "betweenness centrality" emerged in the field of network science to describe the importance of a node in a network. In Internet routing, the more frequently an AS appears in a path, the more traffic it needs to be responsible for transmitting, and the higher its importance. By collecting and analyzing BGP routing in the Internet, the key ASes for routing propagation in the current routing state can be identified.

[0006] Currently, research on routing source verification for RPKI can be mainly divided into two types:

[0007] First, the method of passively measuring the deployment of routing source verification mainly listens to BGP update messages in the network and the associated RPKI verification information, and determines the execution of routing source verification by checking whether the BGP route announcements are consistent with the RPKI data.

[0008] Second, the method of actively measuring the deployment of routing source verification mainly refers to actively sending RPKI-verified BGP update packets with known status to routers in the network and analyzing the corresponding responses to determine the execution of routing source verification by the routers. These methods mainly focus on the analysis of the deployment of routing source verification.

[0009] Since the research on routing source verification deployment recommendations is a new research perspective for Internet RPKI deployment, there are currently no relevant methods based on routing betweenness for routing source verification deployment recommendations. Summary of the invention

[0010] The technical problem to be solved by the present invention is: in view of the technical problems existing in the prior art, the present invention provides a routing source verification deployment recommendation method and system based on routing betweenness which has a simple principle, a wide range of applications and good effects.

[0011] In order to solve the above technical problems, the present invention adopts the following technical solutions:

[0012] A recommended method for routing source verification deployment based on routing betweenness includes:

[0013] Step S1: Using the public routing data set on the Internet, a knowledge graph model of the Internet routing system is constructed;

[0014] Step S2: Select the analyzed routing prefix, obtain its routing propagation range based on the model and construct a network service subgraph;

[0015] Step S3: Based on the network service subgraph, multiple prefix hijacking scenarios are simulated in combination with the routing information provided by the knowledge graph;

[0016] Step S4: Use a recommendation algorithm based on routing betweenness to provide a recommended deployment solution for network-wide routing source verification that protects the network service subgraph.

[0017] As a further improvement of the method of the present invention: in the step S1, the AS business relationship, organizational relationship and prefix ownership relationship, BGP RI B data, and ROA entry data of RPKI resource information obtained from the data set are parsed and converted into triple form data and input into the graph database to construct a knowledge graph model of the Internet routing system.

[0018] As a further improvement of the method of the present invention: the process of step S3 includes:

[0019] Step S301: a method for simulating a hijacking scenario;

[0020] Step S302: Evaluate the hijacking effect based on the indicators.

[0021] As a further improvement of the method of the present invention: in step S301, the AS node set N is constructed h . N h The AS in the network has the ability to propagate routes to the network service subgraph and assumes its actual routes as hijacked route candidates R h , and obtain R h The AS set N' in the network service subgraph affected by the routing.

[0022] As a further improvement of the method of the present invention: the hijacking scenario in step S301 includes:

[0023] (a) Sub - prefix hijacking scenario; when the hijacked route reaches the network service sub - graph, all AS nodes in the graph that can receive it will select the more specific hijacked route; the AS nodes in this state have been hijacked and are moved from the set N to the set N'.

[0024] (b) Prefix hijacking scenario; when the hijacked route propagates into the network service sub - graph, the problem of path preference is considered; path preference is carried out according to the established routing rules between ASs and the BGP routing rules, and then it is judged whether the AS is currently hijacked.

[0025] As a further improvement of the method of the present invention: the step S302 includes: in the network service sub - graph, under normal circumstances, the prefix service for all AS nodes is complete, and the service integrity of each AS node is 1. According to this, the service integrity degree under normal circumstances is obtained by summation; after hijacking occurs, the service integrity of the AS node changes; when there are multiple paths for an AS to reach the victim AS, each path is judged separately, and the proportion of the path that can reach the victim AS normally among all the paths of this AS is used as the normal degree of this AS, that is, the service integrity interval of an AS is [0, 1]; an AS with a service integrity of 0 is called completely hijacked, an AS in the interval (0, 1) is partially hijacked, and an AS with a service integrity of 1 is a normal AS.

[0026] As a further improvement of the method of the present invention: the process of the step S4 includes:

[0027] Step S401: Initialize the routing source path verification recommendation set V and set the target service integrity degree S t , as an index of the strictness of the routing source verification recommendation scheme, perform iterative analysis of the hijacking scenario with AS as the smallest unit;

[0028] Step S402: During the iterative analysis process, combine the current situation of the routing source verification recommendation set, simulate the hijacking of ASs in the network service sub - graph and calculate the service integrity degree S under hijacking h ; if S h has been greater than S t or S h can no longer be improved, then jump to the next hijacking scenario for analysis, otherwise continue to perform routing source verification deployment recommendations in this scenario;

[0029] Step S403: Calculate the betweenness centrality of the ASs involved in the routing propagation path according to the hijacked route;

[0030] Step S404: Give the routing source verification deployment recommendation for the current analysis scenario.

[0031] As a further improvement of the method of the present invention: in step S403, the betweenness centrality is calculated using the formula; let G(N,E) be the Internet topology graph, N be the set of all AS nodes, E be the set of all edges, and B route (n i ) be the betweenness centrality of AS node v i , n j , n k be other AS nodes in the network topology, R jk (n i ) be the number of routes containing n j in the routing path from n j to n k , and R total be the total number of routes. The formula is as follows:

[0032]

[0033] As a further improvement of the method of the present invention: step S404 includes: removing the AS with the largest betweenness centrality, adding the AS with the highest betweenness centrality to the recommendation set V, and returning to step S403 for further analysis; if there is no AS available for recommendation, it is feedback that S h can no longer be improved, and return to step S403 to analyze the next scenario.

[0034] The present invention further provides a routing source verification deployment recommendation system based on betweenness centrality, which includes:

[0035] A network model for organizing large-scale routing information in the Internet public dataset and providing the necessary information for analysis;

[0036] A simulation unit for simulating hijacking events occurring in the Internet to support analysis and recommendation evaluation; the simulation unit runs on the basis of the constructed network model to simulate the state of hijacking scenarios in the Internet, and the recommendation algorithm analyzes the network service situation and evaluates the recommendation effect based on the simulation unit;

[0037] A recommendation unit for recommending the deployment of source routing verification for autonomous systems in the Internet.

[0038] Compared with the prior art, the advantages of the present invention are:

[0039] The routing source verification deployment recommendation method and system based on betweenness centrality of the present invention have simple principles, wide application ranges, and good effects; aiming at the sub-optimal deployment status of routing source verification deployment, the present invention analyzes the specific situation of Internet routing message propagation, and proposes a routing source verification deployment recommendation method based on betweenness centrality, which can recommend the process of autonomous system deploying routing source verification according to the current Internet routing situation, and effectively improve the effectiveness of RPKI security protection. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 It is a schematic flowchart of the method of the present invention.

[0041] Figure 2 It is a detailed flowchart of the present invention in a specific application example.

[0042] Figure 3 It is an ontology structure diagram of the knowledge graph of the Internet routing system in a specific application example of the present invention.

[0043] Figure 4 It is a schematic diagram of entities and semantics in the knowledge graph of the Internet routing system in a specific application example of the present invention.

[0044] Figure 5 It is a schematic diagram of relationships and semantics in the knowledge graph of the Internet routing system in a specific application example of the present invention. Detailed implementation manners

[0045] The present invention will be further described in detail below with reference to the accompanying drawings of the specification and specific embodiments.

[0046] In the description of the present application, it is necessary to understand the following terms:

[0047] BGP route hijacking is mainly divided into prefix hijacking and sub-prefix hijacking. Prefix hijacking refers to the situation where in a network, an autonomous system (AS) wrongly or maliciously announces that it has the routing information of a certain IP address prefix, while this IP address prefix actually belongs to another autonomous system. This behavior will cause network traffic to be wrongly routed to the hijacker's network. Sub-prefix hijacking is a special form of prefix hijacking, which involves an autonomous system wrongly or maliciously announcing a more specific IP address prefix (i.e., sub-prefix), and this sub-prefix is actually a subset of a broader prefix owned by another autonomous system.

[0048] Resource Public Key Infrastructure (RPKI) is a network security framework designed to enhance the security of the Internet routing infrastructure by using digital signatures. It is mainly applied to the routing security of the Border Gateway Protocol (BGP) to prevent prefix hijacking and other routing-related attacks; its working principle is as follows:

[0049] (1) Resource allocation: The allocation of IP address blocks and AS numbers is the responsibility of the Regional Internet Registries (RIRs), which are also the trust anchors in RPKI.

[0050] (2) Certificate Issuance: The RIR issues resource certificates to resource holders, and the holders use these certificates to create routing objects.

[0051] (3) Routing Object Publication: The holders publish the routing objects to a public RPKI repository, and these objects contain information about which ASes can announce specific IP prefixes.

[0052] (4) Routing Verification: BGP routers can download routing objects from the RPKI repository and use them to verify the validity of the received BGP route announcements.

[0053] A graph database is a new type of NoSQL database implemented based on graph theory. Its data storage structure and data query method are both based on graph theory. The basic elements of a graph in graph theory are nodes and edges, which correspond to nodes and relationships in a graph database. In a graph database, the relationships between data are formed into a graph structure through nodes and edges, and all the features of the database are implemented on this structure, such as the ability to perform operations such as creating, reading, updating, and deleting (Create, Read, Update, Delete, abbreviated as CRUD) graph data objects, as well as the ability to handle transactions and high availability. Currently, commonly used graph databases include Neo4j, OrientDB, TITAN, etc.

[0054] Currently, the deployment of the Resource Public Key Infrastructure (RPKI) in the Internet is growing continuously. Route Origin Authorization (ROA) and Route Origin Validation (ROV) need to work together to achieve the protection effect. In view of the suboptimal deployment status of ROV, it is necessary to analyze the specific situation of the propagation of Internet routing messages. The present invention proposes a method for recommending the deployment of route origin validation based on betweenness centrality, which can recommend the process of deploying route origin validation for autonomous systems (ASes) according to the current Internet routing situation, effectively improving the effectiveness of RPKI security protection.

[0055] As Figure 1 shown, the method for recommending the deployment of route origin validation based on betweenness centrality of the present invention includes:

[0056] Step S1: Using the publicly available routing data set in the network, construct a knowledge graph model of the Internet routing system;

[0057] That is, construct a knowledge graph model of the Internet routing system through information such as the BGP routing table and AS business relationships in the data set.

[0058] Step S2: Select the routing prefix for analysis, obtain its routing propagation range based on the model, and construct a network service subgraph;

[0059] Step S3: Based on the network service subgraph, simulate multiple prefix hijacking scenarios in combination with the routing information provided by the knowledge graph;

[0060] Step S4: Use the recommendation algorithm based on betweenness centrality to give a recommended deployment plan for verifying the whole network routing sources to protect the network service subgraph.

[0061] In a specific application example, in step S1, the AS business relationship, organizational relationship, and prefix ownership relationship obtained from the dataset, the BGP RIB (Routing Information Base) data, and the ROA entry data of the RPKI resource information are parsed and converted into triple-form data and input into the graph database to construct an Internet routing system knowledge graph model, and corresponding entities and relationships are formed to represent the corresponding semantics. See Figure 3 , Figure 4 , Figure 5 .

[0062] In a specific application example, in step S2, based on the Internet routing system graph constructed in step S1, select the target prefix for analysis, and construct a network service subgraph through its routing propagation range.

[0063] Furthermore, through the model, the propagation range of the prefix routing can be obtained from the AS2Prefix_Rel relationship. Define the set of nodes N formed by the ASs leading to this prefix, and the relationships between the AS nodes form the edge set E of the subgraph, thus forming the network service subgraph G(N, E).

[0064] See Figure 2 , in a specific application example, in step S3, based on the network service subgraph, simulate multiple prefix hijacking scenarios in combination with the routing information provided by the knowledge graph.

[0065] As a preferred embodiment, the process of step S3 may include:

[0066] Step S301: The method of simulating hijacking scenarios;

[0067] Step S302: Evaluate the hijacking effect based on metrics.

[0068] In the above step S301, as Figure 2 shown, based on the network service subgraph, according to the AS2Prefix_Rel relationship, obtain the prefixes that the AS node N can reach, and then obtain the AS node set N according to the Prefix relationship of the prefix h . Nh AS in it has the ability to propagate paths to the network service subgraph, so it is used as the set of candidate hijacker ASs. It is considered that hijacker ASs are usually in the customer access network, so in N h ASs that are the starting points of P2C_Rel relationships are excluded from the set to avoid the occurrence of unreasonable large-scale hijacking behaviors. N h The route propagation ability of ASs in the set is related to the routes of their prefixes, so the actual routes are assumed to be candidate hijacking routes R h and the set of ASs N' affected by the paths in R h is obtained.

[0069] In the above process, hijacking scenarios can include:

[0070] (a) Sub-prefix hijacking scenario;

[0071] When the hijacking route reaches the network service subgraph, all AS nodes in the graph that can receive it will select the more specific hijacking route. The AS nodes in this state have been hijacked and are moved from the set N to the set N'.

[0072] (b) Prefix hijacking scenario;

[0073] When the hijacking route propagates into the network service subgraph, the problem of path preference needs to be considered. Path preference is carried out according to the established routing rules between ASs and the BGP routing rules, and then it is judged whether the AS is currently hijacked. On the basis of this process, due to the routing problem involved, when an AS is hijacked, it is necessary to judge that all ASs on its path should select the hijacking route, otherwise misjudgment will occur.

[0074] In the above step S302, in the network service subgraph, under normal circumstances, the service of the prefix to all AS nodes is complete, so the service integrity of each AS node is 1, and the service integrity under normal circumstances can be obtained by summing according to this. After hijacking occurs, the service integrity of AS nodes changes. When an AS has multiple paths to the victim AS, each path will be judged separately, and the ratio of the path that can reach the victim AS normally to all paths of this AS is used as the normal degree of this AS, that is, the service integrity interval of an AS is [0,1]. Those with a service integrity of 0 are called completely hijacked, those in (0,1) are partially hijacked, and those with a service integrity of 1 are normal ASs. Through this processing method, combined with the paths in the R set of the network service subgraph, the ASs in the N' set are corrected to a certain extent, and a more accurate hijacking situation is obtained. At this time, the sum of the service integrity of all current ASs is statistically calculated, and the ratio with that under normal circumstances is obtained to get the service integrity degree maintained by the subgraph under hijacking. G(N,R) is the network service subgraph under normal circumstances, G h(N, R) is the network service subgraph under hijacking. I(n) represents the service integrity of AS node n, and n 0 belongs to N in G. n and n' belong to N and N' in G respectively h respectively. S(G h ) is the obtained service integrity under G h , and the formula is as follows:

[0075]

[0076] In a specific application example, the process of step S4 may include:

[0077] Step S401: Initialize the routing source path verification recommendation set V and set the target service integrity S t , as an index of the strictness of the routing source verification recommendation scheme, and perform iterative analysis of the hijacking scenario with AS as the smallest unit;

[0078] Step S402: During the iterative analysis process, combine the current recommendation set of the routing source verification, and simulate the hijacking of the AS in the network service subgraph according to the method of step S3 and calculate the service integrity S under hijacking h . If S h has been greater than S t or S h can no longer be improved, then jump to the next hijacking scenario for analysis, otherwise continue to deploy recommendations for routing source verification in this scenario;

[0079] Step S403: Calculate the betweenness centrality for the AS involved in the routing propagation path according to the hijacked route.

[0080] In step S403, use the formula to calculate the betweenness centrality. Take G(N, E) as the Internet topology graph, N as the set of all AS nodes, E as the set of all edges, B route (n i ) is the betweenness centrality of AS node v i , n j , n k are other AS nodes in the network topology, R jk (n i ) is the number of routes containing n i in the routing path from n j to n k , and R total is the total number of routes. The formula is as follows:

[0081]

[0082] Step S404: Give the routing source verification deployment recommendation for the current analysis scenario.

[0083] Remove the AS with the largest betweenness centrality (i.e., the AS where the hijacking originated), add the AS with the highest betweenness centrality to the recommended set V, and return to step S403 for further analysis. If there is no AS available for recommendation, feedback S h No further improvement can be obtained. Return to step S403 to analyze the next scenario. To recommend ASs in the Internet as source verification deployment points as efficiently as possible, the AS at the hijacked route end will not be selected for source route verification deployment, so as to avoid the extreme situation where all ASs in the network service subgraph are deployed for source route verification as much as possible.

[0084] The present invention further provides a routing source verification deployment recommendation system based on betweenness centrality, which includes:

[0085] A network model for organizing large-scale routing information in the Internet public dataset and providing the necessary information for analysis;

[0086] A simulation unit for simulating hijacking events occurring in the Internet to support analysis and recommendation evaluation;

[0087] A recommendation unit for recommending the deployment of source route verification for autonomous systems in the Internet.

[0088] In a specific application example, the simulation unit runs on the basis of the constructed network model to simulate the state of the hijacking scenario in the Internet, and the recommendation algorithm analyzes the network service situation based on the simulation unit and evaluates the recommendation effect.

[0089] The above are only the preferred embodiments of the present invention. The protection scope of the present invention is not limited to the above embodiments. All technical solutions falling within the idea of the present invention belong to the protection scope of the present invention. It should be noted that for those of ordinary skill in the art in this technical field, several improvements and refinements made without departing from the principle of the present invention should be regarded as within the protection scope of the present invention.

Claims

1. A routing source verification deployment recommendation method based on routing betweenness, characterized in that: include: Step S1: Using the public routing data set on the Internet, a knowledge graph model of the Internet routing system is constructed; Step S2: Select the analyzed routing prefix, obtain its routing propagation range based on the model and construct a network service subgraph; Step S3: Based on the network service subgraph, multiple prefix hijacking scenarios are simulated in combination with the routing information provided by the knowledge graph; Step S4: Use a recommendation algorithm based on routing betweenness to provide a recommended deployment solution for network-wide routing source verification that protects the network service subgraph.

2. The method for recommending routing source verification deployment based on routing betweenness according to claim 1, characterized in that: In step S1, the AS business relationship, organizational relationship and prefix ownership relationship, BGP RIB data, and ROA entry data of RPKI resource information obtained from the data set are parsed and converted into triple form data and input into the graph database to construct a knowledge graph model of the Internet routing system.

3. The method for recommending routing source verification deployment based on routing betweenness according to claim 1, characterized in that: The process of step S3 includes: Step S301: a method for simulating a hijacking scenario; Step S302: Evaluate the hijacking effect based on the indicators.

4. The method for recommending routing source verification deployment based on routing betweenness according to claim 3, characterized in that: In step S301, an AS node set N is constructed. h ; N h The AS in the network has the ability to propagate routes to the network service subgraph and assumes its actual routes as hijacked route candidates R h , and obtain R h The AS set N' in the network service subgraph affected by the routing.

5. The method for recommending routing source verification deployment based on routing betweenness according to claim 3, characterized in that: The hijacking scenarios in step S301 include: (a) Sub-prefix hijacking scenario; when the hijacking route reaches the network service subgraph, all AS nodes in the graph that can receive it will choose a more specific hijacking route; in this state, the AS node has been hijacked and moved from set N to set N'; (b) Prefix hijacking scenario: When the hijacked route is propagated into the network service subgraph, the path optimization problem is considered; the path optimization is performed according to the conventional routing rules between ASs and the BGP routing rules, and then it is determined whether the AS is currently hijacked.

6. The method for recommending routing source verification deployment based on routing betweenness according to claim 3, characterized in that: The step S302 includes: in the network service subgraph, under normal circumstances, the prefix provides complete services to all AS nodes, and the service completeness of each AS node is 1, and the service completeness under normal circumstances is obtained by summing up; after the hijacking occurs, the service completeness of the AS node changes; when there are multiple paths from the AS to the victim AS, the paths are judged separately, and the proportion of the paths that can normally reach the victim AS to all the paths of the AS is taken as the normality of the AS, that is, the service completeness interval of an AS is [0,1]; a service completeness of 0 is called a complete hijacking, between (0,1) is a partial hijacking, and 1 is a normal AS.

7. The method for recommending routing source verification deployment based on routing betweenness according to any one of claims 1 to 6, characterized in that: The process of step S4 includes: Step S401: Initialize the routing source path verification recommendation set V and set the target service completeness S t ,As an indicator of the strictness of the recommended scheme for routing source verification, the hijacking scenario is iterated with AS as the smallest unit; Step S402: During the iterative analysis process, the AS in the network service subgraph is simulated hijacked and the service integrity S under hijacking is calculated by combining the current recommendation set with the routing source verification. h ; if S h Already greater than S t or S h If no further improvement can be achieved, jump to the next hijacking scenario for analysis. Otherwise, continue with the routing source verification deployment recommendation in this scenario. Step S403: Calculate the route betweenness for the AS involved in the route propagation path according to the hijacked route; Step S404: Provide routing source verification deployment recommendations for the current analysis scenario.

8. The method for recommending routing source verification deployment based on routing betweenness according to claim 7, characterized in that: In step S403, the routing betweenness is calculated using the formula: G(N,E) is the Internet topology graph, N is the set of all AS nodes, E is the set of all edges, and B route (n i ) is the AS node v i The routing betweenness, n j 、n k For other AS nodes in the network topology, R jk (n i ) is from n j to n k The number of routes that contain ni in the routing path, R total is the total number of routes, and the formula is as follows:

9. The method for recommending routing source verification deployment based on routing betweenness according to claim 7, characterized in that: The step S404 includes: removing the AS with the largest routing betweenness, adding the AS with the highest routing betweenness to the recommended set V, and returning to step S403 to continue the analysis; if there is no AS to recommend, then feedback S h No further improvement can be obtained, and the process returns to step S403 to analyze the next scenario.

10. A routing source verification deployment recommendation system based on routing betweenness, characterized in that: include: Network models are used to organize large-scale routing information in public Internet data sets and provide the necessary information for analysis; A simulation unit is used to simulate hijacking events that occur on the Internet and support analysis and recommendation evaluation. The simulation unit runs on the basis of the constructed network model to simulate the state of the hijacking scenario on the Internet. The recommendation algorithm analyzes the network service situation based on the simulation unit and evaluates the recommendation effect. The recommendation unit is used to recommend the deployment of source routing verification in autonomous systems in the Internet.

Images