Analysis and Mitigation Strategies of Security Issues of Software-Defined Networks

Analysis and Mitigation Strategies of Security Issues of Software-Defined Networks

Copyright: © 2022 |Pages: 35
DOI: 10.4018/978-1-6684-3448-2.ch003
OnDemand:
(Individual Chapters)
Available
$37.50
No Current Special Offers
TOTAL SAVINGS: $37.50

Abstract

The rapid development in telecommunication technologies in the last decade gave rise to a new set of sophisticated security threats. Software-defined networking (SDN) is a new network paradigm that isolates the network control plane from the data plane. This provides network programmability, which reduces operating costs and enables business growth. However, this new technology has several security threats, which is a major concern in its adaptation. This chapter presents a comprehensive review of the security issues of SDN and mitigation strategies.
Chapter Preview
Top

Introduction

SDN concept is not entirely new; it existed even decades ago. Particular infrastructures were used to decouple the data plane from the control plane. This decoupling was needed for computing systems requiring high speeds and large scale roles. Traditionally, computer networks have been segregated into three planes, data plane, control plane and management plane.

Data Plane, which handles the traffic, consists of devices that forward the packets. Control Plane consists of forwarding tables and enables the data plane functions. Management Plane consists of software services used to configure the control functionality. In this way, the network infrastructure can be virtualized. Thus simplifying it to configure and manage the network centrally.

SDN uses a centralized control application running on a server or virtual machine to allow control over network flows. The control plane decides where the packet is needed to be sent, and the data plane forwards the packet to the destination. The controller defines rules defining how the packets are handled and routed. Routers and switches become slave of application driven controller when these rules are installed.

From the cost perspective, SDN is considerably cheap. It’s due to the universal nature of the data forwarding switching devices that follow specific standards and provide more control over network traffic flow than the conventional network devices.

SDN's layered architecture follows the 'separation of concern' principle. This means, in theory, it should have improved security of networks.

Figure 1.

SDN architecture

978-1-6684-3448-2.ch003.f01

SDN increases the attack surface and misses out on appropriate security mechanisms like authorization. Using a centralized approach has positive effects on many policy types, including centralized routing algorithms, firewalls, and network-monitoring techniques. The negative implications include the situation when a central unit fails. This downgrades the resilience of a distributed system. As SDN is centralized, an external adversary might need less vulnerable SDN components to be compromised to gain complete network control.

Since SDN maintains a global view of the complete network topology, this information can be used along with traffic analysis to reliably detect existing Denial of Service (DoS) attacks.

A new type of Denial of Service (Dos) attack vector has emerged since the centralized controller is taking the decisions. Constant decision making is being done by the controller for the incoming packets. An attacker can flood the network with packets, consuming the resources and memory of the controller.

SDN Architecture

SDN architecture has three main layers: Data Plane, Control Plane and Application Plane. The following section presents an overview of the three layers (Figure 1).

Data Plane

The data plane consists of packet forwarding elements like switches and routers. However, unlike forwarding elements of traditional networks, these have no embedded intelligence to take autonomous decisions. Here the OpenFlow interface comes into play. Different devices communicate through OpenFlow interfaces with the controller. This ensures configuration and communication compatibility between different devices.

An OpenFlow enabled forwarding device maintains a forwarding table with three sections: Rule Matching, Actions to be executed for matching packets, and Counters for matching packet statistics. Rule Matching fields include Switch Port, Source MAC, Destination MAC, Ethernet Type, VLAN ID, Source IP, Destination IP, TCP Source Port, TCP Destination Port.

Southbound API

This is the bridge between forwarding devices and the control plane. It provides a standard interface for the upper layers enabling the controller to use different southbound APIs like OpenFlow and OpenState, and protocol plug-ins like SNMP and BGP to manage new or existing physical or virtual devices. OpenFlow provides three main types of information to the Network Operating Systems: Packet_in message, Event based messages, and Flow statistics generated by the forwarding devices. Packet_in message is sent whenever a forwarding device doesn’t have a matching flow in the flow table for a packet or an explicit rule for a packet. Event_based message is sent each time a link or port change is triggered.

Complete Chapter List

Search this Book:
Reset