When thinking about the functional planes of a network What is unique about the control?

13.1.3 Routing Process Functions

Besides packet forwarding, i.e., the data plane function, a router needs to ensure that the contents of the forwarding table reflect the current network topology. For this, a router needs to also provide control plane and management plane functions. In particular, a router needs to handle the following:

Routing Protocols: Routers need to implement different routing protocols, such as OSPF, BGP and RIP for maintaining peer relationships by sending and receiving route updates from adjacent routers. These route updates are sent and received as normal IP packets. But the key difference between these packets and the packets that transit through the router is the destination address, which is the router itself for route update packets. Once the updates are received, the forwarding table is modified so that subsequent packets are forwarded to the correct outgoing links.

System Configuration: Network operators need to configure various administrative tasks such as configuring of interfaces, routing protocol keep-alives, rules for classifying packets, etc. Hence, a router needs to implement various functions for adding, modifying and deleting these configuration data as well as persistently storing them for later retrieval.

As routers need to configured, administrators can manually modify the configuration of the router. This includes configuring of interfaces.

Router Management: In addition to the configuration tasks, the router needs to be monitored for continuous operations. These functions include supporting various management functions that are implemented using protocols such as simple network management protocol (SNMP).

11.1 Software Defined Networks: An Overview

As it was designed, the IP protocol does not separate control and data plane. While it has served well for the past few decades since it was envisioned, it does have limitations, especially if you want to control and manage the network when the environment is highly dynamic. Indeed, IP routing protocols allow you to recover from a link failure, but can we do it better in terms of minimizing the impact on services when services and devices are mobile? Secondly, IP routing is based on the principle of shortest paths while allowing the option to use the equal cost multipath feature; can we do better by allowing proportional routing on multiple paths to utilize the network more efficiently?

The key essence of software defined networking is the separation of the control plane and the data plane. Before we go further, let us (re-)visit what the data plane and the control plane mean. The data plane is the component of a network gear where the users' traffic flows. The data plane is also referred to as the forwarding plane and they are used interchangeably. The term forwarding plane is helpful as it directly refers to forwarding user traffic by a switching device to the next hop. The control plane refers to the signaling function of the network to control/manage a network. In this sense, the typical routing protocols provide the control function such as exchanging the topology of the network. For example, an IP router is responsible for both the control and the data plane functions. For illustration, consider Figure 11.1 where Figure 11.1(a) shown a number of switching devices where each device has both the control and the data functions. As you can see, control interactions can be between every pair switching devices, irrespective of the topology; that is, a network with N switching devices, there are O(N2 ) control interactions.

When we say we are separating the data plane and the control plane function, we mean that a switching device does the data plane function, and the control function is decoupled from it. Now consider Figure 11.1(b) where devices provide the data functions while a controller communicates the control function directly to each device. In this case, there are O(N) control interactions. So an advantage of the separation is that the control interactions can be drastically reduced. On the other hand, does this scenario seem to imply that the switching device is not very intelligent? In some sense, this is true, but on the other hand, it does the main data plane function that it is designed to do. Then the question is where does the control function go? In a software defined networking world, the control function is dictated by a centralized control function that dictates to the switching devices what to do in terms of forwarding user traffic. It may appear that a centralized controller could be the single point of failure. However, it is important to keep in mind that the controller is a logically centralized function; for practical implementations, a number of steps can be taken to ensure its reliability such as having redundant devices running copies of the controller. Secondly, the SDN approach functionally separates the data plane function from the control function. It is not necessary to provide the control function through a central controller; a distributed approach may also be used for the control function.

In Figure 11.2, we show a functional architecture view of SDN showing the separation from a layered perspective. As we can see from the figure, applications and services use the northbound communication to talk to the controller that performs the control plane function. The controller, in turn, uses the southbound communication to talk to the switching devices that perform the data plane function. Typically, for the northbound communication, an API (Application Program Interface) is used. For the southbound communication, the most well known protocol used is OpenFlow (described later in Section 11.2). That is, the architecture has the following components:

Application/Services: This is where the applications/services reside and originate to request functions from the network. Thus, this layer may also be referred to as the application/service plane.

Northbound communication: An API is used on this interface to communicate the requirements of the services to the controller.

Controller: This is the brain of SDN that has the responsibility to translate service/application requirements to the control functions and to communicate with the switching devices about what to do for the actual data plane function. Conceptually, this is a logically centralized control function. The functions provided by the Controller include routing, traffic engineering, and topology management.

Southbound Communication: Through this interface, the controller communicates with the switching devices, for example, on how the flows are to be routed.

Data Plane: Switching devices such as routers and LAN switches use the data plane function on receiving directives from the controller via the southbound interface.

To complement the functional view, we also show a network view of the SDN architecture in Figure 11.3, where each function resides in different functional planes. In this view, the management plane resides in the controller plane that helps in the coordination between the control and the data plane functions.

The SDN approach is suitable in a network where frequent reconfiguration is necessary and the latency between the controller and the switch is small so that new controls can be installed quickly. For instance, a data center network is an appropriate place for the SDN approach where flow paths can be changed quickly, for example, for load balancing of servers by diverting traffic from one server to another. Secondly, the SDN approach is also helpful where different paths may be desirable for different services, such as video vs. webpage delivery. In such cases, the controller can set up flow entries in the flow table of the SDN switches so that flows for video vs webpage delivery take different paths.

16.5.2.1 Governance, decision, action

The PHAROS functional architecture explicitly separates governance, decision making, and action as three key roles in control and management of multi-layer, multi-domain networks. Their functional relationship is illustrated in Figure 16.7. They are analogous to the traditional management plane, emerging control plane and existing data plane functions.

The governance function controls the behavior of the full system, establishing which actions and parameters will be performed automatically and which require human intervention. Governance establishes policy and reaction on a human scale. It is not on the critical path for service instantiations. This function contains the primary repository of nonvolatile governance information and is the primary interface between human operators and the network.

The decision function applies the policies established by the governance function to effectively allocate resources to meet service demands. It is highly time-critical. The decision process is on the critical path for realizing each service request on-demand: the decision process is applied to each service request and creates directives for control of network resources. The PCE in the IETF architecture addresses the mechanisms required to carry out the decision role. In PHAROS, the decision process is unitary. That is, one and only one decision maker is assigned to a given resource. Minimizing the negotiations required to make a decision improves both the optimality of the decision and the consistency of the state it was made from, ensures deterministic decision times (without backtracking or thrashing), and enhances speed and resilience by reducing the number of entities on the critical path that need to reach a consensus. This results in globally consistent resource allocation, with consistently fast service setup. However, as is the case with the PCE, the decision function may also be implemented in a distributed fashion.

The challenge of allocating and assigning communications resources across multiple technological layers, rapidly and efficiently, requires careful attention to the functionality of the decision role. The key characteristics of the role are to minimize negotiations while maximizing the horizon of resource allocation decisions: that is, making each decision with the widest feasible awareness of the total resources in the network and the total demands upon it. Maximizing the horizon of a resource allocation decision allows consideration of the potential uses of a resource for local as well as for transit and protection functions.

The action function implements decisions made by the decision function quickly and reports any changes in the state of the system. The action function is time-critical. The responsibility of the action role is limited to implementing directives. The network element controllers in a typical router or switch device would be the primary implementation components responsible for carrying out the action function.

1 Introduction

With the advent of the high demand network service era for different users, the network service provider requires a highly flexible network architecture and network components to support network communications flexibility. The Software Defined Network (SDN) comes with the thought of separating the networking control Operating System (OS) from the hardware functionality and plotting the control OS in a centralized position to manage the underneath hardware functionalities. Not only that, SDN provides a standardized Application Programming Interface (API) for adding new programmable features in the networks at any period that overcome the problem of lack of programmability and flexibility of traditional network architecture. In other words, the benefit of these properties of SDN is that it helps the network service provider to achieve a network architecture that is more open, flexible, programmable, and manageable towards fulfilling the high demand network services [1]. These advantageous properties help SDN to achieve the global view of underneath topology and empower the control plane to dynamic modification of network functionalities and the abstractions from hardware concerns. Although these properties reconstruct network architecture and network communication management advantageous compared to the traditional network but on the down-side, it also brings new challenges to the implementation of security in the SDN. For example, the separation of the functionalities of control and data plane, limitation of the flow table in the network component makes the door open for Denial of Service (DoS) or network adversary attack. Due to the lack of explicit practices to open programmability, various functions (data plane and control plane) and components are under severe SDN trust management threat.

This paper intends to identify the information security issues in SDN and provides a comprehensive survey regarding the vulnerability and information security threats of SDN along with addressing the enhanced information security due to the introduction of SDN architecture and the individual vulnerabilities of each component and function of SDN, causing new security threat management challenges. Successful addressing of these mentioned issues will help researchers, industry peoples, and beginners to identify SDN architecture and its working procedure, its blessings, and the consequences of new challenges in the networking environments.

The rest of the paper is structured as follows: Section 2 demonstrates an overview of our motivation. Section 3 provides a short trip to SDN generation, an abstract view of SDN network architecture and its communication. We have also discussed some network functionality and how SDN improves its concern in the networking system. Sections 4, 5, and 6 represent chronological order to expose information security risk in SDN architecture. Each section has an impact on other sections so that Section 4 addresses the SDN vulnerabilities for which information security issues occur in the system, like global view and open programmability lead to a vulnerable surface for authentication and authorization issues. Section 5 addresses these issues elaborately. By exploiting these issues (individually or jointly), a malicious user may generate several threats or attacks in different layers of SDN architecture. Section 6 illustrates possible attacks in different SDN layers. The survey work undergoes deep observations of several existing survey papers and recent or popular existing research works to pinpoint maximum possible issues that SDN architecture or SDN-based networking faces to date. Once the observation is completed (root cause, impacts, consequences), the observation outcomes are distributed in three sections (Sections 4, 5, and 6). Accordingly, references are placed in the respective sections, which are the most recent or most popular research, and more importantly, justify the utterance of that particular section or the issue addressed in the section. Each section also includes a comparative statement among the related references for a particular issue mentioned in that section. The inclusion of the references in such a manner is that the researchers can easily grab the knowledge about the current trends of a particular issue of the respective sections and proceed to future improvement. Vulnerable components are not the only issue in the SDN. There are a few other issues addressed in Section 7 for which SDN suffers and restricts its wide adoption. Section 8 visualizes a few advanced research directions that might reduce the existing information security issues convincingly. Finally, we conclude by pointing out the future dimensions of this evolving networking area in Section 9.

6.1 Hardware design

Currently, there appear a lot of software based technologies that intend to accelerate network innovation from the application layer (i.e., software) instead of the infrastructure layer (i.e., hardware). NFV [24] and SDN [256] are two commonly known representatives among these technologies and they fulfill this target by decoupling software from the dedicated hardware which is replaced by the COTS based hardware. However, most of the already existing data plane functions are based on non-x86 architectures which are in the form of either merchant silicon packet processing or the expensive and customized integrated circuits [257]. The proprietary hardware is closely coupled with network functionalities, which results in network ossification and generates a significant challenge for moving to NFV. In order to solve this challenge, one simple and straightforward method is to replace the dedicated hardware with COTS based hardware once for all [258]. However, this operation not only causes great waste on dedicated hardware, but also leads to tremendous costs such as OPEX and CAPEX. Hence, it is not recommended and unrealistic. Current experiences focus more on collaborating such two kinds of hardware instead of using one of them solely (e.g., [259]). In other words, the proprietary network functions and VNFs can cooperate with each other to construct new services. Besides, we can also regard the proprietary hardware as the backup server, and use the COTS hardware to provide specific service functions. Nevertheless, the proprietary hardware will be gradually replaced by the COTS hardware on the way to NFV.

Despite the desire to migrate to a virtualized environment that is composed of COTS based hardware, the performance requirements of applications should be guaranteed. Specifically, the COTS hardware can support the requirements of many standard applications, and adopting COTS hardware in large scale can reduce network cost (e.g., CAPEX and OPEX) greatly. However, the COTS hardware is relatively weak in terms of offering high performance on throughput and reliability [260], etc. Considering the dynamic requirements of enterprises and operators, the hardware should be designed with all the potential situations covered. In addition, directly migrating existing network functions and applications to general-purpose servers without considering their features and demands may lead to unpredictable results [261].

In order to address the issues suffered by COTS based hardware, two major methods are used. The first one is to use data plane acceleration technologies (e.g., DPDK [115] and SR-IOV [46]) and the second one is to use high performance hardware (e.g., IBM RackSwitch [92] and Cisco Nexus Switch [144]). With respect to the acceleration technologies, they are already elaborated in the previous section and are usually applied to the general-purpose hardware (e.g., x86 server) for providing high performance and predictable operations. In particular, these technologies and other VNFs are installed on x86 servers as software module which is similar to the mechanism of cloud model [186]. However, we should be aware that NFV and cloud are actually two different entities, that is, NFV focuses on function virtualization, while cloud focuses on resource virtualization. In this way, the design of COTS hardware should be different from that of cloud model. With respect to the high performance hardware, it is usually purpose-built [25]. Although the purpose-built hardware may not be able to provide as high flexibility as the COTS hardware does, it can satisfy the rigorous demands of applications and services. For example, in order to achieve significantly high performance, the Application Specific Integrated Circuits (ASICs) are usually designed using purpose-built hardware [262]. Despite this, another drawback of purpose-built hardware is high cost compared to the COTS hardware. As a result, the high performance offered by purpose-built hardware is actually obtained by sacrificing some overhead and flexibility. Hence, based on the actual requirements of customers, the key point of designing suitable hardware for NFV is how to determine the trade-off among performance, cost and flexibility, etc.

Many layer 4-7 network functions such as load balancing and DNS can work well on the COTS based hardware, because their requirements on packet processing and interface speed are not high [263]. However, for those functions (such as data center switching and gateways) with high I/O speed and performance requirements, the COTS hardware is not a good option. Instead, they still rely on specialized hardware which can provide higher I/O performance than the COTS based hardware does [264]. Besides, given one kind of server, it may be offered by many companies or vendors. In this regard, how to determine the most suitable one is another issue. Currently, the factors used for hardware selection usually include cost, service quality, latency, preferences, reliability, scalability, security, etc. [265]. Considering these reasons, most enterprises and operators would like to start out with COTS based hardware first to build their NFVI environment, and then gradually adjust their workload to high performance proprietary hardware in order to satisfy some high performance requirements.