Open Access
ARTICLE
Certrust: An SDN-Based Framework for the Trust of Certificates against Crossfire Attacks in IoT Scenarios
1
School of Computer Science (National Pilot Software Engineering School), Beijing University of Posts and Telecommunications,
Beijing, China
2
College of Engineering, Qatar University, Doha, Qatar
* Corresponding Author: Xiaohong Huang. Email:
(This article belongs to the Special Issue: Models of Computation: Specification, Implementation and Challenges)
Computer Modeling in Engineering & Sciences 2023, 134(3), 2137-2162. https://doi.org/10.32604/cmes.2022.022462
Received 10 March 2022; Accepted 12 May 2022; Issue published 20 September 2022
Abstract
The low-intensity attack flows used by Crossfire attacks are hard to distinguish from legitimate flows. Traditional methods to identify the malicious flows in Crossfire attacks are rerouting, which is based on statistics. In these existing mechanisms, the identification of malicious flows depends on the IP address. However, the IP address is easy to be changed by attacks. Compared with the IP address, the certificate is more challenging to be tampered with or forged. Moreover, the traffic trend in the network is towards encryption. The certificates are popularly utilized by IoT devices for authentication in encryption protocols. DTLShps proposed a new way to verify certificates for resource-constrained IoT devices by using the SDN controller. Based on DTLShps, the SDN controller can collect statistics on certificates. In this paper, we propose Certrust, a framework based on the trust of certificates, to mitigate the Crossfire attack by using SDN for IoT. Our goal is threefold. First, the trust model is built based on the Bayesian trust system with the statistics on the participation of certificates in each Crossfire attack. Moreover, the forgetting curve is utilized instead of the traditional decay method in the Bayesian trust system for achieving a moderate decay rate. Second, for detecting the Crossfire attack accurately, a method based on graph connectivity is proposed. Third, several trust-based routing principles are proposed to mitigate the Crossfire attack. These principles can also encourage users to use certificates in communication. The performance evaluation shows that Certrust is more effective in mitigating the Crossfire attack than the traditional rerouting schemes. Moreover, our trust model has a more appropriate decay rate than the traditional methods.Graphic Abstract
Keywords
With the rapid development of the Internet of Things (IoT), the large volume, pervasiveness, and high vulnerability of IoT devices have attracted many bad actors, particularly those orchestrating distributed denial-of-service (DDoS) attacks [1]. The emergence of Software-Defined Networking (SDN) offers several new advantages to defend against conventional DDoS attacks [2]. The global network view and dynamic network policy update in SDN make the traffic characteristics analysis easy and the DDoS attack prevention timely. The improvement of the defense stimulates the evolution of the attack. The attack traffic is inclined to mimic the legal traffic behaviors. Moreover, this mimicking leads to the invalidation of the traffic characteristics analysis. The Crossfire attack is such a sophisticated and powerful link-flooding attack. This attack cuts off network connections to a target area by flooding low-intensity flows on the selected links around the target area [3]. These low-intensity flows are hard to distinguish from legitimate flows.
Before flooding low-intensity flows to the target links, the attackers need to determine the target links by traceroute. The moving target defense based on traceroute packets analysis can prevent the attackers from finding out the target links [4]. Meanwhile, the traceroute is not only used by the attackers but also utilized in network measurement. Thus, it is hard to distinguish between the legal and malicious traceroute packets. The interference of legal traceroute packets may bring trouble to the target link selection in the moving target defense. Hence, we do not choose the traceroute-based methods.
Another kind of defensive approach is to identify and block the low-intensity flows flooded by the attackers. Statistics-based methods are effective in identifying the sophisticated malicious flows of the Crossfire attack. Traffic rerouting is a classical measure to conduct the repeated statistical experiments [5–7]. After several traffic rerouting rounds, the malicious flows can be identified as the flows with their source IP address always appearing in each attack round. Besides rerouting, the correlation analysis based on IP addresses also can identify the malicious flows in the Crossfire attack [8].
The above identification mechanisms utilize the IP address to identify the malicious flows. Thus, by merely modifying the IP address, an adversary can avoid the identifying mechanism. Even the IP address is required to be changed in many normal scenarios, such as using IPv6 temporary address [9], IP address mutation communications [10] and Mobile IP communications [11,12]. Therefore, the IP-based identification mechanisms may no longer work well in these cases.
A certificate signed and issued by a certificate authority (CA) is much harder to be forged or tampered with than the IP address. Moreover, the certificates are popularly utilized in IoT. On the one hand, in the device-to-device communication scenario, most connected devices do not previously know each other [13]. Thus, the IoT devices in such a situation usually depend on asymmetric encryption techniques and mainly utilize certificates for identifying and authenticating entities [13]. On the other hand, in the scenario of the IoT devices communicating with the cloud service providers, the traffic trend on the Internet is towards encryption. For example, the percentage of web pages loaded by Firefox using HTTPS has sustained growth in recent years [14]. This percentage has exceeded 80% since 2020 for global users. The above example illustrates that service providers on the Internet are inclined to provide encrypted connections. Thus, mimicking the legal traffic, the traffic of Crossfire attacks will have the same trend towards encryption. Furthermore, the certificate is also widely utilized by encryption protocols, such as TLS/DTLS and IPsec, for authenticating the IoT devices. Therefore, we believe that the certificate is an excellent candidate to identify the malicious flows for the Crossfire attack in the IoT scenario.
The certificate-based trust model depends on the statistics on the participation of the certificates in each Crossfire attack. Thus, we need to detect the Crossfire attack accurately. The existing detection methods are implemented by monitoring the congestion on pre-selected target links [6,7] or analyzing the traffic correlation on every link [8]. Without a judgment on whether a separate target area exists, the above detection measures fail to distinguish the Crossfire attack from other types of link-flooding attacks.
The heavy computational overhead of certificate verification makes it hard to implement the certificates on resource-constrained IoT devices. DTLShps [15] provides a new thought to simplify Datagram Transport Layer Security (DTLS) protocol for resource-constrained IoT devices by using SDN. All the handshake messages of DTLShps sessions are sent to the SDN controller by the SDN switch. The certificates will be verified in the controller instead of IoT devices. DTLShps can reduce about 89% energy consumption and 77% computational overhead on an IoT device compared with the traditional DTLS. For other security protocols, such as TLS and IPsec, the handshake messages of these protocols also can be sent to the controller. Then, let the controller verify the certificates contained in the handshake messages. Based on DTLShps, we can use the SDN controller to collect statistics on certificates.
In this paper, as our major contribution, a trust framework (Certrust) is designed to mitigate the link congestion during the Crossfire attack over SDN in the IoT scenario. The direct trust of certificates is calculated through the Bayesian trust system, which is based on the statistics on the historical behavior of certificates. The historical data in the Bayesian trust system is decayed by the forgetting curve instead of the traditional decay method [16–18] for achieving a more moderate decay rate. The recommendation trust of certificates is calculated depending on the reliability of the CA. For detecting the attack accurately, we proposed a method based on graph connectivity to detect the Crossfire attack from the link congestion events. For mitigating the Crossfire attack, several trust-based routing principles, which can encourage users to use certificates in communication, are introduced. Then these principles are implemented by the bandwidth configuration in the SDN switches. The performance evaluation shows that Certrust is more effective in mitigating the link congestion in the Crossfire attack than the rerouting schemes.
The remainder of this article is organized as follows. Section 2 briefly introduces the preliminary and network scenario. Then, the motivation and the framework of Certrust is illustrated in Section 3. Section 4 constructs the trust model of the certificate. The detection mechanism and the mitigation mechanism for the Crossfire attack are provided in Section 5. Section 6 discusses the parameters in the trust model and evaluates the performance of our framework before we conclude this article in Section 7.
The network model is shown in Fig. 1. The normal IoT devices, bots and decoy servers are connected to the network through the SDN switch, which performs as an IoT broker. Several bots can congest the target links by sending low-intensity traffic to different decoy servers. If the target links are congested, the target server cannot be connected by any normal IoT devices. We assume that the SDN switches and the controller are trusted, as our threat model is for the Crossfire attack. All the handshake messages of communicational security protocols, such as DTLS, TLS and IPsec, are sent to the controller by the SDN switch, as shown in DTLShps [15]. The certificates will be verified in the controller instead of IoT devices. The Certrust service is deployed on the controller. The controller will forward the processed handshake packets to the SDN switch that can deliver the handshake packets to the destination directly. After the handshake phase, the encrypted traffic between the two hosts will not pass through the controller any more.
We study our framework in a simple SDN scenario, in which one controller exists in a single SDN domain. The simple SDN scenario will facilitate the analysis and discussion of our framework. Moreover, it is easy to extend one controller by multi-controllers for scalability in practice. The extension for multi-controllers in a single SDN domain has been illustrated in [15]. The cooperation between multiple SDN domains is shown in [19].
Our study focuses on the Crossfire attack, a sophisticated link flood attack. The Crossfire attack can degrade and even cut off network connections to a variety of selected server targets by flooding a few links in the network [3]. The server targets can be selected as the servers of an enterprise, a city, a state, or a small country. A small set of bots directs low-intensity flows to a large number of publicly accessible servers (decoy servers). The concentration of these flows floods a small set of carefully chosen links and effectively disconnects selected target servers from the Internet. The sources of the Crossfire attack are undetectable by any targeted servers since they no longer receive any messages. Moreover, the low-intensity, individual flows of the Crossfire attack are indistinguishable from legitimate flows by traditional traffic anomaly detection. The attack persistence can be extended virtually indefinitely by changing bots, decoy servers, and target links while maintaining the same disconnection targets.
The Bayesian trust system, which is also called the Beta reputation system, works based on the beta probability density function (PDF) [20,21]. This PDF can represent probability distributions of binary (i.e., positive or negative) events. The beta PDF is indexed by two parameters
where
Moreover, trust is a subjective expectation a subject has about another’s future behavior based on the history of their encounters [22]. Therefore, the most natural is to define the trust value, which is denoted by Tv, as
After observing r positive and s negative outcomes of the binary events, the a posteriori distribution is the beta PDF with
Let
The accuracy of Tv can be improved by increasing the number of samples [23]. Let
3 Design of the Certrust Framework
Traditional measures to identify malicious flows against Crossfire attacks is to use the IP address [5–8]. The IP address can be modified easily by an attacker. Thus, the detection mechanism of malicious flows will fail. Moreover, in many scenarios, the IP address even is required to be changed frequently.
On the contrary, the certificate is much harder to be tampered compared with the IP address. The certificate is based on asymmetric cryptography and signed by the secret key of a CA. A tampered certificate can be detected by the verification with the public key of the CA. Furthermore, the traffic in the network has a trend towards encryption and certificates are used widely by IoT devices. Therefore, we propose a framework to utilize the certificate to identify the malicious flows effectively.
The framework of Certrust is shown in Fig. 2. The modules of the framework are deployed in the controller and divided into two types: packets handling and trust handling. There are two packets handling modules: certificate verification and trust-based routing policy generation. The packets handling modules are responsible for dealing with the packet-in messages sent from the SDN switches. When a certificate is sent to the controller by an SDN switch, the certificate will be verified by the certificate verification module firstly. After passing the verification, the trust-based routing policy generation module will generate a routing policy depending on the trust level of the certificate. Then, the routing policy will be sent to the relevant SDN switches.
Moreover, three trust handling modules provide the trust-related data required by the packets handling modules: network behavior counting, trust value update, and trust-based bandwidth configuration. The network behavior counting module is designed to detect the Crossfire attacks and record the network behaviors of the certificates during the Crossfire attacks. The trust value update module maintains the trust model based on the statistics on the network behaviors of the certificates. The trust-based bandwidth configuration module is responsible for grading the certificates according to their trust value and configuring the bandwidths of each trust level on the SDN switches for mitigating the Crossfire attack.
3.2.1 Certificate Verification Module
This module is implemented by the certificate verification mechanism proposed in [15]. It is easy to extend this progress to other security protocols. The handshake process in [15] is shown in Fig. 3. The IoT device that initiates the session performs as a client, and the IoT device that responds to the session performs as a server. The client and server send their certificate chain to the controller by the Certificate message. After the controller has completed the certificate verification, the controller sends the identity information in the certificate to the corresponding end by the Identity message.
To deploy certificate-based authentication on resource-constrained IoT devices, it is common to shift the certificate verification to a trusted third party, such as a delegation server [24–26]. The controller performs as the trusted third party in our framework. Moreover, the controller needs to encourage the client to use the certificate, as our framework is based on the trust model of certificates. Thus, we make some modifications to the above handshake process. The controller will always send the CertificateRequest message to request the client’s certificate, regardless of whether the server has sent the CertificateRequest message to the controller. If the server has not sent the CertificateRequest message to the controller, the controller will not send the Identity message to the server to inform the client’s identity. Otherwise, the controller will send. If the client refuses to send its certificate, the client will send a Certificate message with no certificate to the controller. Then the controller will send an Identity message with no information to the server if the server has sent the CertificateRequest message to the controller.
The user, who wants to be anonymous, can use the anonymous certificate, as presented in [27]. The anonymous certificate is a syntactically valid X.509 certificate, in which the Subject field contains a pseudonym. The anonymous certificate also can accumulate trust in our framework.
3.2.2 Trust-Based Routing Policy Generation Module
After verifying a certificate, the controller will inquire about the trust level of the certificate. The trust level of certificates is recorded in the controller by the trust-based bandwidth configuration module and obtained by searching the records. The controller will generate and issue the routing policy to the relevant SDN switches depending on the trust level of the certificate. Several queues have been created on each egress port of the SDN switches. Each queue corresponds to a trust level. Different queues have been configured with different bandwidths by the trust-based bandwidth configuration module. The routing policy issued from the controller will make the traffic from different trust levels handled by the corresponding queue on the SDN switches. This module is also responsible for recording the mapping between the certificate and the flow in the log file.
3.2.3 Network Behavior Counting Module
This module firstly uses the detection mechanism proposed in [6] to detect link congestion. The available bandwidth of the links over the whole network is monitored by the SDN controller. If the available bandwidth of a link is exhausted, link congestion occurs. The controller will record the period when the congestion lasted and the locations (SDN switches) where the congestion happened. Secondly, this module collects the information of the flows and certificates participating in the link congestion from the log files recorded by the trust-based routing policy generation module. Thirdly, the Crossfire attack is detected from the link congestion events by a method based on the graph connectivity. Finally, if a Crossfire attack is detected, the count of the network behaviors of relevant certificates is updated.
3.2.4 Trust Value Update Module
This module updates the trust value of the certificate based on the network behavior and activity of the certificate. The statistics for network behavior is made by the network behavior counting module. Moreover, the activity can be calculated through the log files recorded by the trust-based routing policy generation module.
3.2.5 Trust-Based Bandwidth Configuration Module
The trust level is graded depending on the trust values maintained by the trust value update module. Different maximum and minimum available bandwidths of the queues on the SDN switches are set according to different trust levels for providing differentiated services.
The trust of a user’s certificate is an expectation about the certificate owner will act as a benign user. The user’s certificate trust
where
4.1 The Direct Trust of a User’s Certificate
The calculation of
It is reasonable to suspect the owner of a certificate, whose traffic often attended the link congestion caused by the Crossfire attacks, is an attacker.
We further consider the factor of time in our model. The more recent the historical data on network behavior is, the more valuable it is to evaluate the trust level of certificates. Time is divided into time slots according to a fixed period T. T can be several hours or days. A weight
where
“
Moreover, a forgetting curve shows the nonlinear decreasing law of human memory retention [28,29]. We use human memory to simulate the historical data. Thus, the forgetting curve can be applied to obtain the decay weight
where
Consequently, (7) can be updated as follows:
Only if the number of samples is equal to or greater than the threshold in (5), the direct trust of the user’s certificate can be calculated by (13). If the number of samples is less than the threshold,
4.2 The Recommendation Trust of a User’s Certificate
When a CA signs a certificate with its private key, it means that the CA uses its reputation to guarantee that the public key in the certificate belongs to the certificate owner. Thus, the recommendation trust of a certificate is related to its CA’s reputation. A user’s certificate is generally contained in a certificate chain, as shown in Fig. 4. The owner’s identity and public key in a user’s certificate are signed by the private key of its issuer (
The closer a CA’s certificate is to the user’s certificate in a certificate chain, the tighter the correlation between them is. Therefore,
where
where
4.3 The Trust of a CA’s Certificate
The trust of a CA’s certificate
where
where
Before the first certificate issued by a CA appears in the network,
The time factor is also considered in the model of
where
where
n′ is the sequence number of the current time slot,
“
Moreover, the parameter
where
The calculation of
where
The model of
where the definitions of n′ and “
The trust value in the trust model is updated at the end of each time slot. Meanwhile, the period of a single time slot can be different for counting the network behavior and user activity. Thus,
The count of network behaviors is updated by the network behavior counting module, as shown in Section 5.2. The user activity can be calculated through the log files recorded by the trust-based routing policy generation module, as illustrated in Section 3.2.2. For example, if a certificate occurred in the record of a specific day, the certificate can be counted as active on this day. Alternatively, if the number of occurrences of a certificate exceeded a certain threshold in one day, the certificate also can be counted as active on this day.
The number of cycles of calculating
5 Attack Detection and Mitigation
5.1 The Crossfire Attack Detection
The Crossfire attack works through the link congestion. Thus, firstly it is required to record the link congestion events that occurred in the network. Secondly, the Crossfire attack is required to be detected from the link congestion events.
The link congestion in SDN can be detected by exploiting the Floodlight controller’s statistics measurement APIs [6]. The link congestion can be identified by a decrease in the available bandwidth. The threshold for the available bandwidth is 10% of the total bandwidth, as set in [6]. After congestion is detected, the controller will record the period when the congestion lasted and the location (SDN switches) where the congestion happened.
We propose a method based on graph connectivity to detect the Crossfire attack from the link congestion events. A striking feature of the Crossfire attack is that all the network connections to a target area are cut off during the attack [3]. As shown in Fig. 5, after all the hollow links are congested, the network inside the broken circle loses the connection from outside during a Crossfire attack. If no area has been disconnected, the attack should be counted as a normal link-flooding attack. Otherwise, if just one link was congested, the attack should be counted as a Coremelt attack [31].
The routing topology as an undirected graph must be connected, because the unreachable routers will not present on the routing topology. The routing topology is stored in the controller. Then, the congested links in the same period are removed from the routing topology. If the rest of the routing topology is not a connected graph, there must be a certain area disconnected. Otherwise, there is no area disconnected.
The steps for detecting the Crossfire attack from the link congestion events are illustrated in Algorithm 1. The graph of routing topology
The time complexity of Algorithm 1 is the same as that of the BFS or DFS algorithm. The time complexity of the BFS and DFS algorithm both are
The network behavior counting of the certificates is based on the detection of the Crossfire attack. Whenever link congestion is detected, the controller will record the period and location of the link congestion, as shown in Section 5.1. The flows participating in the congestion can be obtained by searching the log files of the SDN switches with the period and location recorded previously. The log files can be collected by the controller from the SDN switches regularly. As controlling all the SDN switches in the network, the controller can obtain the link congestion records of the whole network. The certificates associated with the flows participating in the link congestion and active certificates in the same period can be found in the log files recorded by the trust-based routing policy generation module. Thus, if a Crossfire attack is detected from the link congestion events through Algorithm 1, the network behavior count of the certificates can be updated.
5.3 The Crossfire Attack Mitigation
The network provides differentiated services of routing according to different trust levels of certificates to mitigate the link congestion caused by the Crossfire attack. According to the trust value of the certificates, the certificates can be divided into several high levels, several low levels and one medium level. The traffic from the certificates in the high trust levels can be regarded as benign traffic. The traffic from the certificates in the low trust levels can be considered to be malicious traffic. The traffic from certificates in the medium trust level can be treated as unidentified traffic, as the application of the trust model requires accumulating a certain number of samples.
When link congestion occurs, the principles for differentiated routing services are as follows:
1. The traffic from certificates in the high trust levels is guaranteed to receive preferential routing.
2. The traffic from certificates in the low trust levels is restrained.
3. The traffic from certificates in the medium trust level or without a certificate is provided with a relatively fair routing service.
4. The higher trust level a certificate is in, the higher quality of network service the traffic from this certificate will enjoy in the link congestion.
These principles can encourage users to use certificates in communication. It also can encourage users to keep their certificate in the high trust levels and stimulate users to upgrade the trust level of their certificate. The user with a higher trust level certificate will enjoy a higher-quality network service in the link congestion. The finer the granularity of the trust level division is, the more influential the stimulation for users will be; meanwhile, the more complex the implementation will be. Thus, it needs balance. For the coarsest granularity, there should be one high trust level and one low trust level.
If the attacker does not use certificates to launch a Crossfire attack, the attack traffic will be treated as in the medium trust level. The attack traffic is restrained compared with the traffic from the certificate in the high trust levels. Moreover, the service quality of the traffic from certificates in the high trust levels still will be guaranteed under the attack. If the attacker uses the certificate to launch a Crossfire attack, the attack traffic will be distinguished by our trust model.
There are many other kinds of network attacks also conducted by massive traffic, such as Coremelt attacks, scanning attacks, the traditional DDoS attacks targeting a specified server and any other kinds of DDoS attacks. Most of these attacks do not use certificates. Thus, the traffic from these attacks will also be restrained as the traffic from certificates in the medium trust level. The traffic from certificates in the high trust levels can still receive a guaranteed routing service under these kinds of attacks.
We give an implementation of the trust-based routing principles based on bandwidth configuration. We take the coarsest granularity of the trust levels (just three trust levels: high, medium and low) as an example for a concise and explicit illustration. Three queues are created on each egress port of the SDN switches corresponding to the three trust levels. The queue’s maximum and minimum available bandwidth are set according to different trust levels for providing differentiated services. For fairness, the bandwidth of each trust level is configured based on the number of certificates contained in the corresponding trust level. The routing policy issued by the routing policy generation module will make the traffic from different trust levels handled by the corresponding queue on the egress port of the SDN switches.
When link congestion occurs, the traffic is transmitted by the minimum available bandwidth. When the link is idle, the traffic could reach the maximum available bandwidth. The setting of the maximum available bandwidth is to encourage the users to upgrade the trust level of their certificate.
The maximum and minimum available bandwidth of each queue can be configured as the max-rate and min-rate in the SDN switch, respectively. The max-rate and min-rate for each trust level can be set according to the number of certificates in each trust level. The calculating process of the max-rate and min-rate of each trust level is shown in Algorithm 2. The inputs of Algorithm 2 are the bandwidth of an egress port of an SDN switch BW and the number of certificates in the high, medium and low trust level:
6.1 Discussion of the Parameters Selection in the Trust Model
Our trust model is compared with that in [16–18]. In these previous researches, an exponential function with base
where
Fig. 6a shows
In the 10th time slot, the count of legal and suspicious actions are equal, which is two hundred. Without time decay,
Fig. 6b illustrates
The forgetting curve in our trust model is also compared with an exponential function with base
where
Fig. 7a demonstrates
The enhancement of
Fig. 7b presents
Our link congestion detection utilizes the method proposed in [6]. The detection accuracy of link congestion is 100%, as shown in [6]. Moreover, the Crossfire attack identification depends on the judgment of the connectivity of the graph constructed by uncongested links. The connectivity of a given graph is determinate. Therefore, the accuracy of the Crossfire attack identification is also 100%.
6.3 The Effectiveness of Congestion Mitigation
Assuming a trust model has been given, we illustrate how the distribution of the certificates in each trust level affects the link congestion mitigation in this section. We evaluate two contrasting distribution of the certificates. The two distributions are shown as follows:
1) The number of certificates in each trust level is imbalanced, denoted as
2) The number of certificates in each trust level is equal, denoted as
In
In
We use Mininet to simulate an SDN system. Mininet is run on a laptop with Intel Core i7-7600U 2.8 GHz CPU and 16 GB memory. A Floodlight OpenFlow controller is run on the same laptop. The network topology in Mininet is shown in Fig. 8. The seven OpenFlow switches are all managed by the Floodlight controller. The traffic from three trust levels is sent from the IoT devices Host1, Host2 and Host3, and received by the decoy servers Decoy1, Decoy2 and Decoy3. The traffic is generated and received by the software D-ITG [33]. The target links are the link between the SDN switch s1 and s7 and between s7 and s2. The target switch is s7. The network behind s7 is the target area. The bypass switch s6 is only used for rerouting in the comparison experiment. The bandwidth of the target link and rerouting link is both five megabits per second (Mbps).
Our framework is compared with the rerouting mechanism proposed in [6,34]. Optimized Packet Distributor (OPD) [34] is the most recent SDN-based rerouting scheme for mitigating the Crossfire attack. OPD uses the same attack detection mechanism as [6]. After the attack has been detected, the traffic is rerouted by a load balance algorithm. However, OPD has not identified the malicious traffic and just mitigated the link congestion. To evaluate our scheme in the worst condition, we ignore the run time of the load balance algorithm in [34]. Thus, Al Farooq et al. [34] have the same rerouting performance as [6].
We evaluate the effectiveness of differentiated services through the following parameters: throughput, delay and jitter. The performance evaluation of
The receiving rates of the traffic from the three trust levels over time in the two distributions are illustrated in Figs. 9b and 10b, respectively. In Fig. 9b, the receiving rate of the traffic from the high trust level is around 2.5 Mbps, from the medium trust level is around 2 Mbps, from the low trust level is almost zero. In Fig. 10b, the receiving rate of the traffic from the high trust level is around 3 Mbps, from the medium trust level is around 1.5 Mbps, from the low trust level is almost zero. The receiving rate of the traffic from every trust level is restrained below the corresponding min-rate shown in Tables 1 and 2.
The congestion on the traffic from the high trust level obtains the most mitigation. In contrast, the traffic from the low trust level receives the most restraint. Meanwhile, relatively fair routing services are provided to the traffic from the medium trust level. The number of the medium trust level certificates in
Figs. 9c and 10c depict the delay of the traffic from the three trust levels over time in the two distributions, respectively. The delay of the traffic from the low trust level has a linear growth in both distributions. After the 5th second, the delay of the traffic from the high and medium trust levels becomes nearly constant at a small value. In Fig. 9c, the delay of the traffic from the high trust level is about 1.6 ms, from the medium trust level is about 2.0 ms after the 5th second. In Fig. 10c, the delay of the traffic from the high trust level is about 1.3 ms, from the medium trust level is about 2.6 ms after the 5th second. The linear growth of the delay represents that the traffic from the low trust level is restrained, and the transmitting time keeps increasing. The delay of the traffic from the medium trust level is greater than that from the high trust level in both distributions, as the latter has a higher receiving rate. The delay of the traffic from the high trust level in Fig. 9c is more than that in Fig. 10c for the same reason. Moreover, the delay of the traffic from the medium trust level in Fig. 9c is smaller than that in Fig. 10c. This difference is because the receiving rate of the traffic from the medium trust level in Fig. 9b is greater than that in Fig. 10b.
The jitter of the traffic from the three trust levels over time in the two distributions is presented in Figs. 9d and 10d, respectively. The jitter of the traffic from the high and medium trust level is almost zero in both distributions. In contrast, the jitter of the traffic from the low trust level is much more significant as nearly 0.4 ms in both distributions. The almost zero jitter means that the traffic from the high and medium trust level is received with a stable bandwidth. In contrast, a significant jitter indicates that the traffic from the low trust level is restrained to almost zero and received intermittently.
The evaluation of the rerouting scheme is portrayed in Fig. 11 for comparison. The sending rates, receiving rates, delay and jitter of the traffic from three trust levels over time are shown in Figs. 11a–11d, respectively. The sending rate of each trust level is around 5 Mbps. The traffic sending lasts for 60 s. We select the data in 20 s around the point rerouting happened for presenting in Fig. 11. Half of the traffic on the SDN switch s1 is rerouted to the SDN switch s6 at the 11th second. The receiving rates of the traffic from the three trust levels are around 1.5 Mbps before rerouting and around 3 Mbps after rerouting, as illustrated in Fig. 11b. Fig. 11c depicts the delay of the traffic from the three trust levels all descends when the rerouting happens. The delay goes up to the value before rerouting in several seconds because the overall bandwidth is still less than the total sending rate after rerouting. The jitter of the traffic from the three trust levels is also enhanced when the rerouting happens and then goes down to nearly zero in several seconds, as revealed in Fig. 11d. The traffic from the three trust levels has the same performance in the rerouting scheme.
Comparing with the rerouting scheme, Certrust can keep a high quality of services, such as higher throughput, lower delay and lower jitter, for the traffic from the high trust level from the beginning of link congestion. In the rerouting scheme, the congestion is required to be detected firstly and then change the routing policy in the network. The service quality will not change until the rerouting works. Moreover, the traffic from any trust levels is treated equally in the rerouting scheme.
6.4 Computational Overhead of Controller
The computational overhead of the controller for certificate verification has been evaluated in DTLShps [15]. In DTLShps, the computational overhead of the controller is evaluated under the number of concurrent connections from 1 to 30. To evaluate our scheme in the worst condition, we use the data when the number of concurrent connections is 30. When the number of concurrent connections is 30, DTLShps increases the overhead by about 1.7 times compared with the traditional DTLS in SDN. Our framework adds a step of the trust level query compared with the handshake process in DTLShps. The computational overhead of the trust level query for a certificate depends on the search algorithm chosen and the size of the record. For example, the time complexity of Linear Search is
In our experimental environment, the average computational overhead on the controller for the traditional DTLS handshake is 155 ms. The scheme of certificate verification increases this overhead by 1.7 times, as illustrated in [15]. Thus, the computational overhead on the controller for the scheme of certificate verification is
We proposed a certificate-based framework, Certrust, to mitigate the Crossfire attack over SDN in the IoT scenarios. The malicious flows in the Crossfire attack were identified by the trust level of the certificates. The trust of the certificate was modeled by the Bayesian trust system combining with the forgetting curve. Moreover, the trust model was calculated based on the participation of the certificate in each Crossfire attack. For detecting the attack accurately, a method based on graph connectivity was also proposed to detect the Crossfire attack from the link congestion events. Finally, four trust-based routing principles and their implementation were proposed to mitigate the link congestion caused by the Crossfire attack.
Certrust settles link congestion in real-time and identifies the Crossfire attack in the background. The link congestion is mitigated at the beginning without any delay for attack detection. The user with a good reputation will receive a high-quality service under the Crossfire attack. In contrast, the user with a poor reputation will suffer a hard time under the Crossfire attack. The traffic from users, who do not use certificates, is treated the same as the traffic from certificates with a medium reputation. If the attack traffic does not use certificates, the attack traffic will also be restrained compared with the traffic from certificates with a good reputation. Thus, the service quality of the traffic from certificates with a good reputation will always be guaranteed. This guarantee will also encourage users to use certificates in communication.
The experiment illustrated that the decay rate of our forgetting curve is more moderate and appropriate for the Bayesian trust system than that of the decay function proposed in the previous researches. Although the delay in the handshake phase of a secure session is inevitably increased by about 1.7 times, Certrust performed more effectively in mitigating link congestion than the rerouting schemes.
With the rapid development of IoT, certificates will be more and more widely used. Although certificates bring extra overhead compared with Pre-Shared Key (PSK) for authentication in IoT devices, one certificate can be authenticated by multiple communication peers. On the contrary, one PSK can correspond only to one communication peer, and the PSK also needs to be configured on the communication peer previously. The more peers an IoT device needs to communicate with, the more prominent the advantage of certificates will be. Furthermore, it is more and more popular to disguise malicious traffic as regular traffic to improve the success rate of attacks. Thus, with the wide usage of certificates in the future, more and more attacks will also use certificates. Therefore, the proposed trust model of certificates will be applied to protect against more attacks in the future.
Funding Statement: This work was supported by Joint Funds of the National Natural Science Foundation of China and Xinjiang under Project U1603261.
Conflicts of Interest: The authors declare that they have no conflicts of interest to report regarding the present study.
References
1. Kolias, C., Kambourakis, G., Stavrou, A., Voas, J. (2017). DDoS in the IoT: Mirai and other botnets. Computer, 50(7), 80–84. DOI 10.1109/MC.2017.201. [Google Scholar] [CrossRef]
2. Ubale, T., Jain, A. K. (2020). Survey on DDoS attack techniques and solutions in software-Defined network. In: Gupta, B. B., Perez, G. M., Agrawal, D. P., Gupta, D. (Eds.Handbook of computer networks and cyber security: Principles and paradigms, pp. 389–419. Cham: Springer International Publishing. [Google Scholar]
3. Kang, M. S., Lee, S. B., Gligor, V. D. (2013). The crossfire attack 2013. IEEE Symposium on Security and Privacy, Berkeley, CA, USA. [Google Scholar]
4. Aydeger, A., Saputro, N., Akkaya, K. (2019). A moving target defense and network forensics framework for ISP networks using SDN and NFV. Future Generation Computer Systems, 94, 496–509. DOI 10.1016/j.future.2018.11.045. [Google Scholar] [CrossRef]
5. Xie, L., Ding, Y., Yang, H., Hu, Z. (2020). Mitigating LFA through segment rerouting in IoT environment with traceroute flow abnormality detection. Journal of Network and Computer Applications, 164, 102690. DOI 10.1016/j.jnca.2020.102690. [Google Scholar] [CrossRef]
6. Rafique, W., He, X., Liu, Z., Sun, Y., Dou, W. (2019). CFADefense: A security solution to detect and mitigate crossfire attacks in software-defined IoT-edge infrastructure. 2019 IEEE 21st International Conference on High Performance Computing and Communications; IEEE 17th International Conference on Smart City; IEEE 5th International Conference on Data Science and Systems (HPCC/SmartCity/DSS), Zhangjiajie, China. [Google Scholar]
7. Wang, J., Wen, R., Li, J., Yan, F., Zhao, B. et al. (2019). Detecting and mitigating target link-flooding attacks using SDN. IEEE Transactions on Dependable and Secure Computing, 16(6), 944–956. DOI 10.1109/TDSC.8858. [Google Scholar] [CrossRef]
8. Narayanadoss, A. R., Truong-Huu, T., Mohan, P. M., Gurusamy, M. (2019). Crossfire attack detection using deep learning in software defined ITS networks. 2019 IEEE 89th Vehicular Technology Conference (VTC2019-Spring), Kuala Lumpur, Malaysia. [Google Scholar]
9. Narten, T., Draves, R., Krishnan, S. (2007). Privacy extensions for stateless address autoconfiguration in IPv6 (No. rfc4941). [Google Scholar]
10. Xing, J., Yang, M., Zhou, H., Wu, C., Ruan, W. (2019). Hiding and trapping: A deceptive approach for defending against network reconnaissance with software-defined network. 2019 IEEE 38th International Performance Computing and Communications Conference (IPCCC), London, UK. [Google Scholar]
11. Perkins, C. (2010). IP mobility support for IPv4, revised (No. rfc5944). [Google Scholar]
12. Perkins, C., Johnson, D., Arkko, J. (2011). Mobility support in IPv6 (No. rfc6275). [Google Scholar]
13. Hamad, S. A., Sheng, Q. Z., Zhang, W. E., Nepal, S. (2020). Realizing an internet of secure things: A survey on issues and enabling technologies. IEEE Communications Surveys Tutorials, 22(2), 1372–1391. [Google Scholar]
14. Firefox (2020). Percentage of web pages loaded by firefox using HTTPS. https://letsencrypt.org/stats/. [Google Scholar]
15. Ma, Y., Yan, L., Huang, X., Ma, M., Li, D. (2020). DTLShps: SDN-based DTLS handshake protocol simplification for IoT. IEEE Internet of Things Journal, 7(4), 3349–3362. [Google Scholar]
16. Jiang, F., Tseng, H. W. (2019). Trust model for wireless network security based on the edge computing. Microsystem Technologies, 27(4), 1627–1632. [Google Scholar]
17. Kanchana Devi, V., Ganesan, R. (2019). Trust-based selfish node detection mechanism using beta distribution in wireless sensor network. Journal of ICT Research and Applications, 13(1), 79–92. [Google Scholar]
18. Singh, P., Gill, N. S. (2020). Self-observation and recommendation based trust model with defense scheme for wireless ad hoc network. Journal of High Speed Networks, 26(1), 41–54. [Google Scholar]
19. Jain, S., Kumar, A., Mandal, S., Ong, J., Poutievski, L. et al. (2013). B4: Experience with a globally-deployed software defined WAN. ACM SIGCOMM Computer Communication Review, 43(4), 3–14. [Google Scholar]
20. Wu, X., Huang, J., Ling, J., Shu, L. (2019). BLTM: Beta and LQI based trust model for wireless sensor networks. IEEE Access, 7, 43679–43690. [Google Scholar]
21. JÃşang, A., Ismail, R. (2002). The beta reputation system. Proceedings of the 15th Bled Electronic Commerce Conference, Bled, Slovenia. [Google Scholar]
22. Mui, L., Mohtashemi, M., Halberstadt, A. (2002). A computational model of trust and reputation. Proceedings of the 35th Annual Hawaii International Conference on System Sciences, Big Island, HI, USA. [Google Scholar]
23. Wang, W., Zeng, G. S. (2007). Trusted dynamic level scheduling based on Bayes trust model. Science in China Series F: Information Sciences, 50(3), 456–469. [Google Scholar]
24. Park, J., Kwon, H., Kang, N. (2017). IoT–cloud collaboration to establish a secure connection for lightweight devices. Wireless Networks, 23(3), 681–692. DOI 10.1007/s11276-015-1182-y. [Google Scholar] [CrossRef]
25. Park, J., Kang, N. (2014). Lightweight secure communication for CoAP-enabled internet of things using delegated DTLS handshake. 2014 International Conference on Information and Communication Technology Convergence (ICTC), Busan, Korea (South). [Google Scholar]
26. Hummen, R., Shafagh, H., Raza, S., Voig, T., Wehrle, K. (2014). Delegation-based authentication and authorization for the IP-based Internet of Things. 2014 Eleventh Annual IEEE International Conference on Sensing, Communication, and Networking (SECON), Singapore. [Google Scholar]
27. Park, S., Park, H., Lee, J., Kent, S. (2009). Traceable anonymous certificate. Request for Comments (RFC), 5636. [Google Scholar]
28. Liu, H., Cui, L., Yao, T., Li, R. (2019). A personalized recommendation method based on collaborative filtering algorithm. International Journal of Business and Economics Research, 8(5), 297–302. DOI 10.11648/j.ijber.20190805.16. [Google Scholar] [CrossRef]
29. Averell, L., Heathcote, A. (2011). The form of the forgetting curve and the fate of memories. Journal of Mathematical Psychology, 55(1), 25–35. DOI 10.1016/j.jmp.2010.08.009. [Google Scholar] [CrossRef]
30. Kong, W., Li, X., Hou, L., Li, Y. (2020). An efficient and credible multi-source trust fusion mechanism based on time decay for edge computing. Electronics, 9, 502. DOI 10.3390/electronics9030502. [Google Scholar] [CrossRef]
31. Studer, A., Perrig, A. (2009). The coremelt attack. In: Backes, M., Ning, P. (Eds.Computer security–ESORICS 2009, Berlin, Heidelberg: Springer Berlin Heidelberg. [Google Scholar]
32. Cormen, T. H., Leiserson, C. E., Rivest, R. L., Stein, C. (2009). Introduction to algorithms (3rd edition). Cambridge, MA, USA: MIT Press. [Google Scholar]
33. Botta, A., Dainotti, A., Pescapè, A. (2012). A tool for the generation of realistic network workload for emerging networking scenarios. Computer Networks, 56(15), 3531–3547. DOI 10.1016/j.comnet.2012.02.019. [Google Scholar] [CrossRef]
34. Al Farooq, A., Moyer, T., Ahmed, D. T. (2021). OPD: Network packet distribution after achieving equilibrium to mitigate DDOS attack. 2021 IEEE 45th Annual Computers, Software, and Applications Conference (COMPSAC), Madrid, Spain. [Google Scholar]
35. Parmar, P. V., Kumbharana, C. (2015). Comparing linear search and binary search algorithmsto search an element from a linear list implementedthrough static array, dynamic array and linked list. International Journal of Computer Applications, 121(3), 13–17. [Google Scholar]
36. Shneiderman, B. (1978). Jump searching: A fast sequential search technique. Communications of the ACM, 21(10), 831–834. DOI 10.1145/359619.359623. [Google Scholar] [CrossRef]
Cite This Article
This work is licensed under a Creative Commons Attribution 4.0 International License , which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.