Security in Software Defined Networking

de-ployments, which rely extensively data replication and load balancing to ensure elastic scalability [64] and high availability at all times. Watson et al [145] showed that there are limits to the accuracy of verifying the location of data in a cloud storage. The authors demonstrated that when a malicious cloud service provider colludes with ma-licious hosts, it is unfeasible for a user to correctly verify the exact location of files.

Furthermore, Watson et al. were the first to take into consideration cases where two or more malicious hosts collude and make copies of the stored files. This assumption led them to posit that the task of restricting the geographic location of data is impossible.

The authors have suggested a proof of location scheme that can be used by a user to obtain the location of a stored file. However, the proposed scheme required signi-ficant supplementary infrastructure, as the solution relied on the existence of trusted landmarks responsible for verifying the existence of files on a host.

Similar to other solutions that rely on distance-bounding protocols [146–148], and latency-based techniques [149, 150], most data geolocation approaches not not address the question of limiting data accessibility according to geographic location.

NIST described a proof of concept for geolocation of data in the cloud [151], relying on the combination of trusted computing, Intel TXT and a set of manual audit steps to verify and enforce data location policies. The use of hardware-based isolation en-vironments has created the capability to restrict accessibility of cleartext data across jurisdictions (also refereed to as “geo-fencing”) [152, 153] however still relying on the cloud storage provider to enforce the data location policies.

In Paper D, we describe an approach to control access to cleartext data in data centers, based on their geographic location. The approach is based on sealing cryptographic material used to protect data integrity and confidentiality to approved geolocation cells described by a set of geolocation coordinates. We used a hardware RoT to unseal the cryptographic material only if the geographic location of the platform is within one of the approved geolocation cells. As a result, data can only be accessed in plaintext if the storage is placed in one of the geolocation cells approved by the data data administrator.

In all other cases, the data remains encrypted but can be replicated for redundancy purposes. While in the design and implementation phases we relied on gelocation data reported by the Global Positioning System (GPS), the solution can be implemented with other geolocation systems. The prototype was implemented using the Swift object store [154] (part of the OpenStack project); however data stored in other types of storage (such as block storage) could as well be geo-fenced based on the same principles.

While the approaches presented above provided multiple solutions to the data geo-location problem, this aspect remains unresolved in practical deployments, as users must trust the statements of service providers regarding data location.

pop-ularity [155]. This change triggered renewed research in network management security, re-definition of adversary models, re-assesment of security challenges and attack vectors.

While significant work has been done on the security of the SDN model, important chal-lenges remain. A review by Scott-Hayward et al. lists multiple security issues spanning across the architectural layers of SDN [156]. These include unauthorized access, data leakage, data modification, malicious or compromised applications, denial of service, configuration issues, as well as system level SDN security - such as lack of visibility of the network state. Since SDN has seen considerable security research efforts, many of the issues have been addressed to some level in [157–162] along with multiple other contributions. Along with the existing security challenges and solutions, a review by Ahmad et al. [163] highlighted several future directions for security in SDN, such as class-based application security, security scalability in SDN, synchronization of network security and network traffic, network security automation, and identity location (which could be addressed by applying approaches such as the host identity protocol [164]). In Paper E we described an SDN-specific threat model as well as attack vectors identified based on the adversary capabilities and prior work [155,165]. This review helped identify a list of ten security requirements towards SDN deployments. A part of the challenges identified in [163] (in particular class-based security and partly security scalability), as well as part of requirements identified in Paper E were later addressed through the mechanisms described in Papers F, G and in on-going work [166].

Protecting Software-Defined Networking Components

The adoption of software network components executing on commodity operating sys-tems has increased the attack surface of network infrastructure: as highlighted in the European Telecommunications Standards Institute security specification for network function virtualization, software network components are vulnerable to both bugs in their own code and to risks introduced by the underlying trusted computing base (such as hypervisor introspection, vulnerabilities in the OS) [14]. Antikainen et al. described in [167] a series of attacks that can be performed once a virtual switch has been com-promised. Such attacks include eavesdropping control plane communication, network state and topology spoofing, as well as denial of service.

Some of the above attacks can be prevented by protecting southbound communica-tion using standard network security protocols such as TLS with server- or mutual authentication. However, while using TLS prevents certain classes of attacks - such as topology spoofing and traffic eavsdropping - it does not solve the issue but rather shifts the focus on protection of the authentication credentials. Virtual switches commonly contain kernel modules for performance reasons [95], which means that a virtual switch compromise can lead to a complete compromise of the compute host [168]. Beyond revealing authentication credentials, a compromised host can be used to launch attacks throughout the deployment, both on the network and compute infrastructure. Integrity monitoring and integrity verification can be used to prevent forwarding plane comprom-ise. For example, the proliferation of novel and versatile TEEs opened the possibility of using TEEs to strengthen the security guarantees in SDN deployments.

Several related scenarios of protecting SDN components were investigated in [169] - pro-tecting integrity of virtual network function states using TEEs; in Paper F- propro-tecting integrity of forwarding plane components using TEEs; in [170] - enhancing security of the Tor ecosystem by using TEEs; and [171] - packet processing in TEEs. To the best of our knowledge, the contribution described in Paper F (introduced below) was the first to propose ensuring authenticity, as well as protecting confidentiality and integrity of software switches by placing them in TEEs.

In Paper F we address some of the risks introduced by the widespread use of virtual switches in network deployments. Virtual switches executing on commodity operating systems are often assigned the same trust level and privileges as hardware switches.

However, commodity operating systems contain security flaws that can compromise virtual switches. On the other hand, the absence of a secure and scalable process for authentication and authorization of virtual network components prior to enrollment introduces the risk of impersonation of components enrolled into the SDN infrastructure.

We addressed both of the above risks in Paper F by deploying a custom implement-ation of simple a software switch in a TEE with remote attestimplement-ation capability. We use the functionality of the TEE to distribute the key material used to establish an authenticated, confidentiality and integrity protected communication channel between the software switches and the network controller.

Another result introduced by this paper are the so-called ephemeral flow-specific pre-shared keys. TruSDN leverages two aspects of the popular OpenFlow protocol - namely centralized network control and forwarding the first packet of a flow to the network controller - to deliver on demand ephemeral pre-shared keys to communication end-points. This approach allows to relax requirements for high-quality entropy available to virtual endpoints and reduce the time to establish a TLS session. Along with a further extension of this work [166], this approach highlights the opportunities for increased use of TEEs to secure network infrastructure.

Access Control in Network Infrastructure

Beyond the goal of separating forwarding and control planes of network infrastructure, SDN has created new possibilities for network management and network application deployment. While the initial abstractions of virtual switch, flow rules, southbound API and logically centralized network controller are available, the northbound API and the access control to SDN remain undefined.

The access control scheme for SDN controllers proposed in [172] - followed by a pro-totype described in [173] - mimics access control schemes for operating systems, with contextual adjustments. In particular, it introduced the logical separation of network components to reliably assign the object and mode of access, along with support for delegation of access permissions to network components. The permissions supported by the access control system included both operating system-type read and write permis-sions, and additional permissions for reading statistics, requesting information about

the objects and modifying their state. The policies supported by the proposed access control scheme reflect the separation of the administrator and management domains of the network deployment: a mandatory access control component managed by the net-work administrator allows to assign permissions for netnet-work subjects to perform actions on the network deployment; a discretionary access control component enables subjects to delegate the objects they own to peer subjects.

Despite the research efforts on network virtualization and SDN access control [172–176], replacing hardware network middleboxes with software implementations is not sufficient to ensure security while supporting multi-tenancy and deployment flexibility of virtual network infrastructure. In part, this is due to the lack of access control for network man-agement applications, caused by missing or incomplete definitions and understanding of other network abstractions [172]; this also impedes defining an expressive north-bound API. The intent framework [177,178] implemented in the ONOS network controller [100]

enabled a solution for SDN access control for network applications.

In manuscript G, we describe a north-bound network resource access control API for network operators and application developers. The approach is based on three prin-ciples: broad definition of resources in the software defined network model (partly induced by the additional permissions introduced in [172]); explicit assignment of re-sources and privileges for network applications; reuse of the Capability-Based Access approach, where subjects carry an unforgeable token describing their access rights in order to access a resource.

The definition of network resources adopted in manuscript G includes: device resources such as hardware or virtual switches and installed flows; data resources, such as the network topology and flow statistics; and control resources, such as management and security policies in the deployment. This definition enabled a change in the way network applications interact with the network controller (and implicitly the rest of the network deployment): access to resources in the network deployment is explicitly described for each application (or class of applications) using an access mask, which describes both the resources that the application can access and the actions that it can perform on those resources. An unforgeable token created based on the access mask (along with other information) is then supplied along with the intents submitted by applications to the network controller; the token is verified by a reference monitor in order to prevent violation of access policies in the event of a network controller compromise.

Ongoing Work and Future Challenges

In our on-going work [166], we aim to provide comprehensive user security guarantees regarding the trustworthiness the network infrastructure on all planes. This is done by leveraging two emerging aspects: logical centralization of network infrastructure offered by SDN; and increasing availability and hardware support for TEEs on commodity platforms. Future security research challenges in SDN include run-time validation of VNF states, compliance verification of forwarding network functionality, as well as identification of security mechanisms for federated SDN infrastructure.