Multi-administrative domain network verification method and system

Abstract

The present disclosure provides a multi-administrative domain network verification method, comprising: converting router configuration files of respective application servers into input formats determined by a secure multi-party computation protocol to ensure compatibility between the respective application servers; performing simulation processing on the router configuration files meeting the input formats to enable the multi-administrative domain network to generate a secret data plane after convergence; and performing data plane verification on the secret data plane to obtain verification results about respective attributes of the multi-administrative domain network. The present disclosure also provides a multi-administrative domain network verification system.

Description

Technical Field

[0001] This disclosure relates to the field of network security technology, and in particular to a method and system for verifying multi-management domain networks. Background Technology

[0002] Network verification is an automated network fault detection technology that determines whether network behavior meets network correctness requirements by checking the data plane (i.e., packet forwarding rule tables such as routing tables, access control tables, and flow tables) and control plane (i.e., device configuration files) of network devices, such as routing loop-free, routing black hole-free, and reachability. Figure 1 This diagram illustrates a data plane network verification example for related technologies. By examining the forwarding information databases of routers A and B, the data plane verification system can determine that packets with a destination IP address of 10.0.0.0 will get caught in a routing loop between A and B, while packets with a destination IP address of 10.0.0.1 will be dropped by B, thus entering a black hole. Neither packet can be delivered to the destination host 2 normally, leading to network failure. Figure 2 This is an example diagram for control plane network verification of related technologies. Router A and Router B are connected via the Border Network Protocol (BGP). The control plane verification system can determine by checking B's configuration file that B will not advertise BGP routes to A with a destination IP prefix of 10.0.0.0 / 31. As a result, A cannot deliver any packets with a destination IP address belonging to 10.0.0.0 / 31 to the destination host Host 2, leading to network failure.

[0003] Network fault diagnosis tools in related technologies can be mainly divided into the following three categories: The first category of research simulates configuration files by constructing a simulation environment identical to the actual network, and then uses data plane verification tools to check the simulated data plane in order to detect the correctness of the configuration files; The second category of research integrates network configuration with network topology to construct a special abstract graph model, and verifies whether the configuration file meets network correctness by finding paths that meet specific conditions on the abstract graph; The third category of research uses formal methods to logically model the configuration files of network devices and the correctness requirements to be checked using data logic, and determines whether the corresponding network configuration meets the corresponding correctness by checking the satisfiability of the constructed logical model.

[0004] However, the first type of research is limited in its effectiveness, failing to address issues arising from various real-world scenarios such as network latency. The second type is limited in its effectiveness and scope of application; these verification tools cannot verify many common network protocol configurations. The third type suffers from poor scalability; verifying network reachability for simple network configurations requires a considerable amount of time. Furthermore, regardless of whether it's the data plane or the control plane, the network verification tools in these technologies primarily serve single-management-domain networks. Troubleshooting multi-management-domain networks still relies heavily on communication between network administrators from different management domains, resulting in low efficiency. Summary of the Invention

[0005] To address at least one of the aforementioned problems, this disclosure provides a method and system for verifying multi-management domain networks.

[0006] According to one aspect of this disclosure, a multi-management domain network verification method is proposed, comprising: converting router configuration files of various application servers into an input format determined by a secure multi-party computation protocol to ensure compatibility between the various application servers; performing simulation processing on the router configuration files that satisfy the input format to generate a secret data plane after convergence of the multi-management domain network; and performing data plane verification on the secret data plane to obtain verification results regarding various attributes of the multi-management domain network.

[0007] In some implementations, the step of converting the router configuration files of each application server into an input format determined by the secure multi-party computation protocol includes: converting the router configuration files of each application server into the same intermediate representation; and converting the intermediate representation into the input format determined by the secure multi-party computation protocol.

[0008] In some implementations, the input format determined by the secure multi-party computation protocol includes: an inter-domain routing information table, the application server's router configuration information, the application server's router node update status, and a routing information update list. The inter-domain routing information table stores at least route data, which includes at least the route advertisement prefix, the network protocol address of the next router node, the other router nodes traversed, the current router node's local priority, and changed router information. The application server's router configuration information characterizes the relationship between the current router node and neighboring router nodes, including at least the network protocol addresses of the neighboring router nodes, the application server number of the current router node, the interface network protocol address corresponding to the current router node, and the input / output policy corresponding to the current router node.

[0009] In some implementations, the step of simulating the router configuration file that satisfies the input format to enable the multi-management domain network to generate a secret data plane after convergence includes: initializing the inter-domain routing information tables of the router nodes in each of the application servers so that each inter-domain routing information table stores only the original router nodes; in response to update information in any of the inter-domain routing information tables, sending a routing notification to the peer router nodes of the router nodes corresponding to the update information; and controlling each of the router nodes to execute the corresponding routing notification until the multi-management domain network converges and generates the secret data plane.

[0010] In some implementations, the step of sending a routing notification to the peer router node of the router node corresponding to the update information in response to any update information in the inter-domain routing information table includes at least: modeling the action of the router node's outgoing filter using an outgoing route function to convert the update information into outgoing data; and modeling the import filter on the peer router node using an ingoing route function and modifying the outgoing data.

[0011] In some implementations, performing data plane verification on the secret data plane to obtain verification results for various attributes of the multi-management domain network includes: controlling the destination router node to perform a data-independent search operation to determine whether there is a path to the ingress router node among the valid paths corresponding to the destination router node; and in response to the existence of a path to the ingress router node, determining that the ingress router node to the destination router node satisfies reachability, thereby obtaining verification results for the reachability attributes of the multi-management domain network.

[0012] In some implementations, the method further includes encrypting the private values ​​of each application server during data plane verification of the secret data plane to prevent the private values ​​from being read.

[0013] In some implementations, after performing data plane verification on the secret data plane to obtain verification results for various attributes of the multi-management domain network, the method includes: synchronizing the verification results to each of the application servers so that each of the application servers obtains the attributes satisfied by the multi-management domain network.

[0014] In some implementations, before converting the router configuration files of each application server into an input format determined by a secure multi-party computation protocol to ensure compatibility between the application servers, the method includes: connecting and authenticating the router nodes of each application server with a proxy server, and sending the router configuration information of each router node to the proxy server.

[0015] According to another aspect of this disclosure, a multi-management domain network verification system is provided, comprising: a configuration parsing module for converting router configuration files of various application servers into an input format determined by a secure multi-party computation protocol to ensure compatibility between the various application servers; a routing protocol simulation module for simulating the router configuration files that satisfy the input format to generate a secret data plane after convergence of the multi-management domain network; and a data plane verification module for performing data plane verification on the secret data plane to obtain verification results regarding various attributes of the multi-management domain network. Attached Figure Description

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

[0017] Figure 1 This is an example diagram for verifying the data plane network of related technologies.

[0018] Figure 2 Example diagram for verifying the control plane network of related technologies.

[0019] Figure 3 This is a block diagram of a multi-management domain network verification method according to an exemplary embodiment of this disclosure.

[0020] Figure 4 This is a schematic diagram of a multi-management domain network verification system, which is an exemplary embodiment of this disclosure.

[0021] Figure 5 This is a schematic diagram of the InCV cloud server architecture, which is an exemplary embodiment of this disclosure.

[0022] Figure 6 This is a schematic diagram illustrating the vendor neutralization of configuration files in an exemplary embodiment of this disclosure.

[0023] Figures 7 to 14 The following are code diagrams of DO-Simulation algorithms 1 to 8, which are exemplary embodiments of this disclosure.

[0024] Figure 15This is a code diagram illustrating a data-independent algorithm as an exemplary embodiment of this disclosure.

[0025] Figure 16 This is a comparison chart of the time overhead of networks of different sizes in an exemplary embodiment of this disclosure.

[0026] Figure 17 This is a comparison chart of communication rounds and global quantity for different sized networks in an exemplary embodiment of this disclosure.

[0027] Figure 18 This is a comparison chart of the InCV implementation of the exemplary embodiment of this disclosure and the version without FASTPLANE optimization. Detailed Implementation

[0028] The present disclosure will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the disclosure. Furthermore, it should be noted that, for ease of description, only the parts relevant to the present disclosure are shown in the accompanying drawings.

[0029] It should be noted that, where there is no conflict, the embodiments and features described in this disclosure can be combined with each other. The technical solutions of this disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0030] Unless otherwise stated, the exemplary implementations / embodiments shown are to be understood as providing exemplary features of various details that provide ways in which the technical concepts of this disclosure can be implemented in practice. Therefore, unless otherwise stated, the features of various implementations / embodiments may be additionally combined, separated, interchanged and / or rearranged without departing from the technical concepts of this disclosure.

[0031] The terminology used herein is for the purpose of describing particular embodiments and is not restrictive. As used herein, unless the context clearly indicates otherwise, the singular forms “a” and “the” are intended to include the plural forms as well. Furthermore, when the terms “comprising” and / or “including” and variations thereof are used in this specification, it indicates the presence of the stated features, integrals, steps, operations, parts, components, and / or groups thereof, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, parts, components, and / or groups thereof. It should also be noted that, as used herein, the terms “substantially,” “about,” and other similar terms are used as approximate terms rather than as terms of degree, thus explaining the inherent biases in measurements, calculated values, and / or provided values ​​that would be recognized by one of ordinary skill in the art.

[0032] Figure 3This is a block diagram of a multi-management domain network verification method according to an exemplary embodiment of this disclosure. The following is in conjunction with... Figure 3 The steps of the multi-management domain network verification method S100 are described in detail.

[0033] like Figure 3 As shown, according to one aspect of this disclosure, a multi-management domain network verification method S100 is proposed, comprising:

[0034] Step S102: Convert the router configuration files of each application server into the input format determined by the secure multi-party computation protocol to ensure compatibility between the application servers.

[0035] Step S104: Simulate the router configuration file that meets the input format so that the multi-management domain network can generate a secret data plane after convergence.

[0036] Step S106: Perform data plane verification on the secret data plane to obtain verification results for each attribute of the multi-management domain network.

[0037] Router configuration files are used to represent the configuration information of routing nodes in the application server. The Secure Multi-Party Computation (SMPC) protocol uses cryptographic algorithms to ensure data security during data plane verification, preventing data leakage and forgery.

[0038] In some implementations, step S102 specifically includes: converting the router configuration files of each application server into the same intermediate representation; and converting the intermediate representation into an input format determined by a secure multi-party computation protocol.

[0039] In some implementations, the input format determined by the secure multi-party computation protocol includes: an inter-domain routing information base (RIB), application server router configuration information (Config), application server router node update status (HasUpdate), and routing information update list (UpdateList). The RIB stores at least route data, which includes at least the route advertisement prefix (Prefix), the network protocol address of the next router node (NextHop), the other router nodes traversed (AsPath), the local priority (LocalPref) of the current router node, and changed router information IDs (SIDs). The application server's router configuration information characterizes the relationship between the current router node and neighboring router nodes, including at least the network protocol address of the neighboring router nodes (PeerAddress), the application server number (LocalAs) of the current router node, the application server number (RemoteAs) of the neighboring router nodes, the interface network protocol address (Interface) of the current router node, and the input / output policy of the current router node.

[0040] The input / output policy corresponding to the current router node includes at least the input policy ImportPolicy and the output policy ExportPolicy.

[0041] In some implementations, step S104 includes the following specific steps: initializing the inter-domain routing information tables of router nodes in each application server so that each inter-domain routing information table only stores the original router nodes; in response to update information in any inter-domain routing information table, sending a routing notification to the peer router node of the router node corresponding to the update information; and controlling each router node to execute the corresponding routing notification until the multi-management domain network converges and generates a secret data plane.

[0042] In some implementations, in response to an update in any inter-domain routing information table, sending a routing notification to the peer router node corresponding to the updated information includes at least: modeling the action of the router node's outgoing filter using an outgoing route function to convert the updated information into outgoing data; and modeling the import filter on the peer router node using an ingoing route function and modifying the outgoing data.

[0043] In some implementations, step S106 specifically involves: controlling the destination router node to perform a data-independent search operation to determine whether there is a path to the ingress router node among the valid paths corresponding to the destination router node; and in response to the existence of a path to the ingress router node, determining that the ingress router node to the destination router node satisfies reachability, so as to obtain the verification result of the reachability attribute of the multi-management domain network.

[0044] In some implementations, the multi-management domain network authentication method S100 further includes encrypting the private values ​​of each application server during data plane authentication of the secret data plane to prevent the private values ​​from being read.

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

[0046] In some implementations, before step S02, the process 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.

[0047] Figure 4 This is a schematic diagram of a multi-management domain network verification system, which is an exemplary embodiment of this disclosure.

[0048] refer to Figure 4 The system disclosed herein can be divided into three interconnected modules: a configuration parsing module, a privacy-preserving routing protocol simulation module, and a privacy-preserving data plane verification module.

[0049] Specifically, the configuration parsing module converts the router configuration files of each application server into an input format defined by the Secure Multi-Party Computation Protocol (SMPC) (i.e., a unified SMPC input format) to ensure compatibility between application servers. The routing protocol simulation module simulates the router configuration files that meet the input format, enabling the multi-management domain network to generate a secret data plane (i.e., a privacy data plane RIB) after convergence. The data plane verification module performs data plane verification on the secret data plane to obtain verification results regarding various attributes of the multi-management domain network.

[0050] In some implementations, the data plane verification module also returns the verification results publicly to all participants, namely the various application servers. For example, AS (Application Server) 1, AS2, and AS3, and the vendor of each AS is not limited here.

[0051] Specifically, the configuration resolution module is first responsible for the connection and authentication between the eBGP (External Border Gateway Protocol) router and the proxy server. After authentication, each AS's eBGP router can send its configuration to the proxy server or make configuration changes. Furthermore, the configuration resolution module converts the router configuration files of each application server into the input format defined by the SMPC protocol to resolve compatibility issues between different application servers.

[0052] The privacy-preserving routing protocol simulation module (DO-Simulation) processes the transformed input data using the DO-Simulation algorithm of the Fast Multi-Administrative Domain Network Validation (InCV) module. The DO-Simulation algorithm simulates routing notifications in BGP (Border Gateway Protocol). However, during the execution of the DO-Simulation algorithm, no party involved in the computation (or proxy router) discloses private information. After running DO-Simulation, the network generates a secret data plane (RIB) upon convergence, which forms the basis for the next step, DO-DPV (DO-Data Plane Validation).

[0053] The Privacy-Preserving Data Plane Validation Module (DO-DPV) validates different attributes according to operator specifications. For a given secret data plane, it also guarantees the data independence of all validation functions. The final validation result of DO-DPV is publicly disclosed to all participants to indicate whether certain attributes are satisfied in the network under a given configuration.

[0054] InCV (Instant Multi-Management Domain Network Authentication) is a cloud-based authentication system designed to enable collaboration among network operators to determine whether their Autonomous System (ASes) and router configurations meet specific attributes. By ensuring the confidentiality of each AS's configuration information during the computation process, InCV prevents the leakage of configuration information among participants.

[0055] To better illustrate the design, we assume that each AS behaves as a single eBGP router, reducing topology complexity by ignoring the internal topology of the AS. We believe this assumption is reasonable because cross-domain authentication primarily focuses on the correctness of the configurations used between ASs.

[0056] Figure 5 This is a schematic diagram of the InCV cloud server architecture, which is an exemplary embodiment of this disclosure.

[0057] refer to Figure 5 In InCV, each participating eBGP router (e.g., P0, P1, P3, P4) is assigned its own proxy server in the cloud, responsible for performing privacy-preserving configuration transformations and secure computations. During computation, each proxy first converts the configuration into SMPC-compatible input, then communicates with other proxies to securely collaborate on the computation output. This design is necessary due to the massive scale of InCV computations, requiring tens of thousands of communication rounds and hundreds of gigabytes of data streams. Information exchange between data planes is private, while verification results are public; the network topology is also public and accessible at any time; user commands are also public.

[0058] Based on the foregoing, InCV's cloud service architecture offers the following advantages: Better performance: By leveraging the high bandwidth and low latency of the cloud environment, InCV's performance can be significantly improved. Higher privacy: Through agent-side authentication and access control, InCV ensures that the configuration information of each AS is kept confidential from other participants during computation, thus protecting configuration privacy. Stronger scalability: Since the agent server performs computations in the cloud, InCV can easily expand its computing power to adapt to the ever-growing network size. Better full connectivity: SMPC computations typically require full connectivity between participants, or at least pairwise communication. However, in real-world networks, due to complex routing control, communication between multiple ASs often fails to meet this requirement; a cloud service architecture can efficiently solve this problem.

[0059] Figure 6 This is a schematic diagram illustrating the vendor neutralization of configuration files in an exemplary embodiment of this disclosure.

[0060] refer to Figure 6 In the interaction between the participating eBGP routers and the cloud-based proxy server, privacy configuration conversion is a crucial step. Its purpose is to achieve vendor neutrality in configuration. Vendor neutrality means that a product, service, or system is designed and implemented without bias towards any particular vendor or supplier, and can support device inputs from all vendors. In inter-domain networks, it is very common for different ASs (e.g., AS1, AS2, and AS3) to use routers and network equipment from different vendors. The configuration languages ​​of major vendors differ, and even when implementing the same strategy, significant differences can exist.

[0061] To address this challenge, we modified the source code of the network verification tool Batfish. First, we converted the configurations of routers from different manufacturers into a common intermediate representation; then, we converted the intermediate representation of the router configuration files into an input format defined by the SMPC protocol. This approach resolved the compatibility issues between different devices.

[0062] The SMPC protocol defines the data structure for each node in the algorithm implementation process. The input format for each router node consists of four parts: the Inter-Domain Routing Information Table (RIB), the application server's router configuration information (Config), the application server's router node update status (HasUpdate), and the routing information update list (UpdateList). The RIB is stored using an array, with each entry being a Route type data structure. Config represents the router node's configuration, and HasUpdate uses a boolean type to indicate whether the current node has been updated. The UpdateList is also stored using an array, with each entry being the updated route and its type (Type). Type uses a short type, with 0, 1, and 2 representing the three update types: addition, deletion, and update, respectively.

[0063] A route consists of several parts: Prefix (network prefix), NextHop (next hop), AsPath (As path), LocalPref (local priority), Med (multi-egress discriminator), and IDs (route IDs). Prefix represents the prefix advertised for this route, consisting of an IP address and a mask. NextHop is an IP address representing the next hop. AsPath uses an array to store the router nodes that need to be traversed. LocalPref represents the local priority of this route. IDs are used for revocation and update, represented by the router name and sequence number, where the sequence number is the order in which it was added to the routing table to ensure uniqueness; for example, A_1. For instance, if route l1 in A is revoked, and neighbor B's route l2 is correspondingly revoked, B needs to check if l2.OriginID = l1.RIBID to perform the deletion.

[0064] The `Config` section configures each node, containing relationships with neighboring routers, including `PeerAddress`, `LocalAs`, `RemoteAs`, `Interface`, and `Policy`. `PeerAddress` represents the neighbor's IP address, `LocalAs` represents the router's `As` number, `RemoteAs` represents the neighbor's `As` number, and `Interface` represents the interface's network protocol IP address. The `Policy` section contains `ImportPolicy` and `ExportPolicy`. `ImportPolicy` uses an array for storage, where each entry is a routemap. Each routemap contains several `match` and `set` statements. The `match` statements include `Match PrefixList` and `Match NextHop`, used to match the prefix list and next hop; the `set` statements include `Set LocalPref` and `Set Metric`, used to set the local priority and metric. Boolean actions indicate whether the policy denies or permits.

[0065] Figures 7 to 14 The following are code diagrams of DO-Simulation algorithms 1 to 8, which are exemplary embodiments of this disclosure.

[0066] For the routing protocol simulation module under privacy protection, eight DO-Simulation algorithms are involved, which will be discussed below. Figures 7 to 14 A brief explanation of each algorithm is provided.

[0067] The goal of DO-Simulation is to transform the privacy inputs of multiple agents into a data plane, which will serve as the basis for attribute validation in subsequent steps.

[0068] Like many other verification algorithms, DO-Simulation is performed for each IP prefix p specified by the network administrator. Similarly, we consider the router that announces the IP prefix p as publicly known, referred to as origin. The routing information received by router n is stored in RIB(n), representing the Routing Information Base (RIB), a data table stored in the router listing routes to specific network destinations and the metrics associated with those routes. In the algorithm's initialization step, only RIB(Origin) has an entry for p; the RIBs of other routers are set to empty. This is to model the network state when origin has just discovered p. Has_update is a boolean array indicating whether the router has routing information to import. Similarly, only has_update(p) is set to True.

[0069] refer to Figure 7 The function `Converge()`, as Algorithm 1, consists of multiple iterations until the network simulation converges; that is, the network converges if all elements in `has_update()` are false. In each iteration, the algorithm selects a router whose RIB has been changed and issues a route notification to its peers. A change in the RIB refers to a change in the router's optimal route due to the insertion of a better route or the withdrawal of the optimal route. These RIB changes are stored in `update_list`, a global array of dimension |n|, where |n| is the number of participants. The RIB changes are then loaded into a temporary variable named `updates`. All updates are modeled through the `ExportRoutes()` function, which models the export filter action, converting `updates` into `exports`. The `ImportRoutes()` function models the import filter on peer router `n` and similarly modifies `exports`.

[0070] refer to Figure 8 The ExportRoutes() algorithm, as Algorithm 2, is used to model the export filter. If the updated route type is "add," the non-transitive attribute of the route is first cleared. If the AS path contains the peer's AS, the route is not exported. Then, the export policy is applied to determine if exporting the route is allowed. If exporting is allowed, the AS number of the sender in the AS-path is added, and the next-hop IP is set. Finally, the route is added to the exports array. If the updated route information is "delete" or "update," it is exported directly.

[0071] refer to Figure 9 The ImportRoutes() algorithm, as Algorithm 3, is used to model import filters. If the updated route is of type add and its AS path contains the peer's AS, then the route is not imported. An importpolicy is applied to the route to determine if importing is allowed; if allowed, the route is added to the peer's RIB. If the updated route is of type delete or update, the route is deleted or updated in the peer's RIB.

[0072] refer to Figure 10 The PolicyOutAllowed and PolicyInAllowed algorithms, collectively known as Algorithm 4, are used to implement import and export policies for routes. They iterate through all outPolicies (external policies) to check if they match a match statement; if so, the corresponding set statement is executed.

[0073] refer to Figure 11 The Match algorithm, as Algorithm 5, is used to match the routing prefix and the next hop.

[0074] refer to Figure 12 The Set algorithm, as Algorithm 6, is used to set local priority and next hop.

[0075] refer to Figure 13 and Figure 14 The UpdateRIB algorithm, also known as Algorithm 7, handles situations where the best route in a peer's RIB changes due to imports. If the updated route type is "add," the OriginID and RIBID of the route are updated first. Then, the new RIB change is added to update_list(peer), has_update(peer) is set to True, and the peer's RIB is updated. If the update type is "delete" or "update," corresponding to route cancellation and update, the OriginID and RIBID are first matched. If they match, the new RIB change is added to update_list(peer), has has_update(peer) is set to True, and the peer's RIB is updated. When a route notification is imported, it is inserted at the k-th position in the peer's RIB, and all k-1 routes before it have higher priority. The process of comparing routes in the RIB is implemented using the PriorityCompare algorithm (Algorithm 8), consistent with the routing rules in BGP. First, local priorities are compared, then the length of the AS Path and the MED are compared.

[0076] Data-oblivious is a computational method that requires that all operations performed do not reveal any information about the input data. In other words, the execution of a data-oblivious algorithm does not depend on the specific values ​​of the input data, and therefore information about the input data cannot be inferred by observing the execution of the algorithm.

[0077] 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-independent algorithms, computation can be performed among multiple participants while ensuring that their input data is not disclosed to other participants or third-party observers.

[0078] A classic example of a data-free approach is a sorting algorithm based on secure multi-party computation. In this scenario, multiple parties can collaborate to sort a set of numbers, but throughout the process, they cannot obtain any information about the input data of other parties. In this way, data-free methods can protect the privacy of the participants while allowing them to perform collaborative computation without revealing critical information.

[0079] Secure outsourcing of computation is used to motivate this work, assuming that computations are 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 reveal their values ​​to access data at a specific location. For the sake of specificity, we use the symbol [x] to indicate that the value of x is protected from the influence of the entity performing the computation.

[0080] To maintain data privacy, we must ensure that the computation party does not learn any information about the data during algorithm execution. Since we assume that each private value is fully protected, the only way for the computation party to infer information about the private data is when the instruction sequence or the algorithm's memory access patterns depend on the data. Therefore, to guarantee data privacy, we formally formulate the data-forgetting execution of deterministic algorithms as follows:

[0081] Definition 1: Let d denote the input of an algorithm. Similarly, let A(d) denote the sequence of memory accesses performed by the algorithm. An algorithm is considered data-independent if, for two inputs of equal length d and d', it executes the same sequence of instructions, and each side performing the computation cannot distinguish between access patterns A(d) and A(d').

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

[0083] Figure 15 This is a code diagram illustrating a data-independent algorithm as an exemplary embodiment of this disclosure.

[0084] DO-Simulation implements a data-independent execution mode to prevent information leakage. In most cases, even if data is encrypted, access patterns can be recorded. Here, we use a frequently used function in DO-Simulation to determine routing priority (i.e., priority compare). Figure 15Strategy 1 and Strategy 2 are used to illustrate the data-independent algorithm. Based on previous work, this algorithm is data-independent because the program's control flow is fixed and public, allowing all parties to follow it in unison. Furthermore, for intermediate calculations of variables, we employ protocols suitable for secure computation using binary or arithmetic circuits.

[0085] The privacy-preserving Data Plane Validation Module (DO-DPV) attempts to validate network properties (such as reachability, isolation, etc.) on the secret data plane generated by DO-Simulation. As a prototype, we assume that route reachability equals forwarding reachability and translate these properties into linear scan operations on ribs. For example, to verify that A can reach B, we perform a data-independent search on B's RIB to check if there is a valid entry to destination A.

[0086] This disclosure also optimizes the convergence speed of route simulation by incorporating FASTPLANE's route simulation computation acceleration technology. By selecting a reasonable route propagation simulation order, unnecessary route withdrawals are reduced, accelerating convergence and ultimately improving system performance. The key idea of ​​FASTPLANE is to first send globally optimal route advertisements. For monotonic networks, FASTPLANE can efficiently generate the data plane by selecting an appropriate propagation order. However, FASTPLANE cannot be applied to non-monotonic networks because route withdrawals occur during simulations based on the aforementioned propagation order, which FASTPLANE does not perform. To support non-monotonic networks, we implement a route withdrawal operation based on FASTPLANE. Experiments on all our datasets show that this design can accelerate the simulation process by reducing the frequency of route withdrawals. However, this design may lead to inefficiencies in certain networks, such as where each router prefers routes with longer paths.

[0087] We conducted extensive experiments to demonstrate the feasibility and benefits of InCV.

[0088] Figure 16 This is a comparison chart of the time overhead of networks of different sizes in an exemplary embodiment of this disclosure.

[0089] like Figure 16As shown, the horizontal axis represents the number of network nodes, and the vertical axis represents the verification time, measured in microseconds (μs). In terms of SMPC overhead, InCV takes 10^7-10^9 times longer than its plaintext version, a common performance issue for secure multi-party computation (SMPC) solvers for complex problems. For a 32-node network, the plaintext version of the verifier can complete verification in approximately 10µs, while the encrypted version takes approximately 52 minutes.

[0090] Figure 17 This is a comparison chart of communication rounds and global quantity for different sized networks in an exemplary embodiment of this disclosure. Figure 17 (a) The horizontal axis represents the number of network nodes, and the vertical axis represents the total data transfer rate (Global Data Sent). The unit of the total data transfer rate is GB. Figure 17 (b) The horizontal axis represents the number of network nodes, and the vertical axis represents the total number of communication rounds, with the unit of total communication rounds being k.

[0091] like Figure 17 As shown in (a) and (b), the trends of InCV global communication rounds and communication data volume as network size increases are presented. The results indicate that implementing data-independent SMPC in inter-domain verification is very time-consuming, as agents must communicate continuously hundreds of thousands of times, transmitting up to 100GB of data. However, in smaller-scale inter-domain networks, we consider the absolute time consumption to be within an acceptable range.

[0092] Figure 18 This is a comparison chart of the InCV implementation of this disclosure and the version without FASTPLANE optimization. The horizontal axis represents the number of network nodes, and the vertical axis represents the verification time, which is in seconds (s).

[0093] To demonstrate the effectiveness of the optimization technique based on FastPLANE (Fast Control Plane Validation), we compared InCV before and after optimization on the synthesis network. For example... Figure 18 As shown, the results indicate that for a network with 32 ASs, an acceleration of approximately 19% is achieved due to a reduction in the number of route cancellations and simulation iterations.

[0094] This disclosure provides network authentication services for multiple untrusted operators in a multi-managed domain network, enabling troubleshooting of multi-managed domain network faults while ensuring privacy of domain configurations, and ensuring the correctness of the multi-managed domain network control plane.

[0095] The multi-management domain network verification method and system disclosed herein, by combining secure multi-party computation (MPC) technologies, expands the practical applicability of network verification systems from single-management domain networks to multi-management domain networks for the first time, while ensuring the data security of all participating parties. Specifically, we designed a DO-Simulation algorithm that simulates routing notification in BGP. After running DO-Simulation, the network generates a secret data plane (RIB) upon convergence, which forms the basis for the DO-DPV algorithm used in the next step to verify different attributes.

[0096] This disclosure proposes a cloud-based multi-management domain network verification system architecture, which solves problems such as high latency in cross-domain network communication and difficulty in guaranteeing data plane reachability, and reduces communication overhead among participants.

[0097] This disclosure combines FASTPLANE's route simulation calculation acceleration technology, reduces unnecessary route withdrawals, speeds up convergence, and ultimately improves system performance by selecting a reasonable route propagation simulation order.

[0098] The multi-management domain network authentication system provided in this disclosure can also be implemented by a device that employs a hardware implementation of a processing system.

[0099] The apparatus may include corresponding modules that perform one or more steps in the flowchart above. Therefore, each or more steps in the flowchart above can be performed by a corresponding module, and the apparatus may include one or more of these modules. A module may be one or more hardware modules specifically configured to perform a corresponding step, or implemented by a processor configured to perform a corresponding step, or stored in a computer-readable medium for implementation by a processor, or implemented through some combination thereof.

[0100] This hardware architecture can be implemented using a bus architecture. A bus architecture can include any number of interconnect buses and bridges, depending on the specific application and overall design constraints of the hardware. The bus connects various circuits, including one or more processors, memory, and / or hardware modules. The bus can also connect various other circuits such as peripherals, voltage regulators, power management circuitry, external antennas, etc.

[0101] A bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Component Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, this diagram uses only one connection line, but this does not imply that there is only one bus or one type of bus.

[0102] Any process or method description in the flowcharts or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of this disclosure includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as will be understood by those skilled in the art to which embodiments of this disclosure pertain. The processor performs the various methods and processes described above. For example, the method embodiments of this disclosure may be implemented as software programs tangibly contained in a machine-readable medium, such as memory. In some embodiments, part or all of the software program may be loaded and / or installed via memory and / or a communication interface. When the software program is loaded into memory and executed by the processor, one or more steps of the methods described above may be performed. Alternatively, in other embodiments, the processor may be configured to perform one of the methods described above by any other suitable means (e.g., by means of firmware).

[0103] The logic and / or steps represented in the flowchart or otherwise described herein may be specifically implemented in any readable storage medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0104] For the purposes of this specification, a "readable storage medium" can be any means capable of containing, storing, communicating, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of readable storage media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and programmable read-only memory (EPROM or flash memory), fiber optic devices, and portable read-only memory (CDROM). Furthermore, a readable storage medium can even be paper or other suitable media on which a program can be printed, since a program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in memory.

[0105] It should be understood that various parts of this disclosure can be implemented in hardware, software, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in 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 using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0106] Those skilled in the art will understand that all or part of the steps of the methods described above can be implemented by a program instructing related hardware, and the program can be stored in a readable storage medium. When executed, the program includes one or a combination of the steps of the method implementation.

[0107] Furthermore, the functional units in the various embodiments of this disclosure can be integrated into a single processing module, or each unit can exist physically separately, or two or more units can be integrated into a single module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a readable storage medium. The storage medium can be a read-only memory, a disk, or an optical disk, etc.

[0108] Those skilled in the art should understand that the above embodiments are merely for illustrating the present disclosure and are not intended to limit the scope of the disclosure. Those skilled in the art can make other changes or modifications based on the above disclosure, and these changes or modifications still fall within the scope of the present disclosure.

Claims

1. A method for verifying a multi-management domain network, characterized in that, include: The router configuration files of each application server are converted into an input format defined by the secure multi-party computation protocol to ensure compatibility between the application servers. The router configuration files are the configuration information of the router nodes in the application servers. Each router node is assigned a proxy server, which is used to convert the router configuration files into an input format that conforms to the secure multi-party computation protocol and to communicate with other proxy servers. The router configuration file that meets the input format is simulated to enable the multi-management domain network to generate a secret data plane after convergence; as well as Data plane verification is performed on the secret data plane to obtain verification results for various attributes of the multi-management domain network, including: controlling the destination router node to perform a data-independent search operation to determine whether there is a path to the ingress router node in the valid path corresponding to the destination router node; And in response to the existence 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 a verification result regarding the reachability attributes of the multi-management domain network.

2. The multi-management domain network verification method according to claim 1, characterized in that, The step of converting the router configuration files of each application server into the input format determined by the secure multi-party computation protocol includes: The router configuration files of each application server are converted into the same intermediate representation; The intermediate representation is converted into the input format determined by the secure multi-party computation protocol.

3. The multi-management domain network verification method according to claim 2, characterized in that, The input format determined by the secure multi-party computation protocol includes: an inter-domain routing information table, the router configuration information of the application server, the router node update status of the application server, and a routing information update list, wherein... The inter-domain routing information table stores at least route data, which includes at least the route advertisement prefix, the network protocol address of the next router node, the other router nodes traversed, the local priority of the current router node, and changed router information; and The router configuration information of the application server is used to characterize the relationship between the current router node and neighboring router nodes. The router configuration information includes at least the network protocol address of the neighboring router node, the application server number of the current router node, the interface network protocol address of the current router node, and the input / output policy of the current router node.

4. The multi-management domain network verification method according to claim 1, characterized in that, The step of simulating the router configuration file that meets the input format to enable multiple management domain networks to generate a secret data plane after convergence includes: The inter-domain routing information tables of the router nodes in each of the application servers are initialized so that each of the inter-domain routing information tables only stores the original router nodes. In response to an update in any of the inter-domain routing information tables, a routing notification is sent to the peer router node of the router node corresponding to the update information; and Control each of the router nodes to execute the corresponding routing notification until the multi-management domain network converges and generates the secret data plane.

5. The multi-management domain network verification method according to claim 4, characterized in that, The step of responding to an update in any of the inter-domain routing information tables by sending a routing notification to the peer router node corresponding to the updated information includes at least: The actions of the router node's outgoing filter are modeled using an outgoing route function to convert the updated information into outgoing data; and The ingress route function is used to model the ingress filter on the peer router node, and the egress data is modified.

6. The multi-management domain network verification method according to claim 1, characterized in that, Also includes: When performing data plane verification on the secret data plane, the private values ​​of each application server are encrypted to prevent the private values ​​from being read.

7. The multi-management domain network verification method according to claim 1, characterized in that, After performing data plane verification on the secret data plane to obtain verification results regarding various attributes of the multi-management domain network, the process includes: The verification results are synchronized to each of the application servers so that each of the application servers obtains the attributes satisfied by the multi-management domain network.

8. The multi-management domain network verification method according to claim 1, characterized in that, Before converting the router configuration files of each application server into the input format determined by the secure multi-party computation protocol to ensure compatibility between the application servers, the process includes: The router nodes of each application server are connected to and authenticated with the proxy server, and the router configuration information of each router node is sent to the proxy server.

9. A multi-management domain network authentication system, characterized in that, include: The configuration parsing module is used to convert the router configuration files of each application server into an input format determined by the secure multi-party computation protocol to ensure compatibility between the application servers. The router configuration files are the configuration information of the router nodes in the application servers. Each router node is assigned a proxy server. The proxy server is used to convert the router configuration files into an input format that conforms to the secure multi-party computation protocol and to communicate with other proxy servers. A routing protocol simulation module is used to simulate the router configuration file that meets the input format, so that the multi-management domain network can generate a secret data plane after convergence. as well as The data plane verification module is used to perform data plane verification on the secret data plane to obtain verification results for various attributes of the multi-management domain network, including: controlling the destination router node to perform a data-independent search operation to determine whether there is a path to the ingress router node in the valid path corresponding to the destination router node; And in response to the existence 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 a verification result regarding the reachability attributes of the multi-management domain network.

Images