mopdf.com

1.2. OpenFlow and Open vSwitch3the forwarding plane of network devices, which makes it a key enabler for software-definednetworks [1].1.2.2OpenFlow Events and MessagesThe OpenFlow protocol implementation is done between two devices by exchanging seriesof 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 aboutnetwork events and changes made to the switch state. Symmetric messages are sent byeither the switch or the controller to one another without prior request. Messages aresummarized in Table 1.1 [9].TypeSymmetricController SwitchMessageDescriptionHelloEchoFeature RequestSet ConfigurationVersion Numbers are negotiatedSent to detect liveliness of each otherDetermine which switch ports are availableController asks switch to inform about FlowTable entry expirationsIt tells switch to send packets out of specificport. It is also used to forward packetsreceived via Packet In messagesTransfer control of the packet to controllerInform controller about a change on a portPacket OutPacket InPort StatusAsynchronousTable 1.1: OpenFlow protocol: Messages Types1.2.3Open vSwitchAccording to ovs.org, Open vSwitch (OVS) is an open source software switch designed tobe used as a “virtual switch“ in virtualized server environments. The goal of OVS is toimplement a switching platform that enables standard, vendor-independent managementinterfaces and opens the forwarding functions of switches to programmatic extension andcontrol [10]. It supports all versions of OpenFlow protocol. Using ovs-ofctl tool, anydesired OpenFlow version can be implemented on a physical switch.Simply, Open vSwitch is a “software switch“ which implements OpenFlow protocol onswitching hardwares [11]. It manages the Flow Tables for the Datapaths which are usedfor forwarding the incoming traffic according to matched entries. The structure of FlowTable entries is explained in the Table 1.2.Match le 1.2: Flow Table Entry structure Match Fields: will be matched against incoming packets. It includes packet headerand input port Priority: matching priority for this Flow Table entry

41. Problem Analysis 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 controllerFigure 1.2 shows the example of entries within a Flow Table.Figure 1.2: Flow Table Entries [9]1.31.3.1RyuIntroductionRyu [12] is a component-based SDN framework which delivers a suitable platform for SDNapplications to run on the top of Ryu controller. It is an open source tool written in Pythonthat provides well-defined APIs & packet libraries and supports all versions of OFP. It iswell tested with various OpenFlow switches and suits well on Open vSwitch which is usedin this IDP. Ryu has a powerful but complex architecture. However, its active communitysupport, nice documentation and few exemplary applications provide novice developersa room to understand and get adapted to the environment easily. There are numerouscontrollers that deliver SDN capabilities, but choosing the best of them is confusing forthe developers. As a research was carried out with number of controllers, Ryu has beenselected as the best controller choice for SDN environment [6].The following Figure 1.3 depicts the role and features of Ryu SDN framework [13].1.3.2Ryu ArchitectureRYU has ‘Event-based‘ architecture. As shown in Figure 1.4, it uses ‘Event Dispatcher‘ forgenerating and handling events from incoming OFP messages [13]. The controller worksas an event source. Explanation about the architecture in a stepwise manner can be foundbelow:

1.3. Ryu5Figure 1.3: Ryu SDN framework1. Ryu manages two threads for sending and receiving the packets to and from theswitch. Upon receiving a packet, controller’s Receive Thread stores the packet in areceiving queue. This packet is nothing but only raw bytes and yet to be parsed inorder to understand the OFP message that it has carried. To understand the OFPmessage, controller calls an OFP parser (parser file: ofproto v1 N parser.py whereN is the protocol version negotiated with the switch upon connection).2. OFP Parser will generate appropriate OFP event by parsing the packet and labelsit as ‘OFPxxx‘. As for example, a ‘Packet In‘ event becomes ‘OFPPacketIn‘ event[14].Figure 1.4: Ryu architecture: Structural Diagram3. On the other hand, RYU applications that are running on the top of RYU framework,maintain queue of events. Applications register event handlers dynamically accordingto their specification to the Event Dispatcher. It simply means that RYU applicationsare waiting for necessary events to occur in order to start execution.4. At this stage, Event Dispatcher plays an important role. It decouples Event source(which is RYU controller) and Event sinks (which is RYU App). Event source willcall the methods of Event Dispatcher to construct event objects (from OFPxxx to

61. Problem AnalysisEventOFPxxx. [Figure 1.5]). Event dispatcher knows to which RYU app it has todispatch an event [13].Figure 1.5: Conversion of an OFPxxx event into EventOFPxxx5. 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 oneinstance of RYU app can run at a moment [14].Figure 1.6: Dispatching the event to Event Sink1.4Firewall on SDN ControllerFirewalls are the systems which control the incoming and outgoing packets to and from theinner network. They provide security barrier against potential attacks coming from theInternet that can disrupt the services running in the inner network. Firewalls are dividedinto 2 types: Stateful Firewall and Stateless Firewall. In Stateful Firewall, the connectionis tracked by the Firewall and the packets part of the tracked connection, are allowed topass by. Stateful Firewall uses attributes in order to track the traversing packets. Theseattributes include the source and destination IP addresses, port numbers and sequencenumbers which are also known as state of the connection. In our Ryu application, we willuse a Python dictionary to implement connection tracking mechanism of Stateful Firewall.In contrast, Stateless Firewall checks all incoming packets individually with the ruleset. Itdoes not track connections nor keeps state of the traversed packets, rather simply checkeach packet with Firewall rules and identifies whether the packet is allowed to pass by ornot. It assumes that the information within a packet is trustworthy. Hence, one possiblebreach could be: a TCP SYN-ACK packet can be passed by the Firewall before theFirewall has seen a TCP SYN packet. With the Stateful Firewall case, such a packet willbe 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-worldFirewall rules on SDN architecture and analyse the performance of the controller & theapplications with incoming traffic.

2. Design and ImplementationIn section 2.1, general structural design of a Ryu application is presented by means ofa Flow-Chart. It also features security limitation of the applications that are developedusing the proposed design. The next section 2.2 covers description about all 4 types ofFirewall applications developed for the purpose of the IDP. It also explains design of thoseapplications in a Flow-Chart manner and compares Inefficient and Efficient applicationsin greater details.2.1Ryu Application - General Template DesignRyu applications can be run via command-line tool called ryu-manager. We developedour Ryu applications to run under OFP version 1.3, hence, connecting switch must usesame protocol version in order to communicate with the controller. Firewall rules arewritten down in a text file which will be taken as an input by Ryu application. Whenthe application starts running, it maps these rules into Python dictionary keys, which willbe used later for packet inspection. As soon as switch connects with the controller, Ryuapplication will flush out all existing Flow Table entries from switch and installs a DefaultMiss Flow entry. Using Default-Miss Flow entry, switch will forward all incoming hosttraffic to the controller where packets will be inspected. Figure 2.1 shows the structuraldiagram of Ryu application.The applications do not include following security features:(1) ARP security: Applications are designed to work at Layer 3 or above. Hence, Layer 2security considerations are not taken into account while designing the applications. Thiscan make ARP spoofing attacks successful.(2) Link layer security: Applications can learn the MAC address of a host from its association with a switch port. However, applications can not verify the associated MACaddress; hence, a spoofed MAC address attack can be successful. More information aboutthe design can be found in E.1.(3) With Stateful Firewall applications, torn down connection can not automatically remove the ’tracked’ state from the application. Hence, A TCP FIN packet does not triggerdeletion of the Firewall’s state.

82. Design and ImplementationFigure 2.1: Flow-Chart: general template design of a Ryu application

2.2. Firewall Implementation as Ryu Applications2.29Firewall Implementation as Ryu ApplicationsUsing a template from previous section, four Ryu applications are developed to measureperformance of Stateful and Stateless Firewall in SDN environment. They are listed below. Inefficient Stateful Firewall application Efficient Stateful Firewall application Inefficient Stateless Firewall application Efficient Stateless Firewall applicationMain difference between these Firewall applications lies within how they inspect incomingpackets and how they speed up packet processing by using Flow Tables. Table 2.1 comparesEfficient and Inefficient Firewall application in general with various parameters.Inefficient FirewallEfficient FirewallTerminologySwitch forwards all receivedpackets to controller. Noextensive use of OFP Flowtables.Connection Trackingcapabilities withStateful FirewallWhich packets of aconnection are seenon controller?How to handle them?YesSwitch forwards only initialpackets of the connection tothe controller. Afterwards,it will use Flow table entriesto forward/drop packetswithout asking controller.YesICMP all PINGs & PONGsTCP all segmentsUDP all datagramsICMP First PING & PONGTCP SYN & SYN-ACK onlyUDP First 2 datagramsSimply inspect each packetindividually against Firewallpolicies. If a policy allows thepacket then inform switch toforward it, otherwise drop it.Flow Table rules tobe added per flowEfficiencyPotential ConnectionTracking AccuracyNoneCheck connection initiationand response packets againstFirewall policies on controller.Add one Flow Table entryper inspection on switch toallow/deny further trafficfrom the host.OneLess100% accurateMorecan approximate after handshakeTable 2.1: Comparison between Inefficient and Efficient Firewall

102.2.12. Design and ImplementationInefficient Stateful Firewall ApplicationAs per terminology, Inefficient Stateful Firewall application makes switch forward all incoming traffic to the controller. It does not store any Flow Table entry on switch thatspeeds up packet processing. When first packet of an unseen flow is received by the controller, the application checks it against Firewall rules and creates new state informationfor that flow. This information will be used later when subsequent reply-packet from destination host shows up at the controller. The application tracks down the reply-packetwith the stored information and learns about newly established connection. Figure 2.2explains the mechanism of Inefficient Stateful Firewall application in detail.Figure 2.2: Flow-Chart: Infficient Stateful Firewall application

2.2. Firewall Implementation as Ryu Applications2.2.211Efficient Stateful Firewall ApplicationUnlike its Inefficient counterpart, here switch will forward only first few packets of a newflow to the controller. Upon receipt of such packets, Firewall application will decodethem, prepare some Flow Table entries according to the Firewall policies and finally addthem upon switch’s Flow Table. This way, Efficient Stateful Firewall application willtake the advantage of OpenFlow’s capability to set Flow Table entries for fast packetprocessing. After that, switch will check incoming packets with the Flow Table entries.Once a matching entry is found, switch will take out necessary action associated withit rather than forwarding the packet to the controller. However, packets which are notmatched with any Flow Table entries are simply forwarded to the controller. Flow Tableactions can be forwarding or dropping depending upon firewall policies.Figure 2.3: Flow-Chart: Stateful Efficient Firewall application

122.2.32. Design and ImplementationInefficient Stateless Firewall ApplicationCompared to 2.2.1 case, Inefficient Stateless Firewall application does not manage anystate information for packet flows. It does not use any connection-tracking feature totrack down ongoing connections; rather simply checks each packet individually against theFirewall rules and takes out necessary action associated with a rule on the packet. As thename suggests, the application will not store any Flow Table entry on switch either, whichmakes it inefficient in terms of packet inspection.(a) Inefficient Stateless Firewall application(b) Efficient Stateless Firewall applicationFigure 2.4: Flow-Charts of Stateless Firewall applications2.2.4Efficient Stateless Firewall ApplicationSimilar to 2.2.2, Efficient Stateless Firewall application also stores Flow Table entrieson switches to reduce bandwidth consumption of controller-switch link and to speed uppacket-processing. It also does not keep any state information to track down ongoingconnections. It can be seen from details of Flowchart 2.4b that Packet inspection of theapplication is very similar to the one with 2.4a except the Flow Table rule addition foreach inspected packet.Application code are uploaded to Github.org and can be found via [15].

3. Results and EvaluationsThis section explains different tests that are conducted with the designed Firewall applications on local machine and Memphis Testbed. General network tools like Ping and Netcatare used for the tests. Section 3.1 enhances the testing on local system in more details.Next section 3.2 encompasses details about Memphis Testbed, its topology designs andtesting results.3.1Testing on Local MachineIn order to determine correct behavior, the applications are tested with Mininet [16] onlocal machine. Mininet is a command-line tool that creates a virtual network with controllers, switches & hosts and runs applications on the top of controllers to simulate Software Defined Networking environment. Virtual image file consisting Ryu controller withMininet tool can be downloaded from [17]. Figure 3.1 shows network topology used forlocal testing.Figure 3.1: Mininet Topology for Local TestingFollowing Fig. 3.2 depicts how switch can be connected with a controller in Mininet environment. On the controller, Ryu application code is given as argument to ryu-managercommand. Correct OpenFlow version can be provided by ovs-vsctl command whereas,ovs-ofctl command is used to list out Flow Table entries of the switch. More details aboutthe commands can be found in Appendix E.4.

143. Results and EvaluationsFigure 3.2: Console outputs after starting applicationIn this IDP, default policy for the Firewall is set to deny-all. This means all packetsnot matching Firewall rules, will be dropped by the Firewall. For local tests, followingFirewall policies are considered. Motivation behind such design of policies is to coverall functionalities of Firewall applications; e.g., pinging policy covers ICMP functionality,TCP policy covers Stateful & Stateless functionality and datagram policy covers UDPfunctionality of the applications. In this way, these policies will be used to test correctnessof the four Firewall applications.1. Host 1 can ping Host 2 & Host 3 but they can not ping it back.2. Only Host 1 can initiate TCP connection to port 8080 on Host 2 & Host 3 using1000 as source port.3. Host 2 & Host 3 can establish TCP connection with each other only on port 1000.4. Host 1 can send datagrams to port 8080 of Host 2 & Host 3 through port 1000.Following subsections represent local tests that are conducted with each of the applications.3.1.1Inefficient Stateful FirewallPing Test: Ping Test is carried out by sending ICMP Echo Request packets from Host 1to Host 2. Upon receipt of such packets, switch forwards them directly to the controller.It can be seen from controller’s screen that application checks the request with FirewallPolicy to take out necessary actions. Since Policy 1 permits this, application creates newstates corresponding to the packet and forwards it to Host 2 via switch. When Host 2 sendsthe response message, it should also be allowed by the controller. Here, the applicationtracks down the response via managed states and allows it to pass through Firewall. Figure3.3 shows the results of successful ping test with Host 1. The application also behavedcorrectly when Host 2 tried to ping Host 1. (which is not allowed by the Firewall.)

3.1. Testing on Local Machine15Figure 3.3: Console outputs for Ping TestTCP Test: When Host 1 first sends TCP SYN packet, Firewall application checks thisnew connection initiation request with the Firewall Policy. Since Policy 2 allows the portcombination, it would send out the packet to Host 2 and create a new TCP state totrack down other packets of the flow coming from this direction. Host 2, upon gettingSYN packet, prepares SYN ACK packet and sends to Host 1 which will be forwarded tocontroller by the switch. Application will track down this SYN ACK response as it is partof the previously created connection state and also creates a new state to track all packetsof the flow coming from this direction to get passed through. This way, packets comingfrom both directions will be tracked down further and hence, the TCP handshake will getcompleted successfully. Other tests were also carried out in order to see correctness of theapplication with different port combinations and with different connection initiators (bothof which should be denied). The result of such tests are shown in Figure 3.4.Figure 3.4: Console outputs for TCP TestUDP Test: Packet inspection in UDP Test is exactly same as TCP Test. Application willcreate new state information when datagram with appropriate port combination is receivedfrom Host 1 and forwards it to Host 2 via switch. Subsequent datagram from Host 2 willbe tracked down using state information and sent to Host 1. Main difference of UDPhandling compared to TCP handling is: UDP is a connection-less protocol. Unlike TCP,tracking down one entire session is not possible because it lacks handshake mechanism.Hence, application will keep track of one Round Trip of UDP datagram exchange. So,

163. Results and Evaluationswhen Host 1 sent datagram, application will keep state as 0 UNREPLIED0 and change itto 0 ASSURED0 once Host 2 replies back. Results of UDP Test are shown in Figure 3.5.Figure 3.5: Console outputs for UDP Test3.1.2Inefficient Stateless FirewallPing Test: Unlike previous Test, application simp

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 . It is an open source tool written in Python .