Attribute-Guard: Attribute-Based Flow Access Control Framework in Software-Defined Networking

Software-dened networking (SDN) decouples the control plane from the data plane, oering exible network conguration and management. Because of this architecture, some security features are missing. On the one hand, because the data plane only has the packet forwarding function, it is impossible to eectively authenticate the data validity. On the other hand, OpenFlow can only match based on network characteristics, and it is impossible to achieve ne-grained access control. In this paper, we aim to develop solutions to guarantee the validity of ow in SDN and present Attribute-Guard, a ne-grained access control and authentication scheme for ow in SDN. We design an attribute-based ow authentication protocol to verify the legitimacy of the validity ow. e attribute identier is used as a matching eld to dene a forwarding control. e ow matching based on the attribute identier and the ow authentication protocol jointly implement ne-grained access control. We conduct theoretical analysis and simulation-based evaluation of Attribute-Guard. e results show that Attribute-Guard can eciently identify and reject fake ow.


Introduction
Software-de ned networking (SDN) [1] is a new network structure proposed by Clean Slate team of Stanford University.It separates the control plane from the data plane and enables high programmability and dynamic orchestration.In the basic SDN architecture, as shown in Figure 1, there are three layers, the application plane, the control plane, and the data plane.e control plane dictates network behaviors and con gures network devices via a set of ow rules that control the network tra c ows.
e data plane only has the function of data forwarding, which makes it di cult to monitor the data source by controller and cannot achieve end-to-end data authentication.For SDN ow table forwarding, there is no e ective access control framework [2], which can prevent forgery attacks.
A fully functional access and forwarding control framework should have three points: (1) preventing illegal users from accessing network services; (2) giving legitimate users appropriate permissions to access protected services or resources; (3) preventing legitimate users from accessing network services that do not give user permissions.Because OpenFlow can only be based on the rst four layers of network protocols controlling the forwarding, it cannot divide network services and is unable to achieve ne-grained access control.Attackers attack SDN using legitimate devices as springboards.erefore, ensuring the legality and correctness of ow access SDN and preventing the proliferation of malicious ow are clearly the main challenges in SDN security.
Digital signature as a tool for validation of data has been widely used in the operating system and network.FortNOX [3] encrypts and authenticates applications.Attribute signature [4,5] enables users to achieve ne-grained access control without access list.By changing the access attributes, the access control structure is updated.Based on above these, the attribute signature meets diverse security needs [5].

Our Approach.
is paper analyses the shortcomings of SDN's access control frameworks.According to lack of ow authentication and ne-grained network access control, we combine SDN with attribute signature and propose SDN security access control framework based on the attribute identifier-Attribute-Guard.It uses device attributes to generate attribute identifiers.Attribute-Guard manages attribute identifiers in each packet that defines network forwarding.To ensure authentication of each flow, we introduced an attribute-based signature scheme in switch to authenticate the flow based on their signature, thus to prevent invalid flow launching continuous malicious attacks to the network.As a result, the Attribute-Guard can implement fine-grained access control and data source identification based on network services.
To sum up, the main contributions of this paper are as follows: (i) We propose Attribute-Guard, a fine-grained flow access framework.e proposed framework redefines the SDN forwarding framework that binds the flow with its device's attribute identifiers (AIDs).(ii) We present flow authentication protocol that can effectively prevent fake flow and filter invalid flow created by an attacker in unauthorized manners, and it has a fine-grained management.(iii) We prototype our approach in the OpenDaylight controller and evaluate the system performance.e theoretical analysis and experimental results demonstrate that the proposed framework can effectively prevent the forging flow attack and implement fine-grained access control.

Background and Motivation.
e abstract SDN communication model contains the following elements: (1) hosts; (2) SDN controller; (3) application that provides flow rules for controllers; (4) OpenFlow switch; and (5) security devices, such as firewall and security gateways.
If host a (a malicious attacker) wants to attack host c, the attack proceeds as shown in Figure 2: (1) host a sends a request to OpenFlow Switch1; (2) if there is no flow rule matching the request from host a in OpenFlow Switch1, OpenFlow Swich1 sends the request to the controller and waits for the response; (3) application receives a flow rule production request from the controller; (4) the application produces a flow rule and sends it to the controller; (5) the controller receives the flow rule, and it saves the flow rule in the flow rule database and forwards the flow rule to OpenFlow Switch1 and OpenFlow Switch2; (6) the new flow rule matches the packets from host a and forwards the packets to the security device through OpenFlow Switch1 and OpenFlow Switch2, respectively; and (7) the security device detects the packet according to the rule, and it determines that host a cannot communicate with host c.
According to the SDN structure, we constructed two attack methods [6,7], which achieve illegal access by tampering with flow rules and controlling flow.ere are other direct attack scenarios, such as DDos: (i) As shown in Figure 3, the attacker tampers with the flow rule in OpenFlow Switch2, which allows malicious host a to access host c directly.us, the packets from host a can bypass the security device and scan host c. (ii) As shown in Figure 4, Malicious Application B generates two new flow rules.e first flow rule is used to modify the source IP address of the packet from the malicious host a to the source IP address of host b that can access host c. en, the second flow rule changes the destination address of the packet to the IP address of host a.If the packet is delivered from host c to host a, the security device simply allows forwarding the packet from host b to host c.In this way, the packets from host a can bypass the security device.e host can scan host c.
e two examples in Figures 3 and 4 show that an attacker can tamper with flow rules and control flow to  Security and Communication Networks circumvent the security device deployed on fixed paths.e essence of the aforementioned problems is the illegal access of the flow.erefore, it is necessary to implement user authentication in the data plane.Our goal in this paper is to present a fine-grained flow access framework.

Related Work.
ere are two ideas to prevent illegal access in the network: (1) the controller authenticates the flow rules and (2) the controller authenticates the devices entering the SDN and sends network strategy.e first idea is mainly based on the flow rules of role authentication.Porras et al. introduced FortNOX [8], a security enforcement kernel on the NOX controller which provides a rolebased authorization scheme for applications that produce flow rules, in response to perceived runtime requests.It manages applications that create flow rules by default three authorization roles, including the role of administrator, the role of security applications, and the role of nonsecurity applications.ese roles are assigned to each application, and each application is required to sign its flow rules.en, Porras extended the scheme and proposed a new security system named SE-Floodlight [9].
e system introduced security enforcement kernel to the Floodlight controller, implementing role-based flow rule management.Similarly, RoseMary [10] and FRESCO manage flow rules by using roles [11].Although above methods can defend against illegal flow, these may assign the same role to different security applications and unable to achieve fine-grained management of flows.us, Wen et al proposed a set of 18 permissions based on the interface of the controller and used a system called PermOF to distribute privileges.Compared with SE-Floodlight [9], RoseMary [10], and FRESCO [11], WEN achieves fine-grained flow management, but it cannot prevent forgery attacks at terminals.Based on the second idea, Lopez-Millan et al. [12] introduced a terminal management system, which protects the terminal by using the IPsec protocol and proposed a solution to manage IPsec SAs using SDN.But it did not divide the role of the terminal and could not achieve the fine-grained management of the flow.However, these two ideas will greatly increase the load of the controller and reduce the performance of the controller.erefore, researchers had shifted their research direction from controllers to switches and SDN architectures.
ey implement data plane security by modifying the protocol stack.Lopez-Millan et al. [13] described the use case of providing IPsec-based flow protection in SDN, but it lacks fine-grained management.As a supplement, Wundsam et al. implemented OFRewind architecture [14], a new architecture to authorize the device in the network layer and support multiple granularity management.Halpern et al. studied the service function chain SFC [15], using flow rules to control the flow.Caprolu et al. designed FORTRESS: a stateful firewall for SDN networks that leverages the stateful data plane architecture to move the logic of the firewall from the control plane to the data plane [16].Fayaz et al. implemented Bohatei, a flexible and elastic DDoS defense system [17].
According to security requirement, the flow is divided into different security levels assigning different function chains and function link paths to flow of different security levels.On the other contrary, IEEE 802.1X offers secure and flexible authentication mechanisms.Garay et al. [18] proposed flow-based network access control (FlowNAC) which is a modified version of IEEE 802.1X standard and has the advantage to authorize access on the basis of flow nature.Benzekki [19] introduced a secure SDN architecture with IEEE 802.1X port-based authentication, which devolves the access control capability to the data plane.
Southbound protocol is mainly an OpenFlow protocol, and it defines type and field limited to four network layer protocols.It provides limited forwarding granularity [20].However, after OpenFlow v1.2 [21], matching fields use the TLV format of OXM architecture, which makes it possible to expand the scope of matching fields.Atting et al. designed the parsing language PPL [22], which introduced a packet header parsing algorithm, and improved the packet performance in addition to the packet header parsing.Arashloo et al introduced SNAP that offers a simpler "centralized" stateful programming model, by allowing programmers to develop programs on top of one big switch [23].
is paper is organized as follows: in Section 2, we describe overall architecture of Attribute-Guard.Section 3 introduces the attribute-based group signature scheme.Section 4 proposes a flow table processing pipeline based on the attribute identifier.In Section 5, we evaluate Attribute-Guard on security functionalities, time consumption, performance, and availability.Finally, we conclude our study in Section 5.

Overview of the Attribute-Guard Framework
In this section, we describe the Attribute-Guard framework, which is a fine-grained flow access control mechanism to ensure the validity of flow in SDN.
2.1.Overall Architecture.As Figure 5 shows, the conceptual diagram of Attribute-Guard includes four components: an attribute identifier authority, an attribute identifier component, a control plane based on the attribute identifier, and a data plane based on the attribute identifier.Attribute-Guard provides following security functionalities: (1) managing the attribute cipher set of a valid host; (2) verifying the validity of flow; and (3) defining the forwarding behaviour based on the attribute identifier.
(i) Attribute identifier authority: the attribute identifier authority generates system public parameters and access public parameters for the destination device.
On the contrary, it generates an attribute identifier for the source device and uses the attribute identifier to generate the attribute private key.(ii) Attribute identifier component: the attribute identifier component is an application installed on the host.First, it is responsible for generating an attribute set for the new source/destination device.Second, it obtains the attribute private key and the attribute identifier from the attribute identifier authority and generates a packet of flow authentication.e attribute identifier encapsulation is implemented by modifying the protocol stack of the host, and the host is not physically extended.Finally, it stores access structure T (attribute set for verifying the signature, as described in detail in Section 3.1

Communication Using Attribute-Guard.
We use the source host H1 to access the destination host H2 as an example to describe the communication process of the Attribute-Guard in Figure 6.
(i) Before accessing the network, H1 needs to be initialized by a locally installed attribute identifier component and H1 sets its attribute and destination address upload to attribute identifier authority.en, it receives the attribute private key and generates the attribute signature from the attribute identifier authority.(ii) When H1 needs to communicate with H2, it sends a flow authentication request to the source authentication switch (SAS) that connects H1.It forwards the authentication request to the destination authentication switch (DAS) that connects H2 through the controller.DAS verifies the validity of the flow and returns the results to the controller.en, the controller generates the flow rules with attribute identification.(iii) e forwarding switch receives the packet from DAS, and it directly performs the matching and forwarding.(iv) e destination authentication switch receives the packet from the forwarding switch and uses the flow table module to authenticate the validity of the attribute identifier.(v) e destination H2 receives the legal packet to generate a general IP packet by using the local attribute identifier component to decapsulate.

Generate Pocket with Attribute Identification.
e new host H1 needs to define the identity of the device before accessing the network.e traditional method is to generate a unique device ID for each device and use an ID identity table to verify the ID, resulting in an increase in system overhead.In fact, the network needs a few attributes to determine the identity of the device, and the user is a legitimate user as long as certain attributes of the user meet the 4 Security and Communication Networks requirements.
e authenticator does not care about the signer's name, address, and other irrelevant information.
e platform defines device attributes from the department where the device is located, the role of the owner, and the business involved.
ese attributes are represented by Boolean functions.For example, Dan is an IT department engineer who needs to write to a host.His attribute set is IT department ∧ enginer ∧ write.
Assuming that the attribute identifier component receives the attribute that is not forged, we define hash functions to create attribute's length as we just desire: We use an attribute string as the attribute identifier (AID).e AID is used as a license for packets to enter and leave the network.It is located between the network layer and the transport layer.We will encapsulate AID for all packets.e message structure is shown in Table 1.Security and Communication Networks (iv) Reserved (12 bit): to be used in future extensions to attribute identification, and the current protocol specifies that this field should be set to zero We modify the protocol type of the IP header and add AID after the IP header.For example, if the upper protocol without AID is TCP, the protocol type of the IP header is changed to 6.

Attribute-Based Group Signature Scheme
Our attribute-based signature scheme is an extension of the attribute-based group signature scheme presented by Dalia Khader et al. [24].

Access Structure.
e access structure T is an authorization set of attributes for verifying the signature, defined by a verifier.When a verifier requests a signature of a host who satisfies certain attributes, a host will use his different private keys to generate the signature according to the verifier's access structure.e table is a linear structure.If the verifier uses a table to represent the access structure, the verification algorithm will be run as many times as the number of attributes in the signature, thus compromising efficiency.We use the attribute tree Γ that is a nonlinear structure to describe the access structure, and its constructor is based on the constructor presented by Goyal et al. [25].Each root node in the attribute tree has a threshold value, and each attribute is connected to it as its leaf node.Each threshold value indicates the number of conditions that needs to be met in the leaf node to which it is connected; that is, the number of attributes required under the root node.e access tree is shown in Figure 7.
We use the attribute tree to generate the public key.Only the signature of the user who meets the requirements of the attribute tree can pass the verification.As shown in Figure 7, the administrator of the IT department needs to perform the read operation.e user satisfies the attribute tree, so the signature can be verified.Engineers in the IT department want to perform a read operation that does not meet the requirements of the attribute tree and cannot be verified.

Authentication Process.
e attribute signature verification and update the access control structure are implemented by the attribute identifier component, the attribute identifier authority, and the authentication switch.Access to services under Attribute-Guard architecture requires two basic stages: Step 1: it includes five processes and is shown in Figure 8. Firstly, the attribute identifier authority performs initialization to generate system public parameters; the authentication switch creates an access control structure T according to requirements, and it uploads T to the attribute identifier authority.
e attribute identifier authority uses the primary private key and the system public parameter to generate the public parameter of T and stores it in the authentication switch; the attribute identifier component uploads the host's attribute set to the attribute identifier authority.According to the host's attribute, the attribute identifier authority generates the attribute identifier and attribute private key and returns it to the attribute identification component.erefore, different hosts have different attribute identifiers and attribute private keys.If the attacker controls a legitimate host, DAS will update the access structure T to generate the new public parameter of T. e original valid attributes and the signature acquired by the attacker will be invalid.
Step 2: flow identification.Based on the parameters generated by step 1, the authentication switch completes the flow identification, and the process is shown in Figure 9.
(1) e host initiates an authentication request to the controller.e request packet contains the following message: {host's AID, signature, mac, destination mac, source IP, destination IP, source port, destination port}.(2) e controller successfully receives the authentication request packet from the source authentication switch (SAS) port.To prevent malicious users from using the authentication request packet to initiate a malicious DDoS attack, the default flow table will be installed on the SAS and the authentication packet from the port will be discarded in the T period.(3) According to the authentication request information, the controller forwards the request to the destination authentication switch (DAS).e destination authentication switch acquires the access structure T of the destination host according to the request.(4) e destination authentication switch verifies the signature and sends the result protected by SSL to the controller.(5) e controller receives the result; if the flow is legal, it sends the flow rule with the attribute identifier to switch; otherwise, the connection is refused.

Formalization of the Scheme.
e relevant definitions of attribute-based group signatures are given below.

Definition 1.
e attribute tree Γ is used to represent the access structure T, and the attribute tree uses the top-downleft-right order.
e root node is represented as (m, n), where m indicating nthe threshold value and n indicating the number of leaf nodes.κ indicates the number of leaves in the attribute tree, as shown in the attribute tree in Figure 5: , engineer, (1, 2), read, write, notification, write .
(1) Setup: the attribute identifier authority chooses a bilinear pair e: G 1 × G 2 ⟶ G T , where G 1 , G 2 , and G T are multiplicative loop groups and of prime order p. g 2 is the generator of G 2 , and there exists homomorphic mapping g 1 ⟵ ψ 2 .e system chooses an open hash function: h, and randomly select ω ∈ Z * P .We set W � g 2 .Define a universe of attributes U � 1, 2, . . ., n { } and each j ∈ U.
Select t f ∈ Z * p , and then calculate the public parameters and system secret parameters: KeyGen: the process generates an attribute private key and a public parameter of the access control structure T. e system generates a base private key gsk (1) KeyGen public (Γ): to generate a public key for an attribute tree Γ, we select a polynomial q x for each nonleaf node in the middle and use a top-down construction method for the root node.e node x in the tree has a polynomial q x whose number d x is less than its threshold k x , i.e., d x � k x − 1. e root node is q(0) � q(index (x)), and select the polynomial q to construct attribute tree polynomials recursively.Finally, the public parameters of the attribute tree Γ (1 Sign: when the system enters the attribute set c i ⊆ U, j⊆c i , the public parameters of the attribute tree, and the message m, it is calculated as follows: (1) Select attribute ζ ⊆ c i and random number α, β, and rnd ∈ Z * p .
(2) Calculate the linear encryption of A i and T ij , where the formula is as follows: , and CT j � (T i,j h j α+β ) rnd .
(3) Let δ 1 � x i α and δ 2 � x i β.Select the random number r β , r x , r δ 1 , and Finally, the signature and attribute identifier (σ, AID) are sent to the verifier, where the AID is the hash of the attribute set ζ.
Verify: it includes two steps.Firstly, we define a recursive algorithm Verifynode.For leaf nodes, calculate as follows: e result is  e(CT j , D j ) �  e(A i h α+β , g rnd 2 ) q j (0) .If the node x is not a leaf node, we perform the following steps: all child value z of node x are stored in function F We recursively calculate the value of the root node F x using Lagrangian interpolation.Let Δs x,index(z) � (− j/(index (z) − j)), where j ∈ index(z): { z ∈ s x − index(z)}, and compute Let F x �  e(C 3 , η).
If it is established, it means that the signature satisfies the attribute tree Γ, and calculate ), then accept the signature; otherwise, the signature is rejected.

Flow Authentication Protocol
Design.We modify 802.1x protocol, which is widely used at present, and design a flow authentication protocol to support the above process.
e standard Ethernet frame must have the destination MAC address, DST MAC, and Ethernet frame type, Ether Type.When the flow authentication protocol is running, the host client program cannot obtain the destination host MAC address.erefore, we adopt the default multicast address 01-80-C2-00-00-03, and the frame type is defined as 0X888F, which is different from 802.1x.
e flow authentication protocol is carried out in the frame data portion.Since the maximum length of the Ethernet frame data is currently set to 1 518 bytes, the maximum length of the authentication protocol data is 1 500 bytes.
As illustrated in Table 2, the semantic of each field in the flow authentication protocol format is as follows: Version: the version number of the current protocol Type: type field.is field is mainly used to indicate the stage of the current data frame: 00 means registration and 01 means flow identification Sequno: this field indicates the sequence number of the current packet, which prevents the loss and out of order of the packet Length: this field is used to indicate the length of the data body Data body: according to different identification stages, the corresponding data is carried.

Flow Matching Based on Attribute Identifier
e attribute identifier is designed as a match field that the OpenFlow switch can recognize, and a processing pipeline is designed based on the multiple flow tables.e validity of the attribute identifier can be authenticated by the processing pipeline, and the legal data are transferred to the specified location.

Structure of Flow Table.
Due to the addition of the attribute identifier in the packet, the original OpenFlow needs to be extended as shown in Figure 10.According to OpenFlow 1.3 [18], we use the TLV format of the OXM architecture to define a new field called the attribute identifier.We add the attribute identifier in the Flow-Mod message so that the flow rule with the attribute identifier can be accepted by the authentication switch and forwarding switch.In this paper, the southbound protocol is compatible with the OpenFlow1.3protocol.e controller that supports the OpenFlow1.3protocol can generate the flow rule containing the attribute identifier.Security and Communication Networks Processing Pipeline.As illustrated in Figure 11, multiple flow table processing pipeline consists of two flow tables.e verification flow table is a level 0 flow table.It classifies the packets according to the type of the flow entry and selects an appropriate processing manner.

Multiple Flow Table
(1) Filter flow entry: the filter flow entry drops the packet without the attribute identifier (Ether-Type � 0x0800 or 0x86dd).If the packet does not have an attribute identifier, it will be sent to the expired flow entry.(2) Expired flow entry: the expired flow entry is used to authenticate the validity of the user and quickly filters the packet with the expired attribute identifier.e field type is the invalid attribute identifier, and the flow table action is "drop."If the matching succeeds, the SDN switch will discard the packet.
(3) Legal flow entry: the legal flow entry will match the attribute identifier and forward the valid packet to the basic forwarding table for further matching.(4) Table-miss flow entry: the table-miss flow entry is used to be compatible with non-IP packets and directly forwards non-IP packets to the basic forwarding table.e field type is * (arbitrary), and the action is to jump to the basic forwarding table.
e basic forwarding flow table is the Level 1 flow table, which is used for direct matching forwarding of packets.It supports all matching fields and all types of instructions/ actions.e matching process is shown in Figure 9.

Experiment and Evaluation
We have implemented and deployed an Attribute-Guard system.e system is based on OpenDaylight, we extend the function of the OpenDaylight controller and the OVS switch to complete the function deployment and use SFlow to monitor network traffic.Finally, the attribute-based group signature scheme is implemented through bilinear encryption library and C++ code.Next, we will evaluate it in terms of functional effectiveness, time consumption, and performance.

Experimental Environment.
e experiment uses 10 computers as the experimental environment and its configuration is shown in Table 3. Six of them are used to simulate authentication switches and forwarding switches.
Its network topology is shown in Figure 12.We test the function of SDN network based on the attribute identifier: (1) whether the system can identify the validity of flow and (2) whether the system can realize the access control based on the attribute identifier.

Functional Effectiveness
(1) Host h1's authentication request carries a valid attribute identifier and signature.Host h2's authentication request carries the attribute identifier and signature that do not conform to the h6 access structure.h3 is that the general packet does not carry any attribute identifier and signature.e above three hosts continuously send data to h8 at the rate of 50 packages/s.e controller makes the path h1/h2/h3 ⟶ e1 ⟶ a2 ⟶ a3 ⟶ e3 ⟶ h6.We use SFlow to monitor the traffic of e1 and e3, repeating 10 times for 12 seconds each time, and the result is averaged.e results are shown in Figures 9  and 10. e X-axis is the time, and its unit is seconds; the Y-axis indicates the number of packets, and its unit is packages/s, and the positive direction represents the inflow packet; that is, the authentication  As it is illustrated in Figure 13, the authentication switch e1 receives packets from h1, h2, and h3.Since h1 and h2 carry the attribute identifier, e1 only forwards h1 and h2 packets, and h3 packets are discarded directly.However, h2 started with a small amount of forwarding and then discarded.As shown in Figure 14, the packets of h3 are discarded.e packets of h2 are forwarded in the first second and then discarded.e packets of h1 are still forwarded.We check the authentication switch.e3 do not add new flow rules, and e1 generates an invalid flow rule to discard the packets of h2.From the experimental results, it can be seen that when the packet enters the network, the authentication switch first discards the packet that does not conform to the specification; i.e., the attribute identification is empty.e destination authentication switch verifies the validity of the authentication request.Invalid flow tables are sent to the source authentication switch to discard its subsequent packets.erefore, the network can reject the packet with invalid attribute identification and the illegal packets without the attribute identification into the network.(2) h1 sends the packets that carry the attribute identification conforming to the h6's access structure to e1 at the rate of 50 data packets per second, and then the path of h1 is modified to h4 by the controller in the next 12 seconds.SFlow is used to monitor e2 and e3 traffic, repeating 10 times for 12 seconds each time, and the results are averaged as shown in Figures 15 and 16.
In Figures 15 and 16, if the attribute identifier in the switch flow entry is the same as the attribute identifier of the packet.e packet would allow entering the device.When it accesses another device, the authentication switch determines that it is illegal and discards it.erefore, finegrained access control based on attribute identification can be implemented.

Scheme Comparison.
We compare the Attribute-Guard with the six most recent schemes; as illustrated in Table 4, SE-Floodlight [9], RoseMary [10], FRESCO [11], and FortNOX [3] offer a role-based source authentication for flow rules, and PERM-GUARD [26] and PermOF [27] offer a source authentication based on the access list.
Each new flow rule generated in the SDN network represents a change of the flow and the flow needs to be authenticated.e number of flow rules is positively related to the number of authentications, which reflects the granularity of data flow management.Figure 17 illustrates the number of authenticated identities comparison between Attribute-Guard and the most recent schemes.Because SE-Floodlight, RoseMary, FRESCO, and FortNOX provide only three roles for authentication, their bottleneck of identity authentication first appears.PERM-GUARD and PermOF are able to provide a better granularity due to the access lists.But their granularity is limited by the size of the access list.Our scheme provides a fine-grained, Attribute-Guard, which adopts the attribute signature.e scheme defines the access structure according to requirements, and only the signature that satisfies its access structure can be verified successfully.
e signature algorithm implements access control and does not need to create an access list, so it is not limited by the access list and achieves better fine-grained management.
As SDN design enables to push all the control functionality to a centralized controller, SE-Floodlight, Rose-Mary, FRESCO, FortNOX, PERM-GUARD, and PermOF develop network control applications and enforcing policies.us, controllers might potentially become a bottleneck for the network operations.Attribute-Guard reduces the request and the overhead on the SDN controller by delegating the access control capability to the data plane and has the lowest CPU utilization and memory utilization.e result is shown in Figures 18(a) and 18(b).Attribute-Guard has a better scalability than other schemes.

Performance Analysis.
In this section, we will evaluate the performance of Attribute-Guard: SDN network packet processing capability based on attribute identification.
For the problem, we measure the time consumption of generating signature and verification signature to estimate the performance of Attribute-Guard.
ese two features determine how many flows could be handled by Attribute-Guard.However, because the length of the authentication request sent by the host is different and the traffic of the host is different at different times, the measurement results are different.To measure the maximum performance of Attribute-Guard, we need to pay attention to the two points: (1) increase the proportion of signature verification in packet generation and forwarding time and (2) measure time-   consumption when the network is most active.For (1), we continue to send short messages with a fixed length of 64 bytes on the host.For (2), we refer to Stanford 300 users [25] and 22000 [28] user SDN experiments and Berkeley Lab [8] statistics on more than 8000 user SDN networks, and they indicate that the number of packets forwarded by each active host mainly ranges from 9 to 25 minutes.erefore, first we count the generating time of 200 authentication requests within the 9 to 25 minutes of the host running.As shown in Figure 19, the X-axis corresponds to the number of authentication request, and the Y-axis corresponds to the timeconsumption of generating authentication request.From the figure, we can calculate that the average time to generate a new authentication request with attribute identification is 25.76 ms. at is, 38 sets of authentication requests with different attribute identifiers and signatures can be sent per second at a rate of about 760 m/s.
We test 200 authentication requests to measure the average time for the authentication switch verifying each signed authentication request.As shown in Figure 20, the average time for the authentication switch to verify the signed authentication request is about 51.77 ms, which means that the authentication switch can handle 386 m per second.
According to the literature [6,8,9,28,29], the switch needs to handle the traffic in daily use as shown in Table 4.According to Table 5, the Attribute-Guard system performance can meet the basic network requirements.
When the authentication switch receives more packets, the authentication time will increase.It becomes a problem whether the verification efficiency will decrease as the packets increase becomes the bottleneck of data throughput.Figure 21 illustrates the authentication time required for the authentication switch under different packets, with the Xaxis corresponding to the number of packets, of which 20M each.According to the result, the relationship between the number of authentication packets and the time of the  Security and Communication Networks authentication switch is linear.e rate of the authentication packet does not change with the increase of the packet.

Network Overhead.
Attribute-Guard introduces a new single point of failure in the "attribute identifier authority" and deploys security modules in the controller and data plane, and the limitation of the Attribute-Guard is needed to be discussed and the additional performance overhead of the controller, host, and forwarding device should be evaluated.
For the controller, we continuously send legal packets at different locations on the host and count controller additional performance overhead at different Pack_in rates.
Firstly, we compare the CPU utilization of the native OpenDaylight controller with the CPU utilization of the Attribute-Guard's controller.In Figure 22, the CPU utilization of the controller in the Attribute-Guard system is slightly higher than that of the native.OpenDaylight controller at the same Pack_in rate.Secondly, we compare the memory utilization of the native OpenDaylight controller with Attribute-Guard's controller.As illustrated in Figure 23.e memory utilization of Attribute-Guard's controller is slightly higher than the native OpenDaylight controller with a difference about 13%.It indicates that the Attribute-Guard system does not increase the controller load too much under the premise of implementing the security function.
We use hping3 to inject data packets into the network at 50 Mbit/s, 100 Mbit/s, 150 Mbit/s, 200 Mbit/s, 250 Mbit/s, 300 Mbit/s, 350 Mbit/s, 400 Mbit/s, 450 Mbit/s, and 500 Mbit/s.e CPU utilization and memory utilization of host and data plane are measured in different scenarios.It is repeated 10 times at different rates, and the average value is taken each time.
For the host, as shown in Figure 24, the CPU utilization of the host with the attribute identification component is slightly higher than that of the standard host, and both increase with the increase in the traffic.As the network traffic increases, the number of packets requiring authentication increases, and the difference in CPU usage gradually increases because the host with the attribute identification component needs to generate a signature and encapsulate the attribute identifier before sending the packet.Although the computational cost of generating a signature is large, it is only related to device attributes and is independent of the packet.It only needs to perform one operation, and the

Schemes
Size of network e number of packets per second (m/ s) [25] Over 300 hosts 246 [28] 22000 hosts 497 [8] 8000 hosts 356 [9] 4 hosts 196 [26] 100 hosts 320   Security and Communication Networks computational overhead of encapsulating signatures and attribute identifiers is small.erefore, the difference in CPU usage between the two schemes is small as the rate increases, and the maximum difference is 0.8%.Similarly, in Figure 25, the more the network traffic, the more the packets needed to be encapsulated, and thus, the more the memory utilization.e difference between the standard host and the host with attribute identifier component is not very large, which is within the acceptable range.
For the data plane, the Attribute-Guard's data plane is composed of the authentication switch and forwarding switch.erefore, we compare the network overhead between the authentication switch, the forwarding switch, and the OpenFlow switch.e authentication switch deploys a flow identification module and a processing pipeline based on the attribute identifier.When the flow enters the authentication switch, it needs to be authenticated.is process increases the computing overhead.In Figure 26, we can see that as the packet rate increases, the CPU utilization of the forwarding switch is the same as that of the OpenFlow switch, and the authentication switch suffers from a linear growth of CPU utilization rapidly.As shown in Figure 27, the authentication switch and the forwarding switch have higher memory utilization than the OpenFlow switch because the authentication switch and the forwarding switch add a pipeline based on attribute identification.
e authentication switch and the forwarding switch require more flow tables than the Open-Flow switch.Finally, we compare the delay of the authentication switch, the forwarding switch, and the OpenFlow switch.e result is shown in Figure 28.e delay of the forwarding switch is slightly higher than that of the OpenFlow Security and Communication Networks switch, and the delay of the authentication switch is larger than the others.e authentication switch needs flow authentication and forwarding, while the forwarding switch and the OpenFlow switch only need forwarding.erefore, the algorithm complexity of the signature is main network overhead, and the pipeline based on attribute identification has little effect on network overhead.
We have extended the SDN by adding an attribute identifier authority that needs to communicate with the authentication switch and host.In order to describe the impact of the attribute identifier authority on the authentication switch and the host, we count the traffic between the authentication switch and the attribute identifier authority, and the traffic between the host and the attribute identifier authority.Figure 29 shows the traffic ratio of the attribute identifier authority to the authentication switch and the traffic ratio of the attribute identifier authority to the host.e attribute identifier authority's traffic accounts for less than 12% of the total traffic and decreases as the packet rate increases.

Availability Analysis.
We compare the packet loss rate and delay between Attribute-Guard and SDN networks and analyse network availability.First, we send packets with a length of 1514 bytes at different rates and different ports and count the packet loss rate as shown in Figure 30.
As shown in Figure 30, as the packet-receiving rate increases, the packet loss rate of the network increases because the packet with the attribute identifier needs to be verified and the flow table adds the math field based on the attribute identifier in the switch.e packet rate is larger than the network without attribute identifier and signature.en, the average delay is obtained by counting 50 times of ACK return.In the Attribute-Guard scheme, the delay of each ACK return is T Attribute− Guard .e delay of the system without the attribute identifier and signature is T N− Attribute− Guard .
From Figure 31, the average network delay of T N− Attribute− Guard is 31.48ms, while the average network delay of T Attribute− Guard is 103.2 ms, and the average delay is increased by 71.72 ms. e analysis shows that the time to generate signature and verify the signature accounts for 65.4% of the total delay.erefore, the algorithm complexity of the signature directly determines the network delay, but it is still within the feasible communication delay.

Conclusion
In this paper, we propose Attribute-Guard, an access control framework based on the attribute identifier.
e goal of Attribute-Guard is to make flow in the data plane more credible.
is framework implements flow authentication and fine-grained access control, which enables the data plane to shield the host from varieties of malicious flow attacks.We have implemented and deployed Attribute-Guard on the OpenDaylight and OVS while verifying the functionality and usability of the network, and the verification results show that the framework ensures the availability of the network.In the future, we will make more efforts in flow verification to improve the performance of flow forwarding.

Figure 3 :Figure 4 :
Figure 3: Example 1: an attacker tampers with flow rules and uses it to allow malicious packets bypass a security device.
(i) Version (4 digits): the version of the attribute identifier (ii) Secondary protocol (8 bit): the type of the protocol immediately following the attribute identifier, such as 6 (TCP), 17 (UDP), or 50 (ESP) (iii) Length (8 bits): the value is the length of the entire attribute identifier (including the header and metadata) in units of 32 bits (4 bytes)
Testing.We test the two attack scenarios in Section 1.2, indicating that the malicious host a cannot attack host c with the protection of Attribute-Guard: (i) As shown in Figure 2, host a directly accesses the destination device c by tampering with the flow rule.However, Attribute-Guard uses the authentication switch to verify the flow of host a.Since the host does not satisfy the access structure of host c, the packets cannot reach host c. (ii) An attacker can change the address of the packet by generating two new flow rules to scan host c.However, Attribute-Guard forwards the flow by

Figure 10 :
Figure 10: SDN flow entry structure based on attribute identification.

Figure 15 :
Figure 15: Authentication switch e3 traffic statistics under the experiment of access control.

Figure 20 :
Figure 20: e time for the authentication switch to verify the authentication request.

Table 1 :
Attribute identifier message format.Definition 2. c i represents the private key owned by each user.μ indicates the number of private keys.User uses the attribute to signature, and the element in ζ i satisfies c i , that is, ζ i ⊆ c i , and the number of ζ i is τ, for example, Γ � (1, 2), � h t i , and i � att(x).And send the system public parameters TPK � 〈 D x , h x   x∈c Γ 〉 to the authentication switch.(2) KeyGen private (gsk[i] base , c i ): we use attribute c i owned by user i (i.e., j ∈ c i ) to generate private key SK � 〈A i , x i , T i,j   j∈c i 〉 by computer Γ i,j � A t j .

Table 2 :
Flow authentication protocol format.

Table 4 :
e granularity of flow authentication comparison.

Table 5 :
e number of packets forwarding per second in different networks.