CN116684247A - Multi-management domain network verification method and system - Google Patents

Abstract

The present disclosure provides a multi-domain network authentication method, comprising: converting the router configuration file of each application server into an input format determined by a secure multiparty computing protocol to ensure compatibility among the application servers; performing simulation processing on the router configuration file meeting the input format so as to enable the multi-management-domain network to generate a secret data plane after convergence; and performing data plane verification on the secret data plane to obtain verification results on the various attributes of the multi-administrative domain network. The present disclosure also provides a multi-domain network authentication system.

Description

Multi-management domain network verification method and system

technical field

The present disclosure relates to the technical field of network security, in particular to a multi-management domain network verification method and system.

Background technique

Network verification is an automatic network fault detection technology. It judges whether the network behavior is correct or not by checking the data plane of the network device (that is, the routing table, access control table, flow table and other packet forwarding rule tables) and the control plane (that is, the device configuration file). Meet network correctness requirements, such as routing without loops, routing without black holes, reachability, etc. Figure 1 is an example diagram of data plane network verification in related technologies. By checking the forwarding information databases of router A and router B, the data plane verification system can determine that a packet with a destination IP address of 10.0.0.0 in the network will be forwarded between A and B. 0.1 will be discarded by B, thus entering a black hole, and neither of them can be delivered to the destination host Host 2 normally, resulting in network failure. Figure 2 is an example diagram of the control plane network verification of the related technology. Router A and router B are connected through the border network protocol BGP. The control plane verification system can judge that B will not lead to the destination IP prefix 10.0 by checking the configuration file of B. The BGP route of .0.0/31 is advertised to A, so that A cannot deliver any packet with a destination IP address of 10.0.0.0/31 to the destination host Host 2, which causes a network failure.

The network fault diagnosis tools in related technologies are mainly divided into the following three categories: the first type of research simulates the configuration file by constructing the same simulation environment as the actual network, and then uses the data plane verification tool to check the simulated data plane to achieve detection The purpose of the correctness of the configuration file; the second type of research builds a special abstract graph model by fusing the network configuration with the network topology, and verifies whether the configuration file satisfies the correctness of the network by looking for a path that satisfies specific conditions on the abstract graph; The three types of research use formal methods, use data logic to logically model the configuration files of network equipment and the correctness requirements that need to be checked, and judge whether the corresponding network configuration meets the corresponding requirements by checking the satisfiability of the logical model constructed. correctness.

However, the limitation of the first type of research lies in its effectiveness, and it cannot deal with problems arising from various real scenarios such as network delays; the limitation of the second type of research lies in its effectiveness and scope of use. Network protocol configuration. The limitation of the third type of research is that the scale is poor, and it takes a long time to verify the network reachability for some simple network configurations. In addition, whether it is the data plane or the control plane, the main object of the network verification tool service in the related art is a single management domain network, and the troubleshooting of multi-management domain network faults mainly depends on the network administrators of different management domains. Communication, such a verification method is inefficient.

Contents of the invention

In order to solve at least one of the above problems, the present disclosure provides a multi-management domain network verification method and system.

According to one aspect of the present disclosure, such a multi-management domain network verification method is proposed, including: converting the router configuration files of each application server into an input format determined by a secure multi-party computing protocol, so as to ensure compatibility among the application servers performance; perform simulation processing on the router configuration file satisfying the input format, so that the multi-management domain network generates a secret data plane after convergence; and perform data plane verification on the secret data plane to obtain information about the multi-management domain network Validation results for various attributes of the administrative domain network.

In some embodiments, the converting the router configuration files of each application server into the input format determined by the secure multi-party computing protocol includes: converting the router configuration files of each of the application servers into the same intermediate representation; converting the intermediate Represents conversion to the input format determined by the secure multi-party computation protocol.

In some embodiments, the input format determined by the secure multi-party computing protocol includes: an inter-domain routing information table, router configuration information of the application server, update status of router nodes of the application server, and a routing information update list, wherein The inter-domain routing information table is at least used to store route data, wherein the route data at least includes the prefix of the route announcement, the network protocol address of the next router node, the remaining router nodes passed by, and the local address of the current router node. priority, change router information; and the router configuration information of the application server is used to characterize the current relationship between the router node and the adjacent router node, wherein the router configuration information includes at least the Network protocol address, the current application server number of the router node, the application server number of the adjacent router node, the current interface network protocol address corresponding to the router node, and the current input and output strategy corresponding to the router node .

In some implementation manners, the simulating process on the router configuration file satisfying the input format, so that the multi-management domain network generates a secret data plane after convergence, includes: The inter-domain routing information table is initialized so that only original router nodes are stored in each of the inter-domain routing information tables; in response to update information of any of the inter-domain routing information tables, the router corresponding to the update information The node's peer router node sends routing notifications; and controls each of the router nodes to execute corresponding routing notifications until the multi-administrative domain network converges and generates the secret data plane.

In some implementation manners, the sending a route notification to the peer router node of the router node corresponding to the update information in response to any update information of the inter-domain routing information table includes at least: using an egress route function modeling the action of an export filter of the router node to convert the updated information into egress data; and modeling an import filter on the peer router node using an ingress route function and modifying the export data.

In some implementation manners, the performing data plane verification on the secret data plane to obtain the verification result on each attribute of the multi-administrative domain network includes: controlling the destination router node to perform a data-independent search operation, and judging the Whether there is a path to the ingress router node in the effective path corresponding to the destination router node; and in response to the presence of a path to the ingress router node, determine that the ingress router node to the destination router node satisfies reachability, so as to obtain information about A verification result of the reachability attribute of the multi-administrative domain network.

In some embodiments, the method further includes: when performing data plane verification on the secret data plane, encrypting the private value of each application server to prevent the private value from being read.

In some embodiments, after the data plane verification is performed on the secret data plane to obtain the verification results about the attributes of the multi-management domain network, it includes: synchronizing the verification results to each of the applications server, so that each of the application servers obtains the attributes satisfied by the multi-management domain network.

In some embodiments, before converting the router configuration file of each application server into the input format determined by the secure multi-party computing protocol to ensure the compatibility between each of the application servers, it includes: converting each of the application servers The router nodes are connected and authenticated with the proxy server, and the router configuration information of each router node is sent to the proxy server.

According to another aspect of the present disclosure, such a multi-management domain network verification system is provided, including: a configuration parsing module for converting the router configuration files of each application server into an input format determined by a secure multi-party computing protocol, so as to ensure that each Compatibility between the application servers; a routing protocol simulation module, used to simulate the router configuration file satisfying the input format, so that the multi-management domain network generates a secret data plane after convergence; and data plane verification A module, configured to perform data plane verification on the secret data plane, so as to obtain verification results on various attributes of the multi-management domain network.

Description of drawings

The accompanying drawings illustrate exemplary embodiments of the present disclosure and, together with the description, serve to explain the principles of the disclosure, are included to provide a further understanding of the disclosure, and are incorporated in and constitute this specification. part of the manual.

FIG. 1 is an example diagram of data plane network verification in the related art.

FIG. 2 is an example diagram of network verification of a control plane in the related art.

Fig. 3 is a block diagram of a multi-management domain network verification method according to an exemplary embodiment of the present disclosure.

Fig. 4 is a schematic diagram of a multi-management domain network verification system according to an exemplary embodiment of the present disclosure.

FIG. 5 is a schematic diagram of an InCV cloud server architecture according to an exemplary embodiment of the present disclosure.

FIG. 6 is a schematic diagram of configuration file vendor neutralization in an exemplary embodiment of the present disclosure.

7 to 14 are sequentially schematic diagrams of codes of DO-Simulation algorithms 1 to 8 in an exemplary embodiment of the present disclosure.

Fig. 15 is a code schematic diagram of a data-independent algorithm according to an exemplary embodiment of the present disclosure.

Fig. 16 is a comparison diagram of time overheads of networks of different scales according to an exemplary embodiment of the present disclosure.

Fig. 17 is a comparison diagram of communication rounds and global numbers of networks of different scales according to an exemplary embodiment of the present disclosure.

FIG. 18 is a graph comparing InCV of an exemplary embodiment of the present disclosure with a non-FASTPLANE optimized version.

Detailed ways

The present disclosure will be further described in detail below with reference to the drawings and embodiments. It can be understood that the specific implementation manners described here are only used to explain relevant content, rather than to limit the present disclosure. It should also be noted that, for ease of description, only parts related to the present disclosure are shown in the drawings.

It should be noted that, in the case of no conflict, the implementation modes and the features in the implementation modes in the present disclosure can be combined with each other. The technical solutions of the present disclosure will be described in detail below with reference to the accompanying drawings and in combination with implementation manners.

Unless otherwise specified, the illustrated exemplary embodiments/embodiments are to be understood as exemplary features providing various details of some manner in which the technical idea of the present disclosure can be implemented in practice. Therefore, unless otherwise stated, the features of various embodiments/embodiments may be additionally combined, separated, interchanged, and/or rearranged without departing from the technical concept of the present disclosure.

The terminology used herein is for the purpose of describing particular embodiments and is not of limitation. As used herein, the singular forms "a" and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. In addition, when the terms "comprising" and/or "comprising" and their variants are used in this specification, it means that the stated features, integers, steps, operations, parts, components and/or their groups exist, but do not exclude One or more other features, integers, steps, operations, parts, components and/or groups thereof are present or in addition. Note also that, as used herein, the terms "substantially," "about," and other similar terms are used as terms of approximation and not as terms of degree, and as such, they are used to explain what one of ordinary skill in the art would recognize. Inherent deviations from measured, calculated and/or supplied values.

Fig. 3 is a block diagram of a multi-management domain network verification method according to an exemplary embodiment of the present disclosure. Each step of the multi-management domain network verification method S100 will be described in detail below with reference to FIG. 3 .

As shown in FIG. 3, according to one aspect of the present disclosure, such a multi-management domain network verification method S100 is proposed, including:

Step S102, converting the router configuration files of each application server into the input format determined by the secure multi-party computing protocol, so as to ensure the compatibility between each application server.

Step S104, performing simulation processing on the router configuration file satisfying the input format, so that the multi-management domain network generates a secret data plane after convergence.

Step S106, performing data plane verification on the secret data plane to obtain verification results about various attributes of the multi-management domain network.

The router configuration file is used to represent the configuration information of the routing node in the application server. The Secure Multi-party Computation (SMPC) protocol uses cryptographic algorithms to ensure data security in the process of data plane verification to avoid data leakage and forgery.

In some implementations, the specific implementation of step S102 includes: converting the router configuration files of each application server into the same intermediate representation; converting the intermediate representation into an input format determined by the secure multi-party computing protocol.

In some embodiments, the input format determined by the secure multi-party computing protocol includes: inter-domain routing information table (Routing Information Base, RIB), router configuration information Config of the application server, router node update status HasUpdate of the application server, and routing information update list UpdateList, wherein the inter-domain routing information table is at least used to store route data Route, wherein the route data at least includes the prefix Prefix announced by the route, the network protocol address NextHop of the next router node, the remaining router nodes AsPath passed through, and the current router node The local priority LocalPref, change router information IDs; and the router configuration information of the application server are used to represent the relationship between the current router node and the adjacent router node, wherein the router configuration information includes at least the network protocol address PeerAddress of the adjacent router node , the application server number LocalAs of the current router node, the application server number RemoteAs of the adjacent router node, the interface network protocol address Interface corresponding to the current router node, and the input and output policy Policy corresponding to the current router node.

Wherein, the input and output policy Policy corresponding to the current router node includes at least an import policy ImportPolicy and an output policy ExportPolicy.

In some embodiments, the specific execution steps of step S104 include: initializing the inter-domain routing information table of the router node in each application server, so that only the original router node is stored in each inter-domain routing information table; The updated information of the inter-routing information table sends routing notifications to the peer router nodes of the router nodes corresponding to the updated information; and controls each router node to perform corresponding routing notifications until the multi-management domain network converges and generates a secret data plane.

In some embodiments, in response to the update information of any inter-domain routing information table, sending a route notification to the peer router node of the router node corresponding to the update information at least includes: using the export route function to export the filter of the router node An action is modeled to convert update information into egress data; and an ingress route function is used to model an ingress filter on a peer router node and modify the egress data.

In some embodiments, the specific execution steps of step S106 are: controlling the destination router node to perform a data-independent search operation, determining whether there is a path to the ingress router node among the effective paths corresponding to the destination router node; The path from the ingress router node to the destination router node is determined to be reachable, so as to obtain the verification result of the reachability attribute of the multi-administrative domain network.

In some implementations, the multi-management domain network verification method S100 further includes: when performing data plane verification on the secret data plane, encrypting the private value of each application server to prevent the private value from being read.

In some implementations, after step S106, it includes: synchronizing the verification result to each application server, so that each application server obtains the attributes satisfied by the multi-management domain network.

In some implementation manners, before step S02, it includes: connecting and authenticating the router nodes of each application server with the proxy server, and sending the router configuration information of each router node to the proxy server.

Fig. 4 is a schematic diagram of a multi-management domain network verification system according to an exemplary embodiment of the present disclosure.

Referring to FIG. 4 , the disclosed system can be divided into three modules connected in series: a configuration analysis module, a routing protocol simulation module under privacy protection, and a data plane verification module under privacy protection.

Specifically, the configuration parsing module is used to convert the router configuration files of each application server into the input format determined by the secure multi-party computing protocol (that is, the SMPC input in a unified format), so as to ensure the compatibility between each application server. The routing protocol simulation module is used for simulating the router configuration file satisfying the input format, so that the multi-administrative domain network generates a secret data plane (that is, a private data plane RIB) after convergence. The data plane verification module is used to perform data plane verification on the secret data plane, so as to obtain verification results about various attributes of the multi-management domain network.

In some implementations, the data plane verification module also returns the verification results to all participants, that is, each application server, in a public manner. For example, AS (Application Server, application server) 1, AS2, and AS3, manufacturers of each AS are not limited here.

Specifically, the configuration parsing module is firstly responsible for the connection and authentication between the eBGP (external Border Gateway Protocol, external Border Gateway Protocol) router and the proxy server. After completing the authentication, the eBGP router of each AS can send the configuration to the proxy server, or make configuration changes. Further, the configuration parsing module converts the router configuration files of each application server into the input format determined by the SMPC protocol, so as to solve the compatibility problem between different application servers.

The converted input data of the routing protocol simulation module (DO-Simulation) under privacy protection is processed by the simulation algorithm DO-Simulation of InCV for fast multi-management domain network verification. The DO-Simulation algorithm simulates the route advertisement in BGP (Border Gateway Protocol, border network protocol). However, during the execution of the DO-Simulation algorithm, none of the parties involved in the calculation (or proxy routers) will disclose private information. After running the DO-Simulation process, the network will generate a secret data plane RIBs after convergence, which is the basis for the next step DO-DPV (DO-Data Plane Validation, data source plane verification).

Data Plane Verification Module under Privacy Preservation (DO-DPV) According to the operator's specification, DO-DPV verifies different attributes. It also guarantees data independence for all verification functions for a given secret data plane. The final verification results of DO-DPV are disclosed to all participating parties to indicate whether certain properties are satisfied in the network under a given configuration

Rapid Multi-Administrative Domain Network Validation InCV is a cloud-based validation system designed to enable collaboration among network operators to determine whether their Autonomous Systems (ASes) and router configurations meet specific properties. By keeping the configuration information of each AS secret during computation, InCV prevents configuration information from being leaked among participants.

To better illustrate the design, we assume that each AS behaves as a single eBGP router, reducing the topology complexity by ignoring the topology inside the AS. We think this assumption is reasonable, since cross-domain verification mainly focuses on the correctness of the configuration used between ASs.

FIG. 5 is a schematic diagram of an InCV cloud server architecture according to an exemplary embodiment of the present disclosure.

Referring to Figure 5, each participating eBGP router in InCV (such as P0, P1, P3, P4) will be assigned its own proxy server in the cloud, responsible for performing privacy configuration conversion and secure calculation. During computation, each agent first converts the configuration into a compatible input of the SMPC protocol, and then communicates with other agents to safely and collaboratively compute the output. This design is necessary due to the massive scale of InCV computation, which requires tens of thousands of rounds of communication and data streams of hundreds of gigabytes (gigabytes). The information exchange between data planes is private, while the verification results are public; the network topology is also public and can be accessed at any time; user commands are also public.

Based on the foregoing, InCV's cloud service architecture has the following advantages: Better performance. By utilizing the high bandwidth and low latency of the cloud environment, InCV's performance can be significantly improved. High privacy, through identity authentication and authority control on the agent side, InCV ensures that the configuration information of each AS is kept secret from other participants during the calculation process, thereby protecting configuration privacy. Strong scalability, since the proxy server performs calculations in the cloud, InCV can easily expand its computing power to adapt to the growing network scale. Better full connectivity, usually SMPC computing requires full connectivity between participants, or at least two can communicate with each other, but in real networks, due to complex routing control, it is difficult for communication between multiple ASs to meet this requirement. Requirements, and the use of cloud service architecture can efficiently solve this problem.

FIG. 6 is a schematic diagram of configuration file vendor neutralization in an exemplary embodiment of the present disclosure.

Referring to Figure 6, in the process of interaction between the eBGP router of the participating party and the proxy server in the cloud, the conversion of privacy configuration is a relatively critical step. Its purpose is to achieve vendor neutralization of the configuration. Vendor neutrality (Vendorneutrality) means that a product, service or system is not biased towards any specific manufacturer or supplier when it is designed and implemented, but can support equipment input from all manufacturers. In an inter-domain network, it is very common that different ASs (such as AS1, AS2, and AS3) use routers and network equipment from different suppliers. Configuration languages vary among major vendors, and even implementing the same strategy can vary significantly.

To meet this challenge, we modified the source code of Batfish, a network verification tool. First, we converted router configurations from different vendors into the same intermediate representation; and then converted the intermediate representation of router configuration files into the input format determined by the SMPC protocol. This approach solves compatibility issues between different devices.

The SMPC protocol defines the data structure of each node in the algorithm implementation process. The input format of each router node can be determined by the inter-domain routing information table RIB, the router configuration information Config of the application server, the router node update status HasUpdate of the application server, and the routing information The update list UpdateList consists of four parts. Among them, the RIB is stored in an array, and each entry in the array is a data structure of the Route type. Config represents the configuration of the router node, and HasUpdate uses Boolean data to indicate whether the current node is updated. UpdateList is stored in an array, and each entry in the array is the updated route Route and its type Type, where Type uses short type data and uses 0, 1, and 2 to represent three update types: add, delete, and update, respectively.

Route consists of Prefix (network prefix), NextHop (next hop), AsPath (As path), LocalPref (local preference), Med (multi-exit discriminator) and IDs (routing ID). Among them, Prefix represents the prefix announced by this route, which is composed of ip and mask mask. NextHop is an ip address representing the next hop. AsPath uses array storage, which represents the router nodes that need to pass through. LocalPref represents the local priority of this route, and IDs are used for revoking and updating, represented by the router name and sequence number, and the sequence number is the time sequence added to the routing table to ensure uniqueness; for example, A_1. For example, when route l1 in A is withdrawn, route l2 of neighbor B is correspondingly withdrawn, and B needs to determine l2.OriginID=l1.RIBID to delete.

Config is the configuration of each node, which contains the relationship of each neighbor router, including PeerAddress, LocalAs, RemoteAs, Interface and Policy. PeerAddress represents the ip address of the neighbor, LocalAs represents the As number of the router, RemoteAs represents the As number of the neighbor router, and Interface represents the network protocol IP address of the interface. Policy includes ingress policy ImportPolicy and egress policy ExportPolicy. ImportPolicy is stored in an array, where each entry is a routemap. Each routemap contains several match statements and set statements. The match statement contains Match PrefixList and Match NextHop, which are used to match the prefix list and next hop; the Set statement contains Set LocalPref and Set Metric, which are used to set local priority and Metric. Boolean actions are used to indicate whether the policy is deny or permit.

7 to 14 are sequentially schematic diagrams of codes of DO-Simulation algorithms 1 to 8 in an exemplary embodiment of the present disclosure.

For the routing protocol simulation module under privacy protection, eight DO-Simulation algorithms are involved. The following will briefly describe each algorithm with reference to Figure 7 to Figure 14 .

The goal of DO-Simulation is to transform the private inputs of multiple agents into a data plane, which will serve as the basis for property verification in subsequent steps.

Like many other authentication algorithms, DO-Simulation is performed for each ip prefix p specified by the network administrator. Likewise, we consider the router announcing the ip prefix p to be publicly known, which is called origin. Router advertisements received by router n are stored in RIB(n), which stands for Routing Information Base RIB, which is a data table stored in a router that lists routes to specific network destinations, and the metrics associated with those routes . In the initialization step of the algorithm, only the RIB (Origin) has an entry for p, and the RIBs of other routers are assigned empty values. This is to model the state of the network when the origin has just discovered p. Has_update is a boolean array indicating whether the router has route advertisements to import. Similarly, only has_update(p) will be assigned True.

Referring to Figure 7, the function Converge(), as Algorithm 1, consists of multiple iterations until the network simulation converges; that is, if all elements in has_update() are false, the network is converged. In each iteration, the algorithm selects a router whose RIB has changed and sends out route advertisements to its peers. The change of RIB refers to the change of the optimal route of the router due to the insertion of a better route or withdrawal of the optimal route. These RIB changes are stored in update_list, a global array with |n| dimensions, where |n| is the number of parties. Then, load the RIB changes into a temporary variable called updates. All updates are passed through ExportRoutes() to model the action of the export filter, which converts updates into exports (output). The ImportRoutes() function models import filters on peer router n and similarly modifies exports.

Referring to Figure 8, the ExportRoutes() algorithm is used as Algorithm 2 to model the export filter. If the type of the updated route is add (add), first clear the non-transitive attribute of the route; if the AS path contains the AS of the peer, then This route is not exported. After that, apply the export policy to see if the route is allowed to be exported; if the route is allowed to be exported, first add the as number of the as-path sender and set the next hop ip. Finally put the route into the exports array. If the updated routing information is delete (delete), update (update), it will be exported directly.

Referring to Figure 9, the ImportRoutes() algorithm, as Algorithm 3, is used to model import filters. If the type of the updated route is add and the AS path of the route contains the AS of the peer, the route will not be imported. Apply importpolicy to this route to see if the route is allowed to be imported; if import is allowed, add this route to the peer's RIB. If the type of the updated route is delete or update, delete or update this route in the RIB of the peer.

Referring to FIG. 10 , the PolicyOutAllowed algorithm and the PolicyInAllowed algorithm are used as Algorithm 4 to implement import and export policies for routes. Traverse all outPolicy (external policies) to see if they match the match statement, and if they match, execute the corresponding set statement.

Referring to FIG. 11 , the Match algorithm is used as Algorithm 5 for matching route prefixes and next hops.

Referring to FIG. 12 , the Set algorithm is used as Algorithm 6 to set the local priority and next hop.

Referring to Figure 13 and Figure 14, the UpdateRIB algorithm is used as Algorithm 7, which is used to deal with the situation that the best route in the peer's RIB changes due to import; if the type of the updated route is add, first update the OriginID and RIBID of the route , and then add the new RIB changes to update_list(peer), assign has_update(peer) to True, and update the peer's RIB. If the update type is delete and update, corresponding to the revocation and update of the route, first match whether OriginID and RIBID are equal, if they match, add the new RIB change to update_list(peer), and assign has_update(peer) to True, And update the peer's RIB. When a route advertisement is imported, it is inserted at position k of the peer's RIB, with all k-1 routes before it having higher priority. The process of comparing the routes in the RIB is implemented through the PriorityCompare algorithm (namely, Algorithm 8), which is consistent with the route selection rules in BGP. First, the local priority is compared, and then the length of the AS Path and the MED are compared.

Data-oblivious is a method of computation that requires that all operations be performed without revealing any information about the input data. In other words, the execution of a data-independent algorithm does not depend on the specific values of the input data, so information about the input data cannot be inferred by observing the execution of the algorithm.

Data-independent algorithms are of great significance in the fields of privacy protection and security, especially in scenarios such as secure multi-party computation (SMPC) and fully homomorphic encryption. By using data-agnostic algorithms, computations can be performed across multiple parties while ensuring that their input data is not leaked to other parties or third-party observers.

A typical example of a data-independent approach is a sorting algorithm based on secure multi-party computation. In this case, multiple parties can collaborate to sort a set of numbers, but during the entire process, they cannot obtain any information about the input data of other parties. In this way, the data-agnostic approach preserves the privacy of the participants while allowing them to perform collaborative computations without revealing critical information.

Securely outsourced computation is used to incentivize this work, and we assume computation is performed on protected data. This means that all inputs and intermediate results are unknown to the party or parties performing the computation. Unless we explicitly open their values in order to access the data in a specific location. For the sake of specificity of illustration, we use the notation [x] to indicate that the value of x is protected from the entity performing the computation.

In order to maintain data privacy, we must ensure that the computing party does not learn anything about the data during the execution of the algorithm. Because it is assumed that every private value is sufficiently protected, the only way for a computing party to infer information about private data is when the sequence of instructions or the memory access pattern of an algorithm depends on the data. Therefore, to guarantee data privacy, we formally formulate the data-forgetting execution of a deterministic algorithm as follows:

Definition 1: Let d denote the input of the algorithm. Likewise, let A(d) denote the sequence of memory accesses made by the algorithm. An algorithm is said to be data-independent if, for two inputs d and d' of equal length, the algorithm executes the same sequence of instructions, and each party performing the computation cannot distinguish between the access patterns A(d) and A(d') of.

Without loss of generality, in the following description we use arithmetic operations to implement Boolean operations. In particular, we realize the conjunction a∧b by a·b, and the complement a of Boolean a by (1-a).

Fig. 15 is a code schematic diagram of a data-independent algorithm according to an exemplary embodiment of the present disclosure.

DO-Simulation implements a data-independent execution mode to prevent information leakage. In most cases, access patterns can be logged even if the data is encrypted. Here, we illustrate the data-independent algorithm through a function priority compare (i.e. strategy 1 and strategy 2 in Figure 15) that is frequently used in DO-Simulation to determine routing priority. According to previous work, the algorithm is data-independent because the control flow of the program is fixed and public, and all parties can follow it in unison. Furthermore, for intermediate calculations of variables, we do so with a protocol suitable for safe calculations in binary or arithmetic circuits.

The data plane verification module DO-DPV under privacy protection tries to verify network properties (such as reachability, isolation, etc.) on the secret data plane generated by DO-Simulation. As a prototype, we assume that routing reachability is equal to forwarding reachability, and translate these properties into a linear scan operation on the rib. For example, to verify that A can reach B, we do a data-independent search of B's RIB to check if there is a valid entry to destination A.

The disclosure also optimizes the convergence speed of routing simulation, combines FASTPLANE routing simulation calculation acceleration technology, and reduces unnecessary routing revocation by selecting a reasonable route propagation simulation sequence, speeds up convergence speed, and ultimately improves system performance. The key idea of FASTPLANE is to send the globally optimal route announcement first. For monotonic networks, FASTPLANE can efficiently generate data planes by choosing an appropriate propagation order. However, FASTPLANE cannot be applied to non-monotonic networks. Because route withdrawal occurs when simulated according to the above propagation order, and FASTPLANE does not perform the withdrawal operation. To support non-monotonic networks, we implemented a FASTPLANE-based route withdrawal operation. Experiments under all our datasets show that this design can speed up the simulation process by reducing the frequency of route withdrawals. However, this design may lead to inefficiencies in specific networks, such as each router prefers routes with longer paths.

We conduct extensive experiments to demonstrate the feasibility and benefits of InCV.

Fig. 16 is a comparison diagram of time overheads of networks of different scales according to an exemplary embodiment of the present disclosure.

As shown in Figure 16, the abscissa is the number of network nodes (Number of Network Node), the ordinate is the verification time (Verification Time), and the unit of the verification time is microseconds (μs). In terms of SMPC overhead, InCV compares Because the plaintext version takes 10^7-10^9 times longer, this is also a common problem in the performance of complex problem secure multi-party computation solvers. For a network of 32 nodes, the plaintext verifier can complete the verification within about 10us, and the ciphertext version takes about 52 minutes.

Fig. 17 is a comparison diagram of communication rounds and global numbers of networks of different scales according to an exemplary embodiment of the present disclosure. The abscissa in Fig. 17(a) is the number of network nodes (Number of Network Node), and the ordinate is the total data transmission rate (Global Data Sent), and the unit of the total data transmission rate is GB. The abscissa in Figure 17(b) is the number of network nodes (Number of Network Node), the ordinate is the total communication rounds (Average Communication Rounds), and the unit of the total communication rounds is k.

As shown in (a) and (b) of Figure 17, the change trend of InCV global communication rounds and communication data volume with the increase of network scale is given. The results show that implementing data-agnostic SMPC in inter-domain verification is very expensive in time, since the agents have to communicate hundreds of thousands of times continuously, and the amount of transferred data reaches 100GB. However, in smaller-scale inter-domain networks, we believe that the absolute time consumption is still within an acceptable range.

FIG. 18 is a graph comparing InCV of an exemplary embodiment of the present disclosure with a non-FASTPLANE optimized version. The abscissa is the number of network nodes (Number of Network Node), the ordinate is the verification time (VerificationTime), and the unit of the verification time is seconds (s).

To demonstrate the effect of optimization techniques based on fast control plane verification FASTPLANE, we compare InCV before and after optimization on synthetic networks. As shown in Figure 18, the results show that for a network with 32 ASs, about 19% speedup is achieved due to the reduced number of route withdrawals and the reduced number of simulation iterations.

This disclosure can provide network verification requirements services for multiple operators who do not trust each other in a multi-management domain network, and is used to troubleshoot multi-management domain network faults under the premise of ensuring the configuration privacy in the domain, and ensure the correctness of the multi-management domain network control plane. sex.

The multi-management domain network verification method and system proposed in this disclosure expands the actual scope of application of the network verification system from a single management domain network to a multi-management domain network for the first time by combining secure multi-party computing related technologies, and can ensure the data security of each participant. Specifically, we design a DO-Simulation algorithm for simulating route advertisement in BGP. After running DO-Simulation, the network generates a secret data plane (RIBs) after convergence, which is the basis of the DO-DPV algorithm for verification of different properties in the next step.

This disclosure proposes a multi-management domain network verification system architecture based on cloud services, which solves the problems of high delay in inter-domain network communication and difficulty in ensuring data plane accessibility, and reduces communication overhead between participants.

The disclosure combines FASTPLANE's route simulation calculation acceleration technology, by selecting a reasonable route propagation simulation order, reducing unnecessary route withdrawal, accelerating convergence speed, and finally improving system performance.

The multi-management domain network authentication system provided in the present disclosure can also be realized by a device using the hardware implementation of the processing system.

The device may include corresponding modules for executing each or several steps in the above flow chart. Therefore, each step or several steps in the above flowcharts may be performed by corresponding modules, and the apparatus may include one or more of these modules. A module may be one or more hardware modules specifically configured to perform the corresponding steps, or be implemented by a processor configured to perform the corresponding steps, or be stored in a computer-readable medium for implementation by the processor, or be implemented by a some combination to achieve.

The hardware structure can be implemented using a bus architecture. The bus architecture can include any number of interconnecting buses and bridges, depending on the specific application of the hardware and the overall design constraints. The bus connects together various circuits including one or more processors, memory and/or hardware modules. The bus may also connect various other circuits such as peripherals, voltage regulators, power management circuits, external antennas, and the like.

The bus may be an Industry Standard Architecture (ISA, Industry Standard Architecture) bus, a Peripheral Component Interconnect (PCI, Peripheral Component) bus, or an Extended Industry Standard Architecture (EISA, Extended Industry Standard Component) bus, etc. The bus can be divided into address bus, data bus, control bus and so on. For ease of representation, only one connection line is used in this figure, but it does not mean that there is only one bus or one type of bus.

Any process or method descriptions in flowcharts or otherwise described herein may be understood to represent modules, segments or portions of code comprising one or more executable instructions for implementing specific logical functions or steps of the process , and the scope of preferred embodiments of the present disclosure includes additional implementations in which functions may be performed out of the order shown or discussed, including substantially concurrently or in reverse order depending on the functions involved, which shall It is understood by those skilled in the art to which the embodiments of the present disclosure belong. The processor executes the various methods and processes described above. For example, method embodiments in the present disclosure may be implemented as a software program tangibly embodied on a machine-readable medium, such as memory. In some implementations, part or all of the software program may be loaded and/or installed via memory and/or a communication interface. One or more steps in the methods described above may be performed when a software program is loaded into memory and executed by a processor. Alternatively, in other implementation manners, the processor may be configured to perform one of the above-mentioned methods in any other suitable manner (for example, by means of firmware).

The logic and/or steps shown in the flowcharts or otherwise described herein can be embodied in any readable storage medium for instruction execution systems, devices or devices (such as computer-based systems, processor-included system or other systems that may fetch and execute instructions from an instruction execution system, device, or device), or be used in conjunction with such an instruction execution system, device, or device.

As far as this specification is concerned, a "readable storage medium" may be any device that can contain, store, communicate, spread or transmit programs for instruction execution systems, devices or devices or use in conjunction with these instruction execution systems, devices or devices. More specific examples (non-exhaustive list) of readable storage media include the following: electrical connection with one or more wires (electronic device), portable computer disk case (magnetic device), random access memory (RAM), Read Only Memory (ROM), Erasable and Editable Read Only Memory (EPROM or Flash Memory), Fiber Optic Devices, and Portable Read Only Memory (CDROM). In addition, the readable storage medium may even be paper or other suitable medium on which the program can be printed, since the program can be scanned, for example, by optical scanning of the paper or other medium, followed by editing, interpretation or other suitable means if necessary. processing to obtain programs electronically and store them in memory.

It should be understood that various parts of the present disclosure may be realized by hardware, software or a combination thereof. In the embodiments described above, various steps or methods may be implemented by software stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented by any one or combination of the following techniques known in the art: Discrete logic circuits, ASICs with suitable combinational logic gates, programmable gate arrays (PGAs), field programmable gate arrays (FPGAs), etc.

Those of ordinary skill in the art can understand that all or part of the steps to realize the above-mentioned implementation method can be completed by instructing related hardware through a program, and the program can be stored in a readable storage medium. When the program is executed, it includes One or a combination of steps of a method embodiment.

In addition, each functional unit in each embodiment of the present disclosure may be integrated into one processing module, each unit may exist separately physically, or two or more units may be integrated into one module. The above-mentioned integrated modules can be implemented in the form of hardware or in the form of software function modules. If the integrated modules are realized in the form of software function modules and sold or used as independent products, they can also be stored in a readable storage medium. The storage medium may be a read-only memory, a magnetic disk or an optical disk, and the like.

It should be understood by those skilled in the art that the above-mentioned embodiments are only for clearly illustrating the present disclosure, rather than limiting the scope of the present disclosure. For those skilled in the art, other changes or modifications can be made on the basis of the above disclosure, and these changes or modifications are still within the scope of the present disclosure.

Claims (10)

1. A method for verifying a multi-management-domain network, comprising:

converting router configuration files of all application servers into an input format determined by a secure multiparty computing protocol so as to ensure compatibility among all the application servers;

performing simulation processing on the router configuration file meeting the input format so as to enable the multi-management-domain network to generate a secret data plane after convergence; and

and carrying out data plane verification on the secret data plane to obtain verification results of various attributes of the multi-management-domain network.

2. The method of claim 1, wherein translating the router configuration file of each application server into the input format determined by the secure multiparty computing protocol, comprises:

Converting the router configuration file of each application server into the same intermediate representation;

and converting the intermediate representation into an input format determined by the secure multiparty computing protocol.

3. The method of claim 2, wherein the input format determined by the secure multi-party computing protocol comprises: inter-domain routing information table, router configuration information of the application server, router node update status and routing information update list of the application server, wherein

The inter-domain route information table is at least used for storing route data, wherein the route data at least comprises a prefix of a route announcement, a network protocol address of a next router node, other router nodes which pass through, the current local priority of the router node and changed router information; and

the router configuration information of the application server is used for representing the relation between the current router node and the adjacent router node, wherein the router configuration information at least comprises a network protocol address of the adjacent router node, the current application server number of the router node, the application server number of the adjacent router node, the current interface network protocol address corresponding to the router node and the current input/output strategy corresponding to the router node.

4. The method according to claim 1, wherein the simulating the router configuration file satisfying the input format so that the multi-domain network generates a secret data plane after convergence, comprises:

initializing an inter-domain routing information table of router nodes in each application server, so that only original router nodes are stored in each inter-domain routing information table;

responding to the update information of any inter-domain routing information table, and sending a routing notification to a peer router node of the router node corresponding to the update information; and

and controlling each router node to execute the corresponding route advertisement until the multi-management-domain network converges and the secret data plane is generated.

5. The method according to claim 4, wherein the sending, in response to update information of any one of the inter-domain routing information tables, a routing notification to a peer router node of the router node corresponding to the update information, includes at least:

modeling the action of the export filter of the router node with an export route function to convert the updated information into export data; and

The ingress filter on the peer router node is modeled with an ingress route function and the egress data is modified.

6. The multi-domain network authentication method according to claim 1, wherein said performing data plane authentication on the secret data plane to obtain authentication results regarding respective attributes of the multi-domain network comprises:

controlling a destination router node to execute data irrelevant search operation, and judging whether a path reaching an entry router node exists in an effective path corresponding to the destination router node; and

in response to there being a path to the ingress router node, determining that the ingress router node meets reachability to the destination router node to obtain a verification result regarding reachability attributes of the multi-domain network.

7. The multiple administrative domain network verification method according to claim 1, further comprising:

and encrypting the private value of each application server to prevent the private value from being read when the secret data plane is subjected to data plane verification.

8. The multi-domain network authentication method according to claim 1, characterized by comprising, after said performing data plane authentication on said secret data plane to obtain authentication results on respective attributes of said multi-domain network:

And synchronizing the verification result to each application server so that each application server obtains the attribute satisfied by the multi-management-domain network.

9. The method of claim 1, comprising, prior to said translating router configuration files for each application server into an input format determined by a secure multiparty computing protocol to ensure compatibility between each of said application servers:

and connecting and authenticating the router nodes of the application servers with the proxy server, and sending the router configuration information of the router nodes to the proxy server.

10. A multiple management domain network authentication system, comprising:

the configuration analysis module is used for converting the router configuration file of each application server into an input format determined by a secure multiparty computing protocol so as to ensure compatibility among the application servers;

the routing protocol simulation module is used for performing simulation processing on the router configuration file meeting the input format so as to enable the multi-management-domain network to generate a secret data plane after convergence; and

And the data plane verification module is used for carrying out data plane verification on the secret data plane so as to obtain verification results of various attributes of the multi-management-domain network.