FMNISCF: Fine-Grained Multi-Domain Network Interconnection Security Control Framework

Abstract

The integrated air-ground multi-domain network provides users with a set of shared infrastructures. Security policies can be defined flexibly in the context of multi-domain network semantics. The packet filter module in the security gateway can run efficiently, which is an urgent requirement in this network environment. The framework combined with multi-domain network semantics implements the transformation into rules. It replaces the traditional manual method of configuring rules. The framework supports the whole life cycle management of rules from generation state and distribution state to execution state. In the aspect of security, the map security and semantic security are analyzed and optimized, respectively. Finally, through a series of experiments, compared with iptables/DPDK-IPFW/BSD-IPFW/BSD-pfsense, the high efficiency of the scheme is verified.

1. Introduction

In recent years, the complex network environment represented by the integrated air-ground network [1,2], IOT [3,4], and the complex private network [5,6] has developed rapidly, which has brought great convenience to people’s daily life and also generated a lot of security related problems, especially those dealing with data security. Therefore, as an advanced technology to protect the legitimate access to data, the research on access control technology in complex network environment is particularly necessary.

The integrated air-ground network is multiple domain networks with a set of shared communication infrastructures. The differences among the securities of the multi-domain [7] require the communication in the application scenarios to have the complex adaptive ability. This adaptability includes the following aspects, that is, in the network, the business type/feature/security level changes with the spatiotemporal characteristics of multi-domain and multi-user. The integrated air-ground network can form physical or virtual network domains due to different user types, business types, and security levels. In order to ensure the security of the cross-domain communication, a security gateway needs to be set among the domains. We call this gateway the security interconnection gateway. The security interconnection gateway is a device that can connect the multi-domain networks according to the security policies. It is set up in a domain interconnection node of isolated physical or virtual networks.

The complex network environment has the characteristics of dynamic device access, heterogeneous network segment, and frequent information flow across domains. For example, the integrated air-ground network is composed of heterogeneous networks such as space-based backbone networks, space-based access networks, ground-based node networks, ground Internet, and mobile communication networks. In this network, a large number of ground users have frequent dynamic access, and the real-time ground information obtained by the space-based access network flows to ground nodes via the space-based backbone network.

These characteristics bring many new requirements for access control technology in a complex network environment.

(1)

fine-grained control: the complex network environment has a huge amount of information, and different users have different permissions to use the information, so that the coarse-grained control will bring lots of security problems.

(2)

policy tracking: data information flows frequently between networks. If the corresponding control policy does not follow the data information ontology to the new network, users will lose control of the data.

(3)

policy semantic normalization: data information flows across different networks, and inconsistencies in policy languages between networks may cause errors in policy transformation between networks.

Existing packet filtering techniques [8,9,10,11,12] were initially used in the network to provide security protection. The access control function of the network packet is implemented on the router, and the security function of it is separated. The working principle of the program of this technology is that in a interconnected network device, it works by loading some special instructions such as allowing or prohibiting packet transfer from specific source address, destination address, TCP terminal number, etc. Through the corresponding instructions for series of equipment inspections of packets, it can restrict dangerous packets in and out of the internal network. The advantages of the control are obvious. It can keep high transparency to users, and high work efficiency. However, he also has serious shortcomings. For example, the manager can’t fully control information flow in the network. It only can control the most basic security maintenance. In the face of the high technical content of attack without resistance, it is difficult to upgrade maintenance, and so can’t maintain the security of users.

These characteristics bring many new requirements for access control technology in a complex network environment. The fine-grained interconnection security control framework is a key technique for multi-domain interconnection and access control in multi-domain networks. The impacts of it are the following aspects:

First, for the complexity of rules working at the bottom, a policy needs to be designed to simplify the description of logical relationships in complex networks. With this abstract level of policy language, when designing business-oriented access control logic, network configuration scripts based on the policy language can look more concise and understandable. In engineering practice, the domain of the network can be easily configured, and the packet filter program can be executed efficiently in the gateway. The policy language designed for users in the network can be used to configure network security constraints flexibly and improve the readability and maintenance of programs. This requires normalization of policy semantics and data information flows across different networks. In addition, inconsistencies in policy languages between networks may cause errors in policy transformation between networks.

Second, in complex business application scenarios, inter-domain isolation needs to be supported. The traditional coarse-grained access control model can no longer fully meet the requirements of access control under complex networks in many scenarios. In recent years, fine-grained interconnection security control [13,14,15] has developed rapidly and has important applications in the internet of things security and cloud security.

Many of the current attacks are more and more application-oriented, such as cross-network scripting attacks, SQL injection attacks, and lunch attacks. This puts forward higher requirements on the dimension of data filtering. This requires the system to be able to filter packets at a fine-grained level. They include time and characteristics. The complex network environment has a huge amount of information, and different users have different permissions to use the information, so that the coarse-grained control will bring about lots of security problems. Data information flows frequently between networks. If the corresponding control policy does not follow the data information ontology to the new network, users will lose control of the data.

In addition, to turn access control policies for complex application scenarios into rules, a mapping needs to be designed. By designing a map, the polices are translated into the rules automatically. In the security policies, the description of multi-domain interconnection is supported. Users can flexibly set the network functions according to the network security requirements.

Finally, to meet the needs of high-speed network communication, it is necessary to design rules that can adapt to the high-speed filtering packet of security gateway and the fast filtering of gateway. According to our proposed rules, gateways can filter packets efficiently. By summarizing the above requirements, it can be concluded that the fine-grained interconnected security access control framework needs to design an abstract language (policy) that can directly describe complex application scenarios, with fine-grained attributes that resist more attacks. The gateway can load and execute rules efficiently. Mapping mechanisms can translate policies into rules. The research progress in these aspects will be introduced below.

1.1. Related Work

Due to the importance of fine-grained multi-domain interconnection security control to high-traffic network platforms and devices, various methods have been used to solve the problems related to multi-domain interconnection, conflict detection, rule transformation, and fine-grained control. In this section, we’ll review existing technologies and describe the differences from FMNISCF. Regarding multi-domain interconnection management, Iizawa et al. [16] proposed a network orchestrator based on ODENOS (object-defined network allocation system) for orchestrating multi-layer and multi-domain networks. The network orchestrator can dynamically provide end-to-end paths according to requests of network services. Li et al. [17] proposed a controller cluster-based interconnecting framework based on load balance, which can be implemented through two levels of controller coordination, i.e., inter-cluster and intra-cluster interconnection. However, they have not carefully demonstrated and considered the security issues among domains. For the map from policies to rules, Min et al. [18] proposed a policy generation method for a control system in open environments. The main idea is to formalize the description of the control policy step by step, associate each stage of the policy generation in an automatic way, and reduce the difficulty of the description, generation, and final application of the policy. Hager et al. [19] proposed RuleBender, a rule set transformation technique that encodes decision tree search structures into the transformed rule set, which in turn can be traversed significantly faster. However, they have not demonstrated the security of rule map in detail, and there are more ways to utilize the traversal speed of rule set. Aiming at rule conflict detection, Pisharody et al. [20] proposed a security policy analysis framework Brew based on OpenDaylight SDN controller, which identified and solved cross-layer conflicts by using global priority ranking technology for convection rules in a decentralized environment. Khelf et al. [21] proposed an algorithm for dynamic detection of both intra and inter conflicts of an IPsec security policy. The proposed algorithm is based on a simple and comprehensive mechanism that uses Boolean functions to classify and identify. The resolution of intra-policy conflict is also integrated into the algorithm. However, there is no detailed discussion of the semantic security of the rules. For fine-grained management control, Liu et al. [22] proposed a fine-grained two-factor authentication (2FA) access control system for web-based cloud computing services, which requires a user key and a lightweight security device to complete fine-grained access control of the system and enhance the security of the system. Pei et al. [23] proposed a fine-grained access control method for the cloud resources, and the basic idea is to use XACML as an access control language and optimize policies by data fragmentation and policy refinement algorithms. The XACML language can determine whether users can access web resources or not. Merindol et al. [24] proposed a new fine-grained multi-source measurement platform DCART. DCART is a distributed platform running over an operational network (RENATER, the French research and education network); it gathers data from several sources.

1.2. Our Work

However, the above systems do not introduce time features and cannot control the detailed content characteristics of the packet. Different from existing studies, our work generates rules by translating policies, and builds a tree structure of rules to filter packets. The same condition is integrated when the rules are generated by the policy, which ensures that there is no conflict and redundancy among rules. At the same time, the rules are arranged in lexicographical order, which facilitates binary search in packet filtering and improves matching speed. Our work introduces fine-grained control of time, characteristic, and adds constraint conditions of time and characteristics to the rules. When filtering packets, not only the five-tuples need to be matched, but also the time and the URL characteristics need to be matched. We also design the syntax of policies and rules respectively and discuss the semantic security of policy-to-rule transformations in multi-domain networks by using a formal method. In the experimental part, we compare the performance of our scheme with the netfilter/iptables of the Linux operating system. The results show that our scheme is more efficient.

2. Framework

In order to facilitate the management and application, a security policy language is designed, which fits users’ usage habits. However, this security policy language has low performance and complex logic, which cannot be directly applied to high-throughput security interconnection gateway. Therefore, a map method is proposed, which interprets security policies as security rules.

Consider a situation where user $u_1$ of domain $d_1$ and user $u_2$ of domain $d_2$ can communicate with each other using $ap{p}_1$. The communication time is limited from 9:00 a.m. to 10:00 a.m. every day, and there is no restriction on feature contents. The details of $ap{p}_1$ communication among domains $d_1$ and $d_2$ are stored in a relationship and do not appear directly in the policy script. We can express it as follows:

$$\left[\begin{array}{ccc}default& :& drop\\ whitelist& :& \{d_1-d_2,ap{p}_1\}\end{array}\right].$$

By means of map components, we can translate this policy into rules that can be loaded by the gateway. See the following:

$$\left[\begin{array}{c}\mathrm{10.0.0.1}-\mathrm{10.0.0.1},\mathrm{20.0.0.2}-\mathrm{20.0.0.2},6-6,\\ 0-65,535,23-23,287,485,200-287,488,800,\_:accept\end{array}\right],$$

where $\mathrm{10.0.0.1}$ is the address of user $u_1$, $\mathrm{20.0.0.2}$ is the address of user $u_2$, 6 is the type of TCP, 0–65,535 is the source port range, 23–23 is the destination port of range, 287,485,200–287,488,800 means 9:00 a.m.–10:00 a.m. every day, the symbol _ means that there is no restriction on feature contents, and $accept$ is the action of rule. The detail of time code can be shown in Formulas (38) and (39).

Once the gateway loads this rule, it allows only packets that conform to the rule to pass through, with the rest discarded by default.

Generally speaking, security rules are a kind of language which can be loaded by a security interconnection gateway. The security interconnection gateway has a large capacity and high efficiency of execution to meet the requirements of fine-grained security control of the integrated network of air–ground in multiple domains and achieve the purpose of in-depth protection. In this paper, we propose a multi-category of joint protection security rules.

Security rules have life cycle management, which consists of the generation state of security rule, distribution state, and execution state. The elements mentioned above form the framework of fine-grained multi-domain network interconnection security control, FMNISCF for short. The specific relationships will be shown in Figure 1.

2.1. Security Policy

Security policies in the system are used to help engineers configure access control logic information for multi-domain networks. Therefore, the security policy should be able to represent the information such as domain, application, connect/reject etc, and organize them together in the form of a list to form an overall control map. We design a policy language, which is a collection of strings called $\mathcal{P}$. The semantics of security policies can be expressed as a map:

$$pf:\mathcal{D}\times \mathcal{D}\times APP\to action,$$

(1)

where $\mathcal{D}$ is a set of domains of the network, $APP$ is a set of applications of network and $action$ is a set of actions that gateway can do. From the perspective of relationship, in the multi-domain network, application communication among domains needs to rely on IP address, protocol, and port at the network layer. In addition, we also add time and URL (Uniform Resource Locator) characteristics. They form a relationship in a multi-domain network, whose detail is as follows:

$$R_{mdr}\subseteq \mathcal{D}\times \mathcal{U}\times IP\times APP\times PROTOCOL\times PORT\times TIME\times REG,$$

(2)

where $\mathcal{U}$ is a set of users in the multi-domain network, $IP$ is a set of IP addresses, $PORT$ is a set of communication port in the network, $TIME$ is a set of time, and $REG$ is a regular expression language.

2.2. Security Rule

Security rules can be loaded by the gateway. Corresponding to the policy, we also design a rule language, which is a collection of strings called $\mathcal{R}$. In fine-grained access control logic, it is a map that maps dimensional parameters to actions. It can be shown as follows:

$$rf:{\mathcal{T}}_1\times {\mathcal{T}}_2\times \dots \times {\mathcal{T}}_n\to action,$$

(3)

where ${\mathcal{T}}_i$ is a dimension in fine-grained access control logic. In the rule which is designed by engineering personnel, the gateway analyzes packets from seven dimensions: source IP address, destination IP address, protocol type, source port, destination port, gateway time, and URL characteristics.

2.3. Execution of Packet Filter

During the process of gateway loading rules, the loader acts as a map. This map transforms a specific rule string into a packet filtering machine. This machine is the semantics that rules represent. It can be shown as follows:

$$ef:\mathcal{R}\to {\mathcal{M}}_{rf},$$

(4)

where ${\mathcal{M}}_{rf}$ is a machine that can load security rules and filter packets. It has two kinds of instructions: $loadsecurityrule$ and $fiterpacket$. The machine can be understood as having a matching tree. It updates the matching tree structure by executing the $loadsecurityrule$ instruction. When it performs the $fiterpacket$ instruction, it determines whether the packet is accepted or not by comparing each field of the packet in the matching tree.

2.4. Map

The map from policy to rule is a translator that translates the policy language into the rule language. The semantic consistency between the two is required in this process. It can be shown as follows:

$$mf:\mathcal{P}\to \mathcal{R}.$$

(5)

The above is the definition of FMNISCF four components, which are independent of each other and complete the whole life cycle management of security rules through mutual cooperation. In the integrated air-ground multi-domain network, the network communication can be configured according to the actual security requirements of the domain, and the process can be executed safely and efficiently.

3. Implementation

In this section, we will use Backus–Naur Form (BNF) paradigm to give a normalized policy/rule language definition and define a map method from policy language to rule language. As a formal description of policies and rules, subsequent security proofs depend on their structure.

3.1. Security Policy Grammar

In the following production, the string is enclosed in double quotation “”, the brackets $\left[\right]$ indicate that the element appears at most once, the asterisk ${}^{*}$ indicates that the element appears 0 time or more times, and the parentheses 〈〉 indicate that the element is a production reference as a whole:

$$\begin{array}{ccc}policyset& ::& [“default”“:”action]polic{y}^{*},\end{array}$$

(6)

$$\begin{array}{ccc}policy& ::& 〈whitelist〉\\ & |& 〈blacklist〉\\ & |& 〈scopeactionlist〉,\end{array}$$

(7)

$$\begin{array}{ccc}whitelist& ::& “whitelist”“:”“\{”〈listbody〉“\}”\end{array},$$

(8)

$$\begin{array}{ccc}blacklist& ::& “blacklist”“:”“\{”〈listbody〉“\}”\end{array},$$

(9)

$$\begin{array}{ccc}scopelist& ::& “scope”“\{”〈listbody〉“\}”\end{array},$$

(10)

$$\begin{array}{ccc},listbody& ::& confi{g}^{*}\end{array},$$

(11)

$$\begin{array}{ccc},config& ::& ID“-”ID“,”application“;”\end{array}$$

(12)

$$\begin{array}{ccc}application& ::& ID\\ & |& “[”〈applist〉“]”\\ & |& *\end{array},$$

(13)

$$\begin{array}{ccc}applist& ::& ID{(“,”ID)}^{*}\end{array},$$

(14)

$$\begin{array}{ccc}action& ::& “accept”|“drop”\end{array},$$

(15)

where $ID$ is a string literal and its detailed definition can refer to the string definition in the c99 standard.

In addition, the functional-independent annotation syntax is not mentioned above. Strictly speaking, they are also part of the policy language.

3.2. Security Rule Grammar

$$\begin{array}{ccc}ruleset& ::& [default:action]rul{e}^{*}\end{array},$$

(16)

$$\begin{array}{ccc}rule& ::& 〈ipsection〉“,”〈dstiprule〉\end{array},$$

(17)

$$\begin{array}{ccc}dstiprule& ::& 〈ipsection〉“,”〈protocoltyperule〉\\ & |& “\{”〈dstiplist〉“\}”\end{array},$$

(18)

$$\begin{array}{ccc}protocoltyperule& ::& section“,”〈srcportrule〉\\ & |& “\{”〈protocoltypelist〉“\}”\end{array},$$

(19)

$$\begin{array}{ccc}srcportrule& ::& section“,”〈dstportrule〉\\ & |& “\{”〈srcportlist〉“\}”\end{array},$$

(20)

$$\begin{array}{ccc}dstportrule& ::& section“,”〈timerule〉\\ & |& “\{”〈dstportlist〉“\}”\end{array},$$

(21)

$$\begin{array}{ccc}timerule& ::& section“,”〈characteristicrule〉\\ & |& “\{”〈timelist〉“\}”\end{array},$$

(22)

$$\begin{array}{ccc}characteristicrule& ::& 〈characteristicsection〉“:”action“;”\\ & |& “\{”〈characteristiclist〉“\}”\end{array},$$

(23)

$$\begin{array}{ccc}dstiplist& ::& (ip“,”〈protocoltyperule〉{)}^{*}\end{array},$$

(24)

$$\begin{array}{ccc}protocoltypelist& ::& (section“,”〈srcportrule〉{)}^{*}\end{array},$$

(25)

$$\begin{array}{ccc}srcportlist& ::& (section“,”〈dstportrule〉{)}^{*}\end{array},$$

(26)

$$\begin{array}{ccc}desportlist& ::& (section“,”〈timerule〉{)}^{*}\end{array},$$

(27)

$$\begin{array}{ccc}timelist& ::& (section“,”〈characteristicrule〉{)}^{*}\end{array},$$

(28)

$$\begin{array}{ccc}characteristiclist& ::& (〈characteristicsection〉“:”action“;”{)}^{*}\end{array},$$

(29)

$$\begin{array}{ccc}ip& ::& 〈ipnumber〉“.”〈ipnumber〉“.”〈ipnumber〉“.”〈ipnumber〉\\ & & -〈ipnumber〉“.”〈ipnumber〉“.”〈ipnumber〉“.”〈ipnumber〉\end{array},$$

(30)

$$\begin{array}{ccc}ipsection& ::& “[”ip{(“,”ip)}^{*}“]”\\ & |& ip\end{array},$$

(31)

$$\begin{array}{ccc}section& ::& number“-”number\\ & |& “\_”\end{array},$$

(32)

$$\begin{array}{ccc}characteristicsection& ::& 〈regularexpression〉\\ & |& “\_”\end{array},$$

(33)

where $number$ is a decimal natural number, $ipnumber$ is a decimal number ranging from 0 to 255, and the detailed definition of $regularexpression$ is available in reference [25].

3.3. Map Policies to Rules

As a map, this section transforms the conforming policy language into the corresponding rule language. In combination with the actual situation, IP addresses among users are different, and IP addresses domains are also different. Therefore, we can further conclude that the relation has the following properties:

Definition 1.

$\forall u\in \pi {}_{\mathcal{U}}\left(R_{mdr}\right).\exists ip.〈u,ip〉\in \pi {}_{\mathcal{U},IP}\left(R_{mdr}\right)$,

Definition 2.

$\forall d\in L(config-ID).\pi {}_{\mathcal{U}}\left({\sigma }_{\mathcal{D}=d}{R}_{mdr}\right)\ne \varnothing$,

Definition 3.

$\forall app\in L(application-ID).\pi {}_{APP}\left({\sigma }_{APP=app}{R}_{mdr}\right)\ne \varnothing$,

Definition 4.

$\forall re{g}_1,re{g}_1\in \pi {}_{REG}\left(R_{mdr}\right).re{g}_1=re{g}_2\vee \mathcal{L}\left(re{g}_1\right)\cap \mathcal{L}\left(re{g}_2\right)=\varnothing$,

Definition 5.

$\forall 〈d_1,i{p}_1〉,〈d_2,i{p}_2〉\in {\pi }_{\mathcal{D},IP}\left(R_{mdr}\right).d_1\ne d_2⟶i{p}_1\ne i{p}_2$,

Definition 6.

$\forall 〈u_1,i{p}_1〉,〈u_2,i{p}_2〉\in {\pi }_{\mathcal{U},IP}\left(R_{mdr}\right).u_1\ne u_2⟶i{p}_1\ne i{p}_2$,

where $\pi$ is a projection operation on a relationship. The parameters between them are the terms to be projected. The function $L\left(\right)$ represents a collection of strings that a node of grammar tree matches. The function $\mathcal{L}\left(\right)$ is a set of strings represented by a regular expression. Now, we describe the steps of the algorithm by means of the following examples:

$$\left[\begin{array}{ccc}default& :& accept\\ whitelist& :& \left\{A-B,app1A-C,\left[app1,app2\right]A-B,app2\right\}\\ blacklist& :& \{A-B,app1A-B,app3\}\\ scopelist& :& \left\{A-B,app1,app2,app3\right\}\end{array}\right].$$

(34)

• From Formulas (6) and (16), we can know that $\epsilon \in policylanguage\wedge \epsilon \in rulelanguage$, where $\epsilon$ is empty string. We specify that, when the policy is $\epsilon$, the corresponding rule image is $\epsilon$. Using the same policy, we transform $[“default”“:”action]$ statement from the policy to rule.
• Transform a $policy$ statement into a $rule$ statement. We divide the $policy$ into three cases: when the $policy$ is $whitelist$, the rule action is translated as $“accept”$; when the policy is the $blacklist$, it is translated as $“drop”$, and, in the last case, it is translated as the default statement of the opposite action.
  First, merge every $config$ bar in the whitelist into a tree (white list tree). Traversal from root to leaf: if the two nodes currently being compared are the same, merge them into one node; otherwise, the remaining subtrees are merged under the parent node. Figure 2 is the algorithm of $config$ in $whitelist$ to merge into white list tree.
  Next, merge each $config$ of the blacklist into the white list tree in turn and conflict checking is performed for each merge. The specific process is that, if the exact same subtree appears, the system will prompt for a “detected conflict” message. Figure 3 and Figure 4 show an example of a conflict detected.
  Next, each scope list is merged into the whitelist tree, as opposed to the default operation, which merges the list (if the default action is accepted, it merges with the blacklist; otherwise, it merges with the whitelist). Figure 5 shows that the scope list is merged into the whitelist tree.
  Through this algorithm, a new tree can be merged into the existing tree, and the original principle can be maintained. The operation to merge the subtree into the original tree is represented by plus sign +.
• If the $listbody$ is $\epsilon$, translate $\epsilon$ as follows (all other parts of the signed ${}^{*}$ are the same). When there is only one configuration, from Formula (12), we have:

  $$\begin{array}{ccc}config\hfill & ::\hfill & ID“-”ID“,”application“;”\hfill \end{array}.$$
  From script (34), we get the domain set $\{A,B,C\}$ and the application set $\{ap{p}_1,ap{p}_2,ap{p}_3\}$. For example, the domain of A corresponds to IP interval [10.0.0.1-10.0.0.3 10.0.0.5, 10.0.0.7]. Similarly, the IP interval of the domain B is [6,8-9]. For the language element $A-B$ of the security policy script, it can be translated into the source IP interval, and the destination IP interval of the language element in the security rules script respectively. It can be written as [1-3,5,7,10],[6,8-9]. Similarly, $a-c$ can be translated into [1-3,5,7,10],[10,12].
• Ignoring the control characters $“,”$ and $“;”$, we consider the second half of the formula $“application”$. We mark these $APP$s as $ap{p}_i$. By Definition 3, for each $ID$, it can obtain the protocol type, destination port, time, and characteristics via relational operation expression $\pi {}_{PROTOCOL,PORT,TIME,REG}\left({\sigma }_{APP=ap{p}_i}\left(R_{mdr}\right)\right)$. The source port is used for its own side to receive messages and is randomly assigned with no restrictions. Covert this relational structure into a tree structure in order. The application element is translated into protocol type interval, source port interval, destination port interval and time interval characteristics in security rules. By searching for application name in scripts, we can get a security rule subtree with an application from the multi-domain network. For example, $ap{p}_1$ uses TCP, UDP and ICMP protocols. Among them, TCP uses port 80 as the destination port, and UDP uses port 90 as the destination port. The usage time of app1 is limited to 5:00 a.m.–11:00 a.m. per day. The algorithm is illustrated by the following Figure 6:
• In steps 3 and 4, multiple tree merges are involved. Our approach is the same merge, different splits. Combining the whitelist tree of step 2, the security policy language is finally translated into the security rules script. In this process, the subtrees of the step 2 are connected, and the corresponding actions are added to the final rule part in combination with the black and white list action of the whitelist tree.

In the implementation, the packet filter module will call the mutual exclusion of the two operations through the synchronization variable $lock$ when loading the forest rules or filtering the packet. Algorithm 1 is described precisely as follows:

Algorithm 1: Fine-grained packet filter

We define a type named $Forest\_policy$ whose type can be seen in Formula (35):

$$\begin{array}{cc}\hfill Fore& st\_policy\{\hfill \\ \hfill & Forest\_policyparent;\hfill \\ \hfill & List<Forest\_policy>child\_list;\hfill \\ \hfill & Union\{List<Interval>data\_list;\hfill \\ \hfill & Enumerateaction;\hfill \\ \hfill & \}list\_action;\hfill \\ \hfill \},\end{array}$$

(35)

where $parent$ is the parent of this level, and $child\_list$ is its children. $child\_action$ is the data of the node.

There are four levels of the forest which has been built. They are the source of the domain, the destination of the domain, the application, and the action of the forest policy, respectively. Corresponding to $Forest\_policy$, we also define $Forest\_rule$. There are eight levels that are the source of IP, the destination of IP, the source of the port, the destination of the port, the protocol type, the time, the characteristic, and the action. See Formula (36):

$$\begin{array}{cc}\hfill Fore& st\_rule\{\hfill \\ \hfill & Forest\_ruleparent;\hfill \\ \hfill & List<Forest\_rule>child\_list;\hfill \\ \hfill & Union\{List<Interval>data\_list;\hfill \\ \hfill & Enumerateaction;\hfill \\ \hfill & \}list\_action;\hfill \\ \hfill \}.\end{array}$$

(36)

The policies can be mapped to the rules by Algorithm 3. The initialization of it also needs to be finished by Algorithm 2. It merges each policy tree in the policy file into the forest policy. In the process, the algorithm simultaneously merges the policies and detects conflicts.

Algorithm 2: Merge trees into forest

Each policy p in the list is regarded as a tree, so policies f can be considered as a forest. Both forest and trees are three-layer structures. The layers represent source domain, destination domain, and app, respectively. As for app nodes, they all contain an action field ($BLACK$/$WHITE$/$SCOPE$). The function of Algorithm 2 is to merge trees into a forest.

Algorithm 2 is described precisely as follows:

Travel through every tree in the forest and try to merge policy p into the tree. If it fails to merge policy p into any tree in the forest, just add policy p into $f.chil{d}_{l}ist$. The method of merging trees is as follows. First, compare the root node of policy p with that of the i-th tree in the forest, which are denoted as t and $f\_roo{t}_i$, respectively. If they are different, policy p cannot be merged into the i-th tree. Try to merge it into another tree. If they are the same, compare their child nodes which are denoted as $p\_node$ and $f\_node$.

If a child node of $f\_roo{t}_i$ denoted as $f\_nod{e}_j$ is the same as $p\_node$, compare their child nodes which are denoted as $f\_app$ and $p\_app$, or add $p\_node$ to $f\_roo{t}_i.child\_list$.

For each $p\_app$, if there is no $f\_app$ like it, add it to $f\_nod{e}_j.child\_list$. If there is an $f\_app$ denoted as $\_ap{p}_l$ which is the same as $p\_ap{p}_k$, compare their actions. If one is $SCOPE$ and the other is $BLACK$ or $WHITE$, then $f\_ap{p}_k.action$ = $BLACK$ or $WHITE$. If they are different and neither is $SCOPE$, throw “conflict detection!”.

Algorithm 3 is described precisely as follows:

In Algorithm 3, it maps forest policies f, p into forest rules r, t. For each tree in the forest f, p, use the following method to turn it into a rule tree. As mentioned above, the trees of policy forest are three-layer structure, representing source domain, destination domain and app, respectively. Thus, given the root of the i-th tree, we can get the source domain, and further obtain the source IP address $srci{p}_i$ by searching the set of relationships $R_{mdr}$. The destination IP address $dsti{p}_j$ can be obtained similarly. Then, add it to $srci{p}_i.child\_list$. From the app, we can get the information of protocol, source port, destination port, time, reg and action. Add them to the $child\_list$ of their previous element respectively and make $reg$ the leaf node of the rule tree. Leaf nodes of rule trees contain an action field which is the same as the app node of the original policy tree.

Algorithm 3: Map policies to rules

Time coding is divided into absolute time and relative time. Time elements such as year, month, day, week, hour, minute and second are used to encode relative time. Absolute time is encoded in seconds that have elapsed since 1 January 1970. The relative time of the base structure from low to high is 60, 60, 24, 7, 31, and 12. Of these, number 7 means that the week is unlimited. Number 31 means days are unlimited. Number 12 means month is unlimited. For the time format “$yyyy-mm-ddhh:MM:ss$”,

$$\begin{array}{c}\mathrm{intToRe}(mm,dd,w,hh,MM,ss)=ss\times 1+MM\times 60+hh\times 60\times 60+w\times 24\times 60\times 60\hfill \\ \hfill +dd\times 7\times 24\times 60\times 60+mm\times 31\times 7\times 24\times 60\times 60,\end{array}$$

(37)

where the week w can be calculated using the library function provided by “time.h”. For example, from 9:00 a.m. to 10:00 a.m. every day, the code of relative time is Formulas (38) and (39):

$$287485200=\mathrm{intToRe}(12,31,7,9,0,0),$$

(38)

$$287488800=\mathrm{intToRe}(12,31,7,10,0,0).$$

(39)

If it’s 0:00 a.m. to 0:00 a.m. per day, this means that there’s no limit about time. For “$\mathrm{intToAb}(·)$”, we first reverse calculate $[mm,dd,w,hh,mm,ss]={\mathrm{intToRe}}^{-1}(·)$, obtain the current absolute time via “$time(·)$”, then assign the rest to the absolute time structure, and finally calculate the absolute time value through the library function “$mktime(·)$”.

Algorithm 4 is described precisely as follows.

In Algorithm 4, given the relative time interval which begins with $stam{p}_1$ and ends with $stam{p}_2$, the corresponding absolute time interval can be obtained. Time stamp is an integer and can be converted into relative time or absolute time through function “$\mathrm{intToRe}(·)$” or “$\mathrm{intToAb}(·)$”. Using function “${\mathrm{intToRe}}^{-1}(·)$” for $stam{p}_1$ and $stam{p}_2$, we can get six pairs of numbers representing the restrictions on month, date, day of week, hour, minute, and second. Placing restrictions on month means the period from one month to one month every year and no restriction implies January to December. Similarly, for date, day of week, hour, minute, and second, whether to make restrictions or not is optional.

Algorithm 4: Convert relative time into absolute Time

Using function intToAb() for update, the time stamp of current time, we can get the current month, date, day of week, hour, minute, and second. If current time meets the limits to month, date, and day of week, there are two cases to consider. One case is that there are no limits to hour, minute, and second, and the other is that hour, minute, and second are limited. For the former, the absolute time interval converted is from 0:0:0 a.m. that day to 0:0:0 a.m. the next day. For the latter, it is the limited time interval that day. If current time does not meet any limit to month, date or day of week, the absolute time interval converted is from 1 January 1970, 0:0:0 a.m. to 1 January 1970, 0:0:0 a.m..

Algorithm 5 is described precisely as follows:

Since absolute time interval are converted from relative time interval according to current time, the absolute time interval converted should change as current time changes. Thus, it is necessary to invoke Algorithm 5 to update absolute time interval to ensure accuracy. The update input is the time stamp of the last time calling Algorithm 4. If the time stamp of packet $packetTime$ is bigger than $update$, invoke Algorithm 4 and update $update$ ensuring that the next update will be completed before the time constrained.

Algorithm 5: Update time interval

3.4. Match Tree Building of Packet Filter

The transmitted security rules are built into a packet filter match tree in the gateway machine. The implementation method is to build an 8-layer filter matching tree. The root node is in the first layer, the second layer is the source IP range of child nodes, and the third layer is the source IP range of which the parent node is IP range node. By analogy, the fourth floor is protocol type interval, the fifth layer is the source port interval, the sixth layer is the destination port, the seventh layer is the time interval, and the eighth floor is URL characteristics. As you can see from step 2, the security rule script has a very similar structure to the filter match tree. This procedure can be understood as the gateway machine ${\mathcal{M}}_{rf}$ executing the $loadsecurityrule$ instruction.

After the matching tree has been built, when the gateway machine executes the instructions $filterpacket$, it will start from the root node, from top to bottom, and select the matching subtree from the eligible subtree, until it finds the action of the leaf node. In particular, if no eligible subtrees are found at a certain level, it jumps out of the tree traversal and performs the default action.

4. Security of System

We treat the $policyset$ as a string of elements, which can be abstracted into three categories: Empty set $\epsilon$, $default“:”action$, and $policy$. According to the policy set grammar, we know that:

Definition 7.

1. 

Empty set is a policy set.

2. 

The default action is a policy set.

3. 

A policy set join policy is a policy set.

4. 

The other cases are not a policy set.

The join operation between the policy set and the policy is marked as ⊕. According to the above definition, the join operation is closed on $policyset$. The $〈policyset,\oplus 〉$ now constitutes an algebraic system.

In the same way, rule sets are also divided into three similar parts: empty set $\epsilon$, $default“:”action$, and $rule$.

According to the rule set grammar, we know that:

Definition 8.

1. 

Empty set is a rule set.

2. 

The default action is a rule set.

3. 

A rule set join rule is a rule set.

4. 

The other cases are not a rule set.

The join operation between the rule set and the policy is marked as ⊗. According to the above definition, the join operation is closed on $ruleset$. The $〈ruleset,\otimes 〉$ now constitutes an algebraic system.

4.1. Map Security

Review Section 3.3 map policies to rules, we stipulate map $mf$:

$$mf\left(p\right)=\left\{\begin{array}{cc}\epsilon \hfill & p=\epsilon ,\hfill \\ default“:”action\hfill & p=default“:”action,\hfill \\ mf\left(p^{\prime }\right)+p_{config}\hfill & p=p^{\prime }{p}_{config}.\hfill \end{array}\right.$$

(40)

The meaning of the operator + is specified above.

Theorem 1.

$\forall p\in policyset.\exists r\in ruleset.mf\left(p\right)=r$

Proof. 

From Formula (40), if $p=\epsilon$ or $p=default“:”action$, the theorem is established.

Assuming that $mf\left(p^{\prime }\right)$ satisfies the Theorem 1, we can deduce that this policy has a corresponding $tre{e}_{p^{\prime }}$. From Step 3, the policy $p_{config}$ also has a corresponding $tre{e}_{p_{config}}$. From Step 5, these trees can be merged into a $tre{e}_p$, which can be translated into a rule.

Now, this theorem is proved by induction. □

From Theorem 1, we can reach a conclusion that, for every set of grammatical and semantical policies in the network, we can always find the set of rules corresponding to them.

4.2. Semantic Security

In terms of the semantics of rules, machine $M_{rf}$ with the same function is a kind of rule class for different forms of rules. The difference of these rules can be reflected in the choice of the interval, such as the case of $1-3$, $3-4$ and $1-2$, $2-4$. However, in terms of the point of view of the packet filtering function of the machine, they are the same.

Lemma 1.

$!\exists p\in policyset,M_{pf1}\ne M_{pf2}.ef\left(mf\left(p\right)\right)=M_{pf1}\wedge ef\left(mf\left(p\right)\right)=M_{pf2}$.

Proof. 

Suppose there is a rule p that performs both receive and discard actions for a packet. This requires the encoding of the interval to have two meanings, which does not conform to the natural number encoding, time encoding, and collection of characteristic encoding (from Definition 4). This leads to a contradiction. □

Theorem 2.

The map $ef$ is well-defined. (It involves semantics of $mf$)

Proof. 

According to Lemma 1, we know that the relation of the semantics of policy/rule forms a partition of it. From Theorem 1, we can know $\forall p\in policyset.\exists M_{pf}=ef\left(mf\left(p\right)\right)$. Combined with the properties of partition, if two $M_{pf1}$, $M_{pf2}$ are different, the corresponding partition must be different. This satisfies two requirements of a well-definition. □

By Theorem 2, we can guarantee that the “Execution of packate filter” component will not generate ambiguity, thus ensuring semantic security.

4.3. Optimization

Theorem 3.

Nodes in the same hierarchy can be arranged in order except for their characteristics.

Proof. 

Considering the source IP, destination IP, protocol type, source port, destination port and time, they are all encoded with a natural number, and there is no intersection between the intervals of each node, so they can be arranged orderly. □

By Theorem 3, we can optimize the packet filtering algorithm. In addition to characteristic nodes, nodes at other levels can be arranged in an orderly manner, so the gateway can use the binary search method to retrieve the rule tree.

5. Performance

The operation interface of the three procedure in the framework FMNISCF is shown as follows:

Figure 7a shows the configuration of a security policy on a web browser. The newly added security policy is saved in the database, and then the user can see it in the list. Figure 7b shows the deployment of security rules to the gateway through a web browser. While clicking the “Distribute” button, the system automatically converts security policies into security rules and deploys them to the gateway. Figure 7c shows the gateway loading security rules sent by the visual management system into the gateway through the security rules loader. Thus, the interconnected security gateway can filter fine-grained packets.

We test the performance of three processes of the framework FMNISCF. Since instructions are distributed by socket communication, the selection of operating system version does not affect FMNISCF deployment. The test hardware environment, software environment and running speed under different configurations are given below:

Table 1. The Relation between test unit and running environment of hardware.

CPU	DDR4	OS	Test Unit
Intel(R) Xeon(R)	128 G	Centos 7	Policy translation
E5-2670 0 2.60 GHz
Intel(R) Xeon(R)	4 G	Ubuntu 14	Rule loading
E3-1220 V2 3.10 GHz			Packet filter

shows the interconnected security gateway and the hardware environment of the visual management system. Interconnection security gateway, controlled by the visual management system, can accept or drop the packets passing through the network according to the instructions sent by the system.

We use software “iPerf3” [26] as the packet sending tool. It simulates communication scenarios in the network.

Table 2. The relation between test unit and running environment of FMNISCF.

Software	Version	Test Unit
database	MySQL 5.0	Policy translation
in-memory data	redis 4.0	Policy translation
structure store
JVM	JDK1.8.0	Policy translation
web framework	spring MVC 4.2	Policy translation
persistence framework	mybatis 4.2	Policy translation
Java security framework	Apache Shiro 1.2.5	Policy translation
JavaScript library	JQuery 1.8.3	Policy translation
netfilter	linux kernel	Rule loading
	3.10.0-862.el7.x86_64	Packet filter
iPerf3	iperf-3.1.3	Packet sending

shows the software environment of each state during the rule life cycle management. In the policy transfer phase, a database is required to store security policies, security rule data, and other management information. The data caching software in the web background improves the speed of data query in the system. Web service programs rely on JVM and rapid development framework spring. Fine-grained web management requires support from Shiro components. In the front-end, JavaScript provides rich support of the running script. In the phase of rule loading and packet filtering, the network modules in the kernel are used to provide support.

After setting up the running environment, we can test the three processes in the framework FMNISCF. The first step is to write the policy configuration file. Transform policies into rules through the map. The following is the rate at which rule profiles are generated under different semantic environments in a multi-domain network.

In Figure 8, the time of generating security rules increases linearly with the number of policies. When the number of policies reaches 660,000, generating security rules only costs about 5 s. This means that, in actual deployments, the system can support very complex security policy configurations and keep the rule generation process efficient.

Next is the test of time of the rule configuration file loading. In Figure 9, when the number of security rules is 400,000, the loading time of the interconnected security gateway is about 9 s, which means that, in the actual deployment, the system can quickly load the rules generated by the system and respond to the changes in the network. In different rule scales, the loading time changes are shown as follows:

Finally, the iPerf3/pktgen generates packet traffic to test the throughput of gateway after loading rules. In the experiment, the tools are used to generate 10 Gbps of traffic. We compare the iptables, DPDK-IPFW, BSD-IPFW, BSD-pfsense, and FMNISCF.

In Figure 10, we analyze the data: as for the optimization of network card drive, DPDK-IPFW can increase the limit value of the data transmission speed of the device. In the actual transmission, it reaches 9.3 Gbps. Furthermore, DPDK-IPFW supports up to 23,207 rules. In addition, BSD-IPFW supports up to 65,535 rules and maintains a stable transmission speed of 1.03 Gbps when the number of rules is greater than 1 W. This shows that BSD-IPFW is very suitable for deployment on the network equipment with a Gigabit network card. This speed is just the upper limit which is generally supported by the intermediate nodes of the network. The network speed of BSD-pfsense can only maintain at 0.2 Gbps. We compare other schemes with ours. It can be seen from the comparison that the throughput of other schemes decreases rapidly with the increase of rules. The speed of other schemes has dropped to 1 Gbps when there are 1 W rules. In contrast, when the number of security rules is 50 W, the throughput of FMNISCF can still maintain 4.6 Gbps. This means that, in the actual deployment, even if the system is loaded with complex filtering rules, the network data can still be transferred quickly. Our plan does not lead to a significant reduction.

6. Conclusions

This paper proposes the framework of a fine-grained multi-domain network interconnection security control, FMNISCF for short. BNF is used to design the grammar specifications of rules and policies. The map method from policy to rule is designed based on the semantics of integrated air-ground multi-domain network. Unifying policies and rules into the structure of the matching tree is the key to establishing the relationship between policies and rules. This structure also provides a scheme for the implementation of packet filtering semantics of gateway. In terms of security analysis, we discuss the security of design about map and semantic. This ensures that the system does not “crash” or generate ambiguities. Combining the characteristics of the system, we optimize the matching tree structure. Finally, we test the system running environment and the running time of each stage, respectively. Our solution is more efficient than iptables in terms of packet filtering performance. The framework can be used to filter more protocols/attacks from the application layer. In some common SQL injection attacks, mining Trojan attacks and other scenarios, it can filter this type of packet in a fine-grained way. In periodic application scenarios, for example, when employees arrive at work at 9:00 a.m. and leave at 5:00 p.m. on weekdays, window time can be set to prevent employees from accessing the company’s confidential database after work. Through the establishment of multiple domains, the framework can implement the access control management of each department of the company.

7. Future Research Work

In the future, we will design a fine-grained intrusion detection system. Combined with this system, many security policies can be automatically generated by the intrusion detection system and quickly deployed into the FMNISCF. In the intrusion detection system, the attack behavior is analyzed by combining multi-domain network semantics. This includes information such as network topology, department organization structure, and application protocol structure. Coordinated detection and response to attacks are implemented on distributed gateways supported by time synchronization.