An attacker could also leverage these protocols and attempt to instantiate new flows into the device's flow-table. The attacker would want to try to spoof new flows to permit specific types of traffic that should be disallowed across the network. If an attacker could create a flow that bypasses the traffic steering that guides traffic through a firewall the attacker would have a decided advantage. If the attacker can steer traffic in their direction, they may try to leverage that capability to sniff traffic and perform a Man in the Middle (MITM) attack.
An attacker would like to eavesdrop on flows to see what flows are in use and what traffic is being permitted across the network. The attacker would want to try to eavesdrop on southbound communication between the network element and the controller. This information could be useful for a replay attack or simply for reconnaissance purposes.
Many SDN systems are deployed within data centers and data centers are more frequently using Data Center Interconnect (DCI) protocols such as Network Virtualization using Generic Routing Encapsulation (NVGRE), Stateless Transport Tunneling (STT), Virtual Extensible LAN (VXLAN), Cisco Overlay Transport Virtualization (OTV), Layer 2 Multi-Path (L2MP), TRILL-based protocols (Cisco FabricPath, Juniper QFabric, Brocade VCS Fabric), Shortest Path Bridging (SPB), among others. These protocols may lack authentication and any form of encryption to secure the packet contents. These new protocols could possess vulnerabilities due to an aspect of the protocol design or the way the vendor or customer has implemented the protocol. An attacker could be motivated to create spoofed traffic in such a way that it traverses the DCI links or to create a DoS attack of the DCI connections.
1-2. Attacks at Controller Layer
It is obvious that the SDN controller is an attack target. An attacker would try to target the SDN controller for several purposes. The attacker would want to instantiate new flows by either spoofing northbound API messages or spoofing southbound messages toward the network devices. If an attacker can successfully spoof flows from the legitimate controller then the attacker would have the ability to allow traffic to flow across the SDN at their will and possibly bypass policies that may be relied on for security.
An attacker might try to perform a DoS of the controller or use another method to cause the controller to fail. The attacker might try to attempt some form of resource consumption attack on the controller to bog it down and cause it to respond extremely slowly to Packet_In events and make it slow to send Packet_Out messages.
Often times, SDN controllers run on some form of Linux operating system. If the SDN controller runs on a general purpose operating system, then the vulnerabilities of that OS become vulnerabilities for the controller. Often times the controllers are deployed into production using the default passwords and no security settings configured. The SDN engineers got it to "just barely" work and then didn't want to touch it for fear of breaking it so the system ends up in production in a vulnerable configuration.
Sign up for Computerworld eNewsletters.