KR102439162B1 - Network policy inconsistencies detection system in software-defined networks and the method thereof - Google Patents

Abstract

The present invention relates to an automatic fuzz testing framework for detecting inconsistencies that occur between SDN (Software Defined Network) components, and a seed file based on a flow rule dependency tree. A flow rule unit that analyzes and generates a flow rule request for randomizing elements and values of a seed rule, generates a flow rule according to the flow rule request, and a flow rule state of a switch for one of the flow rules and a corresponding and an application agent unit for collecting and managing rule details including message information, and an inconsistency detection unit for detecting occurrence of a flow rule mismatch by searching for the rule details based on a flow rule state diagram.

Description

NETWORK POLICY INCONSISTENCIES DETECTION SYSTEM IN SOFTWARE-DEFINED NETWORKS AND THE METHOD THEREOF

The present invention relates to a network policy inconsistency detection system of a software defined network and a method thereof, and more particularly, automatic fuzz testing for detecting inconsistencies occurring between SDN (Software Defined Network) components. It's about frameworks.

Software-defined networking has emerged as one of the most influential technological directions in modern digital networks. SDNs are now being widely deployed by data computing centers, network infrastructure providers, and in enterprise networks. As this adoption has grown, so has the precision of all aspects of SDN architectures and implementations. Because FortNox's study first explored the feasibility of SDN-specific attack scenarios (see previous papers), many researchers introduced attack scenarios and proposed various defensive measures. However, almost all SDN security projects to date have proposed protection from the standpoint of either mitigating system-level concerns, such as software bugs and application misuse, or combating malicious traffic.

The security community has paid limited attention to the consistency check of network policies (flow rules) translated between the layers and components that make up SDN. While there is considerable preliminary work to address SDN's policy conflict avoidance concerns, these studies have mainly focused on policy conflicts that occur within a single component (eg, the SDN controller's policy database). These previous projects are not directly applicable to detecting policy inconsistencies that may appear between different components of the SDN stack (eg SDN controllers and switches).

In addition, even minor grammatical mistakes that occur during the multi-step process of converting SDN application input into the illustrated flow rules can cause significant instability in network operation. While such issues can cause serious problems for SDN, SDN security researchers have not done a good job of scrutinizing these issues and approaches to alleviating these concerns.

P. Porras, S. Shin, V. Yegneswaran, M. Fong, M. Tyson, and G. Gu, “A security enforcement kernel for openflow networks,” in Proceedings of the first workshop on Hot topics in software defined networks. ACM, 2012, pp. 121-126.

It is an object of the present invention to propose a new framework for automatically analyzing a process in which an administrative SDN policy is delivered through an SDN component and detecting inconsistency between the components.

A network policy inconsistency detection system according to an embodiment of the present invention includes a flow rule unit that analyzes a seed file based on a flow rule dependency tree and generates a flow rule request for randomizing elements and values of a seed rule, the Based on a flow rule state diagram and an application agent unit that creates a flow rule according to a flow rule request, and collects and manages rule details including the flow rule status of the switch for one of the flow rules and message information corresponding thereto and a discrepancy detection unit detecting occurrence of a flow rule discrepancy by searching the rule details.

The flow rule unit receives the seed file from a user, and based on the flow rule dependency tree, a dependency analyzer analyzes a format of a seed flow request and requests one or more modified flow rules according to the analyzed seed flow request. It may include a flow request fuzzer that generates and randomizes, and transmits the seed flow request and the flow rule request to the application agent unit.

The application agent unit generates a flow rule according to the flow rule request and the seed flow request, and a flow rule processing unit that manages a flow rule state of the switch through the flow service provided by the SDN controller, and the flow rule and its and a flow rule collecting unit that collects the corresponding related message information and uses it to detect a flow rule inconsistency.

The inconsistency detection unit may include an inconsistency analyzer that filters the rule details using the flow rule state diagram to analyze inconsistencies between states, and a discrepancy resolution unit that processes the flow rule inconsistency detected by the inconsistency analyzer.

A network policy inconsistency detection method according to an embodiment of the present invention generates a flow rule request that randomizes elements and values of a seed rule by analyzing a seed file based on a flow rule dependency tree by a flow rule unit generating, by the application agent unit, a flow rule according to the flow rule request, and collecting and managing rule details including a flow rule state of a switch for one flow rule and message information corresponding thereto and detecting, by the inconsistency detection unit, occurrence of a flow rule inconsistency by searching the rule details based on the flow rule state diagram.

The generating of the flow rule request includes, by the dependency analysis unit, receiving the seed file from the user, and analyzing the format of the seed flow request based on the flow rule dependency tree, and analyzing by the flow request fuzzer. The method may include generating and randomizing one or a plurality of modified flow rule requests according to the seed flow request, and then transmitting the seed flow request and the flow rule request to the application agent unit.

The step of collecting and managing the rule details includes generating a flow rule according to the flow rule request and the seed flow request by a flow rule processing unit, and a flow rule state of the switch through the flow service provided by the SDN controller. and collecting, by the flow rule collecting unit, the flow rule and the message information corresponding thereto, and using it to detect a flow rule inconsistency.

The step of detecting the occurrence of the flow rule inconsistency includes, by the inconsistency analysis unit, filtering the rule details using the flow rule state diagram to analyze the inconsistency between states, and by the inconsistency resolution unit, the inconsistency analysis unit and processing the detected flow rule mismatch.

According to an embodiment of the present invention, it is possible to automatically analyze a process in which an administrative SDN policy is delivered through an SDN component, and to detect inconsistency between the components.

1 shows an SDN architecture.
2 is a diagram illustrating a procedure for installing a flow rule in a network switch.
3 is a diagram to explain an example of a policy inconsistency due to a flow rule of a malformed form.
4 is a block diagram of a network policy inconsistency detection system according to an embodiment of the present invention.
5 shows an example of a flow rule dependency tree according to an embodiment of the present invention.
6 illustrates an example of randomizing elements and values of a flow rule dependency tree according to an embodiment of the present invention.
7 illustrates an example of randomizing a rule dependency tree by removing a flow element according to an embodiment of the present invention.
8 shows an example of a flow rule state diagram according to an embodiment of the present invention.

Advantages and features of the present invention and methods of achieving them will become apparent with reference to the embodiments described below in detail in conjunction with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below, but will be embodied in various different forms, and only these embodiments allow the disclosure of the present invention to be complete, and common knowledge in the art to which the present invention pertains It is provided to fully inform those who have the scope of the invention, and the present invention is only defined by the scope of the claims.

The terminology used herein is for the purpose of describing the embodiments, and is not intended to limit the present invention. In this specification, the singular also includes the plural, unless specifically stated otherwise in the phrase. As used herein, “comprises” and/or “comprising” refers to the presence of one or more other components, steps, operations and/or elements mentioned. or addition is not excluded.

Unless otherwise defined, all terms (including technical and scientific terms) used herein may be used with the meaning commonly understood by those of ordinary skill in the art to which the present invention belongs. In addition, terms defined in a commonly used dictionary are not to be interpreted ideally or excessively unless clearly specifically defined.

Hereinafter, preferred embodiments of the present invention will be described in more detail with reference to the accompanying drawings. The same reference numerals are used for the same components in the drawings, and repeated descriptions of the same components are omitted.

An aspect of the present invention is to propose a design and implementation of a new framework capable of automatically generating a randomized OpenFlow rule and detecting a flow rule inconsistency.

According to an embodiment of the present invention, a specialized network policy fuzzing module designed to stimulate potential malformation SDN policy creation opportunities is presented, and a detection strategy is introduced to automatically detect such inconsistencies in the actual SDN stack. The detection approach of the present invention is informed by the state transition diagram concept of how SDN flow rules are passed between each layer and component of SDN. This model informs an understanding of fuzzing strategies and how to achieve consistent test coverage that can be generalized across most popular SDN implementations.

Hereinafter, a network policy inconsistency detection system and method will be described in detail with reference to FIGS. 1 to 9 .

1 shows an SDN architecture.

Unlike the existing network, the SDN uses the control unit (ie, the application layer and the control layer) that determines the processing method of network traffic, and the data unit (that is, the data unit) that implements the pack forwarding policy defined by the control layer. , separated from the infrastructure layer). SDN introduces a logically centralized network policy control, enabling agile and flexible administrative control over the internal network topology. The SDN Controller can also provide a network operating system that abstracts the low-level management of implementing flow rules, allowing network programmers to implement intuitive network functions as SDN applications.

The SDN controller manages network configuration and forwarding rules to a network forwarding device (eg, SDN-enabled switch) through a southbound API (eg, Openflow).

OpenFlow is currently the de facto SDN protocol that defines the commands and actions that the controller can interact with forwarding devices (Openflow-compatible network switches). All OpenFlow-enabled switches maintain several flow tables that manage a set of flow entries. According to the OpenFlow specification, each flow input is: i) a match field (baseline) that is compared to an incoming packet, ii) a set of operations (equivalent to a command) defining how to handle a matching incoming packet, iii) the total number of packets/byte It consists of three main parts: a packet/byte counter that adds a count.

When a received packet arrives at the switch and there is no matching flow rule item, the switch sends a PACKET IN message including partial information of the packet to the controller. The controller decides how to process the packet, creates the relevant flow rule, and then sends the rule to the switch via a FLOW MOD message. FLOW MOD includes priority, match fields, and per-rule actions, allowing the switch to tie rules to all subsequent packets that meet the same criteria. At this time, if there is a match field in two or more flow rules, the rule with higher priority takes precedence.

2 is a diagram illustrating a procedure for installing a flow rule in a network switch.

For SDN, each FLOW MOD message represents a network security policy decision. Flow rules define which paths a packet will travel, which endpoints (hosts) the packets will be destined for, and what data will be allowed in the SDN.

When submitting a network flow rule, the Network Admin can i) use an SDN application that dynamically calculates a flow rule in response to a PACKET IN message, and ii) use an existing SDN application running inside the controller. You have two options to actively request flow rules through the REST APIs1 it provides or the command line interface.

FIG. 2 relates to the second option described above, and shows a procedure for proactively installing a flow rule in a network switch.

First, an administrator (Network Admin) submits a flow rule addition to the SDN application through an external interface (eg, REST APIs).

Next, the application (Application) creates a FLOW MOD message based on ② the received request, and ③ stores the flow rule in the internal database (Policy DB) managed by the controller. Then, the SDN controller sends the ④FLOW MOD message to the switch.

Finally, the switch installs the flow rules in the FLOW MOD message in the flow table.

It can be seen that flow rules are managed at four processing points: manager, application, controller and switch by the procedure described above. Accordingly, the present invention utilizes that a network policy may have a different view (state) at each processing point, and refers to the concern that such a state difference may occur during the SDN operation process as a policy inconsistency problem.

3 is a diagram to explain an example of a policy inconsistency due to a flow rule of a malformed form.

More specifically, FIG. 3 shows an example in which a missing prerequisite made by a network administrator causes an error in the controller, which may lead to a state mismatch between the control unit and the data unit. This example assumes that you have a network topology consisting of a Floodlight SDN controller (Floodlight Controller), one OpenFlow-enabled switch and two hosts.

The administrator attempts to install a flow rule on the switch via the REST API provided by the StaticEntryPusher application, allowing Host A to communicate with Host B over TCP port 80. Furthermore, the procedure for installing the flow rule in the switch is as follows.

First, the network administrator requests to add a flow rule in the REST API form and sends it to the application (step 1). Then, the application stores the flow rule in the policy database (Policy DB), and transmits the success or failure of reception back to the manager (step 2).

However, when the application tries to write a FLOW MOD message, a processing error (step 3) causes the switch to disconnect from the controller. Specifically, in Fig. 3, the missing prerequisite results in a malformed FLOW MOD request.

According to the OpenFlow specification, the IP protocol must be specified when using the TCT/UDP port number in the match field of the flow rule. The problem here is that the application does not check this prerequisite and tries to write a FLOW MOD message. As a result, the internal controller loop causes the CPU to burst, resulting in a state in which the connection between the switch and the controller may be disconnected. Even worse, the controller returns a result message to indicate that the requested flow rule was installed successfully when it wasn't installed. This causes the administrator to believe that the requested rule has been properly installed. In addition, the controller will preserve the flow rules in the policy database, which will now affect all SDN applications running through the controller, which becomes a serious problem.

The present invention intends to propose a discrepancy detection technique for preventing such discrepancy.

4 is a block diagram of a network policy inconsistency detection system according to an embodiment of the present invention.

Referring to FIG. 4 , the network policy inconsistency detection system according to an embodiment of the present invention represents an automatic fuzz testing framework for detecting inconsistencies occurring between SDN components.

To this end, the network policy inconsistency detection system 400 according to an embodiment of the present invention includes a flow rule unit 410 , an application agent unit 420 , and a mismatch detection unit 430 .

4 shows how an SDN policy inconsistency is detected by the network policy inconsistency detection system 400 according to an embodiment of the present invention. To explain the workflow for this, first (1) receiving a seed file with a flow rule request from a user, the flow rule unit 410 analyzes the seed rule based on the flow rule dependency tree, Randomizes the elements and values of the seed rule. Thereafter, the flow rule unit 410 transmits the modified flow request to the application agent unit 420 .

(2) The application agent unit 420 sequentially processes the flow rule requests received from the flow rule unit 410 .

(3) The application agent unit 420 stores the flow rules in the policy database, and (4) transmits the FLOW MOD message to the switch through the flow service provided by the controller (SDN Controller).

(5) The application agent unit 420 uses the FLOW STATS message to get the flow rules installed in the switch, and then (6) includes all information about one flow rule in the rule history and transmits it to the inconsistency detection unit 430 do.

Finally, the inconsistency detection unit 430 examines the rule details based on the flow rule state diagram and presents an opinion on the existence of the flow rule inconsistency.

Referring to FIG. 4 , each component of the network policy inconsistency detection system 400 will be described in more detail. The flow rule unit 410 analyzes a seed file based on the flow rule dependency tree to determine the seed rule. Creates a flow rule request that randomizes the elements and values of

The flow rule unit 410 may include a dependency analyzer 411 and a flow request fuzzer 412 .

The dependency analyzer 411 may receive a seed file from the user and analyze the format of the seed flow request based on the flow rule dependency tree. The dependency analyzer 411 may receive a seed file of a flow rule request based on JSON or XML format from the user. Accordingly, the dependency analyzer 411 may determine whether the seed flow request is in the wrong format after examining the seed flow request based on the flow rule dependency tree. Also, the dependency analysis unit 411 may determine which seed flow request elements and values are randomized during test case generation.

The dependency analysis unit 411 according to an embodiment of the present invention maintains and manages a flow rule dependency tree, and the flow rule dependency tree includes a randomized value and a subcomponent of a randomization element, It may be a malformed flow rule created using a fuzzing technique to check whether the target SDN is causing the inconsistency problem. The flow rule dependency tree will be described in detail with reference to FIGS. 5 to 7 below.

Accordingly, the dependency analysis unit 411 transfers the decision to the flow request fuzzer 412 together with the initial flow rule request. The flow request fuzzer unit 412 randomizes by requesting one or a plurality of modified flow rules (eg, randomizing values and elements) according to the analyzed seed flow request, and then sends the seed flow to the application agent unit 420 . Requests (existing requests) and flow rule requests (modification requests) can be sent.

The application agent unit 420 creates a flow rule according to a flow rule request, and collects and manages rule details including the flow rule status of the switch for one flow rule and message information corresponding thereto.

The application agent unit 420 may include a flow rule processing unit 421 and a flow rule collection unit 422 .

The flow rule processing unit 421 serves to manage the flow rule state of the switch through the flow service provided by the SDN controller.

More specifically, the flow rule processing unit 421 receives the seed flow request and the flow rule request from the flow request fuzzer 412 , and generates a flow rule based on each request, and the policy database included in the SDN controller. (Policy DB) can be saved.

Thereafter, the flow rule processing unit 421 may transmit a FLOW MOD message including the generated flow rule and receive the flow rule status installed in the switch using the FLOW STATS message. In addition, the flow rule processing unit 421 may build a FLOW MOD message including the generated flow rule, and transmit the FLOW MOD message to the switch together with the BARRIER REQUEST message to confirm the flow rule installation by the switch.

The flow rule collection unit 422 may collect flow rules and corresponding message information and use them to detect a flow rule mismatch. In particular, the flow rule collection unit 422 may track a process in which one initial flow request received from the flow rule processing unit 421 ultimately becomes a flow rule of the switch. Accordingly, the flow rule collection unit 422 records the position where the rule processing is stopped when the flow rule is deleted in the middle, and the flow rule status of the switch corresponding to each flow rule, a FLOW MOD message, a BARRIER REQUEST message, and a FLOW STATS message It is possible to organize all records including the message information of the rule details and provide it to the inconsistency detection unit 430 .

The inconsistency detection unit 430 detects the occurrence of a flow rule inconsistency by searching the rule details based on the flow rule state diagram.

The discrepancy detection unit 430 may include a discrepancy analysis unit 431 and a discrepancy resolution unit 432 .

The inconsistency analyzer 431 may analyze the inconsistency between states by filtering the rule details using the flow rule state diagram. For example, the inconsistency analysis unit 431 may classify three abnormal cases by checking whether the state S1 flow rule request is malformed. The first anomaly refers to a case where a flow request was malformed, but the flow rule status was reached successfully. The second anomaly represents the case where the flow request conforms to the protocol but the final state is in the failed set (eg S3, S5 or S8). The last anomaly occurs when the number of flow rules on the switch is not equal to the request. The inconsistency analysis unit 431 may extract flow rules of the four states S1, S2, S4, and S9 from the filtered abnormal cases as described above and investigate the inconsistency between these states.

The flow rule state diagram defines 11 states from S0 to S10, and a specific operation of an application agent in charge of flow rule processing can be designated at each edge. The flow rule state diagram will be described in detail with reference to FIG. 8 below.

The discrepancy resolution unit 432 may process the flow rule discrepancy detected by the discrepancy analysis unit 431 . Since the inconsistency resolution unit 432 basically regards the database of the controller as the highest priority, the inconsistent flow rule of the switch may be deleted through the application agent unit 420 .

Also, the discrepancy resolution unit 432 may attempt to resynchronize the flow rules between the controller and the switch. However, the inconsistency resolution unit 432 may also delete the flow rule of the controller when the form of the rule is incorrect or the flow rule cannot be installed because the switch cannot accommodate it. According to an embodiment, the discrepancy resolution unit 432 leaves a log for post-analysis.

FIG. 5 shows an example of a flow rule dependency tree according to an embodiment of the present invention, and FIG. 6 shows an example of randomizing elements and values of a flow rule dependency tree according to an embodiment of the present invention, FIG. 7 shows an example of randomizing the rule dependency tree by removing the flow element according to an embodiment of the present invention.

A network policy inconsistency detection system according to an embodiment of the present invention uses a flow rule dependency tree to create a malformed flow rule that can check whether a target SDN causes an unexpected inconsistency problem, and arbitrarily fuzzes to create malformed flow rules use technology.

In the present invention, the first step of the flow rule dependency tree and flow rule randomization is to determine a set of input parameters that should be subjected to input randomization. All elements constituting a flow rule in the framework of the present invention may be potential targets. Therefore, for efficient randomization of flow rule elements, a flow rule dependency tree is used.

Referring to FIG. 5 , a partial dependency tree of a flow rule is shown. A rectangular node and a circular node represent an element and its value type, respectively. For example, the table_id element is an unsigned byte type, so its value must be between 0 and 255. Also, if an element has a parent element, there are dependencies between those elements. Therefore, in order for the flow rule to filter packets based on the TCP source port (tcp_src), the IP protocol (ip_proto) must be set to 6 in the match field. The dependency tree is derived from the OpenFlow specification, but can be extended depending on the implementation for other SDN controllers (eg 'isPermanent' and 'boolean' in FIG. 5).

In addition, the dependency tree-based flow rule fuzzing framework can be divided into two sub-components: randomized values and randomized elements.

When describing value randomization with reference to FIG. 6 , the value of each element in the flow rule may simply be arbitrarily designated. For example, based on the dependency tree, the priority element must be a numeric value and range from 0 to 65535. The present invention can erroneously lead to applications that create flow rules (eg, 65536 or -1) by randomizing this value without considering the range, causing overflow or underflow of numeric types. You can also add double quotation marks (“65535”) to manipulate the numeric (i.e. cast) of an element into a string format, or change the value to false to allow the application to accidentally leave the element value blank.

In describing element randomization with reference to FIG. 7 , in addition to randomizing values, the meaning of a flow rule may be manipulated by removing dependencies between elements (Element Removal). For example, as shown in FIG. 7 , the ipv4_dst element depends on the ether element, which means that the Ethernet protocol type (eg, 0x0800) must be specified in the match field to filter IP packets. However, you can remove the ether-like element to see if the controller can handle it properly. In addition, arbitrary elements may be added to the dependency tree to impair the creation process of flow rules.

Referring back to FIG. 5 , the present invention proposes a fuzzing algorithm using tree traversal and graph matching concepts to automatically randomize values and elements of a flow rule. This algorithm requires two inputs. The first input is the dependency tree Tdt = (Vdt,Edt), where Vdt is the set of nodes with elements and values, and Edt is the set of dependencies between Vdt. The second input is the seed flow rule flowseed, and the output is a set of modified flow rules M.

The algorithm initializes the output M to an empty set, and transforms the seed flow rule into a seed tree Tseed (lines 2, 3). To perform value randomization, the algorithm recursively visits every node v in the seed tree and transforms each given value. Then we modify the original node v into the transformed vmuted node in the seed tree and add it to the output (lines 4-8).

In the case of semantic randomization, the algorithm transforms the seed tree by adding new nodes or removing existing ones. To do this, we visit every edge e of the dependency tree Tdt and get element-value node pairs (lines 9-12). If they are included in the seed tree, the algorithm removes the dependency by removing the corresponding node pair vparent, vchild from the seed tree and adds it to the output set (lines 13-15). Otherwise, a new dependency edge is added by randomly selecting element node v from the seed tree and adding the node pair vparent, vchild (lines 17-20) to element node v in turn.

8 shows an example of a flow rule state diagram according to an embodiment of the present invention.

The flow rule state diagram shown in FIG. 8 defines 11 states from S0 to S10, and each edge specifies a specific operation of the application agent unit responsible for processing the flow rule. For example, if the application agent unit in the state S1 succeeds in generating the flow rule on behalf of the user request, the state of the flow rule is switched to the state S2, otherwise it moves to the state S3.

The network policy inconsistency detection system according to an embodiment of the present invention may investigate the occurrence of a flow rule inconsistency by searching the details of each rule using the flow rule state diagram.

For example, the present invention can classify three abnormal cases by checking whether the state S1 flow rule request is malformed. The first anomaly refers to a case where a flow request was malformed, but the flow rule status was reached successfully. The second anomaly represents the case where the flow request conforms to the protocol but the final state is in the failed set (eg S3, S5 or S8). The last anomaly occurs when the number of flow rules on the switch is not equal to the request. Accordingly, the present invention can extract the flow rules of the four states S1, S2, S4 and S9 from the filtered outliers as described above and investigate the inconsistency between these states.

9 is a flowchart illustrating a network policy inconsistency detection method according to an embodiment of the present invention.

The method of FIG. 9 is performed by the network policy inconsistency detection system according to the embodiment of the present invention shown in FIG. 4 .

Referring to FIG. 9 , in step 910, a seed file is analyzed based on the flow rule dependency tree to generate a flow rule request for randomizing elements and values of the seed rule.

Step 910 receives the seed file from the user, analyzes the format of the seed flow request based on the flow rule dependency tree, and generates and randomizes one or a plurality of modified flow rule requests according to the analyzed seed flow request. Thereafter, the method may include transmitting a seed flow request and a flow rule request to the application agent unit.

In step 920, a flow rule is created according to a flow rule request, and rule details including a flow rule state of a switch for one flow rule and message information corresponding thereto are collected and managed.

Step 920 creates a flow rule according to the flow rule request and the seed flow request, manages the flow rule status of the switch through the flow service provided by the SDN controller, and collects the flow rule and the corresponding message information It may include steps used to detect rule inconsistencies.

In step 930, the occurrence of a flow rule mismatch is detected by searching the rule details based on the flow rule state diagram.

Operation 930 may include filtering the rule details using the flow rule state diagram to analyze inconsistencies between states and processing the detected flow rule inconsistencies.

The system or apparatus described above may be implemented as a hardware component, a software component, and/or a combination of the hardware component and the software component. For example, the devices and components described in the embodiments may include, for example, a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate array (FPGA). , a programmable logic unit (PLU), microprocessor, or any other device capable of executing and responding to instructions, may be implemented using one or more general purpose or special purpose computers. The processing device may execute an operating system (OS) and one or more software applications running on the operating system. The processing device may also access, store, manipulate, process, and generate data in response to execution of the software. For convenience of understanding, although one processing device is sometimes described as being used, one of ordinary skill in the art will recognize that the processing device includes a plurality of processing elements and/or a plurality of types of processing elements. It can be seen that may include For example, the processing device may include a plurality of processors or one processor and one controller. Other processing configurations are also possible, such as parallel processors.

The software may comprise a computer program, code, instructions, or a combination of one or more thereof, which configures a processing device to operate as desired or is independently or collectively processed You can command the device. The software and/or data may be any kind of machine, component, physical device, virtual equipment, computer storage medium or device, to be interpreted by or to provide instructions or data to the processing device. , or may be permanently or temporarily embody in a transmitted signal wave. The software may be distributed over networked computer systems and stored or executed in a distributed manner. Software and data may be stored in one or more computer-readable recording media.

The method according to the embodiment may be implemented in the form of program instructions that can be executed through various computer means and recorded in a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, etc. alone or in combination. The program instructions recorded on the medium may be specially designed and configured for the embodiment, or may be known and available to those skilled in the art of computer software. Examples of the computer-readable recording medium include magnetic media such as hard disks, floppy disks and magnetic tapes, optical media such as CD-ROMs and DVDs, and magnetic such as floppy disks. - includes magneto-optical media, and hardware devices specially configured to store and execute program instructions, such as ROM, RAM, flash memory, and the like. Examples of program instructions include not only machine language codes such as those generated by a compiler, but also high-level language codes that can be executed by a computer using an interpreter or the like. The hardware devices described above may be configured to operate as one or more software modules to perform the operations of the embodiments, and vice versa.

As described above, although the embodiments have been described with reference to the limited embodiments and drawings, various modifications and variations are possible by those skilled in the art from the above description. For example, the described techniques are performed in a different order than the described method, and/or the described components of the system, structure, apparatus, circuit, etc. are combined or combined in a different form than the described method, or other components Or substituted or substituted by equivalents may achieve an appropriate result.

Therefore, other implementations, other embodiments, and equivalents to the claims are also within the scope of the following claims.

Claims (15)

a flow rule unit that analyzes a seed file based on the flow rule dependency tree and generates a flow rule request that randomizes elements and values of the seed rule;
an application agent unit that generates a flow rule according to the flow rule request, and collects and manages rule details including a flow rule status of a switch for one flow rule and message information according to the flow rule status; and
Inconsistency detection unit that detects occurrence of flow rule inconsistency by searching the rule details based on the flow rule state diagram
A network policy inconsistency detection system comprising a. According to claim 1,
The flow rule unit
a dependency analysis unit receiving the seed file from a user and analyzing a format of a seed flow request based on the flow rule dependency tree; and
A flow request fuzzer unit that generates and randomizes one or a plurality of modified flow rule requests according to the analyzed seed flow request, and then transmits the seed flow request and the flow rule request to the application agent unit
A network policy inconsistency detection system comprising a. 3. The method of claim 2,
The dependency analysis unit
maintaining and managing the flow rule dependency tree;
The flow rule dependency tree is
It comprises a randomization value and subcomponents of a randomization element, characterized in that it is a malformed flow rule generated using a fuzzing technique to check whether the target SDN causes a mismatch problem. , network policy inconsistency detection system. 3. The method of claim 2,
The application agent unit
a flow rule processing unit that generates a flow rule according to the flow rule request and the seed flow request, and manages a flow rule state of the switch through a flow service provided by an SDN controller; and
A flow rule collecting unit that collects the flow rule status and the message information according to the flow rule status and uses it to detect a flow rule mismatch.
A network policy inconsistency detection system comprising a. 5. The method of claim 4,
The flow rule processing unit
generating the flow rule based on the flow rule request and the seed flow request and storing it in a policy database included in the SDN controller. 6. The method of claim 5,
The flow rule processing unit
A network policy inconsistency detection system for transmitting a FLOW MOD message including the generated flow rule to the switch, and receiving the flow rule status installed in the switch using a FLOW STATS message. 7. The method of claim 6,
The flow rule processing unit
Builds the FLOW MOD message including the generated flow rule, and transmits the FLOW MOD message to the switch together with a BARRIER REQUEST message to confirm the flow rule installation by the switch. Network policy mismatch detection system. 8. The method of claim 7,
The flow rule collection unit
All records including the flow rule status of the switch for one flow rule and the message information of the FLOW MOD message, the BARRIER REQUEST message, and the FLOW STATS message are organized into the rule details and provided to the inconsistency detection unit characterized in that, the network policy inconsistency detection system. According to claim 1,
The discrepancy detection unit
a discrepancy analysis unit that filters the rule details using the flow rule state diagram to analyze discrepancies between states; and
A discrepancy resolution unit that handles the flow rule discrepancy detected by the discrepancy analysis unit
A network policy inconsistency detection system comprising a. 10. The method of claim 9,
The flow rule state diagram is
11 states from S0 to S10 are defined, and a specific operation of the application agent in charge of flow rule processing is designated at each edge. 10. The method of claim 9,
The discrepancy resolution unit
A network policy inconsistency detection system for deleting an inconsistent flow rule of the switch through the application agent unit. In the network policy inconsistency detection method of the network policy inconsistency detection system of SDN (Software Defined Network),
generating, by the flow rule unit, a flow rule request for randomizing elements and values of a seed rule by analyzing a seed file based on a flow rule dependency tree;
generating, by the application agent unit, a flow rule according to the flow rule request, and collecting and managing rule details including a flow rule status of a switch for one flow rule and message information according to the flow rule status; ; and
Detecting, by the inconsistency detection unit, occurrence of a flow rule inconsistency by searching the rule details based on the flow rule state diagram
A network policy inconsistency detection method comprising a. 13. The method of claim 12,
The step of generating the flow rule request is
receiving, by a dependency analysis unit, the seed file from a user, and analyzing a format of a seed flow request based on the flow rule dependency tree; and
After the flow request fuzzer unit generates and randomizes one or a plurality of modified flow rule requests according to the analyzed seed flow request, transmitting the seed flow request and the flow rule request to the application agent unit
A network policy inconsistency detection method comprising a. 14. The method of claim 13,
The step of collecting and managing the rule details is
generating, by a flow rule processing unit, a flow rule according to the flow rule request and the seed flow request, and managing a flow rule state of the switch through a flow service provided by an SDN controller; and
Collecting, by a flow rule collecting unit, the flow rule state and the message information according to the flow rule state, and using it to detect a flow rule mismatch
A network policy inconsistency detection method comprising a. 13. The method of claim 12,
The step of detecting the occurrence of the flow rule mismatch comprises:
analyzing the inconsistency between states by filtering the rule details using the flow rule state diagram by the inconsistency analysis unit; and
processing, by the inconsistency resolution unit, the flow rule inconsistency detected by the inconsistency analysis unit
A network policy inconsistency detection method comprising a.

Images