Programming for SDN Security

Posted on Posted in Networks and Security, Uncategorized

Based on an initial model of the Internet as a network of mutually-trusting nodes, traditional networks present various security risks, which may be amplified in the decoupled architecture of SDN configurations.  Currently, most switches and routers can only establish insecure TCP connections [4]. Additionally, some devices and applications are user-accessible, and therefore, prone to attack.  The centralised paradigm of SDNs introduces a significant vulnerability whereby attacks that successfully target the control plane via either the data or the application layers can grant the attacker control of the entire network [4]; in gaining access to the controller, the attacker can make changes in the flow tables [2].  Next, the lack of integration of existing security technologies – such as Transport Layer Security (TLS) – restricts the ability of SDNs to detect and mitigate advanced persistent threats to the network’s integrity [6].  These concerns are particularly relevant within the space of software-defined wireless networks where user mobility and an abundance of Internet-connected devices introduce increased exposure to, and thus opportunities for, attack [1].

Data Layer

On the data plane, switches are accessible to end-users, representing a potential entry-points to the network [2].  Not only are cheap and/or physically-compromised devises vulnerable to tampering, the increased number of connected devices in wireless sensor SDNs creates many de-centralised entry-points for malwares [6].  Attacks on the networks switches may cause a device to behave as a bot, which in turn can wreak havoc across the network [4, 6].  An acknowledged risk for all networks, these data plane vulnerabilities are potentially even more devastating in SDNs as the centralised control architecture makes it possible for attackers to illegally gain access to the entire network via hacked devices.

The hierarchical layering of switches and the utilisation of role-based access control are two solutions for implementing security from the data plane [2].  Additionally, the integration of strong detection mechanisms within the control plane can be used to detect rogue devices trying to interact with the network’s infrastructure along both device and network vectors [6].

Flow Tables

Flow programming enables unprecedented flexibility, limited only to the capabilities of the implemented flow table [4].  However, SDN switches can handle only limited number of flows per time, presenting a potential security weakness.  In the data plane, control plane instructions are stored in device memory; when a matching protocol is found, packet data is forwarded [2].  Most commercial off-the-shelf switches on market have relatively small Ternary Content-Addressable Memory (TCAM), although this is rapidly changing [4].  Because they are implemented using TCAM, flow table size is limited and cannot scale beyond a few hundred entries or rules.  As a result, malicious attacks on forwarding devices, including network switches or wireless access points, can be used to discard and diverge network traffic [1].  Exploiting this weakness, a malicious end-user device can potentially launch a denial-of-service (DoS) attack to disrupt the installed flow tables in a forwarding device, flood it with anomalous traffic, and exhaust switch memory [1].

The continuous overload of a switch can disable it or knock it down; later arriving packets may all be dropped and fail to be forwarded [6].  Additionally, a DoS attack could lead to device failure, system reboot or substantial lookup queries generated towards the controller, affecting both controller and control channel traffic [1].  Further, flow table overloading can be used to mount distributed denial-of-service (DDoS) attacks, whereby forged or faked traffic flows in data plane can be used to launch cascading attacks on forwarding devices and controllers [4].  A DDoS attack opens illegitimate access to control plane, takes control of various systems and injects data packets to desired target, overloads the memory of the switches through an overwhelming number of illegitimate requests, and potentially overloads the entire network [2, 3, 5].  This approach not only harms a single system, but also devastates the multiple systems affected by it, resulting in network resilience issues, such as the limitation or the disruption of network resources [2, 5].

Current research into these flow-table vulnerabilities recommend three potential security solutions. First, anomalous traffic flows could be isolated in real-time through forwarding policies provided by the control plane [1].  Next, enhancement of the TLS layer to include flow-checker algorithms will help to ensure the security of the communication channels between devices and controller [2].  Finally, compression techniques might be applied to reduce the number of flow entries in TCAMs on the data plane [4].

Communication Channels

The controller uses several communication channels to programme high-level policy instructions to low-level forwarding elements.  Southbound protocols, such as OpenFlow, enable control-to-data-plane communication and provide instructions to programme flow tables within switches and routers, enabling data-plane control and communication.  Further, southbound interfaces have the ability to abstract functionality of the programmable switches and connect them to the software running in the controller [3].  Northbound protocols enable application-to-control plane communication and abstract the low-level instruction sets used by southbound interfaces to program forwarding devices [4].   Finally, East-West programming APIs support internal, adjacent-layer communication within multi-controller environments [1].

SDNs are susceptible to cyber-attack at both southbound and northbound interfaces.  East-west or hierarchical control channels in multi-controller environments also require suitable authentication and encryption to mitigate attack vulnerabilities [1].  Transport-layer security for controller-switch authentication is available in some OpenFlow devices, but is typically administratively disabled, which increases risk of anomalous flow-rule injection.  Additionally, latency and jitter due to network congestion can cause communication delay between defense methods and data plane [1].  Out-of-bound network use for the northbound and southbound communication channels could help secure the protocols for controller management [2].

Control Plane

Of principle concern for SDNs, the centralisation of the network’s decision logic at the controller raises the risk that unauthorized access and impersonation could disrupt the entire network operation, allowing network-wide takeover [1, 3].  By hijacking the controller, an attacker can gain access to the network’s flow rules [2].  In botnet attacks, the bot-master can insert and deploy their infection through SDN control plane as an unauthorized computer [6]. In a DDoS attack, the attacker can send multiple requests to the controller to disturb its functionality [2].

Theoretically presenting a vulnerability as a single-point of failure, the centralisation of the control logic in the controller also presents a theoretical security advantage; in aggregating a global view of the network, the controller offers a central vantage-point from which security administrators may observe real-time traffic statistics and deploy policy changes as required [1].  Additionally, architectural strategies – such as hierarchical and horizontal controller distributions, network zoning, and controller distributions across different servers – may help to limit the scope of control-plane compromises [1, 2].  While many intrusion-detection systems work to detect network anomalies, controller-specific mechanisms are needed to better understand and profile traffic patterns within SDNs [1, 2].  These mechanisms, together with AI integrations, must serve to detect false traffic by checking the flow of the various packets received by the control plane against these profile patterns.  Finally, SDNs must enforce the implementation of policies such as TLS [2].

However, even general network-security solutions introduce some risk.  The continuous development of security policies and protocols that respond to new and emerging vulnerabilities may introduce configuration issues between the controller and the forwarding devices [2].  Seeking to mitigate the risk of a compromised, “brainless” network, the distribution of control functionality across multiple controllers within the control plane still leaves SDNs vulnerable to cascading failure [2].  Further, enhancing the controller’s intelligence software to detect flow changes may increase controller vulnerability to hackers [6].  Finally, many implementations of TLS/SSL suffer from Man-in-the-Middle attacks, making it a less-than optimal choice for implementing control-channel security [1].

Application Plane

The application plane comprises business applications as well as network-specific policy implementation utilities, which remotely monitor and configure the control functionality [1, 4].  From the control plane, the application layer receives an abstract view of underlying network; from the application plane, application requirements and administrator-set policies determine a consolidated set of requests that are returned to the control plane, which the controller then implements at the data plane [1].   Leveraging the northbound interface, this management tier defines the network policy and operation logic to be implemented by the switches, as given from the control plane [2, 4].  As with the data layer, the principle vulnerability in this plane emerges as a general network threat from its touch-points with end-users. When applications are attacked, compromised web-servers might expose precious information [2].  Additionally, the need for standard TLS adoption and server authentication renders the northbound interface particularly vulnerable to man-in-the-Middle attacks.

To prevent data leakage from the controller when web-servers are compromised, SDN’s must ensure user-authentication techniques – s.a. maintaining records of users currently logged in, and prompting users to login after sessions expire.  Additionally, security policy enforcement at the control layer may help to deconflict security policies by making a hierarchy of flows and data packets to be implemented in the devices.  The lack of a standardized northbound interface requires additional broker functionality to reduce chances of policy conflicts; multiple applications are able to provide a consolidated set of clash-free forwarding requirements, or added middleware functionality verifies instructions prior to communication with controller [1].  For example, the addition of the FortNOX kernel implements role-based authentication to help detect and reconcile potentially conflicting flow rules imposed by dynamic applications [2].

Discussion

Additional research is needed to test and mature security solutions unique to SDN configurations.  Not only is the centralization of the control plane a potentially devasting single-point-of-failure, general network security concerns may present new, previously unconsidered vulnerabilities within SDN configurations.  Further, research is required to uncover specific security requirements across a variety of SDN implementations and configurations.  The growth of wireless-device connectivity and the predominance of software applications present risk to networks in the form of new and/or increased exposure to attack.  The potential risk of total network devastation via controller attack restricts the widespread adoption of SDNs at production-scale.  By assuring the thorough consideration of network security throughout the design, development, deployment, and sustainment phases of a network’s lifecycle, SDN implementations will stand as a powerful resource enabling the future Internet of everything.

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *