U
NIVERSIDADE DE
L
ISBOA
Faculdade de Ciˆencias
Departamento de Inform´atica
TOWARDS SECURE SOFTWARE-DEFINED
NETWORKS
C´atia Alexandra Bimbo Magalh˜aes
Dissertac¸˜ao orientada pelo Prof. Doutor Fernando Manuel Valente Ramos
e co-orientada pelo Mestre Diego Lu´ıs Kreutz
DISSERTAC
¸ ˜
AO
MESTRADO EM INFORM ´
ATICA
Acknowledgments
Firstly, I would like to thank my advisor, Professor Fernando Ramos, for accepting me as his student, for trusting me this interesting work and for believing in me, even at times when I stopped believing in myself. Also, I would like to thank Diego Kreutz for all the help and knowledge that you share. Both are responsible for all the knowledge acquired by myself during this year. Many of these skills will certainly be very important for my future. I also want to apologize for something that I could have done better or faster.
Secondly, I would like to thank my friends. They were very important throughout this process. They were responsible to keep me focus, for cheer me up when I was down and for believing in me. Without them it would not have been able to advance.
Thirdly, I would like to thank my mother and sister to have always been with me and believed in me.
Last but not least, to my father. I truly believe that you have been always taking care of me. Wherever you are, I know you protect me and give me strength to achieve my goals. Even at this time not being here with me, I know that you are with me.
Abstract
Computer networks are complex, difficult to configure and manage. The number of de-vices and their diversity hampers the process of configuration and management. Besides these aspects, there are also other requirements to be fulfilled, e.g. introduction of secu-rity policies or intrusion detection. Issues related with secusecu-rity are particularly important. But makes network management harder. Software-Defined Networking (SDN) was to take the complexity and cost of managing network infrastructures. SDN offers flexibility, interoperability between devices and introduces programmability in the network. Besides addressing the limitations of existing network infrastructures, it allows their development and innovation.
Security is still one of the major challenges of SDN. Given that security issues are a priority concern for the adoption of SDN, it is necessary to ensure the essential security mechanisms for the proper functioning of the infrastructure. In this sense, control plane communications represent the most crucial link between network devices and, at the same time, one of the weakest links from a security and dependability viewpoint. By compro-mising or controlling the control plane communications an attacker can easily take over the entire network. With this issue in mind, this work has as main goal the development of a new approach to improve and simplify traditional secure control plane communications using novel security techniques, with improved performance, and robustness.
For the development of this approach, we make an in-depth study of existing secu-rity techniques. In particular, we analyze the impact of several cryptographic primitives and the overhead of secure control plane communications. Based on this assessment, we propose a new security architecture for SDN that offers the same level of security of tra-ditional techniques with improved performance (2x better than OpenSSL) and robustness (8.5x less lines of code compared to TLS and PKI).
Resumo
As redes de computadores s˜ao complexas, dif´ıceis de configurar e gerir. O n´umero de dispositivos e a sua diversidade dificulta o processo de configurac¸˜ao e gest˜ao. Al´em des-tes aspetos, existem tamb´em outras exigˆencias a serem cumpridas, como por exemplo, a introduc¸˜ao de pol´ıticas de seguranc¸a ou detec¸˜ao de intrus˜oes. Problemas relacionados com seguranc¸a s˜ao particularmente importantes. Mas torna a gest˜ao da rede mais com-plexa. Redes Definidas por Software (SDN) nasceram tirar a complexidade e ao custo de gest˜ao das infraestruturas de rede. SDN oferece flexibilidade, interoperabilidade en-tre dispositivos e introduz a programac¸˜ao na rede. Al´em de abordar as limitac¸˜oes das infraestruturas de rede, permite o seu desenvolvimento e inovac¸˜ao.
A seguranc¸a ´e ainda um dos maiores desafios nas SDN. Uma vez que as quest˜oes de seguranc¸a s˜ao uma preocupac¸˜ao priorit´aria na adoc¸˜ao das mesmas, ´e necess´ario garantir os mecanismos de seguranc¸a necess´arios para o funcionamento adequado da infraestrutura. Neste sentido, as comunicac¸˜oes no plano de controlo representam uma ligac¸˜ao crucial entre dispositivos de rede e, ao mesmo tempo, uma das ligac¸˜oes mais fracas em relac¸˜ao `a seguranc¸a e confianc¸a. Ao comprometer ou controlar as comunicac¸˜oes no plano de controlo, um atacante pode facilmente assumir o controlo de toda a rede. Com isto em mente, este trabalho tem como principal objetivo desenvolver uma nova abordagem para melhor e simplificar as tradicionais comunicac¸˜oes seguras no plano de controlo, utilizando novas t´ecnicas de seguranc¸a, com melhor performance, e robustez.
Para o desenvolvimento desta proposta, fizemos um estudo aprofundado de t´ecnicas de seguranc¸a j´a existentes. Em particular, analisamos o impacto de v´arias func¸˜oes crip-togr´aficas e a sobrecarga das comunicac¸˜oes seguras no plano de controlo. Com base nesta avaliac¸˜ao, propomos uma nova arquitetura de seguranc¸a para as SDN que oferece os mes-mos n´ıveis de seguranc¸a das t´ecnicas tradicionais com desempenho melhorado (2x melhor que o OpenSSL) e robustez (8.5x menos linhas de c´odigo comparando com o TLS e PKI).
Resumo alargado
As redes de computadores s˜ao complexas, dif´ıceis de configurar e gerir. O elevado n´umero de dispositivos e equipamentos necess´arios, bem como a diversidade dos mesmos, difi-culta todo o processo de configurac¸˜ao e gest˜ao. Cada fabricante utiliza as suas pr´oprias especificac¸˜oes sendo necess´ario, a quem configura a rede, ter conhecimento pr´evio dessas
mesmas especificac¸˜oes bem como de toda a arquitetura da rede. ´E necess´ario tamb´em
que todos os dispositivos da rede sejam configurados individualmente, o que torna a ta-refa penosa. Fora a complexidade inerente ao trabalho de configurac¸˜ao da rede, a mesma dever´a se adaptar em caso de alterac¸˜oes ou faltas. Al´em da configurac¸˜ao em si, existem tamb´em outras exigˆencias que necessitam ser satisfeitas, como ´e o caso da introduc¸˜ao de pol´ıticas de seguranc¸a ou detec¸˜ao de intrus˜oes. Problemas relacionados com seguranc¸a s˜ao particularmente importantes. Uma rede, independentemente da sua utilizac¸˜ao, dever´a ser segura para todos os seus utilizadores. Por outro lado, para complicar ainda mais, as redes tradicionais s˜ao verticalmente integradas, ou seja, o plano de controlo e de dados est˜ao inseridos nos dispositivos da rede. Neste caso, o plano de controlo ´e respons´avel pela decis˜ao de controlo do tr´afego da rede e o plano de dados ´e respons´avel por enca-minhar o tr´afego, tendo em conta a decis˜ao tomada pelo plano de controlo. Este tipo de abordagem, al´em de reduzir a flexibilidade da rede, torna-se um grande obst´aculo para o crescimento, evoluc¸˜ao e inovac¸˜ao das infraestruturas de rede. Para mitigar estes proble-mas surgiu um novo paradigma de redes: as SDN (Software-Defined Networking). Este novo paradigma promete oferecer, entre outras, maior flexibilidade, interoperabilidade entre dispositivos e introduzir a capacidade de programac¸˜ao da rede. As SDN combatem as limitac¸˜oes das infraestruturas de rede existentes hoje em dia e permitem a sua evoluc¸˜ao e inovac¸˜ao. Com as SDN quebra-se a verticalidade das redes tradicionais, separando o plano de controlo do plano de dados. Neste sentido, as funcionalidades de controlo s˜ao re-movidas dos dispositivos de rede, tornando-se os mesmos apenas elementos que efetuam o encaminhamento dos pacotes na rede. A parte de controlo, anteriormente integrada nos dispositivos, passa agora para uma entidade externa: o controlador SDN. Esta entidade ´e, nada mais nada menos que software a correr num servidor e que fornece os recursos e abstrac¸˜oes necess´arias para facilitar a programac¸˜ao dos dispositivos de encaminhamento. A rede torna-se assim program´avel, atrav´es de aplicac¸˜oes a correr por cima do
contro-tradicionais, as decis˜oes de encaminhamento s˜ao baseadas no enderec¸o de destino para onde o pacote deveria ser encaminhado, nas SDN este mesmo processo ´e concretizado atrav´es de fluxos. Um fluxo ´e definido por um conjunto de cabec¸alhos dos pacotes que descrevem a ac¸˜ao a efetuar. Atrav´es da programac¸˜ao dos fluxos ´e poss´ıvel dar uma grande flexibilidade `a rede. Estes quatro conceitos - separac¸˜ao dos planos de controlo e dados, controlador SDN, rede program´avel, encaminhamento atrav´es de fluxos - constituem os pilares de uma SDN.
Apesar das suas ineg´aveis vantagens, as SDN ainda tˆem por resolver quest˜oes de seguranc¸a. A seguranc¸a ´e uma prioridade para a adoc¸˜ao das SDN nas infraestruturas de rede das empresas. Algumas das quest˜oes de seguranc¸a das SDN transitam das redes tradicionais, mas h´a novos vetores de ataque. Com as SDN vˆe-se aumentado o perigo de ataques, quando comparados com as redes tradicionais. Todo o tr´afego que passa na rede pode ser falsificado ou mesmo alterado, podendo ser ou n˜ao malicioso. Este tipo de tr´afego pode ser usado para atacar os dispositivos de encaminhamento ou os contro-ladores. O atacante pode utilizar os elementos da rede para iniciar ataques DoS contra os dispositivos de encaminhamento ou contra o controlador, podendo se apoderar dos re-cursos do mesmo. O foco deste trabalho s˜ao os ataques `as comunicac¸˜oes no plano de controlo. Estas comunicac¸˜oes representam a ligac¸˜ao mais importante entre controladores e dispositivos de encaminhamento e, simultaneamente, a ligac¸˜ao mais fraca a n´ıvel de seguranc¸a. Ao comprometer ou controlar as comunicac¸˜oes no plano de controlo, um ata-cante pode assumir o controlo de toda a rede. Neste momento, para assegurar a seguranc¸a nas comunicac¸˜oes no plano de controlo, o OpenFlow, standard base de uma SDN prop˜oe o protocolo TLS/SSL. Este protocolo ´e muito conhecido e utilizado em diversos contextos. No entanto, o TLS/SSL, por si s´o, n˜ao garante seguranc¸a nas comunicac¸˜oes e isso pode comprometer as comunicac¸˜oes entre o controlador e os dispositivos da rede. Este me-canismo necessita de uma infraestrutura de confianc¸a para a gerac¸˜ao de chaves p´ublicas bem como uma autoridade de certificac¸˜ao. Uma vez comprometida uma destas entida-des, a comunicac¸˜ao deixa de ser de todo segura. Al´em disso, o modelo TLS/SSL n˜ao ´e suficiente para estabelecer uma comunicac¸˜ao, entre os controladores e os dispositivos, de confianc¸a. Outra situac¸˜ao que n˜ao favorece a utilizac¸˜ao deste protocolo ´e o facto de que nem todos os dispositivos de encaminhamento suportam este protocolo. Nestes equi-pamentos n˜ao ´e poss´ıvel sequer garantir algum tipo de seguranc¸a. Sendo este protocolo bastante complexo requer alguma capacidade computacional. Sendo que os equipamen-tos geralmente utilizados, principalmente nos dispositivos de encaminhamento, tˆem uma capacidade computacional baixa leva-nos a quest˜oes relacionadas com desempenho.
Tendo em vista a resoluc¸˜ao das quest˜oes relacionadas com as comunicac¸˜oes no plano de controlo, este trabalho tem por objetivo o desenvolvimento de uma nova abordagem de seguranc¸a, com bom desempenho, alta robustez e os requisitos de seguranc¸a. Ir´a ser abordada uma alternativa `a utilizac¸˜ao do TLS/SSL tendo como maior preocupac¸˜ao
segurar comunicac¸˜oes seguras, seguindo o princ´ıpio de simplificac¸˜ao (reduc¸˜ao de linhas de c´odigo) e tendo em conta o desempenho da soluc¸˜ao. Para o desenvolvimento desta abordagem ser˜ao analisadas t´ecnicas criptogr´aficas existentes do ponto de vista da perfor-mance. Com base nesta avaliac¸˜ao, propomos uma nova arquitetura de seguranc¸a para as SDN que oferece os mesmos n´ıveis de seguranc¸a das t´ecnicas tradicionais com desem-penho melhorado (2x melhor que o OpenSSL) e robustez (8.5x menos linhas de c´odigo comparando com o TLS e PKI).
Palavras-chave: Redes definidas por software, Seguranc¸a, Desempenho, Comunicac¸˜oes Plano de Controlo
Contents
List of Figures xv
List of Tables xvii
1 Introduction 1
1.1 Context . . . 1
1.2 Motivation . . . 3
1.3 Goals . . . 4
1.4 Structure of the document . . . 4
2 Context and Related Work 7 2.1 Software-Defined Networks . . . 7
2.1.1 The Historical Evolution of SDN . . . 7
2.1.2 SDN Architecture . . . 10
2.2 SDN Security Issues . . . 12
2.2.1 Threat Vectors . . . 12
2.2.2 Control Plane Communications . . . 15
2.3 Related SDN Security Work . . . 16
2.3.1 Rosemary . . . 16
2.3.2 FRESCO . . . 16
2.3.3 AVANT-GUARD . . . 17
2.4 Security Tools and Techniques . . . 17
2.4.1 Hash and MAC Primitives . . . 17
2.4.2 The Transport Layer Security Protocol . . . 18
2.4.3 iCVV . . . 22
2.4.4 One-Time Password . . . 22
2.4.5 Networking and Cryptography Library (NaCl) . . . 23
2.4.6 Diffie-Hellman . . . 23
3 The SDN KISS: An Architecture for Keeping It Simple and Secure 25
3.1 Security and Performance Analysis . . . 26
3.1.1 Connection and Communication Costs . . . 26
3.1.2 The Impact of Cryptographic Primitives . . . 28
3.1.3 The Impact of Securing the Control Plane . . . 30
3.2 SDN KISS Architecture . . . 31
3.2.1 Anchor of Trust (AoT) . . . 32
3.2.2 Integrated Device Verification Value (iDVV) . . . 33
3.2.3 Device-to-Device Communications . . . 36 3.3 Implementation . . . 37 3.3.1 iDVV Generators . . . 37 3.3.2 iDVV Synchronization . . . 37 3.3.3 Device-to-Device Communications . . . 37 4 Evaluation 39 4.1 Environment . . . 39 4.2 iDVV Generation . . . 39
4.3 Control Plane Communications Performance . . . 42
4.4 Robustness . . . 43
5 Conclusion 45
Bibliography 53
List of Figures
1.1 Layered view of networking functionality . . . 2
2.1 Simplified view of an SDN architecture . . . 10
2.2 Flow Table entry . . . 11
2.3 TLS/SSL Protocol Layers . . . 20
2.4 TLS Handshake Protocol (with mutual authentication) . . . 21
3.1 TCP and TLS connection setup times (in log scale) . . . 27
3.2 FLOW MOD latency (in log scale) . . . 28
3.3 Hashing Primitives . . . 29
3.4 Implementations of Hashing Primitives . . . 30
3.5 MAC Primitives . . . 31
3.6 General Architecture . . . 32
4.1 Latency of different iDVV generators . . . 41
4.2 Latency of different iDVV generators . . . 42
List of Tables
2.1 SDN specific vs non-specific threats . . . 13
Chapter 1
Introduction
Network infrastructures are everywhere and play a key role in our modern society. The Internet has even been classified as a basic human need, such as water and electricity, in some countries. However, network management remains still a rather complex, challeng-ing and costly task. It is necessary to find a way to simplify these operations, without harming the services, the infrastructure, companies and users. But simplifying should not mean to neglect other important issues like security.
1.1
Context
Computer networks are complex and very hard to manage and configure. Typically, they are stratified in three layers, the data, control and management planes, as shown Fig-ure 1.1. The data plane corresponds to the networking devices, which are responsible for forwarding data. The control plane represents the protocols used to populate the for-warding tables of the data plane elements. The management plane includes the software services used to remotely monitor and configure the control functionality [27].
A traditional network is composed of many different kinds of equipment, from routers and switches to middleboxes such as firewalls, network address translators, server load balancers, and intrusion-detection systems. Routers and switches run complex, distributed control software that is typically closed and proprietary [41]. The management software varies not only among manufacturers, but also among different products of the same man-ufacturer. Moreover, network administrators need to configure each device individually, i.e., in an error prone and time consuming device-to-device manner. In fact, configuration errors still account for a large percentage of data center failures and are the number one security threat. In addition to the configuration complexity, network environments have to endure the dynamics of faults and adapt to load changes. However, reconfiguration and response mechanisms are virtually non-existent in current IP networks [27].
To complicate even more, traditional networks are vertically integrated. The control plane (that decides how to handle network traffic) and the data plane (that forwards
traf-Chapter 1. Introduction 2
fic according to the decisions made by the control plane) are bundled inside the same networking devices, reducing flexibility and hindering innovation and evolution of the networking infrastructure [27]. Management plane Control plane Data plane
Figure 1.1: Layered view of networking functionality
Software-Defined Networking (SDN) is an emerging networking paradigm that can help to change the landscape of network infrastructures. SDN is changing the way net-works are designed and managed. We can define an SDN as a network architecture with four pillars:
1. The control and data plane are decoupled
2. Forwarding decisions are flow-based instead of destination-based
3. Control logic is moved to an external entity, the SDN controller or Network Oper-ating System (NOS)
4. The network is programmable through software applications running on top of the NOS that interacts with the underlying data plane devices
The first pillar is the responsible for breaking the vertical integration of the network. By separating the control plane from the data plane, network devices become simple forward-ing devices and the control logic is implemented in a logically centralized controller. The second pillar concerns the behaviour of devices. Being flow-based, the behaviour of the devices are defined by flows. Flows are a set of packet field values acting as a match crite-rion and a set of actions. The NOS provides a logically-centralized view with the essential
Chapter 1. Introduction 3
resources and abstractions to facilitate the programming of forwarding devices. The ca-pability of programming the network is a fundamental characteristic of SDN, considered as its main value. These aspects mentioned above are key factors to obtain the desired flexibility, break the network control problem into tractable pieces, and make it easier to create and introduce new abstractions in networking, simplifying network management and facilitating network evolution and innovation [27].
In spite of the benefits of this new paradigm, the security and dependability of the SDN itself is still an open issue. The network programmability and control logic centralization introduce new threats and attack surfaces [52]. The several security issues of SDN may be holding back its growth and wide spread adoption.
1.2
Motivation
There are several threats vectors and attacks that can severely compromise the operation and reliability of the networks. Therefore, security and dependability are becoming first class priorities for enabling and fostering the deployment of SDN in enterprise and cloud infrastructures.
One of the main concerns of SDN are the control plane communications. Being an important link between controllers and forwarding devices, we expected a high level of security. However, control plane communications still represent one of the weakest links from a security and dependability viewpoint [52, 53]. By compromising or controlling the control plane communications an attacker can easily take over the entire network. TLS is the recommended alternative to TCP for securing control plane communications in SDN. However, only a small number of forwarding devices and a few controllers support TLS. We speculate the slow adoption of TLS for secure control communications to have its root in at least three important concerns: low computing power of forwarding devices, performance penalty, and complexity of the support infrastructure. Additionally, TLS is not enough for ensuring the security requirements of SDN [63].
There are three fundamental principles regarding control plane communications: (a) latency matters;
(b) security is critical;
(c) the complexity of the supporting infrastructure should be kept as low as possi-ble [63].
The latency experienced by control plane communications is particularly critical for SDN operation. Previous work has demonstrated that the use of cryptographic primitives has a perceivable impact on the latency of sensitive communications, such as VoIP [25] (e.g.,
Chapter 1. Introduction 4
[67]. Another recent work has also shown that the latency added by SSL/TLS protocols can be significant [28]. Interestingly, different cryptographic primitives, ciphers, or even implementations of protocols can significantly impact the performance of communica-tions [25, 32].
The security of control plane communications and related services (such as device registration and association) should be carefully addressed [52, 53, 38, 63]. Faked or compromised devices can be used by attackers to eavesdrop data plane traffic, launch powerful attacks on the SDN architecture, impact the operation of services, and so forth.
From a security perspective, one of the major strengths of a technology is its simplicity and simplified configurability, as is the case of Ethernet [47]. Similarly, SDN was born as an attempt to reduce network management complexity [36]. And, in fact, SDN is allowing operators and infrastructure owners to significantly reduce the complexity of manning networks.
The more complex the system, the higher the probability of having vulnerabilities, and consequently the larger the attack surface. This seems indeed to be one of the major problems faced by the technology industry. Specialized security reports have recurrently highlighted the complexity and size of systems as one of the most important security challenges [14].
1.3
Goals
The main goal of this project is to design, implement and evaluate a mechanism to provide security to the control plane communications. The communications between the network devices and the controller can suffer several attacks that can be used to generate DoS attacks or for data theft. The approach currently used, TLS/SSL, has a high performance overhead and the support infrastructure is very complex (the PKI).
Our contribution with this work is:
1. an analysis of the impact of cryptographic primitives and their different implemen-tations on the control plane communications;
2. the blueprint of an security architecture for SDN; 3. improve the performance (vs TLS):
4. increase the robustness of SDN control communications by decreasing the com-plexity of the support infrastructure
1.4
Structure of the document
Chapter 1. Introduction 5
• Chapter 2 - Here we provide a discussion of the related work. We describe the SDN architecture, and the security problems of SDN. We also describe several security techniques that will be used for our proposal.
• Chapter 3 - This chapter describes the SDN architecture we propose.
• Chapter 4 - Here we evaluate the performance and robustness of our architecture. • Chapter 5 - In the last chapter we present the conclusions we take from this work.
Chapter 2
Context and Related Work
2.1
Software-Defined Networks
2.1.1
The Historical Evolution of SDN
The history of SDN began 22 years ago, just as the Internet was taking off, at a time when the Internet’s amazing success exacerbated the challenges of managing and evolving the network infrastructure. The focus was on innovations in the networking community, al-though these innovations were in some cases catalysed by progress in other areas, in-cluding distributed systems, operating systems, and programming languages. The efforts to create a programmable network infrastructure also clearly relate to the long thread of work on supporting programmable packet processing at high speeds. The history is di-vided in three stages. For the first stage, we have the idea of active networks (from the mid-1990s to the early 2000s), which introduced programmable functions in the network, leading to greater innovation. Second, the control and data plane separation (from around 2001 to 2007). Lastly, the emergence of OpenFlow as an open interface to make control and data plane separation practical. In addition to these concepts, the research on network virtualization also had an important role throughout the historical evolution of SDN [41]. Active Networks
The role of computation within traditional packet networks is extremely limited. Active networks represent one of the early attempts on building new network architectures based on data plane programmability. The main idea behind this concept is for each node to have the capability to perform computations on, and modify packet contents [27]. Ac-tive networks propose two distinct models: capsules and programmable routers/switches. In the capsule model, packets are replaced by little programs that are encapsulated in transmission frames and executed at each node along their path. On the other hand, the programmable routers/switches model maintains the existing packet format, and provides a discrete mechanism that supports the downloading of programs [75]. Active networks were motivated by both a technology push and a user pull. The pull comes from network
Chapter 2. Context and Related Work 8
elements that perform user-driven computation at nodes within the network. The push was the reduction in the cost of computing, allowing more processing in the network. An-other push were advances in programming languages, such as Java, that offered platform portability, some code execution safety, and virtual machines technology that protected the host machine and other processes from misbehaving programs [75, 41].
Separating Control and Data Planes
The earliest initiatives on separating data and control signalling data back to the 80s and 90s. The network control point (NPC) is probably the first attempt to separate control and data plane. NPCs were introduced to improve the management and control of tele-phone networks [27]. In the early 2000s, increasing traffic volumes and a greater empha-sis on network reliability, predictability, and performance led network operators to seek better approaches to certain network management functions. Debugging, configuration problems and predicting or controlling routing behaviour became a big challenge. The increasing size and scope of networks, as well as the demands for greater reliability and new services brought problems of management. Simultaneous with the rapid advances in commodity computing platforms meant that servers often had substantially more mem-ory and processing resources than the control-plane processor of a router. With that two innovations emerged. First, open interfaces between the control and data planes, such as the ForCES (Forwarding and Control Element Separation) [20] interface standardized by the IETF or the Netlink interface to the kernel-level packet-forwarding functionality in Linux. Second, a logically centralized control of the network, as seen in the RCP (Routing Control Platform) [34] architectures, as well as the PCE (Path Computation Element) [72] protocol defined by IETF. Compared with active networking, these two in-novations are focused on network management problems, programmability in the control plane and network-wide visibility and control. Moving control functionality off of the network equipment and into separate servers made sense because network management is a network-wide activity [41].
OpenFlow and Network Operating System
Before the emergence of OpenFlow [59], the ideas underlying SDN faced a tension be-tween the vision of fully programmable networks and pragmatism that would enable real-world deployment. OpenFlow appeared to balance both goals by enabling more func-tions than earlier route controllers while building on existing switches hardware. With the creation of the OpenFlow API, network controller platforms start to emerge, such as NOX [43], enabling the creation of new control applications. The initial OpenFlow protocol standardized a data-plane model and a control-plane API by building on tech-nology that switches already supported. Specifically, because network switches already supported fine-grained access control and flow monitoring, enabling OpenFlow’s initial
Chapter 2. Context and Related Work 9
set of capabilities on a switch was as easy as performing a firmware upgrade [41]. An OpenFlow switch has a table of packet-handling rules, a list of actions, a set of counters and a priority. Upon receiving a packet, an OpenFlow switch identifies the highest-priority matching rule, performs the associated actions, and increments the counters.
The concept of a network operating system was reborn with the introduction of Open-Flow [27]. In the SDN context, a network operating system (also known as an SDN controller) is software used to abstract the installation of state in network switches from the logic and applications that control the behaviour of the network. With a network oper-ating system, we can decompose network operation in three layers. First, a data plane with an open interface. Second, a state management layer that is responsible for maintaining a consistent view of network state. And third, a control logic that performs network oper-ations. But separating the control and data planes introduces new challenges concerning state management. Running multiple controllers is crucial for scalability, reliability, and performance. However, these replicas should work together to act as a single, logically centralized controller [41].
Network Virtualization
Network virtualization, the abstraction of a network that is decoupled from the under-lying physical equipment, was a prominent early use case for SDN. It allows multiple virtual networks to run over a shared infrastructure, and each virtual network can have a much simpler topology than the underlying physical network. Network virtualization has evolved in parallel with programmable networking and both are connected in some as-pects. Both had mechanisms for sharing the infrastructure and supporting logical network topologies that differ from the physical network. Before SDN, we already had network equipment with the ability to create virtual networks in the form of VLANs and virtual pri-vate networks. Despite this possibility, there are some limitations which made the devel-opment of new technologies difficult [41]. One of the first initiatives to introduce network virtualization was proposed by the Tempest Project [15]. Tempest introduced the concepts of switchlet and associated virtual network in ATM networks allowing the introduction of alternative control architectures into an operational network. With this, multiple inde-pendent ATM networks can share the same physical network [27]. Other of the earliest initiatives for the creation of virtual networks was MBone [56]. In this project, the virtual network topologies run on top of legacy networks. In an overlay network, the upgraded nodes run their own control-plane protocol and control-plane messages to each other by encapsulating packets, sending them through the legacy network, and de-encapsulating them at the other end. SDN and network virtualization do not need each other but they are related. For example, the ability to decouple an SDN control application from the underlying data plane makes it possible to test and evaluate SDN control applications in
Chapter 2. Context and Related Work 10
2.1.2
SDN Architecture
Similarly to a traditional network, a SDN is composed of network devices. The main dif-ference between them is that in SDN, the network devices are simple forwarding elements without (or with limited) embedded control or software to take autonomous decisions. The network intelligence is removed from the data plane devices to a logically-centralized control system. To ensure the compatibility of communication and configuration and in-teroperability between different data and control plane devices, these new networks are built on top of open and standard interfaces, like OpenFlow [27]. In Figure 2.1 we can see a simplified view of an SDN architecture.
Network Infrastructure
Open southbound API
Controller Platform Network Application(s)
Open northbound API Data Plane Control Plane Management Plane
Figure 2.1: Simplified view of an SDN architecture
In this type of architecture, there are two main elements, the forwarding devices and the controllers. The first ones are specialized in packet forwarding and are part of the data plane. An OpenFlow-enabled forwarding device is based on a set of flow tables. Each entry of a flow table has three parts, a matching rule, actions to be executed on matching packets and counters to keep statistics of matching packets. When a packet arrives, the lookup process starts in the first table and ends with a match in one of the tables (or if a rule is not found). A flow rule can be defined by combining different matching fields, such as switch port, MAC source, MAC destination or VLAN ID. If a rule is not found and there is no default rule, the packet will be discarded. In respect of actions, we can have some actions as forward the packet to outgoing port(s), encapsulate it and forward it to the controller, drop it, send it to the normal processing pipeline or send it to the next flow table. The priority of the rules follows the natural sequence number of the tables and the row order in a flow table [27]. We can see the composition of a flow table in Figure 2.2.
Chapter 2. Context and Related Work 11
FLOW TABLES
RULE ACTION STATS
FLOW TABLE Switch port MAC src MAC dst VLAN ID IP src TCP psrc TCP pdst IP dst Eth typ e Packet + counters
1. Forward packet to port(s) 2. Encapsulate and forward to controller 3. Drop packet
4. Send to normal processing pipeline
Figure 2.2: Flow Table entry
Some of the goals of SDN is to facilitate network management and ease the burden of solving network problems through a logically-centralized control offered by a network operating system (NOS). The controller is a critical element in an SDN architecture and it is located in the control plane. It provides abstractions, essential services and common application programming interfaces to developers. Generic functionality as network state and network topology information, device discovery, and distribution of network configu-ration can be provided as services of the controller. There are a large number of controllers and control platforms with different characteristics. From an architectural point of view, one of the most relevant aspect is if they are centralized or distributed [27].
In a centralized controller, we have just a single entity that manages all forwarding devices of the network. Being a single entity brings some important limitations such as being a single point of failure, and may have scalability limitations. Some controllers are based on multi-threaded designs to explore the parallelism of multi-core computer architectures. With this kind of design, the controllers can achieve the throughput required by enterprises class networks and data centers. Some examples of controllers with these features are NOX-MT [21], Maestro [11] and Beacon [19].
On the other hand, a distributed controller can be a centralized cluster of nodes or a physically distributed set of elements. These controllers can be scaled up to meet the re-quirements of any environment, contrary to a centralized implementation. Some examples of distributed controllers are ONIX [48] or ONOS [40].
An important aspect about distributed controllers is consistency. When we have a cen-tralized element, all information is concentrated in one place. Every read operation, after a
Chapter 2. Context and Related Work 12
fine strategies to guarantee the consistency of data updates. Some distributed controllers offer weak consistency semantics, which means that data updates on distinct nodes will eventually be updated on all controller nodes. On the other hand, we have strong consis-tency. Strong consistency ensures that all controller nodes will read an updated value after a write operation. Despite its impact on system performance, strong consistency offers a simpler interface to application developers, when compared with weak consistency [9].
Other important property is fault tolerance. Whereas a centralized controller repre-sents a single point of failure, in a distributed controller, when a node fails, another node should take over the place and operation of the failed node. So far, despite some con-trollers tolerating crash failures, they do not tolerate arbitrary failures, which means that any node with an abnormal behaviour will not be replaced by a potentially well behaved node [27].
2.2
SDN Security Issues
As explained before, SDN brings more flexibility and the capability of programming the network. SDN provides new ways to solve age-old problems in networking while si-multaneously enabling the introduction of new network policies, such as security and dependability. However, the security and dependability of the SDN itself has been ne-glected. Thinking about SDN characteristics, we verify that the main problems lie on the main benefit of SDN, i.e. the network programmability and control logic centralization. These capabilities introduce new fault and attack planes, which open the doors for new threats [52]. Next, we will describe potential threat vectors that may enable the exploit of SDN vulnerabilities.
2.2.1
Threat Vectors
SDN have two properties that can be exploited by malicious users: the ability to control the network by means of software, and the centralization of the network control logic in the controller. Anyone with access to the servers that host the control software can potentially control the entire network. We can divide the SDN threats into two groups: the threats that are specific of SDN and are not present in traditional networks, and the threats that are not specific of SDN but their impact may be potentially augmented when compared with traditional networks. Table 2.1 summarizes the threats that we will de-scribe [52].
Threats Non-Specific to SDN
Chapter 2. Context and Related Work 13
Specific
to SDN? Description Consequences in SDN Possible Solutions
No
Forged or faked traffic flows
Can be a door for DoS attacks Intrusion Detection Systems Attacks on vulnerabilities in switches The impact is potencially augmented Software attestation, monitor and detection of abnormal behavior Attacks on and vulnerabilities in administrative stations The impact is potencially augmented Protocols with double credential verification and assured recovery mechanisms Lack of trusted resources for forensics and remediation It is still critical to assure fast recovery and diagnosis when
fault happens
Logging and tracing data and control planes with logs stored in remote and secure environments Yes Attacks on and vulnerabilities in controllers Controlling the controller may compromise the entire
network
Replication, diversity, recovery and security policies Lack of mechanisms to ensure trust between the controller and management applications Malicious applications can now be easily
developed and deployed on controllers Autonomic trust management Attacks on control plane communications Communication with logically centralized controllers can be explored Oligarchic trust models with multiple trust-anchor certification authorities, threshold cryptography, and dynamic, automated
and assured device association
Chapter 2. Context and Related Work 14
The first threat we describe is faking traffic flows. In a network, the traffic flows can be forged or faked by a faulty (non-malicious) device or by a malicious user that can be used to attack switches and controllers. An attacker can use network elements to launch a DoS attack against the switches and controller resources. A possible solution to this problem is the use of intrusion detection systems with support for run-time root-cause analysis to help identify abnormal flows. Second, all elements of a network can see their vulnerabilities explored and switches are no exception. One single switch could be used to drop or slow down packets in the network, clone or deviate network traffic, or even inject traffic or forged requests to overload the controller or other switches. A possible solution to this second threat is the use of mechanisms of software attestation or mechanisms to monitor and detect abnormal behavior of network devices. Besides the switches, the administrative stations may also see their vulnerabilities explored. These machines are already an exploitable target in current networks, the difference being that a single compromised machine increases dramatically the threat in SDNs. With this, an attacker can access the network controller and control or reprogram the entire network from a single location. A possible mitigation is the use of protocols requiring double credential verification. Assured recovery mechanisms may also be useful to guarantee a reliable state after reboot. When a problem is detected, it is important to understand the cause and perform a fast and secure recovery. For that purpose, we need reliable information from all components and domains of the network. The saved data can only be used if its trustworthiness can be assured, i.e. integrity, authenticity, etc. To guarantee a fast and correct recovery of the elements of network, we thus need secure and reliable system snapshots. Logging and tracing are the common mechanisms in use, and are needed both in the data and control planes. The created logs should be stored in a remote and secure environment [52].
Threats Specific to SDN
All the threat vectors mentioned above exist in current networks. In an SDN, these same problems exist, but are exponentiated by the characteristics of this architecture (e.g. an attacker can easily control all the network if he has access to the controller). To make matters worse, there are other threats that are specific of SDN. First, in SDN the controller is a new element of the network and like the other elements, its vulnerabilities can be explored. An attack on a controller is probably the most severe threat to SDNs. A faulty or malicious controller could compromise an entire network. In this case, the use of a common intrusion detection system may not be enough, as it may be hard to find the exact combination of events that trigger a particular behavior and, more importantly, to label it as malicious. To try to solve this threat, several techniques can be used, such as replication, employing diversity of controller, protocols, or programming languages, and recovery. Replication allows to detect, remove or mask abnormal behavior and recovery
Chapter 2. Context and Related Work 15
allows to periodically refresh the system to a clean and reliable state. Second, it is also important to secure all sensitive elements inside the controller.
An important threat falls on the communications between the three planes. First, the communication between the controller and management applications. There are not many mechanisms to ensure trust between both controller and applications. It is required the applications to be certificated to guarantee that they are trusted during their lifetime. To that end, we need mechanisms for autonomic trust management. On the other side, we have the communications between the data and control planes. Attacks performed here can be used to generate DoS attacks or for data theft. TLS/SSL can be used for the communications between the controller and the forwarding devices, but it does not per se guarantee secure communication, and that compromises the controller-device link. This last threat will be the focus of study of this work.
2.2.2
Control Plane Communications
Control plane communications represent the most crucial link between controllers and forwarding devices, allowing seamless and flexible on-the-fly remote configuration of the data plane. While this is a desirable and important feature of SDN, the control plane com-munications represent also a new threat vector and are one of the weakest links from a se-curity and dependability viewpoint [52, 53]. By compromising or controlling the control plane communications an attacker can easily take over the entire network. As an example, a man-in-the-middle attack can be a challenging threat from the security perspective since there is no easy or simple way to detect it because the “brain of the network” is now in the controller. In fact, compromised OpenFlow-enabled forwarding devices can be used for man-in-the-middle attacks (both on in-band and out-of-band control plane channels) that are nearly impossible to detect [3]. In other words, the lack of strong security mechanisms (e.g., identification, authentication, authorization, integrity verification, and so forth) on control plane communications is an open avenue for maliciously reprogramming the data plane and, eventually, take over the real control of the network.
Despite a few recent efforts on improving the security of SDN controllers, such as creating security domains to isolate applications, [69, 71, 70], the security of SDN is still reduced to the optional use of TLS [62] and principles and practices recently published
by ONF1 [63]. From a practical perspective, the number of SDN controllers and
switch-ing hardware that supports TLS is still reduced [27]. As in-band is a common mode of operation (using the same infrastructure for both data and control plane traffic), control plane communications are vulnerable to several attacks [52, 53]. With the current state of affairs, a single malicious forwarding device can easily intercept control traffic and be-come a dangerous threat to the SDN infrastructure. It is also worth emphasizing that the
Chapter 2. Context and Related Work 16
use of TLS and best principles and practices is a good start, yet insufficient for building secure and dependable SDN architectures by design.
We estimate the slow rate of adoption of TLS to have three main causes. First, using secure communications has a non-negligible cost in terms of communications latency and scalability. Several studies have analyzed this overhead in some detail recently, in various contexts [25, 67, 28]. For example, a recent paper has examined the cost of the “S” in HTTPS and one of its conclusions was the perceptible impact of security in terms of latency [28]. Second, TLS relies on a Public Key Infrastructure (PKI) as an anchor of trust. Unfortunately, the PKI is complex [22], expensive [74], prone to failure, and a recurrent target of successful attacks [60]. In fact, the number of incidents related to PKI has been increasing at a fast pace and has no sign to stop [18, 8, 45]. Not surprisingly, recent findings show that the vast majority of large enterprises has already experienced at least one trust exploit [45]. Third, TLS itself is complex and implementations are recurrently a target of attacks and vulnerabilities [51, 35]. Different weaknesses of the TLS are related to the its own design, such as coupled and complicated interactions among distinct sub-protocols. Similarly, most of the network failures can be directly associated to the inherent complexity of managing them, leading to inevitable human errors [37]. As one would expect, one of the way of making is easier to identify and fix security issues is by reducing the complexity (e.g., by providing modular design and reducing the number of LOC) [51].
2.3
Related SDN Security Work
Next, we describe some related work about SDN security. We will briefly describe Rose-mary [70], FRESCO [69] and AVANT-GUARD [71].
2.3.1
Rosemary
Rosemary is a controller that integrates key safeguards that extend the control layer and impose an independent sandbox around each network application. The main goal of Rose-mary is to prevent applications from performing operations that will otherwise corrupt other widely used OpenFlow controllers. In addition, ROSEMARY also provides com-petitive performance, while supporting its robustness and security features [70].
2.3.2
FRESCO
FRESCO is an application development framework to assist researchers in prototyping new composable security services in OF-enabled networks. FRESCO is intended to ad-dress several key issues that can accelerate the composition of new OF-enabled security
Chapter 2. Context and Related Work 17
services and it exports a scripting API that enables security practitioners to code secu-rity monitoring and threat detection logic as modular libraries. With FRESCO is possible to replicate a range of essential security functions, such as firewalls, scan detectors, at-tack deflectors, or IDS detection logic. FRESCO modules can produce flow rules, and thus provide an efficient means to implement security directives. FRESCO is designed to address the issues of developing and deploying complex OF security services [69].
2.3.3
AVANT-GUARD
AVANT-GUARD is a security extension to the OpenFlow data plane. The extension is made by adding two modules, a connection migration module (to add intelligence to the data plane to differentiate those sources that will complete TCP connections from sources that will not) and an actuating trigger module (which enable the data plane to asyn-chronously report network status and payload information to the control plane). AVANT-GUARD also slightly modifies existing data plane modules to support other features. The goal of AVANT-GUARD is to make SDN security applications more scalable and respon-sive to dynamic network threats [71].
2.4
Security Tools and Techniques
This section is reserved to describe the security tools and techniques that will be used during this work. Initially we talk about hash and MAC primitives. These cryptographic primitives will be analysed, evaluated and used in our proposal. Next we describe the Transport Layer Security Protocol. This security protocol is optionally used by Open-Flow. We also describe other security tools and techniques, such as the iCVV, one-time password, NaCl, Diffie-Hellman or KDF. These elements will be used later in the design of the solution or in our evaluation.
2.4.1
Hash and MAC Primitives
Hash functions can be used to generate output data with fixed size from input data with arbitrary size. They are widely used in cryptography. Hash functions are useful to easily generate a hash value from arbitrary input data, whereas the opposite is difficult. That is, by knowing the hash value it is computationally very hard to obtain the original input data. The input data is often called message, and the hash value is often called digest. Hash functions can be used for digital signatures, message authentication codes (MAC) and other forms of authentication. The cryptographic hash functions should be strong enough to resist to all known types of cryptanalytic attack. A hash function h must have
Chapter 2. Context and Related Work 18
1. Preimage resistance: for all pre-specified outputs, it is computationally infeasible
to find any input which hashes to that output, i.e., to find any preimage x0 such that
h(x0) = y, when given any y for which a corresponding input is not known.
2. 2nd-preimage resistance: it is computationally infeasible to find any second in-put which has the same outin-put as any specified inin-put, i.e., given x, to find a
2nd-preimage x0 6= x such that h(x) = h(x0).
3. Collision Resistance: it is computationally infeasible to find any two distinct inputs
x, x0 which hash to the same output, such that h(x) = h(x0).
Some examples of cryptographic hash functions are MD5, SHA-1, SHA256, SHA-512, or RIPEMD-160 [49].
As mentioned above, cryptographic hash functions can be used for message authenti-cation codes (MAC). A MAC is a value produced from a message and a secret key that is shared by the sender and the receiver. A MAC generated by one of these peers (say, the sender) can only be validated by this receiver, as she is the only one who knows the key. There are several ways to generate a MAC. A MAC mechanism based on cryptographic hash functions is called Hashed-based Message Authentication Code (HMAC). HMAC can be used in combination with any iterated cryptographic hash function and also uses a secret key for calculation and verification of the message authentication values. The key for HMAC can be of any length. However, less than the length of the digest is strongly discouraged. Keys need to be chosen at random (or using a cryptographically strong pseudo-random generator seeded with a random seed), and periodically refreshed [66].
The definition of HMAC requires a cryptographic hash function, which we denote by h, and a secret key K. We denote by B the byte-length of blocks of data used by a basic compression function and by L the byte-length of the digest. We define two fixed and different strings ipad and opad, where ipad is the byte 0x36 repeated B times and opad is the byte 0x5C repeated B times. To compute HMAC over the data text we perform [66]
HM AC = h(K ⊕ opad, h(K ⊕ ipad, text)) (2.1)
The security of the HMAC depends on the cryptographic properties of the hash func-tion. These properties are the collision resistance (limited to the case where the initial value is secret and random, and where the output of the function is not explicitly avail-able to the attacker), and the message authentication property of the compression function when applied to single blocks [66].
2.4.2
The Transport Layer Security Protocol
The Transport Layer Security Protocol is the security protocol optionally used by Open-Flow. The main goal of the TLS protocol is to provide privacy and data integrity between
Chapter 2. Context and Related Work 19
two communicating applications [17]. The TLS protocol also seeks interoperability (pro-grammers should be able to develop applications with exchange of cryptographic param-eters without knowing the code of the other programmer), extensibility (incorporate other elements without the need of create a new protocol and avoid the need of implement an en-tire new security library) and relative efficiency (incorporate an optional session caching scheme to reduce the number of connections that need to be established from scratch).
TLS Record Protocol
As shown in Figure 2.3, one of the layers of the protocol is the TLS Record Protocol. The TLS Record Protocol provides connection security with two basic properties. First, the connection is private. Symmetric cryptography is used for data encryption and the keys used for symmetric cryptography are generated uniquely for each connection and are based on a secret negotiated by another protocol. The Record Protocol can be used with-out encryption. The second property is the reliability of the connection. Message transport include a message integrity check using keyed MAC and secure hash functions are used for MAC computations. The Record Protocol can also operate without a MAC [17].
TLS Handshake
Other layer of TLS, that we can observe in Figure 2.3, is the TLS Handshake. The TLS Handshake Protocol allows the server and client to authenticate each other and to negotiate an encryption algorithm and cryptographic keys before the application protocol transmits or receives its first byte of data. The TLS Handshake protocol provides connection se-curity with three basic properties. First, the identity of the elements of a communication can be authenticated using asymmetric, or public key, cryptography. This authentication can be made optional, but it is generally required for at least one of the elements. Second, the negotiation of a shared secret is secure. That means, in any authenticated connection, the negotiated secret cannot be obtained, even by an attacker who can place himself in the middle of the connection. Finally, the negotiation is reliable. That means no attacker can modify the negotiation communication without being detected by the parties to the communication [17].
During handshaking, for identification purposes, the server must send a certificate. Usually, a certificate contains the server name, the trusted certificate authority (CA) and the public encryption key of the server. These certificates are documents with expiration time limited. When the time expires, the certificate is no longer valid. The client only sends a certificate if he has a request from the server.
In Figure 2.4, we can see the twelve steps of the TLS Handshake protocol. The client initiates the protocol by sending a Client Hello message. The server responds with a
Chapter 2. Context and Related Work 20 HTTP FTP IMAP Other Application Layer Handshake Protocol Cypher Change Protocol Alert Protocol Handshake Layer Record
Layer Record Protocol
TCP/IP
Transport Layer TLS/SSL
Figure 2.3: TLS/SSL Protocol Layers
security enhancement capabilities between both parts. Next, the server will send its cer-tificate in a Cercer-tificate message and ask for the client cercer-tificate. To finish the handshake phase of the protocol, the server sends a Server Hello Done message. The server will then wait for a client response. The client sends its certificate and the Client Key Exchange message. The content of that message will depend on the public key algorithm selected between the ClientHello and the ServerHello. Next, the client sends a Change Cipher Spec message and the client copies the pending Cipher Spec into the current Cipher Spec. The client then immediately sends the Finished message under the new algorithms, keys, and secrets. In response, the server will send its own Change Cipher Spec message, trans-fer the pending to the current Cipher Spec, and send its Finished message under the new Cipher Spec. At this point, the handshake is complete, and the client and server may begin to exchange application layer data [17].
As stated above, a number of operations in the TLS record and handshake layer re-quire a keyed MAC to protect message integrity or to construct key derivation functions. For all versions of TLS the construction used is an HMAC. However, in TLS 1.2 other cipher suites may define their own MAC constructions, if needed [17]. In the TLS hand-shake layer, the HMAC can be used with several hash algorithms. For handshaking, TLS 1.0 and TLS 1.1 can use two different algorithms, MD5 (HMAC MD5) and SHA-1 (HMAC SHA). Other hash algorithms can be defined by cipher suites and used to pro-tect record data, but MD5 and SHA-1 are hard coded [16]. TLS 1.2 moved away from the hard coded MD5 and SHA-1. When TLS 1.2 is negotiated, the default hash function for all cipher suites defined is SHA-256. TLS 1.2 also advices the use of SHA-256 or a stronger standard hash function for new cipher suites [17]. Another important element
Chapter 2. Context and Related Work 21
1. ClientHello 2. Server Hello
6.Client Certificate 3. Server Certificate 4.Client Certificate Request
5. Server Hello Done 7. ClientKey Exchange
8. Certificate Verify 9. Change Cipher Spec
10. Finished 11. Change Cipher Spec
12. Finished
Client Server
Figure 2.4: TLS Handshake Protocol (with mutual authentication)
in TLS handshaking is the Pseudo-Random Function (PRF). The PRF is used to calcu-late the master secret, calcucalcu-late session keys, and verify the negotiated algorithms. For TLS, the definition of the PRF is based on HMAC. The PRF takes as input a secret, a seed, and an identifying label and produces an output of arbitrary length [17]. For TLS 1.0 and TLS 1.1, the PRF is created by splitting the secret into two halves and using one half to generate data with P SHA-1 and the other half to generate data with P SHA-1, then exclusive-or’ing the outputs of these two expansion functions together [16]. The expression for PRF is the following,
P RF (secret, label, seed) = P M D5(S1, label + seed) ⊕ P SHA1(S2, label + seed) (2.2) where S1 and S2 are the two halves of the secret and + indicates a concatenation. PRF for TLS 1.2 is based on HMAC as well, but does not require spliting the secret. This way only one hash function is used [17]. The expression for PRF is the following,
P RF (secret, label, seed) = P hash(secret, label + seed) (2.3)
where + indicates a concatenation.
In order to begin connection protection, the TLS Record Protocol requires specifica-tion of a suite of algorithms, a master secret, and the client and server random values. For all key exchanged methods, the same algorithm is used to convert the pre master secret into the master secret. The master secret is always exactly 48 bytes in length. The length of the pre master secret will vary depending on the key exchange method [17]. There
Chapter 2. Context and Related Work 22
RSA is used for server authentication and key exchange, a 48-byte pre master secret is generated by the client, encrypted under the public key of the server, and sent to the server. The server uses its private key to decrypt the pre master secret. Both parties then convert the pre master secret into the master secret. In the Diffie-Hellman method, the negotiated key is used as the pre master secret, and is converted into the master secret. Diffie-Hellman parameters are specified by the server and may be ephemeral or contained within the certificate of the server [17].
A fundamental element for TLS is the Public Key Infrastructure (PKI). PKI is used to manage digital certificates and public-key encryption [2]. One popular implementation of a PKI is EJBCA.
2.4.3
iCVV
The iCVV (integrated Circuit Card Verification Value) is used in credit cards to authenti-cate and authorize transactions in a secure and inexpensive way. There is a unique check value encoded on the magnetic strip of every card, which is validated during the authoriza-tion process for the transacauthoriza-tion to detect counterfeit cards, protecting against the copying of magnetic-strip data. iCVV is calculated from data encoded on the magnetic strip using a secure cryptographic process [77]. The main advantage of the iCVVs is that they are not expensive (can be easily computed even by low power device such as smart cards) and a secure way of authorizing transactions.
2.4.4
One-Time Password
A one-time password is a password that is valid for only one login session or operation. oPass [73] is one such technique where the one-time password is generated by means of a secure one-way hash function. With a given input, the set of one-time passwords is established by a hash chain through multiple hashing. Assuming we wish to prepare N one-time passwords, the first of these passwords is produced by performing N hashes on input c. The next one-time password is obtained by performing N-1 hashes, and so on. So, the general formula that define these steps is
δi = hN −1(c) (2.4)
For security reasons [73], one-time passwords are used in reverse order. If an old one-time password is leaked, the attacker is unable to derive the next one. Besides, the input c is derived from a long-term password P , the identity of the server (ID), and a random seed (S) generated by the server, according the following expression
Chapter 2. Context and Related Work 23
2.4.5
Networking and Cryptography Library (NaCl)
NaCl [7] is a cryptographic library, designed and implemented to address and solve the problems created by other libraries, such as OpenSSL. NaCl is a clean slate implementa-tion of primitives for authenticated public-key and authenticated shared-key encrypimplementa-tion, public-key and shared-key signatures, hashing, keyed hashes for short messages, and se-cure pseudo-random numbers generation. It provides a simple and easy to use API. This, by itself, significantly reduces the likelihood of mistakes because developers do not need to worry about all the details for correctly setting up secure communications. NaCL is an attempt to provide a less complex, efficient, yet provably secure alternative to OpenSSL-like implementations. Its security has been thoroughly scrutinized. Moreover, researchers have already developed automated formal verification methods for NaCl, which prove the resistance against different classes of side-channel attacks, such as timing [31].
2.4.6
Diffie-Hellman
Diffie-Hellman is a method for key agreement that requires both the sender and the re-ceiver of a message know a key pair. By combining one’s private key and the other public key, both elements can compute the same shared secret number. This number can then be converted into cryptographic keying material. That keying material is typically used as a key-encryption key to encrypt a content-encryption key which is in turn used to encrypt the message data [64].
2.4.7
KDF
Key derivation functions (KDFs) are used to generate secure cryptographic keys, i.e., keys that can resist to different types of attacks such as brute force and exhaustive key search attacks [79, 50]. KDFs have common design characteristics, such as strong hash functions
to compute digests for the raw key material. A secure KDF can be defined as H(c)(p||s||c)
[79]. H is a strong hash function such as SHA256 or SHA512 [1]. The exponent c rep-resents the number of iterations used to make the task of the attackers harder. A common
value for c is 216. This exponent is particularly necessary if the entropy of the input p
(e.g., password, seed, key) is unknown. In practice, the input of the KDF is likely to be of low-entropy [79, 42]. While in some use cases a high exponent c might be necessary to increase the cost of an attack trying to recover the key, it also significantly increases the cost of the key derivation function latency-sensitive applications.
Given the context and the introduction of the problems, in the next chapter we present a new security architecture for SDN that offers the same level of security of traditional
Chapter 3
The SDN KISS: An Architecture for
Keeping It Simple and Secure
As explained in Section 2.2.2, control plane communications represent one of the the weakest link of SDN, from a security point of view. Attacks in the control plane com-munications can lead to critical security breaches. To address this issue, we make two contributions in this dissertation, which are motivated by the slow adoption of TLS and the principles and practices recommended by ONF. We estimate the slow adoption of security mechanisms to be due, to a good extent, to two problems: the performance im-pact of security mechanisms and the complexity of the supporting infrastructures (i.e., the PKI).
First, we investigate the impact of essential security primitives on the performance and scalability of control plane communications. In particular, we investigate the impact of hashing and MAC primitives which are used by nearly all security protocols. Our goal is to understand how these primitives affect the control plane performance to allows us to select the ones that offer a good trade-off between security and performance.
Second, we propose an innovative security architecture for SDN. The main goal of our architecture is to offer the same security guarantees as traditional infrastructures, TLS and the PKI, but increasing its robustness (by reducing the threat surface) and its performance (by using the security primitives and implementations that present lower overhead).
The design of our solution includes a novel component, the integrated device veri-fication value (iDVV). Its idea was inspired by the iCVVs (integrated card veriveri-fication values) used in credit cards to authenticate and authorize transactions in a secure and inexpensive way. We develop the idea for SDN, proposing a flexible method of generat-ing iDVVs by adaptgenerat-ing proven one-time password techniques and efficient cryptographic primitives. iDVVs can safely replace existing key-exchange protocols and key deriva-tion mechanisms, such as those used in TLS [16] and IKEv2bis [24], in the context of SDN. iDVVs are simpler and faster to generate, making them a good choice for provid-ing stronger security for communications (e.g., by ensurprovid-ing one authentication code per packet).
Chapter 3. The SDN KISS: An Architecture for Keeping It Simple and Secure 26
The architecture relies on an anchor of trust that provides “logically-centralized” se-curity services such as device registration and association. The anchor of trust is also responsible for providing strong security by means of a source of strong entropy and a re-silient pseudorandom generator. This is particularly crucial to avoid the recurrent security incidents caused by weak sources of entropy, which compromise the strength of crypto-graphic keys [39, 30, 46] (this has been identified as a wide spread problem in networking devices) and are the cause of many security pitfalls of computer systems [76].
3.1
Security and Performance Analysis
In this section we provide an insight on the impact of cryptographic primitives on con-trol plane communications. Hashing and MACs are the essential primitives for providing security properties such as authenticity and integrity in protocols used for securing com-munications. We compared the performance of several hashing and MAC primitives, including different implementations such as those provided by the OpenSSL (version 1.0.0) and PolarSSL (version 1.3.9) libraries, two of the most widely used SSL imple-mentations. PolarSSL has been used for different applications, including post quantum SSL/TLS for embedded platforms [12]. The primitives were evaluated on an Intel Core i3-3217U 1.80GHz with 256KB L2 / 3MB L3 cache, 4GB SODIMM at 1600MHz, with hyper-threading enabled and running Ubuntu Desktop 14.04 LTS. Before running the ex-periments we turned off overclocking and dynamic CPU frequency scaling. We fixed the frequency of each core to its highest value (e.g., 1800MHz). To measure the execution latency we used Linux’s resource usage system call (getrusage()) to get only the user CPU execution time. This allowed us to obtain fine-grained measurements.
3.1.1
Connection and Communication Costs
Our first experiments assess the performance of TCP and TLS on control plane commu-nications. We analyze the latency of connection setup and latency of the communica-tions. The controllers and forwarding devices are emulated and implemented in C, using OpenSSL and PolarSSL. We ran the standard configuration for both libraries, i.e., with-out any library-specific optimizations. The numbers we present in this section represent the median of 10 thousand executions. The standard deviation is very small and it is imperceptible in the graphs.
The connection setup time (per forwarding device) is shown in Figure 3.1. The higher cost of TLS is a result of the handshake between the devices. While TCP uses a simple three-way handshake, TLS imposes a far more complex handshake of twelve messages for mutual authentication between the communicating entities. As expected, the overhead
increases non-linearly (note the plot is log10in the y axis and log2 in the x axis) with the
