Attack-Aware Security Function Chaining

Abstract

Cyberattacks have become more frequent and more violent in recent years. To date, defensive infrastructure has been relatively static, and security functions are usually placed in a common order that does not depend on the current situation. We propose the concept of attack-aware Security Service Function Chain reordering. The idea is to change the order of security functions depending on the malicious traffic observed. We present the basic idea, evaluate the impact of the function chain order, and introduce a framework for function chain reordering. Our evaluation shows that the order often has a significant impact on the performance of the security function chain and that there is no single order that outperforms all other orders in every situation. The proposed proof-of-concept framework successfully validates the feasibility of attack-aware security function chain reordering, and we propose additional extensions to eliminate the remaining deficiencies.

1. Introduction

In recent years, cybersecurity has become a public concern. The FBI cybercrime report [1,2] shows a steadily growing number of reported losses. In the United States of America alone, losses increased by 25,773% from USD 485,000,000 in 2011 to USD 12,500,000,000 in 2024. Similar reports from Germany’s Federal Information Security Office [3] and the British Department for Digital Culture, Media, and Sport [4] confirm this to be a global issue. This growth in the damage that cyberattacks cause correlates with their increase in strength and versatility. Therefore, cybersecurity has become a dominant issue for both companies and personal life.

Today, most IT services run within cloud environments. Complex security architectures protect these environments from attacks. Incoming traffic inspection is very computationally intensive, and the employed computing resources are not available for regular cloud operation. In the past, security systems have kept up with their adversaries through advances in microtechnology. However, with the decline of Moore’s law [5]—the number of transistors doubling every two years—and especially the expectation that performance will follow the same law, this approach is coming to an end.

On the other hand, the number of Internet of Things (IoT) devices is growing at an exponential rate [6]. Many of these devices lack security features, and sophisticated update policies are rare. These deficiencies make IoT devices an easy target for cybercriminals looking to take control of these devices and use them as parts of their botnets to attack online services [7]

The growing importance of cybersecurity, coupled with the diminishing ability to counter threats by regularly replacing hardware, motivates the search for more efficient uses of available resources. A major inspiration for this work and the accompanying publications is a position paper by Cloud Security Alliance (CSA) [8] envisioning a security framework that optimizes the use of security functions by converting them into Virtualized Network Functions (VNFs) and combining them with Software-defined Networking (SDN). SDN allows for a simple reconfiguration of networks using dynamic flows instead of static switching and routing rules, and Network Function Virtualization (NFV) transforms network functions into software that can be run on general-purpose hardware. In this work, we develop several of the functionalities envisioned in this white paper.

Security functions that protect against attacks add additional complexity for network architects. Unlike “normal” network functions, security network functions do not just process packets and forward them; they add the complexity of dropping packets considered malicious. Furthermore, setting security functions at a very high load level often creates the undesirable behavior of increasing the number of false positives.

Security network functions often defend only against one or a few selected attacks. No single function can defend against all possible attacks. Thus, especially when chaining multiple network security functions behind each other in so-called Security Service Function Chains (SSFCs), the dropping property creates a new level of complexity. While changing the order of non-security-related network functions does not impact the performance of the functions at the back of the chain, for security functions, every packet filtered out at the beginning reduces the load on the following security functions. As described in the previously mentioned reports, recent cyberattacks regularly change their composition and the attack vectors used. Therefore, it is virtually impossible for network designers to predict, at design time, what the attack composition will look like throughout the lifetime of a security architecture.

In general, we see a lack of mutual adaptation between single security functions, SSFCs, and the interconnecting network infrastructure. SSFCs—like non-security-related function chains—uses a fixed order created at the design time. Depending on the attack or attack mix that occurs, malicious packets may proceed through many security functions that have to process them but do not defend against their attack type. This detour creates unnecessary resource demands. Network infrastructure that adapts to events and is aware of the behavior of deployed security functions could alleviate this problem.

SSFCs design is mainly static, and SSFCs does not adapt to the surrounding circumstances and the incoming traffic mix. As we show in this paper, there is no single optimal static order for every situation. Thus, adapting to the situation and dynamic reordering can improve performance and reduce resource demands.

1.1. Research Questions

In this work, our aim is to answer the following research questions:

RQ 1: 

To what extent can we improve security systems by introducing dynamic function chain reordering?

RQ 1.1 

What components and capabilities define an Security Service Function Chaining (SSFCing) framework?

RQ 1.2 

How do single security functions perform under attack load?

RQ 1.3 

What is the impact of ordering when combining different security service functions?

RQ 1.4 

How can single security functions be modeled for the reordering decision?

RQ 1.5 

How can security function chains be modeled for the reordering decision?

RQ 1.6 

What strategies are suitable for determining a better order?

RQ 2: 

How can a framework for dynamic SSFC reordering be defined?

RQ 2.1 

How should a framework for dynamic function chain reordering be structured?

RQ 2.2 

What results does a prototype implementation provide?

RQ 2.3 

Do new attack vectors and other issues arise from dynamic function chain reordering—and if yes, how can these issues be addressed?

1.2. Contributions

1.2.1. Performance Modeling for Security Service Function Chain Orders

This contribution concerns RQ1. First, we introduce the general idea behind attack-aware security function chaining. This idea constitutes placing security functions that defend against an occurring attack early in the SSFC to have them drop malicious packets and stop them from creating resource demands in security functions later in the chain. We conclude that for this approach to work, we need a central instance, the so-called Function-Chaining Controller (FCC), that takes care of the security function’s ordering. This controller requires knowledge about the traffic that passes through the security functions and the number of attacks detected. To this end, security function wrappers colocated with the security functions report the number of detected attacks at the specific function to the FCC. We introduced the vision of this approach in [9,10].

We conduct a performance analysis to analyze the effect of different SSFC orders. First, we measure the performance of single security functions and show that they have different behaviors and performance characteristics under benign and malicious workloads. For this paper, we limit our analysis to firewalls and DDoS Protection System (DPS) and Intrusion Detection and Prevention System (IDPS) functions. For attacks we use UPD, HTTP, SYN, and intrusion floods. When combining the security functions of size two in SSFCs, we note that the performance is best when the function that defends against the current attack is put first. The performance difference between different orders is up to two orders of magnitude. For different attacks, we show orders that contradict each other. Thus, no optimal static order exists. We previously published selected results in [11].

Based on these experiences, we create models for single security functions and security function chains. We model the traffic, categorizing it into traffic classes, and map the traffic to constant resource demands per traffic unit (frame, packet, or segment), as well as dynamic demands depending on the size of the traffic unit. Every security function affects traffic as a function depending on the composition of the traffic. The model for an SSFC consists of multiple security function models. Traffic that exits under one function continues to the next. Thus, it is possible to compute the total resource demand. Finally, we discuss three approaches with different levels of accuracy and varying computational complexity for the decision-making process based on this model. We presented the first iteration of the idea for this model in [9].

1.2.2. A Framework for Attack-Aware Security Service Function Chain Reordering

In this contribution, we address RQ2. We introduce a framework for attack-aware dynamic SSFC reordering that builds on the knowledge from the previous sections. All security functions of an SSFC reside inside an SDN-enabled network. A security function wrapper centrally located within every security function reports attacks to the FCC. Then, the FCC computes the desired order for the security functions and executes it via the SDN controller. We presented the communication design of the framework in [12].

We then developed a Proof-of-Concept (PoC) implementation using a simplified decision-making algorithm (putting the function with the most registered attacks first) and a minimal SDN controller tailored to our infrastructure. We put this framework through simulated attack patterns, showing that it correctly adapts to all attacks and restores the initial state afterward. This result demonstrates the desired functionality. However, we see rare issues, where a single packet can jump over a security function during reordering and propose four possible solutions to this problem. We published our experiences in [10].

Our contributions can assist security infrastructure architects in increasing their systems’ performance without adding additional computing resources. Security function developers can test their functions in our evaluation environment for SSFCs and, thereby, evaluate how they interact with other security functions and if they pose a possible bottleneck. Finally, researchers can use our results as a reference to refine modeling and decision-making strategies and expand on our SSFC reordering framework.

1.3. Outline

The remainder of this work is structured as follows. After this introductory chapter (Section 1), we introduce the relevant foundations of our research in Section 2. We discuss the current state-of-the-art in Section 3.

Then, we discuss the general idea of dynamic SSFC reordering in Section 4, the performance impact of the order inside an SSFCs in Section 5, and how to model an SSFCs in Section 6. Based on these findings, we present our SSFC reordering framework in Section 7. Finally, we conclude this work and provide an outlook on future work in Section 8.

2. Foundations

2.1. Relevant Types of Attacks

There is a seemingly infinite number of different attacks. In the following, we describe three common types of attacks that we also later use when evaluating our approach with the aim of achieving more performant security. First, we introduce the SYN flood and Hypertext Transfer Protocol (HTTP) flood DDoS attacks, then describe intrusion attacks.

2.1.1. SYN Flood

The SYN flood attack is currently the most common Distributed Denial of Service (DDoS) attack [13]. It attacks a Transmission Control Protocol (TCP)’s connection establishment process.

Attacker Model: First, the attacker model describes the circumstances under which it is possible to launch an SYN flooding DDoS attack. In general, an attacker operates using remote connections and, hence, does not require physical access to the targeted machine. The attacker’s goal is to disrupt service and render it unavailable to legitimate requests. In general, an attacker requires little knowledge about the attacked service. An attacker has usually obtained control over several machines and can use multiple endpoints to amplify his attack.

Threat Model: This type of attack exploits the connection-based behavior of the TCP protocol by creating a multitude of semi-established connections, rendering the target host unable to accept any new, benign connections. The final part of the three-way handshake, the TCP ACK (Acknowledgment) packet (ACK), is omitted by the attacker. This omission leaves the connection in a valid but unfinished state. This attack exploits the fact that the TCP protocol stores currently opened connections in a so-called Transmission Control Blocks (TCBs). The TCB backlog has a limited capacity. Eventually, an attacker can fill the TCB backlog with malicious, half-established connections, making the server drop new SYN requests instead of creating new connections.

Mitigation: Another entity has to take over the connection establishment process to mitigate SYN flood attacks. Section 2.2.2 describes two conventional approaches, namely the use of SYN cookies and SYNPROXY.

2.1.2. HTTP Floods

The HTTP flood attack works on the application layer (layer 7 in the Open Systems Interconnection (OSI) model). The attack aims to overwhelm a targeted service with HTTP requests.

Attacker Model: The attacker model shares similarities with the SYN flood attack. However, in contrast, the attacker requires more knowledge about the attacked service. He needs to know how to structure HTTP requests to the service. Thus, the attack requires knowledge of the arguments for website access or parameters of Representational State Transfer (REST) interfaces.

Threat Model: The attacker sends as many HTTP requests as possible to the attacked service. For this attack, the botnet sends multiple requests to either send form data or redeem images, files, or other data provided by the targeted server. By saturating the target’s maximum throughput, the attacker forces the target to drop additional requests from legitimate traffic sources.

Mitigation: Mitigating application-layer attacks is rather complicated. One method is to implement a challenge to the requesting machine to test for bots, e.g., a captcha if automated connections are entirely undesirable. For automated connections, challenges like JavaScript computational tasks for the attacker slow down the attack frequency. The use of a Web Application Firewall (WAF) is another alternative.

2.1.3. Intrusion

While the previous attacks rely on having control over a botnet or similar infrastructure, intrusions do not require this ability. Instead, single packets or requests trigger a vulnerability.

Attacker Model: Again, intrusions like the described DDoS attacks are remote attacks. The attacker must know what service he is attacking. The attacker also requires knowledge about an existing vulnerability for the Web server in its specific version.

Threat Model: With his knowledge, the attacker sends a request or a series of requests to the service. These packets then trigger an effect that is not desired by the service provider.

Mitigation: The obvious way to mitigate intrusion attacks is to patch the software so that the vulnerability is eliminated. However, in some scenarios, patching is, unfortunately, not an option. Thus, it is necessary to prevent harmful packages from reaching the service. Intrusion Detection Systems (IDS) can perform this task.

2.2. State-of-the-Art Security Appliances

A variety of security appliances protect against the attacks described in Section 2.1, among many others. State-of-the-art security systems comprise a great selection of these appliances in various combinations. The following sections introduce Intrusion Detection Systems (IDS) (Section 2.2.1), DDoS protection systems against the SYN flood attack (Section 2.2.2), and firewalls (Section 2.2.3).

2.2.1. Intrusion Detection and Prevention System

Intrusion Detection and Prevention Systems (IDPS) combine IDS and Intrusion Prevention Systems (IPS). IDS can detect attacks [14], and many IDS provide additional defense mechanisms. IPS are capable of actively defending against incoming attacks, and many IPS are deployable in a detection-only mode.

IDS can detect attacks originating from outside the protected system, as well as local attacks. Therefore, different monitoring platforms allow for the classification of IDS into network-based, host-based, and hybrid IDS.

The next distinction relies on the used attack detection methods. Misuse-based approaches primarily target singular attacks that are usually carried out in a single step [15], exploiting a selected vulnerability. Here, an IDS uses signatures containing features of an attack for its detection. Anomaly-based solutions use training techniques to detect when a system diverges from its normal behavior, which allows for the detection of multi-phase attacks.

Real-time or event-based IDS intercept an activity before it reaches the target system, inspecting it synchronously to the traffic flow. Polling IDS do not interrupt the traffic flow but analyze the target activity periodically and are asynchronous.

Non-distributed IDS are deployable at a singular (central) position inside the system. An alternative is to use a distributed IDS that is spread all over the system, allowing for detection of interconnected attacks on multiple non-collocated targets.

In this work, we focus on network-based, misused-based, non-distributed, and real-time IDS.

2.2.2. SYN Flood Protection

In the following, we describe two of the most popular mechanisms to mitigate DDoS attacks, namely SYN cookies and SYNPROXY. Being readily available for services running on top of the mainline Linux Kernel makes both of these solutions widely used.

SYN Cookies

As mentioned in the description of the threat model, an SYN flooding attack exploits the size limitation of the TCP backlog as a critical resource for establishing new connections. SYN cookies [16] are a fully TCP standard-compliant way of eliminating the need for backlog entries related to half-open connections. In a usual scenario, the backlog stores source and destination addresses, as well as ports, the client’s Initial Sequence Number (ISN), the server’s ISN, and the requested TCP options for half-open connections. The idea of SYN cookies is to not store this information not but encode it into the sent TCP SYN+ACK (Synchronization and Acknowledgment) Packet (SYN+ACK) packet and retrieve the information from the ACK response. For this mechanism to work, the SYN cookies’ functionality must run on the same machine as the protected service. Due to this limitation, SYN cookies are not scalable independent of the service itself.

SYNPROXY

The second presented solution to mitigate TCP SYN floods is SYNPROXY, a Netfilter module [17]. SYNPROXY utilizes this functionality to prevent SYN packets from directly reaching the networking stack, where they would trigger TCB allocation and an SYN+ACK response. It sends a manually crafted SYN+ACK packet as if the SYN were legitimately handled by the network stack, thereby masking the connection establishment from the kernel. Similarly to the previously presented SYN cookies, SYNPROXY stores the connection state in the packet itself instead of in local memory. Upon arrival of an ACK packet, SYNPROXY checks if the packet belongs to a valid handshake. If this is the case, from the client perspective, the connection establishment seems to have successfully concluded. The server, on the other hand, does not yet know that a connection was requested. Therefore, the SYNPROXY module has to impersonate the client and execute a handshake with the server. Thereby, it opens the connection in the client’s stead. While both ends of the connection now known, they cannot directly communicate with each other because the ISN chosen by SYNPROXY differs from the one the server chooses in the second handshake.

SYNPROXY allows for either co-deployment with the protected application or deployment on a separate machine. When opting for co-deployment, SYNPROXY suffers from the same shortcomings as SYN cookies, namely the inability to scale the mechanism independently of the service. Additionally, unlike SYN cookies, the application is stateful. When deploying SYNPROXY on a separate machine, all traffic between the client and the server must pass through the proxy.

2.2.3. Firewalls

Oppliger [18] defines firewalls as “intermediate system[s] […] plugged between the network and the Internet to establish a controlled link, and to erect an outer security wall or perimeter. The aim of this perimeter is to protect the network from network-based threats and attacks, and to provide a single choke point where security and audit can be imposed”. The use of network firewalls lies in the idea of moving security away from a single host and the running applications to dedicated and more manageable entities. Such network firewalls can work on multiple protocol layers.

2.3. Architecture of Current Security Systems

Figure 1 shows infrastructure with multiple services. The firewall symbol represents security appliances, and different colors determine different appliance types. Some security appliances are usable by multiple services (e.g., the first appliances in the depicted chain). The decision as to how many services a single appliance can handle depends on the performance properties of the appliance. When designing an architecture, architects derive these values from datasheets. When extending existing architectures, the number of services per appliance often grows in a trial-and-error pattern until the security appliance becomes a bottleneck. In this case, it is possible to augment the throughput of the exhausted appliance type by adding further instances (in many cases, by adding a second physical device in a rack). Figure 1 shows this approach with the second appliance for the top and middle service (both Web servers). In many cases, services cannot share all elements of the security infrastructure (as depicted for the third security appliance for the top Web server, the proxy server for the central Web server, and the second security appliance for the mail server).

We call these chains of security appliances (or security functions) SSFCs [19]. An SSFC defines the number and order of security appliances in the chain.

With the introduction of SDN, security appliances no longer require a direct interconnection. Instead, SDN-enabled networks can reroute traffic to any security appliance instance, including remote instances in other computing centers or even in the cloud following the idea of Security as a Service (SECaaS).

Combined with the concurrent introduction of NFV, security appliances no longer need to be specialized hardware components; instead, generic computing hardware can provide these capabilities. With the virtualization of resources, this allows for the quick scaling of security architectures to meet rising resource demands by adding additional instances when needed. Since most attack patterns are unpredictable, reactive autoscalers allow for adaptations when attacks occur. However, the architectures do not yet adapt to the order of the used security appliances.

3. Related Work

Many works focus on characterizing the performance of security functions like IDS [20,21]. In addition, they deal with the behavior mentioned under overload conditions [22]. However, these works rarely describe approaches to alleviate the identified shortcomings and focus solely on the security functions themselves without considering the surrounding network.

For DDoS protection, more works consider the surrounding infrastructure. For example, they use stateful SDN to monitor traffic using simple state machines on switches to detect DDoS attacks. Other works aim to protect against saturation of the connection between the data plane and the control plane [23]. Two approaches provide protection against TCP floods. However, they either inherit the shortcomings of existing solutions [24] or provide insufficient evaluation and no code to reproduce their results [25]. In general, these works aim to replace existing security functions by SDN and not to augment them using SDN.

Two categories of works tackle the topic of SDN and security. On the one hand, the first category deals with security for SDN. Therefore, they analyze SDN’s security challenges in general [26,27] and for specific network operating systems [28]. The second category, on the other hand, uses SDN to enhance security. Therefore, they propose multiple solutions to integrate IDS in SDN-enabled networks [29], create blocking and diversion rules based on alerts from security functions [30], or use SDN to replace dedicated security functions [31]. However, these works do not focus on improving the security functions performance-wise.

A considerable amount of research targets the NFV domain. Works deal with the following1. NFV frameworks [32], 2. methods to benchmark NFV frameworks and VNFs [33], 3. the possibility of combining NFV with SDN [34], or 4. implementations of network functions as VNFs [35]. Further works focus on the general concept of Service Function Chains (SFCs) and dynamic service chaining [36,37]. However, they do not consider the special properties of security functions. Works that analyze challenges explicitly state the intelligent positioning of (security) functions within a function chain as an open problem [38].

A major inspiration for our work is the CSA’s “Security Position Paper: Network Function Virtualization” [8]. The authors define multiple work packages and challenges for NFV-enabled security architectures. This work addresses multiple of their mentioned goals.

In summary, existing work leaves the intelligent placement of security functions inside SFCs and performance-oriented cooperation between security functions and SDN open. Consequently, we require novel approaches and solutions to these problems.

4. Approach

As described in Section 2.3, different services have different sets of security functions that protect them against attacks from external networks. Figure 2 shows an example with three different security functions forming an SSFC. In most current security architectures, such an SSFC is hard-wired or—if using SDN for interconnection—interconnected using a fixed order.

We make the following four assumptions:

• A security function can defend against precisely one class of attacks.
• The attack classes associated with different security functions are mutually exclusive.
• Security functions drop packets deemed malicious.
• Traffic, whether benign or malicious, passing through a security function creates a resource demand.

Figure 3 presents multiple configurations of the setup from Figure 2 under different types of load. Figure 3a shows the setup under standard load without an attack occurring. In this scenario, the SSFC order is not relevant. All packets are benign and, therefore, have to pass through all security functions in the SSFC. Reordering the functions would not change the resource demand generated by benign packets.

In Figure 3b, an attack originates from external networks. The attack corresponds to the attack class against which the blue security function defends. With the initial configuration, the traffic passes through all security functions in the SSFC. Thus, it creates resource demands at every step until the last security function stops it. This order would require scaling of the white and red security functions, as well as the blue security function, to handle the load. Changing the order of the red and white security functions would not affect the resource demands, since all traffic would still pass through both security functions.

In Figure 3c, the blue security function moves up to the middle of the SSFC. Thus, attacks belonging to the blue attack class must only pass through the white security function until the blue security function discards them. Therefore, malicious traffic creates resource demands in the white and blue security functions but not in the red function. If scaling is necessary, it only applies to the white and blue security functions. Switching the red and white security functions can have an impact on the total resource demand. If one of the two security functions has a higher resource demand per processed packet, placing this function at the back of the SSFC would reduce the total resource demand compared to the reversed SSFC order.

Finally, in Figure 3d, the blue security function is in front of the SSFC. This SSFC order leads to the first security function dropping all malicious traffic immediately. Thus, traffic does not pass on to the white and red security functions and only creates resource demands at the blue security function. Therefore, potential scaling as a reaction to the attack is only necessary for the blue security function. The ordering of the white and red security functions is not relevant for the total resource demand, since malicious traffic does not reach these two security functions, and all benign traffic passes through both security functions.

We calculate the resource demand of the six possible permutations of the example SSFC to illustrate the impact of the SSFC order. We assume three example security functions. An instance of the red security function can handle 100 MBit/s, one instance of the white security function can handle 200 MBit/s, and one instance of the blue security function can handle 150 MBit/s. As a sample workload, we assume 50 MBit/s of benign traffic and 950 MBit/s of malicious traffic. We calculate the load relative to one instance of each security function, the number of instances per security function, and the total number of required instances.

Table 1. Example calculation of the resource demands (in instances) for different SSFC orders. Throughput per instance: red, 100 MBit/s; blue, 150 MBit/s; white, 200 MBits/s. The load profile is 950 MBit/s of malicious traffic matching the blue security function and 50 MBit/s of benign traffic.

Ordering	Red		White		Blue		Total
	Rel. Load	No. of Inst.	Rel. Load	No. of Inst.	Rel. Load	No. of Inst.	No. of Inst.
red–white–blue	1000%	10	500%	5	667%	7	22
red–blue–white	1000%	10	667%	7	25%	1	18
white–red–blue	500%	5	1000%	10	667%	7	22
white–blue–red	500%	5	667%	7	50%	1	13
blue–red–white	667%	7	50%	1	25%	1	9
blue–white–red	667%	7	25%	1	50%	1	9

shows the computed results. The results for the example show that optimal configurations (in this case, two exist) can reduce the total number of required instances from 22 to 9 or by 59%. The results also confirm our previous statements regarding the order of the security functions that do not defend against the occurring attack.

In practice, attacks are increasingly occurring in conjunction with other attacks. DDoS attacks frequently serve as so-called smokescreen attacks to hide other attacks, such as intrusions. Thus, in many cases, malicious traffic comprises a mix of attacks. To assert the optimal SSFC order for such a mix again requires a computation like in Table 1. A significant difference for attack mixes is that the order of all security functions in the SSFC becomes essential. Unlike in the previous example, only one optimal configuration remains.

Function-Chaining Controller: The gathering of the required information to approximate the traffic composition, the modeling, and decision for the ordering of the SSFC, as well as the enforcement of the desired ordering, requires an entity taking up these responsibilities. We call this entity the Function-Chaining Controller (FCC).

Figure 4 shows a coarse description of the FCC’s operation. The FCC connects to the security functions and the service host to access their performance statistics. Based on this information, the FCC decides whether a reconfiguration is beneficial. At first, no attack occurs. Therefore, no reconfiguration is necessary. Once an attack occurs, the FCC deducts the composition of malicious traffic from the available information. Based on this composition, the FCC computes the optimal order for the SSFC. The FCC then enforces that ordering. Once the reordering completes, the FCC continues monitoring the traffic. Every time the approximate composition of the malicious traffic changes, the FCC computes whether another reconfiguration is necessary or not.

We design the FCC as a self-aware system. Thus, it implements the self-aware LRA-M (Learn, Reason, Act—Model) loop [39]. Its state and phenomena (e.g., data about the security functions’ states) comprise empirical observations. The FCC uses these observations to learn and reason in combination with a model to achieve its goal (highest throughput with the least amount of resources). Based on this reasoning, the FCC acts (enforcing a new order for the SSFC).

5. Effect of the Security Service Function Chain Order

We claim that the order of the security functions inside the SSFC influences its performance. In this section, we evaluate the security functions and SSFCs with different security function orders to assert our claim. First, in Section 5.1, we present the evaluation environment used in this study. We then measure the performance of three different security functions in benign and malicious traffic in a standalone deployment in Section 5.2. The measured security functions are a firewall, a DPS, and an IDS. In Section 5.3, we put these security functions in an SSFCs consisting of two such functions and vary their order. Finally, in Section 5.4, we discuss the results and conclusions that we must consider for modeling and decision making in Section 6 and incorporate them into the reordering framework in Section 7.

5.1. Evaluation Environment

We designed a testbed that can incorporate benign and malicious workloads to evaluate the performance of security functions, using single security functions and composite SSFCs with modifiable security function orders and different server applications. Figure 5 shows the architecture of that testbed.

5.1.1. Hardware Components

We use a total of six physical servers to incorporate this setup. These take the roles of 1. a client and attacker; 2. an application server (the protected application); 3. a DDoS Protection System (DPS); 4. a firewall; 5. an Intrusion Detection and Prevention System (IDPS); and 6. an SDN, experiment, and function chaining controller.

For all servers, we use an Intel Xeon E3-1230 V2 Central Processing Unit (CPU) at 3.30 GHz equipped with 16 GB RAM. The machines connect to a back-end network (for example, to download software packets) and the controller network (controlling experiments, gathering data) using a Broadcom 1 Gb/s controller. Additionally, all servers, except the controller, also connect to a 10 GBit/s network using Intel 10 GBit/s cards. Servers running pass-through applications like the IDPS and the firewall connect to this network using two ports. The client-and-attacker machine plays two roles and, therefore, also uses one link for each role.

Table 2. Hardware specifications for all servers inside the evaluation environment.

Unit	Value
Product	Dell PowerEdge R210 II
CPU	Intel Xeon E3-1230 v2
Default CPU frequency	3.30 GHz
Max CPU frequency	3.70 GHz
Min CPU frequency	1.60 GHz
Cores (Threads)	4 (8)
Cache (L1/L2/L3)	64 KB/256 KB/8192 KB
Memory size	16GB ($2 \times 8$  GB) DDR4
Memory frequency	1.600 GHz
Memory connection	Dual Channel
Storage dodel	HGST Ultrastar A7 K2000 500 GB@7200 rpm
Storage Connection	SATA II (3 GBit/s)
1st NIC	2 Port Broadcom Limited NetXtreme II
(Controller and Backend)	BCM5716 Gigabit Ethernet
2nd NIC	Intel X520
(Experiments)	10-Gigabit SFI/SFP+ Network Connection
Operating System	Ubuntu 18.04.3 LTS (x86-64)
Kernel	4.4.0-72

provides additional details on these machines.

Two standard, non-programmable 1 GBit/s HPE ProCurve 3500yl-24G switches provide the connectivity for the back-end and controller network. Four HPE 5130 24G 4SFP+ EI SDN switches span the network for experimentation data. Since these switches only have four 10 GBit/s network ports (numbers 25 through 28), we require four of them to interconnect all servers, as shown in Figure 5. The switches provide enough backplane switching capacity to ensure that this setup does not become a bottleneck. Figure 5 shows which cable connects to which 10 GBit/s port on the switches to facilitate the reproducibility of this setup All 1 GBit/s links use Cat 6a copper cables, and all 10GBit/s links use fiber-optic cables.

5.1.2. Software Components

Traffic Generator (Benign): On the first 10 GBit/s interface of the client-and-attacker server, we generate benign HTTP traffic. For this purpose, we use an HTTP load generator [40]. The HTTP load generator can generate HTTP loads. The HTTP load generator comprises the following two components: a director and a generator. The component director controls one or more generator components and directs when they send packets. The component generator performs the actual packet generation. We deploy the director component to the experimental controller host and the generator component to the client-and-attacker server.

Traffic Generator (Malicious): We use the second 10 GBit/s interface of the client-and-attacker server to create malicious packets. We create TCP SYN (Synchronization) packet (SYN), User Datagram Protocol (UDP), and IDS floods using Cisco’s Trex [41] generator. For the chosen attacks, we do not require stateful generation and, therefore, use only the stateless mode. Trex uses Data Plane Development Kit (DPDK) to create high-volume loads. DPDK binds the whole interface to the program. Therefore, benign HTTP traffic needs to use a different interface. To generate HTTP floods, we employ BoNeSi [42], a BotNet simulator. BoNeSi can create high-volume HTTP floods by emulating spoofed IP addresses.

Intrusion Detection and Prevention System: The IDPS host runs Snort IDPS version 2.9.7. Snort uses both 10 GBit/s interfaces—one for incoming traffic and one for outgoing traffic. For the measurements, we extended the standard Snort community signatures by several rules.

Firewall: Like IDPS, the firewall uses one interface for incoming traffic and one for outgoing traffic. We interconnect both interfaces using a Linux bridge, and Netfilter/iptables rules accomplish packet filtering.

DDoS Protection System (DPS): As a DPS, we use a modified version of TCP Handshake Remote Establishment and Dynamic Rerouting using Software-defined Networking (THREADS) [43] in a TCP handshake protection system that uses SDN to protect a service from SYN floods. It counters many shortcomings of SYN cookies and SYN-Proxy. THREADS comprises two components. A DPDK application attached to a single 10 GBit/s interface handles incoming packets. It forwards successful TCP handshakes to a Python application via a named pipe that generates the needed calls to the SDN controller. Successful TCP handshakes are forwarded to the service host directly via the SDN.

Protected Service: The target server runs TeaStore. “The TeaStore is a micro-service reference and test application to be used in benchmarks and tests. The TeaStore emulates a basic web store for automatically generated, tea and tea supplies. As it is primarily a test application, it features UI elements for database generation and service resetting, in addition to the store itself. The TeaStore is a distributed microservice application featuring five distinct services plus a registry. Each service may be replicated without limit and deployed on separate devices as desired. Services communicate using REST and using the Netflix Ribbon client-side load balancer. Each service also comes in a pre-instrumented variant that uses Kieker to provide detailed information about the TeaStore’s actions and behavior” [44].

SDN Controller: We use Ryu 4.15-0 as the SDN controller. Its ryu.app.ofctl_rest module provides a REST-based interface to deploy flows.

Monitoring and Metric Collection: The testbed measures and records the following metrics from various sources:

• CPU usage of each server in various states, i.e., user, iowait, softirq, system, etc.;
• Total number of sent benign HTTP requests;
• Number of successful benign HTTP requests;
• Average Internet Control Message Protocol (ICMP) latency between sender and receiver;
• ICMP packet loss between sender and receiver;
• Average TCP SYN latency;
• TCP SYN packet loss.

Telegraf’s [45] inputs.cpu plugin [46] collects CPU usage statistics and sends them to an InfluxDB [47] running on the experimental controller. It reports the usage of the CPU in various states, among which user, system, iowait, and softirq are of interest. We use Grafana [48] to visualize the gathered data. We used a moving average of 10 s to help interpret the data.

5.1.3. Deployment

We provide the configuration files for our setup for download at https://github.com/bladewing/SSFC_testbed, accessed on 17 August 2024. Since most people do not have the exact switching and benchmarking hardware like the one we use, we provide a fully virtualized environment to deploy our solution, where we replace the four hardware switches with a single Open vSwitch instance. To use the environment, a user must install Vagrant [49].

5.2. Single Security Function Performance

Before evaluating the impact of SSFC ordering on performance, it is necessary to evaluate the individual security functions. With this knowledge, we can then assert the impact of SSFCs ordering.

5.2.1. Benign Workloads

At first, it is necessary to build a baseline of how the security functions behave under a benign load. It is possible to make statements on the differences in behavior under attack using that information.

Baseline without a Security Function

We require a baseline that establishes a realistic maximum performance that is attainable by the service host. To this end, we query the service host with a varying benign load. Thereby, we determine the maximum amount of HTTP requests per second that the service can handle. Figure 6 visualizes the results for this experiment. The results show that the service scales linearly, and beginning at 16,000 requests per second, the number of successful requests stalls. There is even a small decrease in throughput afterward. This decrease is probably attributable to, e.g., queuing, swapping, and context-switching effects. At that point, the target service has reached its limit. These results serve as a baseline for evaluation of how the appliances impact latency and data loss.

Firewall

The firewall has little effect on the number of successful requests. Again, the number grows linearly with the workload up to 16,000 requests per second, then stalls out and slowly drops when in overload. As

Table 3. Latency and packet loss for single security functions with a benign workload.

Chain	Average ICMP Response	Packet Loss	Average SYN Response	SYN Packet Loss
Direct	0.191 ms	0%	4.5 ms	0%
Firewall	0.343 ms	0%	3.8 ms	0%
DPS	0.194 ms	0%	4.7 ms	0%
IDPS	0.340 ms	0%	4.4 ms	0%

shows, the firewall has a small impact on the ICMP response.

DDoS Protection System (DPS)

The DPS has a significant effect on the number of successful requests. In the beginning, the number grows linearly. Nevertheless, the limit is reached at 3000 requests per second, then stalling out and dropping significantly when in overload. As Table 3 shows, the DPS has almost no impact on the ICMP response compared to the direct connection. The SYN response slightly increases.

Intrusion Detection and Prevention System (IDPS)

Lastly, the IDPS has a significant effect on the number of successful requests. Until its peak, the IDPS behaves similarly to the DPS. The IDPS reaches its limit at 3000 requests per second, then stalls out and drops significantly when in overload. As Table 3 shows, the IDPS has some impact on the ICMP response.

5.2.2. Malicious Workloads

Evaluating the performance of the service and the various security functions under benign workloads provides a reliable performance baseline for comparison with attack workload scenarios. In this section, we put the various functions under attack (attacks matching the function that defends against them) using malicious workloads and evaluate their performance.

Firewall (UDP Flood)

As a first benchmark for the firewall, we perform a UDP flood attack. The firewall rules block all received UDP traffic. To assert the Quality of Service (QoS) for the benign packets, we perform 2000 benign HTTP requests per second for one minute. We measure metrics—other than the throughput—at 500 MBit/s flood strength.

We visualize the results for the successful HTTP requests under the UDP flood shown in Figure 7a. Up until 500 MBit/s, both the direct and the protected system perform at peak efficiency. From thereon, for both systems, the number of successful requests drops. The firewall’s throughput drops faster than the unprotected system’s throughput. At the worst point, the firewall can only serve 3.6% of requests, and the unprotected system manages only 5.0%. For the other metrics, as seen in

Table 4. Latency and packet loss during various attacks with and without a single security function.

Attack	Chain	Average ICMP Response [ms]	Packet Loss [%]	Average SYN Response [ms]	SYN Packet Loss [%]
UDP Flood	Direct	0.679	0	4.2	0
UDP Flood	Firewall	0.229	0	4.2	0
HTTP Flood	Direct	0.154	0
HTTP Flood	Firewall	0.266	0
SYN Flood	Direct	0.108	0	3.9	0
SYN Flood	DPS	0.146	0	1.1	0
Intrusion Flood	Direct	3.973	0	8.5	0
Intrusion Flood	IDPS	35.000	32	39.0	11

, we observe that the SYN response is not affected by this protection. However, when using the firewall, the ICMP response is reduced by two-thirds.

Firewall (HTTP Flood)

The firewall blocks HTTP requests from malicious sources. We scale the HTTP flood attack in steps of 1000 requests per second up to 14,000 requests per second. Again, we perform 2000 benign HTTP requests per second for one minute to assert the performance for benign workloads. We measure metrics–other than the throughput–at a flood strength of 5000 requests per second.

Figure 7b shows the successful requests during the HTTP attack. The firewall-protected system always stays at peak efficiency. However, the unprotected system can hold this state only up to 1000 requests per second, then is no longer able to perform all requests. After a first steep drop at 2000 requests per second, the throughput continues to drop until it flattens out at 14.9% of handled requests from an attacking load of 10,000 requests per second and above. Table 4 shows that the firewall slightly increases the ICMP response time.

DDoS Protection System (DPS) (SYN Flood)

We perform an SYN flood attack. For each run, the amount of SYN packets is increased by 500 Mbit/s, up to 6500 Mbit/s. We generate a load of 2000 benign HTTP requests per second for one minute to evaluate the successful requests during an SYN flood. We measure metrics other than the successful requests under a 5 000 MBit/s attack load.

Figure 7c shows the throughput results with and without the DPS enabled. The unprotected service operates at peak efficiency for up to 2000 MBit/s, but from 2500 MBit/s on, it is no longer able to handle all benign requests. At 3000 MBit/s, the service drops to around 12.3% of successful requests. With the DPS enabled, full throughput is possible until 5500 MBit/s (2.75 times the load the direct service can handle). After that point, the number of successful requests drops. However, that drop is less steep than for the direct service, and even at 6500 MBit/s, the DPS-protected system still completes around 2.5 times as many requests as the unprotected system. Further stats presented in Table 4 show that the effect of the DPS is a slight increase in the ICMP response time. However, the SYN response is much faster with the DPS enabled than for the unprotected service (reduced by 71.8%).

Intrusion Detection and Prevention System (IDPS) (Intrusion Flood)

The last attack is an intrusion flood. We use UDP packets containing a signature that matches the IDPS rules. We perform the intrusion flood for up to 5000 MBit/s, scaling in steps of 500 MBit/s. We measure further metrics at an attacking load of 1000 MBit/s.

As seen in Figure 7d, both configurations keep peak efficiency only until 500 MBit/s. Afterward, for both configurations, the throughput drops significantly. The throughput drops faster for IDPS than for the unprotected system. For higher loads, both systems drop to 5%. Table 4 shows a massive increase of one order of magnitude for the ICMP response time when using the IDPS. The SYN response time quadruples. The packet loss rates also grow from 0% to 32% (ICMP) and 11% (SYN).

5.3. Security Service Function Chain Performance

After evaluating the single security functions in the previous section, we now proceed to combinations of security functions. Therefore, we use the same attacks as before and combine pairs of security functions for each attack and switch their ordering for comparison.

We measure the CPU load levels for the IDPS and the firewall. For concicesness, we summarize the load levels in the following four levels: low, medium, high, and overloaded. The low level indicates that the total load of the system is below 25%. Medium load means that the total load is between 25% and 80%. High load means that the total load is between 80% and 200%. Overloaded means that the total load is above 200%. The highest value from the user, system, and softirq modes decides the load level.

5.3.1. UDP Flood

The first attack to benchmark SSFC orders is the UDP flood attack. The device that protects against this attack is the firewall. Thus, we use the firewall rules from before to block all received UDP traffic. Again, we scale the UDP flood attack in steps of 500 MBit/s up to 5000 MBit/s. As before, we perform 2000 benign HTTP requests per second for one minute to assert the QoS for the benign packets. We measure metrics—other than the throughput—at 500 MBit/s flood strength.

We compare the following two SSFC orders: 1. IDPS$\to$Firewall, and 2. Firewall $\to$ IDPS. Figure 8a shows the performance of both SSFC orders. Without an attack, both SSFC orders can perform all requests. Already at only 500 MBit/s, the performance of the IDPS$\to$Firewall SSFC order drops by 98% to 2720 successful requests per second, while the Firewall$\to$IDPS SSFC order only loses 7%. From thereon, the performance of the IDPS-headed chain stays below 3500 requests per second. In contrast, the firewall-headed chain only loses performance step by step, and only at 4000 requests does it fall below the limit of the other SSFC order.

In general, the Firewall$\to$IDPS SSFC order at any load level has a higher rate of successful requests per second than the IDPS$\to$Firewall chain.

Table 5. Latency, packet loss and CPU load during different attacks with various SSFCs orders.

Attack	Chain	ICMP		SYN		CPU Load
		Response [ms]	Loss [%]	Response [ms]	Loss [%]	Firewall	IDPS
UDP Flood	IDPS$\to$Firewall	350	27	636	18	low	overload
UDP Flood	Firewall$\to$IDPS	0.355	0	4.4	0	medium	high
HTTP flood	Firewall$\to$IDPS	0.390	0			low	high
HTTP flood	IDPS$\to$Firewall	0.403	0			low	overload
SYN flood	DPS$\to$IDPS	0.285	0	0.9	0	-	low
SYN flood	IDPS$\to$DPS	223	26	233	36	-	overloaded
SYN flood	DPS$\to$Firewall	0.288	0	1.0	0	low	-
SYN flood	Firewall$\to$DPS	0.242	0	4.5	0	high	-
IDS flood	IDPS$\to$Firewall	36	30	37	34	low	overload
IDS flood	Firewall$\to$IDPS	16	0	17.9	0	medium	overload

confirms these findings of better performance when putting the firewall first. The IDPS$\to$Firewall SSFC order results in almost a thousandfold of the ICMP response time of the other chain and two orders of magnitude increase in the SYN response. This chain also creates massive packet loss compared to no loss for the firewall-headed SSFC order. Considering CPU load, the IDPS $\to$ Firewall order creates low load at the firewall but overloads the IDPS. Reversing this order creates a slightly higher medium load, while the load level of the IDPS is stabilized to a high level.

5.3.2. HTTP Flood

The second benchmark is an HTTP flood attack. We scale the attack in steps of 1000 requests per second up to 14,000 requests per second. Once more, we perform 2000 benign HTTP requests per second for one minute to assert the performance for benign workloads. As before, we measure metrics–other than the throughput–at 5000 requests per second flood strength.

We compare the same SSFC orders as for the UDP flood attack. Figure 8b presents the throughput results. As for the UDP flood, both SSFC orders handle the benign workload and a small attack load of 1000 requests per second well. At higher attack-load levels, the number of successful benign requests drops for the IDPS$\to$Firewall SSFC order. It continues to drop with higher load and, form 10,000 requests onward, settles above 20,000 successful requests. Meanwhile, the Firewall$\to$IDPS chain is hardly affected by the attack load, and remains close to the maximum attainable level, always staying significantly above the other order’s level.

Table 5 shows further metrics for the two orders. Unlike for the UDP flood, the IDPS$\to$Firewall SSFC order does not generate a massive increase in latency or packet loss. Thus, considering these values, the two SSFC orders perform similarly. Considering CPU load, the firewall remains at low load levels in both combinations, while the IDPS is in overload when placed first, which is reduced to high when reversing the order.

5.3.3. SYN Flood

As a third benchmark, we perform an SYN flood attack. For each run, we increase the SYN flood strength by 500 requests per second, up to 6500 requests per second. We generate a load of 2000 benign HTTP requests per second for one minute to evaluate the successful requests during an SYN flood. We measure metrics other than the successful requests at a 5000 requests per second attack load.

DPS ⟷ IDPS

Figure 9a visualizes the successful benign requests. Without an attack, both configurations work at peak performance. From 500 requests on, the results for the IDPS$\to$DPS chain drop and reach their minimum of around 4000 successful requests (a 97% drop) at only 1000 requests per second. For higher load levels, the results vary only slightly but neither improve nor deteriorate. In contrast, the DPS$\to$IDPS chain keeps up full throughput until 3500 requests per second. From thereon, the results slowly drop almost linearly. At the maximum load in our experiment, this chain still serves 76,719 requests or 62%.

When we look at the other metrics, as presented in Table 5, vast differences become visible. The IDPS $\to$ DPS SSFC order increases both response times by three orders of magnitude. It also introduces significant packet losses at 26% (ICMP) and 36% (SYN). These losses do not appear for the DPS$\to$IDPS SSFC order. While the IDPS is extremely overloaded when placed first, the reversed order only creates a small load for the IDPS.

DPS ⟷ Firewall

Figure 9b presents the number of successful requests for both SSFC orders. Both orders maintain an optimal success rate until 2000 requests per second. After that, the firewall-headed SSFC order slowly drops to around 100,000 successful requests at 3000 requests per second, then suddenly drops to below 40,000 successful requests at 3500 MBit/s. Then, again at 4000 requests per second, it slightly drops below 30,000 successful requests, where it stays until 5000 MBit/s. Then, it drops again to only 10,881 successful requests at 5500 requests per second. At 6000 requests per second, it further drops to 3688, then stays at a similar level. The DPS$\to$Firewall SSFC order continues at maximum performance until 3000 requests per second. Then, it continuously drops but stays significantly above the performance of the inverse chain to 44,803 successful requests at 6500 requests per second (14.7 times the result for the inverse SSFC order).

Table 5 shows further metrics for both orders. The results are a little more diverse than for the previous attacks and combinations. The Firewall$\to$DPS SSFC order offers a faster ICMP response, while the DPS$\to$Firewall SSFC order yields a faster SYN response. The relative difference for the SYN response is more substantial than for the ICMP response. Neither configuration produces any packet losses. Placing the defending DPS first reduces the otherwise high load of the firewall to a low level.

5.3.4. Intrusion Flood

The fourth and last attack is an intrusion flood. We perform the intrusion flood for up to 5000 MBit/s, scaling in steps of 500 MBit/s. We measure further metrics at an attacking load of 1000 MBit/s.

We compare the following two SSFC orders: 1. IDPS$\to$Firewall and 2. Firewall $\to$ IDPS. Figure 10 shows the number of successful requests for both chain orders. Both SSFC orders can fully handle the benign workload. However, already at a flood strength of 500 MBit/s, the Firewall$\to$IDPS chain drops to 31,732 successful requests. At 1000 MBit/s flood strength, this chain further drops to 7238 successful requests and, from there on, stays at similar or lower levels. The performance of the reverse chain drops later, starting at 1000 MBit/s with a drop to 43,442 MBit/s. Then, it continues to fall slowly and finally aligns with the throughput of firewall-headed chains at 4000 MBit/s. Between the beginning of attacks at 500 MBit/s and the alignment, the IDPS$\to$Firewall SSFC order outperforms the other chain.

Looking at the further metrics in Table 5 with the previous impressions in mind yields an unexpected result. In particular, the IDPS$\to$Firewall SSFC order doubles the response time compared to its counterpart. It also introduces a packet loss rate of about one-third of packets. This result is surprising, since the higher throughput of the IDPS-headed chain does not hint at this behavior. However, this shows that a way to obtain higher throughput might lie in accepting packet losses. For both orders, the IDPS is in an overloaded state. However, the load of the firewall is significantly reduced when putting the IDPS first.

5.4. Discussion

Section 5.2.1 shows that even under benign workloads, the different security functions perform with significant differences. Although the firewall can protect a service without reducing the throughput, the DPS and the IDPS reach their limits long before the protected service. In addition, both systems (the IDPS more than the DPS) show that their performance can decrease further when load increases after reaching peak performance. The probable cause for the only significant impact on the latency between the client and the service is the number of necessary hops. The DPS also slightly increases the SYN response time.

When adding attacks in Section 5.2.2, other patterns emerge. Protecting the service against a UDP flood reduces the throughput while only yielding a small improvement in ICMP response time. This behavior shows that adding security functions that protect against vulnerabilities that are not present (the server does not listen to UDP packets) can harm performance. The same firewall can massively increase performance when protecting against the “right” attack—in this case, an HTTP flood with only a small cost in ICMP response time. Similar behavior occurs when protecting against an SYN flood with the DPS. Although the firewall can perform faster than our attack generator, the DPS extends the point where throughput caves in by almost a factor of three. Unlike the DPS and the firewall, which protect against Denial of Service (DoS) attacks, the IDPS protects against intrusion attacks. For this protection, Deep Package Inspection (DPI) and, therefore, a massive amount of computing resources, are necessary. Thus, as expected, the IDPS reduces the total performance of the system. The single-function workloads show massive differences between the functions under benign and malicious loads. Thus, even without regard to the ordering, these differences require significant considerations when it comes to scaling and placement.

Section 5.3 confirms our assumption that the order of security functions within an SSFC has a significant impact on SSFC performance. When considering throughput, we see different behaviors when comparing different attacks. Those behaviors share one commonality, that is, placing the security function that defends against the attack first yields the most successful benign requests. In some cases, the SSFC order significantly prolongs the load level at which performance drops and slows the drop. Still, at some point, both SSFC orders converge to similar results. This convergence is the case for UDP flood and intrusion flood attacks. The results for the SYN flood converge slower than before and are still at high multitudes of the inverse SSFC order’s performance when we reach the limit of our attack generator. The SYN flood also shows that the second function of the chain is relevant and yields better performance when using the firewall rather than the IDPS. The most significant difference is visible for the HTTP flood attack. Putting the firewall first consistently yields optimal performance, while the inverse order drops.

When analyzing further statistics, like ICMP and SYN response times and the respective packet loss, we observe that in many cases (UDP flood and SYN flood for IDPS and DPS), the order with the highest throughput yields the best metrics. For the HTTP flood and SYN flood for the firewall and DPS, only small differences occur. Lastly, for intrusion flood, the order with the highest throughput is also the SSFC order with the worst other metrics. The ordering also affects the CPU load on the security function servers. In general, the order with the highest throughput yields the lowest load level once again, except for intrusion floods, where the IDPS load rises. For all scenarios, this change in order removes or reduces the load level on the non-defending security function.

Thus, we have shown that the SSFC order has a significant effect on throughput, as well as other metrics and the CPU load. For the selected attack combinations, we also find that there is no optimal SSFC order for all attacks. While for HTTP and UDP floods, the firewall performs best before IDPS, the reverse chain is superior during intrusion floods. In general, putting the security function dedicated to protecting against the current attack first yields the best results. Therefore, we require different SSFC orders depending on the current attack state of the system.

6. Performance Modeling for Reordering Decision

In the previous sections, we focused on the general idea of dynamic SSFC reordering and the impact of the SSFC order on performance. Here, we further focus on how to arrive at a precise model and a reasonable decision-making approach, especially for more complex systems. Later, this model can be an input to a dynamic SSFC reordering framework.

First, we look at how to model single security functions based on incoming traffic. We then use this knowledge and combine multiple security function models into an SSFC model. Finally, we discuss approaches to decision making.

6.1. Modeling Single Security Functions

We model individual functions according to the traffic they process. Therefore, we first need a traffic model that models benign and malicious traffic classes.

6.1.1. Modeling Traffic

As shown in Section 5, different security functions show different behavior for different types of traffic. Thus, we need a model that, on the one hand, takes benign traffic into account and, on the other hand, considers the various attack types. To this end, our arrival-rate model must consider the content (e.g., relevant for DPI used by an IDPS) and the composition of the traffic. Therefore, we model the traffic as different workload classes. For every workload class, we record the packet rate and the bandwidth used by this class. For the security functions, we benchmarked in Section 5, this would constitute at least the following workload classes:

(1) 

Benign requests and unprotected attacks: In our setup, this represents benign HTTP queries, ICMP timing packets, and the TCP SYN requests from the client to the server. While this is sufficient for modeling of the security function performance, modeling an entire system, including the security service functions and the compute services might require dividing this class into multiple subclasses. We also summarize all malicious packets we do not have a security function for in this class, since there is no way of discerning them from the benign packets.

(2) 

UDP packets: Since we do not use benign UDP packets, they are an unwanted workload class. In a more complex scenario with UDP servers, there would be a port separation.

(3) 

Malicious SYN requests: We consider all SYN requests that do not follow up with a complete connection establishment as malicious. This simplification might lead to a few misclassifications, but (a) these are on the safe side, and (b) failed connection establishments that are not intended by the client still create load on the DPS or fill the server’s buffer without the DPS.

(4) 

Malicious HTTP requests: This class contains all HTTP requests that do not target a valid port or Uniform Resource Identifier (URI).

(5) 

Intrusion packets: All packets that match the IDPS rules and would cause damage to the server if not filtered belong to this class.

For our modeling, we, therefore, have five workload classes with two pieces of information per class. We model the traffic composition for the link from the external network to the first security function, every connection between security functions, and the link from the last security function to the protected system. Section 6.2 shows how to derive the values at each of these points.

6.1.2. Security Function Modeling

With a traffic model, it is possible to model the behavior of the individual security functions. We propose applying architectural performance models to model security functions. Architectural models capture the semantics, allowing for a clear view of the security functions, in contrast to low-level stochastic formalisms. We model each security function a software component. However, we also offer simplified approaches to model security functions. It is necessary to model the following three aspects: 1. the effect of the security functions on the traffic composition, 2. the performance behavior of the security function, and 3. tertiary effects like packet loss.

Modeling the Effect on Traffic Composition

Based on the distribution of the input traffic of a security appliance, the corresponding output traffic can be derived. We define the distribution of the input/output traffic as $P_{in/out}\left(t_i\right)$ with $i\in [1,n]$ for n different types of traffic.

For an exemplary security function that drops all packets of traffic type k, the output traffic looks as follows:

$$P_{out}\left(t_i\right)=\left\{\begin{array}{cc}{P}_{in}\left(t_i\right)/(1-P_{in}\left(t_k\right))\hfill & \mathit{for}i\ne k\hfill \\ 0\hfill & \mathit{for}i=k\hfill \end{array}\right..$$

(1)

Figure 11 shows the behavior of such a security function that drops a single class of packets—visualized regarding the bandwidth.

For our example, we use the functions from Section 5 and the traffic types described above for the firewall ($k=2\vee k=4$) for DPS $k=3$, and the IDPS $k=5$. As seen, a security function can match more than one traffic type.

The current model assumes that a function eliminates all malicious traffic of one or more traffic types. This model does not yet take other behavior (e.g., false positives) into account. We discuss that, along with other tertiary factors.

Modeling the Performance of the Security Function

For the function, the most precise modeling solution would be to use a full-blown model of the software component to model the function’s performance behavior. Such models are usually based on the function source code or are extracted by heavy black-box testing. However, often, neither the source code nor the time and resources is available to perform extensive black-box testing. Even when such a model is not possible, we see a minimal model for a security function, as shown in Figure 12.

The depicted model shows the security function as a software component of the SecurityFunction type. This component has a behavior description that contains a BranchAction, and this BranchAction contains a default behavior description and a description for at least one traffic class. Equation (1) is such a BranchAction for the behavior with respect to traffic.

As expected, our security functions usually exhibit different behavior depending on the types of traffic against which they defend. However, they can also exhibit divergent reactions to other classes. Furthermore, the behavior for the class that the functions protect against can have various sub-branches.

Example

For illustration purposes, we describe the branch actions for the evaluated security functions used in Section 5 with respect to the five different types of traffic before.

• Firewall:
  • The firewall analyzes the headers of all Internet Protocol (IP) packets. This analysis creates a resource demand per packet. The resource demand is equal for all packets, since the firewall only considers fixed-size IP headers.
  • The firewall discards UDP packets (Traffic Class 2). They do not create additional resource demand. The same is true for further non-TCP packets (e.g., the benign ICMP packets from Traffic Class 1).
  • For all TCP packets, the following further distinction is necessary (here, our firewall is capable of working on OSI Layer 4—the protocol layer):

    −

    For all TCP segments, the firewall inspects the header of the segment. This inspection, again, creates an additional resource demand per segment. If the header contains the wrong TCP destination port, the firewall drops the segment (Traffic Class 4). However, this resource demand is constant per segment.

    −

    For packets addressed to the correct port on the protected server again, the following distinction becomes necessary (thus, we have an OSI Layer 7—application layer—firewall):

    *

    The firewall checks the HTTP request for blocked URIs. This check creates a resource demand to parse the resource passed in the HTTP request. This validation can take longer for longer URIs. However, this aspect is relatively small, and therefore, we assume the resource demand to be constant per HTTP request.

• DPS:
  • The DPS application listens to TCP segments. Therefore, we assume no resource demand for other traffic types (e.g., UDP packets from Traffic Class 2 and ICMP packets from Traffic Class 1).
  • For TCP segments, the DPS makes a distinction based on enabled SYN and ACK flags. This distinction creates a constant resource demand per TCP segment.

    −

    If none or both of the flags are enabled, the packet does not concern the DPS, and it passes through and creates no additional resource demand (e.g., the first packets of established connections from Workload Class 1).

    −

    If only the SYN flag is enabled, the SYN handling component computes the sequence number and replies with an SYN+ACK packet. These steps create a constant load per segment with the SYN flag.

    −

    If only the ACK flag is enabled, the DPS validates the sequence number. This step creates a constant resource demand.

    *

    If the sequence number is invalid, the DPS drops the segment, eliminating additional resource demand.

    *

    If it matches, the DPS notifies the server, which, in turn, informs the SDN controller. Thus, this step creates the following constant resource demands per segment in the ER: 1. the DPS itself, 2. the server, and 3. the SDN controller.

• IDPS:
  • The IDPS step-by-step checks incoming traffic against its rules. For every level, this creates a constant resource demand per frame/packet/segment.

    −

    If a file matches all header conditions for at least one rule, the IDPS performs DPI on the body of the packet. Thus, it creates a dynamic resource demand depending on the size of the packet. The correlation between packet size depends on the pattern types. For simple patterns, a linear correlation is likely, while more generic patterns can even cause an exponential correlation.

For these devices, we find two general types of resource demand generation. The first type is a constant demand created per unit (e.g., frame, packet, segment, request, etc.). The second type creates a demand correlating to the size of the unit with different correlation types. A special case is with the DPS, which creates additional resource demand on the server and the SDN controller. Since we only model the security functions, we ignore this effect for now.

With these types, it is possible to obtain a relatively accurate model consisting of a single function by running measurements with a simplified ANOVA approach, always modifying only one parameter until successfully deriving a complete model of the security function.

Modeling Tertiary Factors

There are additional factors that can increase the accuracy of the model in certain situations. These factors do not correlate directly with single packets or the traffic distribution but, instead, with the state of the security appliance.

• Queuing Behavior: Some security appliances (e.g., the IDPS) have a characteristic queuing behavior. This may delay the resource demand—on the current and following functions—as well as traffic.
• False Positives and False Negatives: Not all security functions (e.g., an IDPS based on anomaly detection), by default, are safe from having false positives and false negatives. An accurate model should account for these. False positives result in a reduction in traffic classes the system does not protect against, while false negatives have the opposite effect. Some packets of the traffic class—that the security function defends against—remain after the traffic leaves the function.
• Drop Rate: Some security functions can—in certain situations—undesirably drop packets. Such a drop rate, as well as the resulting necessary retransmissions (at least for the benign packets), impact the system, and the model should consider them.
• Overload Behavior: Under very high load levels, some security functions change their behavior. This effect especially impacts the three factors listed above and requires separate modeling.
• Short-Term CPU Frequency Scaling: For short terms, the use of CPU frequency scaling can counter the issues caused by an overload. The modeling of the overload behavior should account for this functionality and implement a delay for the overload effect.

6.2. Modeling Security Service Function Chains

Based on the previously presented model for single security functions, it is possible to model the whole security function chain. Therefore, we model the chain by putting the functions one after the other and feeding the output of the previous function to the next.

6.2.1. Modeling Traffic Composition throughout the Security Function Chain

When starting with the input traffic, the traffic results from putting it through one function after the other. Figure 13 shows such a development of the traffic for the function described above. For illustration, we use a simplified model without tertiary factors. The traffic starts with a distribution over all traffic types. At every security function, this function removes one or more traffic classes. Therefore, the share of the other classes increases. This process repeats itself at every security function until only the benign traffic remains.

This combination allows for a full model of the chain when the composition at startup is known. However, most of the time, this composition is unknown. Still, it is possible to compute this composition using reports from the security function about occurring attacks. We present an implementation for this reporting in Section 7.

In the server, the traffic wholly consists of benign packets. The switch before the server (in a more complex system, the switches before the servers) can report the number of packets and the bandwidth of benign traffic using, e.g., Simple Network Management Protocol (SNMP). With the reported attack composition from the last security function in the chain, we add an equal amount of packets and bandwidth with the equivalent share in the traffic composition.

Again, this step repeats at every security function. After inverse processing through by first security function, the result is the incoming traffic.

In some experiments, we realized that this approach yields a smaller total bandwidth than actually present at the input link. This effect is due to unmodeled tertiary factors, as described before. A simple fix is to scale the traffic without changing its relative composition. We, therefore, propose the scaling of the total bandwidth and number of packets to the number reported by the SNMP switch or switches before the respective security function.

6.2.2. Calculating Total Resource Demand for the Security Service Function Chain

With the knowledge of the traffic composition at every step of the SSFC and the resource demand model for every single security function, we can compute the required resource demand.

We put the traffic composition at every stage through the resource demand model of its security function. This calculation yields the resource demand per function. The sum of single resource demands is the total resource demand.

The unique resource demands help to decide upon necessary scaling (especially since we have corrected for dropped packets using the data from the switches) and co-placement. As a result of this correction, resource demands more extensive than the provided resources can occur. This knowledge can facilitate scaling according to these demands. If the sum of demands for functions that follow in the SSFC is below the resources, these functions can be placed on the same server to reduce the number of required virtual or physical instances and remove network latency due to additional hops (which Section 5.2 indicates as a significant factor).

6.3. Decision Making

Based on the introduced models, it is now possible to make decisions. During attacks, a dynamic SSFC reordering framework has to decide in which order to place the security functions inside the chain to achieve optimal performance. We present the following three approaches for how to compute the order for the security functions:

• Complete calculation of all permutations of the chain;
• Front-to-back placement of the optimal security functions; and
• Security function swapping.

These approaches have different advantages and disadvantages and suit different use cases depending on the complexity, the required accuracy, response time, and the available computational resources.

6.3.1. Complete Calculation of All Chain Permutations

The first approach is the most straightforward and accurate. The FCC computes every possible permutation of the security function chain. For each of these permutations, we feed the current traffic composition (gathered as shown before from the network switches and the security function reports) through a model of that permutation. For all these SSFC orders, the models yield the resource demand. The SSFC order with the lowest resource demand is the optimal SSFC order. Based on the resource demand, it is also possible to calculate how many instances of a security function are necessary.

Since we calculate all permutations, this approach is guaranteed to yield the SSFC order with the optimal (modeled) performance. However, this approach can be very compute-intensive. The number of permutations (P) of n different security functions results from Equation (2).

$$P\left(n\right)=n·\left(n-1\right)·\left(n-2\right)·\dots ·1=n!$$

(2)

While for our examples of three security functions, only six permutations exist, four security functions already increase this to 24 permutations. The number of permutations grows faster than an exponential function. With this knowledge, it is possible to approximate the number of computing steps (C) for n security functions as follows using Equation (3):

$$C\left(n\right)=n\left(n·\left(n-1\right)·\left(n-2\right)·\dots ·1\right)=n!·n\in \mathcal{O}\left(n!\right)$$

(3)

For a sophisticated security system with a multitude of security functions, the exploration space explodes. This growth leads to a massive need for computing resources and increases the possible reaction time to changes in the attack composition.

6.3.2. Front-to-Back Placement of the Optimal Functions

In contrast to the first approach, the second does not fully compute all permutations. Instead, the FCC builds the SSFC order from front to back. In the first step, the FCC applies the standalone model of every security function on the incoming traffic (as derived by the model). The security function with the smallest resource demand in this model then takes its place as the first security function in the chain. Next, we use the traffic after passing through this function and model it for every security function except for the already used function. The approach continues until it has placed all functions in the chain.

This solution reduces the complexity of the calculation, since it no longer calculates all permutations—in fact, it only computes the final order entirely. It is possible to approximate the number of computing steps (C) for n security functions as follows in Equation (4).

$$C\left(n\right)=n+\left(n-1\right)+\left(n-2\right)+\dots +1\in \mathcal{O}\left(n^2\right)$$

(4)

Thereby, the runtime shrinks from more than exponential growth to quadratic growth. This shrinkage is a massive reduction and allows us to compute more complex SSFCs. However, in some cases, a faster reaction is necessary, or computing resources for the FCC are rare. This approach also yields a good order but can not guarantee that a different order might not be more efficient.

6.3.3. Security Function Swapping

Unlike the first two, the latter approach does not recompute the entire chain. Instead, it calculates the effect of swapping two functions. Therefore, it randomly selects two functions to swap and models the system with and without swapping these functions. If swapping reduces resource demand, the FCC decides to swap.

This solution further reduces the complexity of its invocation by calculating only two full chains. The number of computing steps (C) for n security functions per iterations results from the Equation (5).

$$C\left(n\right)=2n\in \mathcal{O}\left(n\right).$$

(5)

This reduction allows for a constant and fast reconfiguration. However, the reconfigurations are only stepwise. A complete reordering of the chain can take multiple steps.

In addition, the approach behaves like a simple hill-climbing algorithm. Thus, it can reach a local performance maximum and stop. In contrast, a better global maximum might be available (e.g., when performing a single reordering that decreases performance, this can open another reordering with a more significant benefit). Furthermore, the selection of the functions to be swapped is non-trivial. A random approach is inefficient, and the algorithm could benefit from taking into account factors such as the position in the chain and the current resource demand. Here, a heuristic study could improve this approach.

6.3.4. Overview

We have introduced three approaches to decision making and reordering. They have different characteristics, as shown in

Table 6. Comparison of the suggested decision-making approaches.

Approach	Optimal Order Guaranteed	Full Reordering Performed	Runtime
Complete Calculation	✓	✓	$\mathcal{O}\left(n!\right)$
Front-to-Back	✗	✓	$\mathcal{O}\left(n^2\right)$
Swapping	✗	✗	$\mathcal{O}\left(n\right)$

. As expected, reducing the runtime of the calculation also removes quality features such as a guaranteed optimal order or a full reordering. Depending on the use case, a system architect has to weigh these factors and decide which best suits the desired use case. Furthermore, the approaches could be combined, e.g., the swapping approach could run continuously while performing the full calculation in longer intervals.

7. Attack-Aware Security Service Function Chain Reordering Framework

We design a SSFC reordering framework to realize the described vision of an attack- aware SSFC.

7.1. Architecture

The attack-aware SSFC reordering framework consists of multiple components. Figure 14 presents an overview of these components. As a backbone, a generic SDN-enabled network connects the external network and the service protected by our security system. Thus, all relevant security functions are also connected to that network. We deploy security function wrappers alongside security functions to collect metrics about them and their attack and report them to the FCC. The FCC collects data from the wrappers and, optionally, other sources. It makes a decision as to whether another ordering is better based on the gathered security function data. If it estimates that a reordering would improve performance, it sends the new ordering to the SDN controller. The SDN controller then enforces the new order inside the SDN-enabled network. In the following pages, we provide further details about the security function wrapper, the FCC, and the requirements for their communication Application Programming Interface (API).

7.1.1. Security Function Wrapper

The security function wrapper is a program that runs on the security function hosts and communicates with the FCC. It is responsible for registering the security function with the FCC; deleting it upon graceful shutdowns; maintaining a connection to the FCC to allow for the management of security functions through the FCC; and, finally, offering an interface for the security function to report detected attacks to the FCC over the wrapper.

7.1.2. Function-Chaining Controller

The FCC runs in a central location accessible from all security functions. A website showing attack statistics, as well as the current and standard configuration, is part of the FCC. Additionally, the website contains a form to manually change the routing configuration based on the available groups of security functions. The controller needs to handle the requests from the wrapper instance, namely registration, delete requests, attack alerts, and keep-alive requests, as shown before. The FCC must keep a list of the security function groups and their respective attack rates to reactively calculate the new optimal routing configuration. After calculating the new routing configuration, the FCC sends it to the SDN controller, which then applies it to the switches and, therefore, the network.

7.1.3. API Requirements

The security function wrapper and the FCC communicate and exchange data. This communication requires a predefined API. As is the standard for modern APIs, we encode all information using the JavaScript Object Notation (JSON) format. Each message uses a unique type key to determine the message type. Our framework uses the following four types of messages for communication between the security function wrapper and the FCC: 1. REGISTER, 2. KEEP-ALIVE, 3. ATTACK, and 4. DELETE.

7.2. Proof-of-Concept Implementation

The complete framework uses Python 3. We chose Python because it is simple to learn, offers useful libraries for REST interfaces and HTTP requests, and does not require compilation, allowing for unhindered modification. In this section, we first look at the libraries used in this study and move on to the security function wrapper and FCC implementations. We also introduce a small SDN controller, which we use for the evaluation.

We provide the source code for the security function wrapper at https://github.com/bladewing/SecurityFunctionWrapper, for the FCC at https://github.com/bladewing/FunctionChainingController and that for the SDN controller at https://github.com/bladewing/SDN-Controller, all accessed on 17 August 2024.

7.2.1. Libraries

We use the following four non-standard Python libraries: Flask [50], PyJWT [51], requests [52], and netifaces [53].

Flask is a lightweight Web Server Gateway Interface (WSGI) Web application framework designed with simplicity and scalability in mind for sophisticated applications. It started as a simple wrapper and is now one of the most used Python Web application frameworks. It uses the Jinja templating engine and the Werkzeug WSGI library.

Requests gives itself the slogan “HTTP for humans” and describes itself as “A simple, yet elegant HTTP library”. It allows the sending of HTTP/1.1 requests through it. Thus, it removes the need to configure the query strings to Uniform Resource Locators (URLs) manually.

PyJWT implements JSON Web Token (JWT). “JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC*) and/or encrypted” [54].

The netifaces packet is a networking abstraction. It takes care of the underlying networking management tools and allows an independent standardized interface to access network information. We use this packet to obtain the IP and Media Access Control (MAC) addresses of the underlying machines.

7.2.2. Security Function Wrapper

The wrapper is a Flask application. The main task of the security wrapper is to send security function attack reports to the FCC. After validating the configuration file of the wrapper, the security function wrapper sends a registration request to the FCC, which responds with a token. The FCC later uses this token to validate requests from the security function wrapper.

In the course of our research, we developed implementations for the IPTables firewall [55] and the Snort IDPS [56]. The THREADS DPS supports attack reporting by default.

Following registration, the keepalive method starts in a separate thread. It contains a loop where, every TIMEOUT minutes, it sends a keep-alive message to the FCC. The wrapper will not start if the FCC is not available at the configured URL. When the wrapper catches a SIGTERM signal from the operating system, it shuts off the keep-alive thread and sends a delete message to the FCC.

7.2.3. Function-Chaining Controller

The FCC is, at its core, a Flask application, and FCC has a log file where it logs everything to make debugging easier. The FCC provides interfaces for security function wrappers to register, send keep-alive messages, report attacks, and delete themselves. The FCC also offers a URI to change the routing configuration.

7.2.4. Software-Defined Networking Controller

In general, this framework supports every SDN controller offering a REST API for flow modification. To ensure the absence of side effects from the SDN controller, we implement a minimalistic SDN controller ourselves. To this end, for this proof-of-concept evaluation and the following evaluation, we limit our framework to use with Open vSwitch. This SDN controller consists of the following two Flask applications: the actual controller and a switch wrapper running on Open vSwitch machines. The SDN controller receives a list of security function groups, generates flows for the passed configuration, and forwards those flows to the switch wrappers, which execute the necessary ovs-ofctl commands and, therefore, apply the new settings. Matching packets on the IPv4 source address and MAC address is sufficient to achieve distinct flows.

7.3. Evaluation

7.3.1. Testbed Environment

Figure 15 provides an overview of the testbed used in this study. For the evaluation, we used four servers named C39, C45, C48, and C49. Each server has the same configuration as the servers used in Section 5.1. All servers and spawned virtual machines use minimal Ubuntu as an operating system. Minimal Ubuntu is a regular Ubuntu stripped of all command-line convenience features to reduce image size, installation duration, and the number of required security updates (only installed software requires patching). Kernel Virtual Machine (KVM) is the hypervisor that spawns all needed Virtual Machines (VMs).

C39 and C48 are hosts for additional virtual machines. All servers and switches are on the 192.168.66.0/24 subnet. The security function wrapper runs on each virtual security function, and the FCC runs on C45, together with the SDN controller. The VMs Sender, FW, and DDoS all run on C39, in combination with an Open vSwitch instance as a bridge between host and guest. Next, the VM IPS and receiver run on C48, alongside an Open vSwitch instance as a bridge. The Open vSwitch on C49 connects the Open vSwitches from C39 and C48. It forwards every packet coming from C39 to C48 and back. In this setup, the incoming traffic from the sender to the receiver passes through all three switches. All three VMs FW, DDoS, and IPS have two Network Interface Cards (NICs) each. One NIC handles incoming traffic that, after processing, leaves via the other NIC.

7.3.2. Manual Reordering

Experimental Description

We test the six possible routing orders for the three security functions. Therefore, we create an automated system to test these routing configurations in the network based on the standard configuration. After starting the system and registering the security appliances, the Sender sends an ICMP echo request to the Receiver. We start with tcpdump for each security function. Furthermore, the simple SDN controller saves the flows generated for each switch before sending them to the switches. The script iterates through all valid permutations of the standard configuration to show that the generated flows are correct. This automatic permutation allows us to reuse the script for SSFCs with more than three security functions.

Results

Figure 16 visualizes all changes in the ordering configuration during the automated experiment. The graph visualizes the recorded packets from the tcpdumps, showing the order of security functions that each packet passes through. The x axis shows the time of the experiment, and the y axis depicts the security functions. The circles (first security function the packet passes through), squares (second security function), and triangles (third security function) mark the routing order. Cases where a packet traverses more than three functions are indicated by colored diamonds in the charts. The black vertical lines show the time when the script applies a new permutation of the default routing configuration. The first section (before the first vertical line) shows that the packets traverse through the DPS VM, then through the firewall VM and, lastly, through the IDPS VM. This order is the default configuration of the network. After applying the first new routing configuration, the packets traverse through the firewall VM first, then through the DPS VM and, lastly, through the IDPS VM. Thus, the packets traverse the security functions in the desired order. Moreover, Figure 16 shows that our framework applies every permutation of the default configuration correctly. As seen, it is possible to traverse through more security functions than there are in the network. This issue is a result of the change of the routing configuration as traffic passes through the system. The following packets go through the desired function chain. The gray and black diamonds in the graph show the packets that traverse more security functions than configured because a new routing configuration takes effect during the ICMP requests. Although packet loss is theoretically possible, it does not occur, and even then, new routing configurations are applied instantly. Additionally, while theoretically possible, no attack skips a security function.

7.3.3. Reaction to Simulated Attacks

Experimental Description

This experiment analyzes the FCC’s attack-awareness. Thus, it validates whether the FCC correctly changes the routing configuration based on the attacks reported by the security functions. The previous section showed that the framework creates all the generated flows correctly and applies them successfully to change the network routing configuration. As described in Section 4, the main idea that led to the development of the framework is to change the routing configuration dynamically. As described in Section 7.1 and Section 7.2, the security functions report detected attacks to the co-located security function wrapper instance, which then reports it to the FCC. We simulate attacks on each virtual machine to show that attack reporting works and that the routing configuration changes depending on the attack reports. The simulated security functions send attack reports with a changing probability of $2·{10}^{-6}$, $4·{10}^{-6}$, and $6·{10}^{-6}$ every millisecond. We configure a threshold of 100 in the FCC. Only if the attack count exceeds this threshold does the FCC calculate and—if necessary—apply a new routing configuration. In addition, we define an imminent threshold, which is three times as large as the regular threshold. The FCC checks for new routing configurations every five minutes, but every ten seconds, the FCC checks if the reported attacks of a security function group exceed the imminent threshold. In that case, it immediately recomputes the routing configuration and applies it if it has changed. We selected these values to validate our proof-of-concept implementation.

Experimental Results

During this experiment, we select four instances in which the routing configuration changes. Visualizing the complete experiment in one graph yields unreadable results. Therefore, we show only parts of the graph in the time frame of 40 s around changes of the routing configuration to illustrate the functionality tested in the experiment.

Figure 17 illustrates the imminent attack functionality. The first modification of the routing configuration occurs almost 3 min into the experiment. The routing order changes from DPS-Firewall-IDPS to Firewall-IDPS-DPS. This change could not originate from the regular check, as it occurs before the five-minute mark.

Figure 18 illustrates the regular functionality of the FCC. The routing configuration takes effect approximately 12 min after the start of the experiment. The routing order changes from firewall–IDPS–DPS to IDPS–firewall–DPS. Here, it becomes visible that for one ping, the packets does not cross every security function, posing a potential security risk. In the discussion, we provide possible solutions to this issue.

Figure 19 shows that the framework applies the new routing configuration approximately 15 min after the start of the experiment due to an imminent attack on the IPS. The routing changes from IDPS–firewall–DPS to IDPS-DPS–firewall. Although IDPS is already the first instance through which traffic is traversed, DPS reports more attacks than the firewall and, therefore, moves ahead of the firewall.

Figure 20 shows a routing configuration applied approximately 23 min after the start of the experiment. The routing changes from IDPS-DPS–firewall to DPS–firewall–IDPS. DDoS and FW report more attacks than IPS, resulting in the corresponding configuration.

The function-chaining controller resets the configuration to the standard configuration if reported attacks of all security functions are below the configured threshold.

7.3.4. Discussion

Functionality

In summary, the developed framework works as expected. Small issues like packet loss may occur during the application of new routing configurations. The generation of routes and their application work as desired. We have also showed that the framework is, indeed, attack-aware and successfully changes the routing configuration of the network based on attacks reported by the security functions. After the attacks fade out, the framework switches back to the default configuration.

Security Issues during Reconfiguration

As shown before, the following three undesired scenarios can occur during reconfiguration:

• Packets can get dropped because the framework has not installed the required flow yet. This packet loss requires retransmission.
• Packets can traverse one or more security functions more than once. For example, in a chain with three functions, if a packet currently resides in the third function and a reconfiguration puts the third function first, the packet, again, has to traverse the former first and second functions.
• The packets may not traverse all required security functions. For example, when using a chain with three functions, a packet residing in the first function may continue directly to the receiver if a reordering puts the former first function last. Thus, the packet may skip the former second and third functions.

The first and second issues only pose QoS and Quality of Experience (QoE) concerns. Retransmissions (if supported by the protocol) take additional time. Similarly, passing through more security functions increases the time packets spend in the SSFC. However, the third issue is relevant to security. If packets can skip security functions, single malicious packets can reach the receiver. This issue is of little concern for flood attacks, but for intrusions, a single packet might be enough to trigger a vulnerability and cause a severe security breach.

To avoid this issue, we propose several solutions.

• A straightforward solution would be to have a second set of security functions. Reconfigurations would then use this second set for the SSFC. Once all packets clear the security functions in the first chain, those functions become the functions that the next reconfiguration can use. Many security systems have hot spares to ensure the availability component of security. Therefore, for these systems, this solution is simple to implement and has no overhead. As a beneficial side effect, this option also fixes the first and second issues.
• A second option is to model the stay of packets inside the security function by adding short-lived flows with artificial delays that ensure that no packets are inside the functions when executing the reordering. However, this requires detailed knowledge of all security functions inside the chain, especially regarding their queuing behavior. Although precise modeling is possible using existing performance engineering tools (e.g., [57]), when the source code is available, black-box models are more complicated to achieve and less precise. This approach does not fix the first and second issues.
• The third concept is to force the security functions to drop all packets before executing the reordering. This solution fixes the second and third problems but moves the affected packets and others to the first issue.
• The fourth option is to use the options field in the IP header. We create a counter-field in the options. For every reconfiguration, the SDN controller increments this counter. The inbound switch has a rule that modifies the incoming packet headers to contain the current counter value. The flows match against this header field and the current counter. Older flows expire after some time (either by removing them manually with a clean-up routine inside the SDN controller or by using soft timeouts). The main limitation of this approach is that many hardware switches do not support matching against this field. However, newer hardware switches and software switches generally support matching against this field.

Table 7. Comparison of the suggested solutions with framework issues.

Solution	Issue			Complexity
	Packet Drop	Multiple Passes	Skipped Functions
Second SSFC	✓	✓	✓	Medium (spare functions)
Artifical Delays	✗	✗	✓	High (Modeling)
Dropping Packtes	✗	✓	✓	Low
Options Field	✓	✓	✓	Medium (SFCC extention)

provides an overview of the proposed solutions. Depending on the use case, the security system architecture, the employed switches, and the used security functions, there are different optimal solutions. We have not yet implemented these solutions, but we will do so in the future. For proof of concept, the presented implementation is sufficient.

8. Conclusions

In this section, we conclude this paper and provide a summary of its contributions. We also discuss the benefits of our work and provide an overview of the potential for future work.

8.1. Summary

SSFCs design is mainly static, and SSFCs do not adapt to the surrounding circumstances and the incoming traffic mix. In response to this issue, we first present the general idea of attack-aware SSFC reordering, then perform performance measurements and modeling for a better understanding of SSFC behavior. With this knowledge, we then create a framework to realize our idea.

8.1.1. Performance Engineering and Modeling for Security Service Function Chain Orders

Next, we introduce the idea of attack-aware SSFC reordering. This idea follows the vision to always position the security functions inside an SSFC in the optimal order for the current attack composition. Security functions have the added complexity that, unlike other network functions, they also drop traffic categorized as malicious. Thus, traffic dropped at the SSFC’s beginning does not reach the security functions further along the chain and also does not create resource demands for them. While for a single attack, the simple answer would be to just place the matching security function first, for more complicated composite attacks that require multiple security functions that have different performance characteristics, the choice is not as simple. We, therefore, propose the use of a model for the SSFC to optimize its order. An instance called the FCC collects attack statistics from the security functions and decides the optimal order based on this model.

We perform measurements to prove our claim that the ordering is relevant during attacks. First, as an example firewall, we show IDPS, and DPS, which have significantly different performance characteristics, even for benign traffic, which mainly appear in the throughput they can handle. Under the specified attacks, we show that the performance of the service increases when using systems that protect against DoS attacks, while securing against software vulnerabilities even decreases performance. Furthermore, protecting against attacks that are irrelevant to the service can also hamper the overall performance. When putting the security functions in SSFCs of size two, we find that putting the defending function first always yields better throughput and, in most cases, also better latency and drop rate. This advantage can be up to three orders of magnitude.

Furthermore, better orders also reduce the total CPU load on the employed servers. At this point, we conclude that the order inside an SSFC is essential to its performance. Optimal orders for different attacks also contradict each other, which makes it a case to always adapt the order to dynamically achieve optimal performance.

Next, we develop a modeling formalism for SSFCs. To do this, we first model single security functions. A security function changes the composition of the incoming traffic. Thus, we categorize the traffic into multiple traffic classes comprising one class per attack type and another class for benign traffic and unmatched attacks. We then describe the effect of a security function as a function on these traffic classes. Following the composition, the resource demand also results from the traffic classes. Each packet, depending on the class, creates a fixed resource demand per frame, packet, or segment. In addition, for some security functions, the resource demand depends on the size of the data unit. Multiple of these security function models form an Security Function Chaining Controller (SFCC) model, where the output traffic from one function is the input traffic of the next function—until only benign or unmatched packets remain—and the total resource demand results from the sum of all single functions. Knowledge about the traffic volume reaching the server and the number of attacks at each step of the chain allows for computation of the original incoming traffic composition. Based on this composition and the models, the FCC can compute the desired SSFC order. We provide three approaches for order adaptation with complexity between factorial and linear differing in their guarantee of an optimal order, as well as full and partial reordering.

8.1.2. A Framework for Attack-Aware Security Service Function Chain Reordering

Having laid out and validated the idea of attack-aware SSFC reordering before, we create a framework that realizes this idea using SDN. All security functions of an SSFC reside inside an SDN-enabled network. A security function wrapper co-located with every security function reports attacks to the FCC. Then, the FCC computes the desired order for the security functions and executes it via the SDN controller. We propose an authentication and communication interface that enables this interaction and provides a PoC implementation. For this PoCs implementation, we also provide a minimal SDN controller.

We test our PoC inside a testbed. First, we prove the correct ordering by permuting through all possible orders and validate the correct route through the security functions. Then, subjecting the framework to simulated attacks, we show that the framework correctly adapts to all attacks as desired, and after the attacks subside, it returns to the initial state. The following three issues can occur during reordering: 1. Packets drop, 2. Packets pass through a function twice, or 3. packets skip a function. While the first two issues are undesirable yet without security impact, the third issue could result in malicious packets reaching the service. We propose four different solutions depending on the use case to alleviate these issues.

8.2. Benefits

This work benefits multiple groups of people. Among others, data center, service operators, and software and hardware developers benefit from the performance engineering and model for SSFCs and the framework for attack-aware SSFC reordering. They lay the groundwork for further research in this field. The current solution can already augment existing data center structures and is available to cloud providers. In general, the concept of attack-awareness can change how security infrastructure works and significantly reduce costs while, at the same time, increasing the quality of service.

8.3. Future Work

Our contributions lay the ground for future work. We see several potential directions to follow and challenges to address in the future.

In this work, we show the value of reordering SSFCs using SDN. Systems like Open Network Operating System (ONOS) [58] and OpenDaylight [59] contribute to the simple deployment of NFV and SDN. Still, they fail to develop sophisticated, complex SDN strategies without having to know each other and explicitly interact.

We developed a solution for attack-aware SSFC reordering and already defined traffic classes for different attacks. We propose to develop a more fine-grained classification approach regarding traffic type (e.g., protocol) but also other factors, like regional origin, using GeoIP. Then, our system can determine an optimal order for groups of those types or each type.

We use manually developed models to model security functions and SSFCs. Although this is acceptable for scientific work and small-scale infrastructure, for more extensive infrastructure, operators often do not have the time or the knowledge to model all possible attacks. We, therefore, propose an automated approach that—at times when the system operates under benign conditions—sends attacks through the network or via single functions and learns (e.g., by regression learning) the effects of the functions on the traffic composition and the generated resource demands. The system should regularly repeat these steps until the desired accuracy is reached.

So far, we have mainly considered throughput as the primary metric for SSFC performance while also discussing latency and packet loss. While reducing the resource demands and the number of required security function instances is a generally reasonable guideline, we also find that sometimes, load balancing across multiple servers can reduce power consumption. Thus, we propose further energy-efficiency research on SSFCs and the incorporation of the results into our security function models and as a factor for deriving the optimal SSFC order.