Fundamentals of Software Defined Networking

Software Defined Networks (SDN) offer a fundamentally new approach to traffic engineering and routing, creating more static flows over relatively stable routes, enabling quality of service and potentially superior network utilization. Yet traffic engineering depends on security. Dependable traffic engineering requires not just the resolution of conflicts between resource requests, but mutual authentication, trustworthy platforms, trustworthy information, and much else.

Software Defined Networks differ from current networks in two main ways. First, they separate the data and control planes, implementing out-of-band control for packet-switched networks. They offer many potential advantages for network resilience, control, and management. Yet almost every advantage can also be an opportunity for an attacker. For example, a single SDN controller greatly simplifies network management, but simultaneously risks a single point of failure. As SDN and IPv6 concurrently diffuse, new forms of unpredicted cascading failure may also arise.

Second, software defined networks move control (and thus risk) from the expensive optimized hardware of routers to software running on commodity hardware. Changing the economics and mechanics of routing changes the economics and mechanics of security and network resilience.

Today, SDN is primarily adopted by data centers, each within a single organizational framework and in clearly bounded physical locations. The next step in SDN diffusion is likely to include Internet exchange points. These have a single organizational trust structure but are places where many network operators host their equipment: consumer ISPs, transit providers, CDNs and even intelligence agencies.

Bluntly, assumptions of physical security, trustworthiness of operators, incentive alignment and technical competence in SDN today echo the assumptions about mail servers and routers in the nineteen eighties. While there are commonalities, the new factor in SDN is the monitoring and management of the control plane, and the increased programmability. While traditional routers were driven by command-line scripts that were complex and thus fragile, SDN supports multiple virtual networks and services. This creates a new universe where firms can innovate - and things can go wrong.

The report begins by enumerating remaining core challenges, particularly in inter-networking. While SDN may exist at multiple levels in the network (from home networks to Internet exchange points) the focus here is on the risks at the higher levels. Thus emergent risks from more widespread adoption and the inherent complexity are explored. Managing them requires a move beyond current protocol and security mechanism design into the design of protection mechanisms for network applications and their infrastructure. As these applications mostly don't exist yet, we explore what we can do with modeling. We also need to consider the risks of cyber-physical systems to determine under what constraints and at what level of abstraction modeling is useful for providing insights to the future SDN world.

There are many flavors of SDN, but in this report we focus on one particular implementation, OpenFlow. OpenFlow instantiates paths through the network as deterministic flows; the path selected by a controller from a point in the network will be the same for all switches in the location. That path is determined by the switches' controller; and the packet forwarding is implemented by switches based on controller rules as opposed to being optimized by routers. Flows are not circuits; flows from one switch to another can be determined by a single controller (no negotiation between controllers is required) and there are none of the quality of service guarantees associated with virtual circuits.

Openflow has succeeded in the marketplace due to its early availability on merchant silicon switches and its greater programmability for applications (such as traffic engineering). Security is also a core promise, as yet unmet. Filtering, resilience against control plane misinformation (or misconfiguration) attacks, and load balancing are at the intersection of traffic engineering and security. But if a controller cannot be secured, the traffic engineering promises cannot be dependable; and the same is true if the traffic-engineering mechanisms can be gamed.

Of the traditional security goals of confidentiality, integrity and availability, traffic engineering in general (and SDN in particular) mainly deliver availability. Confidentiality and integrity are not entirely excluded: they can always be provided by encryption at higher layers, but they can be greatly helped by dependable separation, and separation may be the most economical way to protect legacy networks such as industrial control systems where retrofitting cryptography may be impractical.

Most denial of service issues demand traffic engineering as a component to any solution. The exclusion of unwanted traffic is made possible by OpenFlow. Consider that new and unknown traffic can be given a priority, as with FRESCO, or filtered out, as with the demonstration project developed under this proposal. Filtering out traffic not intended for legitimate routes may function effectively in normal operation. But determining whether such rules would be effective under different failure conditions is not at all trivial. The Internet's resilience in the face of natural disasters and acts of war has been remarkable. Strict filtering in network exchange points might limit that resilience in emergencies. There are complex questions around how we manage filtering at scale, which is not yet understand properly.

This leads to the next category of traffic management: allocating resources. The two options of prioritizing versus filtering are extreme cases. In reality, operations will require a more subtle approach to resource allocation, in particular resource allocation from remote requests. Currently SDN installations are sufficiently organizationally controlled or built in conjunction with organizational trust where reputation is embedded in the human or institutional principals. The past two decades of Internet growth have depended on human trust, as key technical staff at large ASes know and work with each other to resolve problems. This system is starting to fray, and it's not clear how it can scale to networks that are partially trusted. One current approach is to provide information about the state of the network, and make decisions based on that abstract representation of state. However, this approach will not scale. As the world goes online, the competence and benevolence of operators will increasingly vary.

There are interesting issues around transparency. BGP is designed to be an information hiding protocol; it lets ASes conceal sensitive business information from competitors with whom they peer. Yet transparency is good for detecting malicious behavior. For example, that Hong Kong's reported exports to China are so much smaller in dollar value than China's imports from Hong Kong indicates the prevalence of tariff avoidance (by marking more valuable cargo as less valuable) in Chinese imports. Similarly, observations of traffic across borders can provide an indication of the sources of malicious traffic. SDN will centralize control information and may thus force a rethink of transparency.

Distributed traffic management requires mutual authentication of components. This is still not a solved problem in the context of client/server and router/router interactions. DNSSEC is being deployed, and BGPSEC is being standardized. However it's not at all clear if there are adequate deployment incentives for BGPSEC as it's currently conceived, or whether it can cope with all attacks. As SDN islands emerge, first in data centers, then at IXPs, then in corporate networks, and then in consumer ISPs, the solution of how to securely link them may give us a once-in-a-generation opportunity to revisit the assumptions underlying all networking from addressing. Specifically, SDN must in some way address naming, (e.g., DNS), and inter-domain routing (e.g., BGP).

OpenFlow

An SDN controller has two sets of interfaces, commonly considered north and south. The southbound interface views the switches under the controller's domain. The northbound interface provides a view of the state of the exterior network; interacting with multiple protocols and responding to changes.

The risks of the southbound interface are primarily denial of service and disclosure of information. The channel between controllers and switches is typically low-bandwidth, as only control information is needed, and denial of service is correspondingly simplified.

The risks of the northbound interface are from interaction with the network and interaction with what can be termed the management plane itself. The management plane will provide information about the state of the network to which controllers will respond. This is key to the dependability and performance of SDN but is not yet standardized.

The management plane is likely to be instantiated as a series of applications engaging with different protocols (e.g., eBGP) in order to take full advantage of SDN traffic engineering capabilities. Indirect manipulation through incomplete or malicious monitoring data could be bidirectional, with insecure controllers being leveraged for surveillance, stolen network resources, or for amplifying attacks from the SDN network into the BGP network. The management plane consists of software which may come from diverse sources. Monitoring software will be marketed, installed, and updated in the way that applications are today. Monitoring information, manipulation of the networks, and direct alternation of controllers are risks from malicious code. While an SDN app store is eminently foreseeable, the security questions have yet to be asked: what would the permissions look like for an SDN app? No-one seems to have any idea yet.