A Secure Data Flow Forwarding Method Based on Service Ordering Management

Abstract

The transmission of data flows in current networks is in a scattered and disordered state, which makes it difficult to effectively discover and defend against network attacks in a timely manner, while network managers lack the tools for the secure and orderly management of data flows. To solve this problem, a secure data flow forwarding method based on service ordering management is proposed in this paper. By defining the service header, the scheme realizes a fine-grained service-based division of data flows. The rules for services in the network are formulated, and orderly control over data flows based on the rules is implemented through the software-defined network architecture, such that only data flows meeting the rules are allowed to pass through the network. Meanwhile, to achieve secure data flow forwarding, data flow is signed, and the signature fields are sampled and verified on the forwarding device to ensure the correctness and tamperproof nature of the data flow forwarding process. The experimental results reveal that the proposed method based on service ordering management can achieve fine-grained and orderly secure data flow control forwarding, effectively defending against network attacks and improving network security. Furthermore, the additional forwarding delay introduced by the scheme is in the controllable range, making the approach practical.

1. Introduction

Data flows in current networks are characterized by scattering and disorder, making it difficult to effectively manage network traffic and detect and defend against network attacks. A software-defined network (SDN) [1] is a novel network architecture that provides conditions for flexible and fine-grained control and forwarding of data flows. While SDN is widely used, SDN itself still faces many security threats [2], such as the lack of methods to detect abnormal data flow and ensure the security of data packet forwarding [3,4,5]. However, the OpenFlow protocol, the main southbound protocol of SDN [6], only contains the first four layers of the Open Systems Interconnection (OSI) model in the matching domain of its version 1.0, which makes it difficult to effectively distinguish, control, and forward data flow from the service level. Meanwhile, when SDN controls and transmits the data flow according to the matches, it lacks the authentication mechanism for them and is unable to effectively defend against attacks such as match tampering or forgery [7]. Therefore, applying SDN in the data flow forwarding process to achieve secure and orderly data flow forwarding still faces some problems that need to be solved.

P4 is an advanced language for programming protocol-independent packet processors [8], which can provide programmable capabilities for switches and other forwarding devices in the SDN data plane. P4 can learn and match the custom fields in data packets, overcome the matching domain limitation in the OpenFlow protocol, and achieve fine-grained and accurate data flow control and transmission.

The digital signature is a network security technique based on the public key cryptosystem [9], which can ensure the unforgeability and integrity of the information. As one type of digital signature [10], the identity-based signature generates the public key according to the user’s identity and then creates the secret key, which eliminates the dependence of traditional digital signatures on certificates and simplifies the key management process. By signing the matching domain field in the data packet, the correctness and security of data flow forwarding based on matches in the matching domain can be guaranteed.

In response to current problems in the network forwarding of data flows, referring to the idea of vehicle transport network management, P4 and digital signature are adopted to improve the SDN architecture in this document. A secure data flow forwarding method based on service ordering management is proposed that regulates the services in the network to allow only data flows that meet the service rules to pass through the network and terminate illegal services. With this approach, the orderliness of network services is ensured, and secure forwarding of data flow is realized to improve network security. The main achievements and innovation of this study are as follows: (1) by adding the service header to the message and describing the data flow from the service level, the granularity of data flow control and forwarding is improved. The data flow is signed and sampled for signature verification to ensure the correctness and unforgeability of the data flow transmission process; (2) rules are formulated for the services in the network, and the data flows are matched at the network transmission terminal, such that only the data flows that satisfy the rules are allowed to pass, ensuring network security through the ordering management of data flows; (3) a secure data flow forwarding model based on service ordering management is established, whereby the module can achieve secure data flow forwarding and effective defense against network attacks. The increase in forwarding delay is within an acceptable range compared to those of traditional data flow forwarding methods, which proves the practicability of the proposed scheme.

2. Related Work

There is a lack of effective management mechanisms for data flow transmission in the network; therefore, attackers can achieve network attacks by hijacking, forging, or tampering with data flows [11,12,13]. Current research on data flow security focuses mainly on the detection of abnormal data flows and the improvement of secure data flow forwarding mechanisms.

Anomalous traffic detection technology is employed to detect invasion attacks and other abnormal traffic from network traffic to ensure data flow security. These methods often focus on improving the performance of the detection algorithm [14,15,16,17]; thus, most features based on data flows are selected only from the header, such as the source IP address, destination IP address, source port number, and destination port number. The analysis of the service characteristics in the message payload is lacking, which may lead to false negatives for some abnormal data flows. Referring to the concept of zero trust security, previous studies [18] took the position of “never trusting and always verifying” for data traffic, conducted periodic and continuous monitoring of user behavior in the network, and constructed an access control model based on user behavior trust measurement. The model measured the user trust level according to the user behavior, and, when the user trust level dropped to an unreliable level, the data flow sent by that user was terminated through the SDN architecture. This approach ensured the security of data flows in the network, although the distinction between trust levels was fuzzy in this method. Previous studies [19] introduced self-training and self-learning into the SDN anomaly detection system and proposed a new training and learning mechanism, which can effectively improve the identification performance of unknown attacks. However, this method requires comprehensive acquisition of data flows, which results in a large computing process.

The authors in [20] forwarded data flows using user identity and service content as matches of the SDN forwarding device, realizing fine-grained forwarding of data flows according to people, things, and services. To solve the security problems of SDN in the data flow forwarding [21,22,23,24], the framework in [25] included a verification module for the source address of the data flow in the controller to filter the data flows with false addresses. The Ethane architecture [26] sent a policy to the switch through the controller to perform authentication of network access authentication for data flows in the network. Earlier studies [27] added password identification to the data message, which included several data flow characteristics, e.g., the service information. Password identification enabled a more accurate representation of the data flow and ensured the integrity of the message. Previous studies [28] introduced an attribute-based group signature algorithm to verify the data packet forwarding process, signed data packets flowing into the network according to the user identity and other attributes, and controlled and forwarded data flows based on user attributes, achieving fine-grained secure data flow forwarding and verification. However, the methods proposed in [27,28] only signed the message load, which could not guarantee the security of the matches as the basis for forwarding and could not defend against network attacks launched by attackers through match tampering or forgery. SDNsec [29] added a code containing the transmission path information to the data packet; thus, the switch could verify this field of data packets that pass through the switch in the network, discard those that violated the path rules, and ensure data packet forwarding according to the path specified path in the SDN. However, this method required the encryption and decryption of data packets at each switch, posing high demands on the switch configuration in the network. The authors in [30] filled the packet verification label in the original IP header by port address overloading, which can effectively reduce the additional header overhead in the packet verification process. However, due to the short length of the verification field, when the forwarding path is short, it may cause a high detection false positive rate.

3. Secure Data Flow Forwarding Model Based on Service Ordering Management

The transport network regulates traffic by dividing lanes and putting up traffic lights and signs, reducing the occurrence of traffic accidents by ensuring orderly vehicle travel. The secure data flow forwarding method based on service ordering management is proposed to transfer this idea of ordering in the transport network to the Internet. A model based on the proposed method is established, and its architecture is displayed in Figure 1.

The solid lines in Figure 1 represent the directions of data flows in the network. First, the service originator gets the key information from the key generation center and defines the service header. Then, the header-adding module in the service originator adds the service header to the data packet and divides the network services in a fine-grained manner based on the service header. The service management server formulates rules for the services in the network, regulates the data flows through the data flow control module, forwards only those that conform to the rules, and discards those that do not, thereby achieving secure and orderly data flow transmission. Meanwhile, the service header uses an identity-based signature scheme to sign the service flow matches, which ensures that the data flow is forwarded securely on the basis of correct and unforgettable matches. Each part of the model is described below.

(1)

Key generation center (KGC): It is responsible for key generation and information distribution during the digital signature process, providing the secret signature key to the service originator and providing the public system parameters to the controller in the data flow control module for signature verification.

(2)

Header-addition module: Before sending the data flow from the service originator, the header-add module inserts the service header into the front end of the original data message, which provides the basis for secure and orderly data flow forwarding. The structure of the service header is detailed in Section 3.1.

(3)

Service management server: It is responsible for formulating rules for the services in the network and sending the rules to the controller of the data flow control module, providing the basis for matching and forwarding data flows. The generation of the service rules is detailed in Section 3.2.

(4)

Data flow control module: It consists of the control layer and the data layer. The controller in the control layer controls the generation of the flow table according to the service rules in the service management server and sends the flow table to the switches in the data layer. The switches in the data layer perform service header-based data flow control and forwarding according to the flow table information. Only data flows that meet the service rules are allowed, and those violating the rules are discarded. The specific process that implements the orderly forwarding of data flows is described in Section 3.3. Meanwhile, the entry switch verifies the signature of the matches in the received data flow to ensure their correctness and tamperproof nature. The process of verifying the data flow matches is described in Section 3.4.

3.1. Service Header Structure

The service is the basic unit that describes the activities in a network. By defining the service header and describing the data flow based on the service, managers can precisely divide the data flows from a higher level of the network to achieve fine-grained control and forwarding of the data flows. Meanwhile, to solve the security problems of the SDN architecture in data flow forwarding, signature fields can be added to the service header to ensure secure data flow forwarding. The location of the service header is chosen between the Ethernet header of the traditional data packet and the IPv4 header; the addition of the service header does not change the way the original network protocol works. The service header consists of four fields: ID, matches, signature, and Next_Type; its structure is shown in Figure 2.

The contents of the four fields are described below.

(1)

ID (16 bits): It stores the identity of the data flow originator.

(2)

Matches (128 bits): It stores the characteristic information describing the data flow, which may include the type of service, the type of originator role of the service, the type of source host, and the destination host type. Fine-grained control and forwarding of data flows can be achieved on the basis of the Matches field, which ensures the secure and orderly transmission of data flows in the network.

(3)

Signature (768 bits): It guarantees the authenticity and unforgeability of the Matches field.

(4)

Next_Type (8 bits): It stores the type of header that the switch will need to parse next, providing a logical relationship between multiple headers for the switch.

The service header can provide a fine-grained description of the data flow and guarantee the accuracy and tamper-proofing nature of the descriptive features through the signature fields, thereby implementing fine-grained and orderly security management of data flows.

3.2. Generation of Service Rules

The service management server formulates rules for the services in the network and generates the service rule table, on the basis of which the data flow can be controlled and forwarded. The process of creating the service rule table by the service management server is presented in Figure 3.

In Figure 3, the solid line arrow indicates the process of generating the service rule table from the service in the service library, and the dotted line arrow indicates the process of the update module sending the update information to other modules when a new business occurs in the network or the authentication information of the business changes. The modules in Figure 3 are introduced below.

(1)

Service library: It stores the set of service types in the network.

(2)

Authentication module: It authenticates the parties (users and hosts) who use the services. When a user or host on the network wants to qualify for a certain type of service, it applies to the authentication module, which then establishes a logical relationship between the authenticated role and host information and that type of service, and then sends it to the rule generation module.

(3)

Path generation module: It generates the service transmission path in the network according to the type of service. Currently, network forwarding devices only forward data flows through IP or MAC addresses, making it difficult to manage network services and prevent attacks. Therefore, it is essential to arrange data flows by service type by regulating service transmission paths in the network. The method of generating the service transmission path is described below.

(4)

Rule generation module: It generates the service rule table for the services in the service library based on the results obtained from the authentication and path generation modules.

(5)

Update module: It is responsible for ensuring the update of information on the service management server. When information is added or excluded in the service library and other modules, the update module notifies the corresponding modules to update accordingly.

(6)

Service rule table: It records the management rules for each type of service, including the set of users and hosts allowed to use a certain type of service and the service transmission paths in the network. The service rule table acts as the basis for performing orderly and secure data flow forwarding by the service control module.

The path generation module obtains the service type information and the host information allowed to use the service from the service library and the authentication module, to establish the service–host relationship. The ordered service transmission path is built in combination with the topology of the forwarding device in the network. The resulting path consists of the nodes of the switching device in the network. The method to establish the ordered service transmission path is described below. First, some definitions are given.

Definition 1. 

$v_i$represents a host node or a route node in the network. $e_{ij}$represents the link between$v_i$and$v_j$. G(V,E)denotes the topology of the current network, where$V=\left\{v_1,v_2\dots \dots v_n\right\}$represents the set of nodes in network and$E=\left\{e_{ij}|i,j\in V\right\}$represents the set of links between host and route or between routes.

Definition 2. 

Tindicates the category of network service.

Definition 3. 

$h_i$represents the host node in the network. $H=\left\{h_1,h_2\dots \dots h_s\right\}$represents the set of$h_i$.

Definition 4. 

$h_i^T$represents the host node in the network that has access to serviceT. $H^T=\left\{h_1^T,h_2^T\dots \dots h_{\mathrm{m}}^T\right\}$represents the set of$h_i^T$.

Definition 5. 

Considering that part of some$h_i^T$do not need to communicate with each other,$H^T$is divided into multiple subsets$H_i^T$on the basis of interconnected$h_i^T$, where each$H_i^T$is a connected subgraph of$H^T$; that is,$h_i^T$in each$H_i^T$can interoperate with service$T$.

Definition 6. 

${\epsilon }_{ij}$  is used to denote whether a connectivity path exists between $v_i$ and $v_j$. ${\epsilon }_{ij}=1$ means that the connectivity path exists, whereas ${\epsilon }_{ij}=0$ signifies the absence of the connectivity path.

Definition 7. 

$R_i^T=\left\{v_1,v_2\dots \dots v_t\right\}$  represents the routing path generated for service $T$ in $H_i^T$. $R^T=\left\{R_1^T,R_2^T\dots \dots R_x^T\right\}$ represents the routing paths for service $T$ in H^T.

The ordered service transmission path must satisfy the following conditions:

(1)

All hosts that have been cleared by the authentication module must be connected to the destination host via a path, as in Equation (1).

$${\displaystyle \prod _{\forall h_p^T,h_q^T\in H_o^T}\left({\epsilon }_{h_p^{T}i}\cdot {\epsilon }_{ij}\cdot {\epsilon }_{jk}\cdots {\epsilon }_{st}\cdot {\epsilon }_{t{h}_q^T}\right)}=1$$

(1)

where $i,j,k,s,t\in V,H_o^T\in H^T$.

(2)

The path length between hosts that need to communicate with each other should be minimized to avoid excessive traffic and improve the efficiency of service transmission. Assuming that the distances between host and route or between routes are not considered, the number of routing address hops can be used to describe the path length. The ordered transmission path length of the service T is denoted by $le{n}^T$ and expressed as

$$le{n}^T={\displaystyle \sum _{\forall H_i^T\in H^T}{\displaystyle \sum }_{h_j,h_k\in H_i^T}len(h_j,h_k)}$$

(2)

where $h_j$ and $h_k$ represent the hosts that need to interact regarding the service, and $len(h_j,h_k)$ represents the path distance between $h_j$ and $h_K$.

Dijkstra’s shortest path algorithm is improved and applied according to the conditions that the ordered service transmission path needs to satisfy. The method to generate the ordered service transmission path topology is designed, which is described in pseudocode form and presented in Algorithm 1.

Algorithm 1. Path topology generation algorithm.

$\begin{array}{l}\mathrm{Input}: \mathrm{Service} \mathrm{type} T,\mathrm{Host} \mathrm{set} H^T\\ \mathrm{Output}: \mathrm{service} \mathrm{Topology} R^T\\ 1: \mathrm{BEGIN}\\ 2: \mathrm{Initialize} T,H^T,R^T\\ 3: \mathrm{int} le{n}^T=0\\ 4: \left\{H_i^T\right\}=\phi (H^T)\\ 5: \mathrm{For} H_i^T \mathrm{in} H^T:\\ 6: \mathrm{Repeat} Q \mathrm{times}:\\ 7: h_j,h_k=\mathrm{Rand}(H_i^T)\\ 8: (R_i^T,le{n}^T)=\mathrm{Dijkstra}(R^T,le{n}^T,h_j,h_k)\\ 9: \mathrm{Repeat}:\\ 10: h_l=\mathrm{Select}\_\mathrm{notputback}(H_i^T)\\ 11: (R_i^T,le{n}^T)=\mathrm{AddRoute}(h_l,R_i^T)\\ 12: \mathrm{If} \mathrm{Select}\_\mathrm{notputback}(H_i^T) \mathrm{is} \mathrm{finished}:\\ 13: \mathrm{Drop} \mathrm{Repeat}\\ 14: (len,R_i^T)=\mathrm{Compare}\_and\_update(le{n}^T,len,R_i^T)\\ 15: \mathrm{Get} R_i^T \mathrm{of} H_i^T\\ 16:\mathrm{Get} R^T \mathrm{of} H^T\\ 17:\mathrm{END}\end{array}$

The path topology generation algorithm first defines the service type $T$, host set $H^T$, and path topology $R^T$, and sets the initial value of routing distance $le{n}^T=0$. First, divide $H^T$ into several connected subgraphs $H_i^T$ based on function $\phi ()$. For each part of $H_i^T$, select two hosts $h_j,h_k$ randomly by function $\mathrm{Rand}()$ to obtain the shortest path using the Dijkstra algorithm. Next, select the host $h_l$ by function $\mathrm{Select}\_\mathrm{notputback}()$ in $H_i^T$ without placing it back, and then sequentially use $h_l$ as the condition of path generation based on the shortest path, before adding the routing node $h_l$ to the path by function $\mathrm{AddRoute}()$. The shortest path generated in each cycle and the corresponding routing topology are saved in $le{n}^T$ and $R_i^T$ by function $\mathrm{Compare}\_and\_update()$. Find better $R^T$ using $le{n}^T$ as the value function after $Q$ cycles. To reduce the algorithm complexity, if the route obtained by the algorithm is not the optimal solution, increase $Q$ to make $R^T$ closer to the optimum.

3.3. Ordered Forwarding of Data Flows

The data flow control module improves the SDN architecture and uses the P4 technique to implement orderly data flow forwarding on the basis of the service header. The control layer obtains the service rule table from the service management server, generates the flow table information that controls the data flows according to the service rule table, and sends it to the data layer. The data layer then uses the P4 programmable switch as a forwarding device. The P4 switch parses the service header of the data packet and performs a ‘match action’ to the data flow according to the flow table. In other words, the corresponding action is executed according to the matching result to achieve orderly data flow forwarding.

The P4 switch can improve granularity by service-based data flow forwarding on the basis of the Matches field in the header. By matching the Matches field with the flow table information, only the matched data flows are forwarded along the prescribed paths, which can improve the orderliness of data flows and transmission security. Meanwhile, the P4 switch validates the signature field in the header to ensure that the matches field used as the basis for data flow forwarding matching is accurate and untampered with. The control and transmission process of the data flow by the P4 switch is shown in Figure 4.

The data flow control and forwarding by the P4 switch are divided into five stages: input, parser, ingress, deparser, and output. In the input stage, the switch receives the incoming data flow. During the parser phase, the switch parses the packet header and retrieves the information within the header. Ingress is the core control part of the P4 switch, during which the service header is checked first, and the data flow without the service header is discarded. Next, the signature field in the service header is validated, and the data flows that fail the signature verification are discarded. Lastly, the match field information in the service header is compared with the information in the matching and forwarding table. When the matching is successful, the specific forwarding action in the matching and forwarding table is performed on the data flow, and the unmatched data flow is discarded. During the deparser phase, the data packets are encapsulated. In the output phase, the result of data flow processing is outputted.

The process of data flow control and forwarding by the flow control module is presented in Algorithm 2.

Algorithm 2. Control and forwarding of data flow.

$\begin{array}{l}\mathrm{Input}: \mathrm{packet} A\\ \mathrm{Output}: \mathrm{Action} \mathrm{executed} \mathrm{on} A\\ 1: \mathrm{BEGIN}\\ 2: header=\mathrm{get}\_\mathrm{Header}(A)\\ 3: \mathrm{IF} header.\mathrm{service}\_\mathrm{header} \mathrm{is} \mathrm{non}-\mathrm{existent}:\\ 4: \mathrm{return} \mathrm{drop}(A)\\ 5: s=header.\mathrm{service}\_\mathrm{header}.\mathrm{Signature}\\ 6: m=header.\mathrm{service}\_\mathrm{header}.\mathrm{Matches}\\ 7: id=header.\mathrm{service}\_\mathrm{header}.\mathrm{ID}\\ 8: ver=\mathrm{verify}(s,m,id)\\ 9: \mathrm{IF} ver\ne 1:\\ 10: \mathrm{return} \mathrm{drop}(A)\\ 11: next\_drop=\mathrm{match}(m)\\ 12:\mathrm{IF} next\_drop \mathrm{is} \mathrm{Null}:\\ 13: \mathrm{return} \mathrm{drop}(A)\\ 14:\mathrm{ELSE}:\\ 15: \mathrm{return} \mathrm{forward}(A,next\_drop)\\ 16:\mathrm{END}\end{array}$

In Algorithm 2, the switch extracts the header information from the received packet $A$ to determine whether $\mathrm{service}\_\mathrm{header}$ is contained. If not, A is not forwarded and return $\mathrm{drop}(A)$. For $A$ containing $\mathrm{service}\_\mathrm{header}$, acquire its $\mathrm{Signature}$, $\mathrm{Matches}$, and $\mathrm{ID}$ separately and save them in $s,m,id$. verify() is the function used to verify signatures, and the verification results are saved in ver. The specific signature verification process is described in Section 3.4. When ver is 1, it means that the signature is successful; as for the failed packet A, return $\mathrm{drop}(A)$. The $\mathrm{match}()$ function matches the input to the matching and forwarding table generated on the basis of the service rule table, and the result is saved in $next\_drop$. $\mathrm{Null}$ indicates a match failure. In this case, return $\mathrm{drop}(A)$; else, return $\mathrm{forward}(A,next\_drop)$, meaning that packet $A$ is forwarded to port $next\_drop$.

3.4. Identity-Based Match Signature

To ensure the security of orderly data flow forwarding based on services, the matches in the service header need to be authentic and non-forgeable. By signing and verifying the service field, match tampering and forging by attackers can be prevented, ensuring orderly secure forwarding of data flows based on the correct matches. The signature scheme proposed by Galindo et al. [31] is improved and applied here, using the sender of the identity of the data flow as the public key to avoid storage and distribution. Meanwhile, the scheme does not use the bilinear pairing operations common in identity-based signatures, effectively reducing the time consumed in signature verification.

To describe the signature scheme more clearly, we define some parameters. Define m as the signed message waiting to be signed. ID indicates the identity of the signer. $mpk$ represents the master public key. $msk$ represents the master secret key. $sk$ represents the secret signature key of the signer. Define $\sigma$ as the signature of $m$ generated by $sk$. $p$ represents a prime. Define G as a group of order p, and g is the generator of $G$. $H_1$ and $H_2$ are hash functions.

The security of the signature scheme is based on the following assumptions:

(1)

It is safe against an attacker, who initiates an attack by randomly selecting a message $m^{\prime }$ and identity $I{D}^{\prime }$. In other words, the signature ${\sigma }^{\prime }$ generated by $m^{\prime }$, $I{D}^{\prime }$ and $mpk$ cannot pass signature verification.

(2)

It is based on the difficulties of discrete logarithms. For example, suppose $a$ is a positive integer; it is difficult to solve $a$ even if we have $p,g,g^a$ in $G$.

The network implementation of the identity-based data flow matching signature scheme can be divided into four phases: initialization, key generation, signature, and signature verification, which are described below.

Initialization $\left(n\right)\to \left(mpk,msk\right)$: Define $n$ as an input positive integer. Select the value of $p$ through $n$,$2^n\le p<2^{n+1}$. $z$ is a randomly selected positive integer. KGC generates $mpk$ and $msk$, $\left(mpk,msk\right)=\left(\left(G,p,g,g^z,H_1,H_2\right),z\right)$.

Key generation $\left(mpk,msk,ID\right)\to (sk)$: KGC distributes the secret key to users according to their identity information. r is a randomly selected positive integer. Calculate $y=r+z\cdot H_1(g^r,ID)$, and get the secret signature key $sk$, $sk=(y,g^r)$.

Signature $\left(mpk,sk,m\right)\to (\sigma )$: $A$ represents the package to be signed. $m$ is the match field of $A$. a is a randomly selected positive integer. The source host signs the match information before sending the packet and saves the signature in the signature field of the service flow header, as presented in Algorithm 3.

Algorithm 3. Packet signature algorithm.

$\begin{array}{l}\mathrm{Input}: mpk,sk,m\\ \mathrm{Output}: \mathrm{packet} A\\ 1: \mathrm{BEGIN}\\ 2: \mathrm{load} g,H_2 \mathrm{form} mpk\\ 3: \mathrm{load} y,g^r \mathrm{from} sk\\ 4: \mathrm{generate} a,a\in {\mathbb{Z}}_q\\ 5: b=a+y\cdot H_2(ID,g^a,m)\\ 6: \sigma =(g^a,b,g^r)\\ 7: A=\mathrm{insert}(A,\sigma )\\ 8: \mathrm{return}(A)\\ 9: \mathrm{END}\end{array}$

Signature verification $\left(mpk,\sigma ,m,ID\right)\to (1/\perp )$: The controller obtains the public key according to the public parameter $mpk$ and identity information $ID$. The access switch parses the service flow header information flowing into the packet and verifies the signature field in the header. The process of signature verification is given in Algorithm 4.

Algorithm 4. Packet signature verification algorithm.

$\begin{array}{l}\mathrm{Input}: \mathrm{packet} A\\ \mathrm{Output}: 1/\perp \\ 1: \mathrm{BEGIN}\\ 2: \mathrm{get} mpk \mathrm{from} \mathrm{KGC}\\ 3: \mathrm{get} \sigma ,m,ID \mathrm{from} A\\ 4: \mathrm{load} G,p,g,g^z,H_1,H_2 \mathrm{from} mpk\\ 5: c=H_1(g^r,ID)\\ 6: d=H_2(ID,g^a,m)\\ 7: g^{\Delta }=g^a{(g^r{g}^{zc})}^d\\ 8: \mathrm{IF} g^{\Delta }=g^b:\\ 9: \mathrm{return}\left(1\right)\\ 10:\mathrm{ELSE}:\\ 11: \mathrm{return}(\perp )\\ 12:\mathrm{END}\end{array}$

By signing the matching fields in the data flow service header and checking them at the entry switch, the security of the data flow forwarding process can be guaranteed. Meanwhile, the selected scheme only needs 1- and 1.5-power operations of the group $G$ in the signature and signature verification phases, respectively, which results in lower time overhead and is suitable for the security verification of data flows.

4. Experiment and Analysis

4.1. Experiment Environment

The experiment was carried out on an Intel i7-1165G7 3.733 GHz host with 16 GB memory. Mininet was used to establish the network topology environment, the bmv2 switches were used as the switch for network data transmission, and the P4 language was used to write and generate the JSON format description files for the data plane, which were fed into the switch for execution. Scapy was used to generate the message information needed for the experiment, which was then sent to the host computer. Wireshark was used to capture and analyze the data flow forwarding information. The network topology used in the experiment is shown in Figure 5.

4.2. Validity Analysis

In the network topology shown in Figure 5, assume that Host₁ and Host₄ have permission to use service $T_1$, Host₁, Host₂, and Host₄ have permission to use service $T_2$. Algorithm 1 is used to generate the ordered transmission path for service $T_1$ and service $T_2$. The process is shown in

Table 1. Ordered service transmission path generation process.

Cycle Number	Service Type	Host Nodes	Path Length	Ordered Service Transmission Path
1	$T_1$	${\{\mathrm{Host}}_1{,\mathrm{Host}}_4\}$	$le{n}^{T_1}=3$	$R^{T_1}{=\{\mathrm{Host}}_1{,\mathrm{Host}}_4,\mathrm{Switch}1,\mathrm{Switch}2,\mathrm{Switch}4\}$
	$T_2$	${\{\mathrm{Host}}_1{,\mathrm{Host}}_2\}$	$le{n}^{T_2}=2$	$R^{T_2}{=\{\mathrm{Host}}_1{,\mathrm{Host}}_2,\mathrm{Switch}1,\mathrm{Switch}3\}$
		${\{\mathrm{Host}}_1{,\mathrm{Host}}_2{,\mathrm{Host}}_4\}$	$le{n}^{T_2}=4$	$R^{T_2}{=\{\mathrm{Host}}_1{,\mathrm{Host}}_2{,\mathrm{Host}}_4,\mathrm{Switch}1,\mathrm{Switch}3,\mathrm{Switch}4\}$
2	$T_1$	${\{\mathrm{Host}}_1{,\mathrm{Host}}_4\}$	$le{n}^{T_1}=3$	$R^{T_1}{=\{\mathrm{Host}}_1{,\mathrm{Host}}_4,\mathrm{Switch}1,\mathrm{Switch}2,\mathrm{Switch}4\}$
	$T_2$	${\{\mathrm{Host}}_2{,\mathrm{Host}}_4\}$	$le{n}^{T_2}=2$	$R^{T_2}{=\{\mathrm{Host}}_2{,\mathrm{Host}}_4,\mathrm{Switch}3,\mathrm{Switch}4\}$
		${\{\mathrm{Host}}_1{,\mathrm{Host}}_2{,\mathrm{Host}}_4\}$	$le{n}^{T_2}=4$	$R^{T_2}{=\{\mathrm{Host}}_1{,\mathrm{Host}}_2{,\mathrm{Host}}_4,\mathrm{Switch}1,\mathrm{Switch}3,\mathrm{Switch}4\}$

.

It can be seen from Table 1 that, for the topology shown in Figure 5, the results of the first cycle are the same as those of the second cycle, indicating that Algorithm 1 can obtain the optimal ordered transmission path for service $T_1$ and service $T_2$ through one cycle. When the network topology is more complex, it is necessary to increase the number of cycles to find a better ordered transmission path. The generation process of ordered service transmission path is carried out in the controller. When the number of host nodes applying for service permission changes little, it is not necessary to regenerate the ordered service transmission path; the host nodes on the original path are simply added or deleted, and the path is updated. Therefore, the generation process of ordered service transmission path has less impact on data flow transmission.

To verify the validity of the secure data flow forwarding method based on service ordering management, four types of data flows, FlowA–FlowD, were constructed. FlowA was a data flow without the service header; FlowB was a data flow in which the service header contained a forged matching field; FlowC and FlowD were data flows of two different service types, corresponding to service $T_1$ and service $T_2$, respectively, in Table 1. FlowC and FlowD are forwarded according to the ordered service transmission path shown in Table 1. In the network topology shown in Figure 5, the four data flows were sent from Host₁ to Host₄ at a rate of 30 packets/s, each lasting 10 s. Traffic statistics were counted for the eth0, eth1, and eth2 ports of Switch1 and Switch 4, respectively. The traffic of Switch1 is shown in Figure 6, and the traffic of Switch2 is presented in Figure 7. In them, the positive direction of the y-axis indicates the flow of data toward the port, whereas the negative direction indicates that the data are flowing out of the port.

As can be seen from Figure 6 and Figure 7, FlowA–FlowD flowed into Switch1 from port eth0, but Switch1 did not forward FlowA and FlowB. Because FlowA does not contain a service header, it cannot pass the control and forwarding process of packets in Algorithm 2. Since FlowB tampers with the match field of the data packet, when verifying the signature of the packet match field, the calculated signature value is inconsistent with the Signature field in the service header calculated by Algorithm 3. Therefore, packets in FlowB cannot pass the signature verification process in Algorithm 4. It can be concluded that the proposed scheme could intercept data flows that did not contain the service header or included match abnormalities in the service header. FlowC and FlowD flowed from the eth1 and eth2 ports of Switch1, entered the eth1 and eth2 ports of Switch4, and flowed out of port eth0 of Switch4, which was consistent with the forwarding paths in the service rules. According to the experimental results, the secure data flow forwarding scheme based on service ordering management could achieve fine-grained data flow control and forwarding in the network. Meanwhile, signature verification ensured the authenticity and tamperproof nature of the matches, thus achieving secure and orderly data flow forwarding and proving the validity of the proposed scheme.

4.3. Protection against Network Attacks

The essence of a network attack is disordered behavior in the network. After ordering the management of data flows, only ordered data flows that comply with the service rules are allowed to pass, and disordered data flows are prohibited in the network, which can effectively prevent network attacks. To verify the effectiveness of the secure data flow forwarding method based on service ordering management against network attacks, two types of network attacks were selected for analysis.

(1)

MS08–067 vulnerability attack

The full name of the MS08–067 vulnerability is Windows Server Remote Procedure Call over Server Message Block [32], which is a buffer overflow vulnerability triggered by the NetPathCanonicalize function in the server message block (SMB) and the Microsoft Remote Procedure Call (MSRPC). The SMB service provides the remote file and printer sharing network service most commonly used in the Windows network. The attacker interacts with an attacker using the SMB communication protocol and completes the network attack by overwriting the remote code.

In the network topology shown in Figure 5, it was assumed that Host2–Host5 conformed to the MS08–067 vulnerability triggering environment. An attacker initiated the MS08–067 vulnerability attack on Host1 to Host2–Host5 in a regular network and a network that adopted the secure data flow forwarding method based on service ordering management, and the results in both cases were analyzed. The regular network did not restrict the forwarding of data flows, whereas the secure data flow forwarding scheme based on service ordering management established rules for the SMB service through the service management server, which restricted the identity of the SMB service originator, allowing only qualified users to legally use the SMB service, and sent the rules to the data flow control module.

The regular data flow FlowA and the service header included FlowB were created at Host₁ to simulate the MS08–067 vulnerability attack based on the SMB service. FlowA and FlowB sent 20 packets to Host₂–Host₅, and the forwarding cases of the data packets were separately counted at the eth0–eth2 ports of Switch1, eth0 and eth4 ports of Switch3, and eth0 and eth3 ports of Switch4. The traffic is shown in Figure 8.

The black bars represent the forwarding scenarios of the packets that transmitted the SMB service of each switch port in the regular network. First, port eth0 of Switch1 received 80 packets from Host₁ and forwarded them from ports eth1 and eth2, respectively. Switch3 and Switch4 forwarded the received packets through eth0 or eth3 and eth0 or eth4, respectively, dispatching 20 packets to Host₂–Host₅. The red bars represent the forwarding scenarios of the packets that transmitted the SMB service of each switch port in the secure data flow forwarding scheme based on service ordering management. Port eth0 of Switch1 could receive the 80 packets sent by Host1 but did not forward them from the other ports of Switch1. Moreover, packet forwarding did not occur in the ports of either Switch3 or Switch4. Since the user identity information in the service header Matches field of the packets sent by the attacker did not conform to the matching and forwarding rules of the SMB service, Switch1 discarded the received packets and did not forward them. As shown in the figure, network attacks against targets in the traditional network could be successfully implemented based on the MS08–067 vulnerability. However, the secure data flow forwarding scheme based on service ordering management could prevent network attacks based on the MS08–067 vulnerability by terminating the forwarding of abnormal data flows at the switching device.

(2)

Apache Log4j2 vulnerability attack

Apache Log4j2 is a significant remote code execution vulnerability found in December 2012 [33]. When the server reads the user input “name” to the log’s “object” through the Lightweight Directory Access Protocol (LDAP) module in Log4j2, the module may not be able to return the object content directly but load the building object by remotely downloading the Class file. When an attacker changes the address of the Class file to a hacker server by entering special content, the downloaded Class file may contain the attack code and attack the target server.

Figure 9 illustrates the process via which the LDAP service obtains the downloaded file from a normal server, and an attacker uses the Apache Log4j2 vulnerability to obtain the downloaded file from a hacker server. As shown in Figure 9, under normal circumstances, when the target server needs to download data remotely, it initiates a request for the LDAP service to the remote server. The remote server then replies with data, and the solid line shows the data flow in the figure. However, when an attacker enters a character with a malicious link to the target server, the target server interacts with the malicious server about the LDAP service. The dashed line shows this data flow in the figure. At this stage, the malicious server replies to the attack code, placing the target server under network attack.

To verify the effectiveness of the secure data flow forwarding scheme based on service ordering management against the Apache Log4j2 vulnerability attack, an experiment was set up in the topology shown in Figure 6, where Host₁ simulated the target server, Host₂ and Host₃ simulated the secure server, and Host₄ simulated the malicious server. The attack was carried out on a conventional network and a network using the secure data flow forwarding scheme based on service ordering management, and the results were analyzed in both cases. The regular network did not restrict data flow forwarding, whereas the secure data flow forwarding scheme based on service ordering management formulated rules for the LDAP service through the service management server. The rules restricted the hosts that initiated the LDAP service, allowing only those hosts that met the requirements to legally use the SMB service, which was also sent to the service flow control module.

The regular data flow FlowA and the included data flow FlowB were created in Host₁ to simulate the Apache Log4j2 vulnerability attack based on the LDAP service. Both FlowA and FlowB sent 20 packets to Host₂–Host₄. The traffic in eth0, eth1, and eth2 of Switch1, eth0, and eth4 of Switch3, and eth0 of Swich4 were monitored, and the port traffic statistics are shown in Figure 10.

The black bars in the figure represent the data flow forwarding scenarios by the ports in a regular network, whereas the red bars represent the traffic statistics of the ports when the data flows were managed on the basis of service orders. Evidently, Switch1 forwarded the 60 packets it received in the regular network to the target server via eth0 and eth4 of Switch3 and eth0 of Swich4. Host₄, the malicious server, could interact with Host₁ about the LDAP service, thus implementing the network attack on the basis of the Apache Log4j2 vulnerability. As for FlowB, of the 60 received packets, Switch1 forwarded only 40 packets from port eth1 but not from port eth2. The 40 packets flowed out of the eth0 and eth4 ports of Switch3, but not out of port eth0 of Switch4. Because the secure data flow forwarding scheme based on service ordering management restricted the hosts that used the LDAP service, Switch1 matched the Matches field in the service header when forwarding the incoming data flows. When the match field of the data flow sent to Host₄ contained abnormal host information, the data packet was discarded due to a matching failure. This indicated that Host₁ could only interact with Host₂ and Host₃ about the LDAP service, thus preventing the data flows carrying the LDAP service from transferring between the target and malicious servers and protecting against attacks based on the Apache Log4j2 vulnerability.

According to the two cases of network attacks mentioned above, the secure data flow forwarding method based on service ordering management could achieve orderly management of data flows by formulating rules for the services in the network. Only ordered data flows conforming to service rules could be allowed to pass through the network, whereas irregular and disordered data flows could not be transmitted in the network, proving the feasibility of the proposed scheme in defending against network attacks.

4.4. Performance Analysis

To ensure fine-grained, secure, and orderly forwarding of data flows, the proposed scheme added the service header field to the traditional data packet, which would increase the delay in the header information parsing and matching and forwarding process in the switching device. Meanwhile, the data flow control module needed to verify the signature of the matches, which would also cause additional delay during data flow transmission.

The following experiment tested the delay of data flows in the secure transmission method based on service ordering management. The performance analysis test was conducted under the topology shown in Figure 5. A total of 100 normal IP messages and 100 messages containing the service header were created and sent from Host₁ to Host₅. To enhance the precision of comparison, only data flows that could be effectively transmitted in the secure data flow forwarding model on the basis of service ordering management were considered, and the payload field of the messages was uniformly set at 100 bytes. Since the data flow carrying the same service consisted of multiple packets with the same message matches, it was not necessary to verify the signature of the match on all the packets. In the secure data flow forwarding model based on service ordering management, the data flow was sampled at a rate of 1:10, and only the match signatures of the sampled packets were verified. The forwarding delay results are shown in Figure 11.

The black dotted line in Figure 11 represents the forwarding delay of general packets, and the red dotted line represents the forwarding delay of packets in the secure data flow forwarding model based on service ordering management. It could be seen that 10 packets in the proposed model exhibited significantly longer forwarding delays than the other packets. The increased time was spent on packet sampling and match signature verification of the selected packets. The average forwarding delay of the 10 packets undergoing the signature verification process was 9.11 ms. The average forwarding delays for the traditional packets and the packets with the service header were 1.09 and 1.80 ms, respectively. Although the signature verification process increased the delay, the secure data flow forwarding method based on service ordering management did not need to perform the process on all packets, and the increase in the average forwarding delay was acceptable. The proposed scheme was compared with some related works that verified the data packets, as shown in

Table 2. Comparison of data packet security verification schemes.

Scheme	Principle	Forwarding Device	Functionality	Delay Increase
Scheme 1 [34]	Sampling data flows at the first and last switches and checking the consistency of the message validation code	OpenFlow switch	Detecting and locating forged and tampered packets	2.85 ms (three-layer tree structure, up to five switches)
Scheme 2 [35]	Sampling data flow at the entry switch and verifying the message validation code generated by the message	P4 switch	Detecting forged and tampered data packets	0.09 ms (three switches)
Ours	Sampling data flow at the entry switch and verifying the matching signature	P4 switch	Ensure that matches were not tampered in the data flow forwarding process	0.71 ms (three switches)

.

Because the schemes’ functionalities and experiment environments varied, Table 2 only compares the delay increase from packet forwarding. The delay increase by the proposed scheme was 0.71 ms, which was lower than that of Scheme 1 and higher than that of Scheme 2. However, the authentication method used in Scheme 2 needed to distribute the shared key, which increased the difficulty of key storage and distribution. The proposed scheme avoided this process and exhibited greater feasibility in terms of performance.

5. Conclusions

Network behavior is generally disordered and scattered; therefore, network attacks cannot be effectively discovered and defended. In view of current network environment problems, this paper proposed a secure data flow forwarding method based on service ordering management. The scheme added the header describing the service information to the data flow in the network and managed the data flows in a fine-grained way from the service level. Meanwhile, rules were formulated for services in the network to achieve orderly control of data flows. Only data flows that conformed to the rules were allowed to pass through the network, and those that did not were terminated in transmission, thus effectively defending against network attacks. The scheme signed the matches in the data flow service header, sampled data flow at the entry switching device, and verified the signatures of the sampled data packets to ensure the security of the data flow forwarding process. Experiments verified that the proposed method based on service ordering management could achieve secure data flow forwarding and effective defense against network attacks. The increase in forwarding delay was within an acceptable range compared to that of traditional data flow forwarding methods, proving the practicability of the proposed scheme.