«Implementation and Performance Analysis of Firewall on Open vSwitch Interdisziplinares Projekt in der Elektrotechnik ¨ durchgef¨hrt am u Lehrstuhl ...»
Technische Universit¨t Munchen
Fakult¨t f¨r Informatik
Lehrstuhl f¨r Netzarchitekturen und Netzdienste
Implementation and Performance
Analysis of Firewall on
Interdisziplinares Projekt in der Elektrotechnik
Lehrstuhl f¨r Netzarchitekturen und Netzdienste
Fakult¨t f¨r Informatik
Technische Universit¨t M¨nchen
Aufgabensteller: Prof. Dr.-Ing. Georg Carle
Betreuer: M.Sc. Cornelius Diekmann and M.Sc. Florian Wohlfart Tag der Abgabe: 29. April 2015 Ich versichere, dass ich die vorliegende Arbeit selbst¨ndig verfasst und nur die angegebenen a Quellen und Hilfsmittel verwendet habe.
Garching, den 29. April 2015
Software Deﬁned Networking (SDN) is a current research trend that follows the ideology of physical separation of the control and data plane of the forwarding devices. SDN mainly advocates with two types of devices: (1) Controllers, that implement the control plane and (2) Switches, that perform the data plane operations. OpenFlow protocol (OFP) is the current standard through which controllers and switches can communicate with each other.
Using OpenFlow, SDN controllers can manage forwarding behaviors of SDN switches by managing Flow Table entries. Switches use these low-level Flow Table entries to forward packets to appropriate hosts.
Firewalls are integral part of today’s networks. We can’t imagine our network without a Firewall which protects our network from potential threats. As SDN is getting pace in replacing traditional architecture, it would be very interesting to see how much security features can be provided by OpenFlow-enabled switches. Hence, it will be very important to see if SDN, on the top of OpenFlow, can eﬃciently implement Firewalls and provides
support for an advanced feature like connection tracking. The task is straightforward:
Controller will add Flow Table entries on switches based upon Firewall rules. Such way, we can enhance packet-processing by providing security.
In this Document, one strategy for implementing Firewall on SDN is presented. We can write some controller applications that work as Firewall and inspect incoming packets against the Firewall rules. These applications are also able to implement connection tracking mechanism. As SDN devices for the experiments, we selected Ryu controller and Open vSwitch. Initially, such applications are tested on local machine with small Firewall ruleset. Later, they are tested with real-world traﬃc and comparatively large Firewall ruleset.
The testing results present that such strategy can be used as a ﬁrst step in implementing security features (including connection tracking) in SDN environment.
This chapter illustrates the technologies that are used in this IDP. Section 1.1 discusses the concept and need for Software Deﬁned Networking along with architectural diagram.
In the next Section 1.2, OpenFlow protocol, message exchange types and Open vSwitch are explained. Ryu controller, its architecture & features are described in Section 1.3, whereas Section 1.4 demonstrates Firewall and its implementation strategy on Ryu.
1.1 Software Deﬁned Networking Software Deﬁned Networking (SDN) is a rising network architecture which splits the functions of networking devices into two groups, namely network control and forwarding; where network control is directly programmable. Earlier, these functions were tightly coupled within a device. But, since they are separated into two individual functions, they make network a logical entity by abstracting the underlying complex architecture for upper layer networking applications and services .
SDN has risen from the failure of current networking technologies to meet current market needs ,. Static nature of a network fails to adapt network traﬃc and user demands that are tremendously growing. Carriers and enterprises seek to deploy new capabilities and services, however lack of standard and open interfaces between networking devices limit their abilities. Although enterprises are encouraging cloud services, scaling of computing and networking resources has been a painful task yet to be solved. These issues put forward a need of a new standard which should be capable of overcoming them; and hence, Software Deﬁned Networking has been introduced ,.
The architecture of Software Deﬁned Networking, which is illustrated in Figure 1.1, consists of 3 major parts, namely Application Layer, Control Layer and underlying Infrastructure Layer. Unlike traditional network architecture where each device possesses a separate control plane, in SDN architecture it is taken out and made centralized on a remote process (called controller) running at Control Layer. This remote process (controller) provides global view of the network. As a result, the applications and services running at Application Layer appear to be running on a single, logical network switch. Network carriers and companies face signiﬁcantly less complexity in designing and operating a network since the Infrastructure Layer becomes vendor-independent with the introduction of SDN. Infrastructure Layer devices (for example: switches and routers which are also referred as forwarding devices) should be conﬁgured to understand instructions from SDN controllers only. This makes the conﬁguration process easy and fast.
2 1. Problem Analysis
Figure 1.1: Software Deﬁned Networking: Architectural Diagram 
Since the Control Layer has become programmable, Network Managers can easily conﬁgure the state of the network by writing some SDN programs . These programs break the vendor speciﬁc software dependencies of the devices and make them self-contained.
In addition to network abstraction, common network services like routing, multicasting, security, load balancing etc. can also be implemented on SDN architecture to achieve business objectives . These advantages and features make SDN right candidate to overcome current network problems and establish a new norm of Networking.
1.2 OpenFlow and Open vSwitch 1.2.1 Introduction to OpenFlow OpenFlow Protocol(OFP) is the ﬁrst, industry-speciﬁed, standardized SDN protocol which deﬁnes a way for the controller to communicate with switches. The purpose behind it is to provide standardized speciﬁcation for communication interfaces of Control and Infrastructure Layer devices. It allows manipulation of the data stored on forwarding devices to reﬁne policy-based decision for packet forwarding .
OpenFlow is implemented on both ends of communication: On SDN controller and on forwarding devices. With OpenFlow, each forwarding device can export their network interfaces to the controller which will manage their forwarding states. The managed states are segregated into Flow Tables on such devices, which are nothing but set of packet header ﬁelds and associated actions. Some examples of these set of ﬁelds are standard Ethernet, IP and transport protocol ﬁelds which are roughly equivalent to the ﬁelds used in ASIC match. The actions associated with these ﬁelds are basically common packet operations like sending a packet to some ports or modifying protocol ﬁelds . OpenFlow has been consistently revising under various versions and in this IDP, OpenFlow version 1.3 is used.
Deploying OFP-enabled SDN on physical (and virtual) networks is thought to be an easy process for an enterprise to gradually introduce SDN on the existing network infrastructure.
This is because OFP enabled switches can forward packets based on matching rules as well as in traditional manner. Even in multi-vendor network infrastructure, carriers can easily deploy it ignoring vendor dependencies. According to the opennetworking.org, OpenFlow protocol is currently the only standardized SDN protocol that allows direct manipulation of
1.2. OpenFlow and Open vSwitch 3 the forwarding plane of network devices, which makes it a key enabler for software-deﬁned networks .
1.2.2 OpenFlow Events and Messages The OpenFlow protocol implementation is done between two devices by exchanging series of OpenFlow negotiation messages. It supports three message types, namely controllerto-switch, asynchronous, and symmetric; each with multiple sub-types. Controller-toswitch messages are sent by the controller to directly manage the state of the switch.
Asynchronous messages are sent by the switch in order to notify the controller about network events and changes made to the switch state. Symmetric messages are sent by either the switch or the controller to one another without prior request. Messages are summarized in Table 1.1 .
1.2.3 Open vSwitch According to ovs.org, Open vSwitch (OVS) is an open source software switch designed to be used as a “virtual switch“ in virtualized server environments. The goal of OVS is to implement a switching platform that enables standard, vendor-independent management interfaces and opens the forwarding functions of switches to programmatic extension and control . It supports all versions of OpenFlow protocol. Using ovs-ofctl tool, any desired OpenFlow version can be implemented on a physical switch.
Simply, Open vSwitch is a “software switch“ which implements OpenFlow protocol on switching hardwares . It manages the Flow Tables for the Datapaths which are used for forwarding the incoming traﬃc according to matched entries. The structure of Flow Table entries is explained in the Table 1.2.
• Counters: number of received packets matching this rule
• Instructions: Used to modify the action to be applied on the packet
• Timeout: The number of seconds this Flow Table entry lives in the Table
• Cookie: Opaque value chosen by controller. Not used while processing a packet.
Used by controller Figure 1.2 shows the example of entries within a Flow Table.
1.3 Ryu 1.3.1 Introduction Ryu  is a component-based SDN framework which delivers a suitable platform for SDN applications to run on the top of Ryu controller. It is an open source tool written in Python that provides well-deﬁned APIs & packet libraries and supports all versions of OFP. It is well tested with various OpenFlow switches and suits well on Open vSwitch which is used in this IDP. Ryu has a powerful but complex architecture. However, its active community support, nice documentation and few exemplary applications provide novice developers a room to understand and get adapted to the environment easily. There are numerous controllers that deliver SDN capabilities, but choosing the best of them is confusing for the developers. As a research was carried out with number of controllers, Ryu has been selected as the best controller choice for SDN environment .
The following Figure 1.3 depicts the role and features of Ryu SDN framework .
1.3.2 Ryu Architecture
1. Ryu manages two threads for sending and receiving the packets to and from the switch. Upon receiving a packet, controller’s Receive Thread stores the packet in a receiving queue. This packet is nothing but only raw bytes and yet to be parsed in order to understand the OFP message that it has carried. To understand the OFP message, controller calls an OFP parser (parser ﬁle: ofproto v1 N parser.py where N is the protocol version negotiated with the switch upon connection).
2. OFP Parser will generate appropriate OFP event by parsing the packet and labels it as ‘OFPxxx‘. As for example, a ‘Packet In‘ event becomes ‘OFPPacketIn‘ event .
3. On the other hand, RYU applications that are running on the top of RYU framework, maintain queue of events. Applications register event handlers dynamically according to their speciﬁcation to the Event Dispatcher. It simply means that RYU applications are waiting for necessary events to occur in order to start execution.
5. These events are dispatched to event queues of RYU Apps. As shown in Figure 1.6, each RYU App runs a thread over the event queue to consume the events. Only one instance of RYU app can run at a moment .
1.4 Firewall on SDN Controller Firewalls are the systems which control the incoming and outgoing packets to and from the inner network. They provide security barrier against potential attacks coming from the Internet that can disrupt the services running in the inner network. Firewalls are divided into 2 types: Stateful Firewall and Stateless Firewall. In Stateful Firewall, the connection is tracked by the Firewall and the packets part of the tracked connection, are allowed to pass by. Stateful Firewall uses attributes in order to track the traversing packets. These attributes include the source and destination IP addresses, port numbers and sequence numbers which are also known as state of the connection. In our Ryu application, we will use a Python dictionary to implement connection tracking mechanism of Stateful Firewall.
In contrast, Stateless Firewall checks all incoming packets individually with the ruleset. It does not track connections nor keeps state of the traversed packets, rather simply check each packet with Firewall rules and identiﬁes whether the packet is allowed to pass by or not. It assumes that the information within a packet is trustworthy. Hence, one possible breach could be: a TCP SYN-ACK packet can be passed by the Firewall before the Firewall has seen a TCP SYN packet. With the Stateful Firewall case, such a packet will be discarded by the Firewall itself as there is no state information found for the packet.
The goal of this IDP is to implement both types of Firewall applications with real-world Firewall rules on SDN architecture and analyse the performance of the controller & the applications with incoming traﬃc.