Software-Defined Networking (SDN)

Similar documents
2 5 A p r 12. Princeton University

Abstractions for Model Checking SDN Controllers. Divjyot Sethi, Srinivas Narayana, Prof. Sharad Malik Princeton University

Application of SDN: Load Balancing & Traffic Engineering

Professor Yashar Ganjali Department of Computer Science University of Toronto

Software-Defined Networking (Continued)

Abstrac(ons for Model Checking SDN Controllers. Divjyot Sethi, Srinivas Narayana, Prof. Sharad Malik Princeton University

Languages for Software-Defined Networks

Frenetic: Functional Reactive Programming for Networks

Introduction to Software-Defined Networking UG3 Computer Communications & Networks (COMN)

Composing Software-Defined Networks

Software Defined Networking

Design and development of the reactive BGP peering in softwaredefined routing exchanges

Formal Verification of Computer Switch Networks

Languages for SDN (Frenetic)

VeriCon: Towards Verifying Controller Programs in SDNs

Software-Defined Networking (SDN) Now for Operational Technology (OT) Networks SEL 2017

Programming Network Policies by Examples: Platform, Abstraction and User Studies

HY436: Modular Network Programming with Pyretic

CSC 401 Data and Computer Communications Networks

Computer Networks. Sándor Laki ELTE-Ericsson Communication Networks Laboratory

Network Programming Languages. Nate Foster

Policy-based networking. CSU CS Fall 2017 Instructor: Lorenzo De Carli

I Know What Your Packet Did Last Hop: Using Packet Histories to Troubleshoot Networks.

An Assertion Language for Debugging SDN Applications

PIX-IE An SDN-based Programmable Internet exchange

Chapter 5 Network Layer: The Control Plane

Software Defined Networking Security: Security for SDN and Security with SDN. Seungwon Shin Texas A&M University

Advanced Computer Networks. Network Virtualization

Assignment 5. 2 Assignment: Emulate a Data Center and Manage it via a Cloud Network Controller

MED: The Monitor-Emulator-Debugger for Software-Defined Networks

Data Link Layer. Our goals: understand principles behind data link layer services: instantiation and implementation of various link layer technologies

BYZANTINE FAULT TOLERANT SOFTWARE- DEFINED NETWORKING (SDN) CONTROLLERS

Software Defined Networks and OpenFlow. Courtesy of: AT&T Tech Talks.

CSC 4900 Computer Networks: Network Layer

Typhoon: An SDN Enhanced Real-Time Big Data Streaming Framework

OpenState demo. Hands-on activity. NetSoft 15 - April 13, 2015 A.Capone & C. Cascone: OpenState Live Demo 1

Switching & ARP Week 3

UMass Amherst Cornell Princeton

Experiences in Realizing Large Robust Software Defined Networks. Ravi Manghirmalani Ramesh Subrahmaniam

Lecture 16: Network Layer Overview, Internet Protocol

Trident. Toward a Unified SDN Programming Framework with Automatic Updates. Kai Gao 1 Taishi Nojima 2 Y. Richard Yang 2, 3 August 23, 2018

Lecture 17: Network Layer Addressing, Control Plane, and Routing

DYNAMIC SERVICE CHAINING DYSCO WITH. forcing packets through middleboxes for security, optimizing performance, enhancing reachability, etc.

Software Defined Networking

Our Narrow Focus Computer Networking Security Vulnerabilities. Outline Part II

Chapter 4 Network Layer: The Data Plane

Lesson 9 OpenFlow. Objectives :

Project 4: SDNs Due: 11:59 PM, Dec 12, 2018

Software Defined Networking

Question Score 1 / 19 2 / 19 3 / 16 4 / 29 5 / 17 Total / 100

I Know What Your Packet Did Last Hop: Using Packet Histories to Troubleshoot Networks

Network Security: Network Flooding. Seungwon Shin GSIS, KAIST

Cisco Nexus Data Broker for Network Traffic Monitoring and Visibility

So#ware Defined Networking

SDNRacer. Concurrency Analysis for SDNs. Ahmed El-Hassany Jeremie Miserez Pavol Bielik Laurent Vanbever Martin Vechev.

Cybersecurity Threat Mitigation using SDN

Software-Defined Networking (SDN) Overview

VeriFlow: Verifying Network-Wide Invariants in Real Time

SDN-based Network Obfuscation. Roland Meier PhD Student ETH Zürich

POMP: Protocol Oblivious SDN Programming with Automatic Multi-Table Pipelining

Reliable Distributed System Approaches

Automatic Test Packet Generation

OpenFlow. Finding Feature Information. Prerequisites for OpenFlow

OpenFlow. Finding Feature Information. Prerequisites for OpenFlow

Minimizing ARP traffic in the AMS-IX switching platform using OpenFlow

Outline. Routing. Introduction to Wide Area Routing. Classification of Routing Algorithms. Introduction. Broadcasting and Multicasting

History Page. Barracuda NextGen Firewall F

Int. J. Advanced Networking and Applications Volume: 6 Issue: 3 Pages: (2014) ISSN :

A framework to evaluate 5G networks for smart and fail-safe communications

Chapter 4: network layer. Network service model. Two key network-layer functions. Network layer. Input port functions. Router architecture overview

Data Plane Verification and Anteater

Configuration and Management of Networks

The challenges of computing at astronomical scale

CS 5114 Network Programming Languages Data Plane. Nate Foster Cornell University Spring 2013

and controller independence with NetIDE

Exercises: Basics of Networking II Experiential Learning Workshop

Compiling Path Queries

Scalable Enterprise Networks with Inexpensive Switches

Scribe Notes -- October 31st, 2017

CSC 574 Computer and Network Security. TCP/IP Security

Verified Secure Routing

Switching and Routing projects description

Network Layer: The Control Plane

Lecture 19: Network Layer Routing in the Internet

ECPE / COMP 177 Fall Some slides from Kurose and Ross, Computer Networking, 5 th Edition

Mininet & OpenFlow 24/11/2016

CSE 461 Module 10. Introduction to the Transport Layer

Network Verification: Reflections from Electronic Design Automation (EDA)

Introduction to Communication Networks Spring Unit 13 Network extensions Bridges.

Internet Layers. Physical Layer. Application. Application. Transport. Transport. Network. Network. Network. Network. Link. Link. Link.

Chapter 3 Part 2 Switching and Bridging. Networking CS 3470, Section 1

Building Efficient and Reliable Software-Defined Networks. Naga Katta

COMP211 Chapter 4 Network Layer: The Data Plane

Chapter 4 Network Layer: The Data Plane. Part A. Computer Networking: A Top Down Approach

COCONUT: Seamless Scale-out of Network Elements

Multicast Communications. Tarik Čičić, 4. March. 2016

Life, Death, and the Critical Transition: Finding Liveness Bugs in System Code

This is the accepted version of a paper presented at The 1st European Workshop on Software Defined Networks (EWSDN).

5.1 introduction 5.5 The SDN control 5.2 routing protocols plane. Control Message 5.3 intra-as routing in Protocol the Internet

Advanced Computer Networks. RDMA, Network Virtualization

Transcription:

EPFL Princeton University 2 5 A p r 12 Software-Defined Networking (SDN) Third-party Enables new functionality through mability 2 1

at the risk of bugs 3 Software Faults Will make communication unreliable Major hurdle for success of SDN We need effective ways to test SDN networks This talk: automatically testing OpenFlow Apps 4 2

Quick OpenFlow 101 Controller Execute packet_in OpenFlow event handler Default: forward to controller Install rule; forward packet Host A Packet Switch 1 Flow Table Rule 1 Rule 2 Rule N Switch 2 System is distributed and asynchronous can misbehave under corner cases Host B Match Actions Counters Dst: Host B Fwd: Switch 2 pkts / bytes 5 Bugs in OpenFlow Apps Install rule Controller OpenFlow Install rule Delayed!? Drop packet Host A Inconsistent distributed state! Host B Packet Goal: systematically Switch 1test possible behaviors Switch to 2 detect bugs 6 3

Systematically Testing OpenFlow Apps Carefully-crafted streams of packets Many orderings of packet arrivals and events -space exploration via Model Checking (MC) Host A Unmodified OpenFlow Environment model Switch 1 Complex 2 environment Switch Host B Target system 7 Scalability Challenges Data-plane driven Complex network behavior Huge space of possible packets Huge space of possible event orderings Equivalence classes of packets Domain-specific search strategies Enumerating all inputs and event orderings is intractable 8 4

Input Unmodified OpenFlow Network topology NICE No bugs In Controller Execution -space search Output Traces of property violations Correctness properties NICE found 11 bugs in 3 real OpenFlow Apps (e.g., no loops) 9 Input Unmodified OpenFlow Network topology NICE No bugs In Controller Execution -space search Output Traces of property violations Correctness properties (e.g., no loops) 10 5

-Space Model Model Checking 0 1 2 3 4 5 6 7 8 9 11 System Controller (global variables) Environment: Switches (flow table, OpenFlow agent) Simplified switch model End-hosts (network stack) Simple clients/servers Communication channels (in-flight pkts) 12 6

Transition System 0 Data-dependentRun actual transitions! packet_in handler 1 2 3 4 5 6 7 8 9 13 Combating Huge Space of Packets pkt Equivalence classes of packets: 1. Broadcast destination 2. Unknown unicast destination 3. Known unicast destination yes is dst broadcast? no no dst in mactable? yes Packet arrival handler Flood packet Install rule and forward packet Code itself reveals equivalence classes of packets 14 7

Code Analysis: Symbolic Execution (SE) Symbolic packet λ 1 path = 1 equivalence class of packets = 1 packet to inject λ.dst {Broadcast} yes is λ.dst broadcast? no no λ.dst {Broadcast} λ.dst mactable λ.dst {Broadcast} λ.dst in mactable? yes Infeasible from initial state λ.dst {Broadcast} λ.dst mactable Packet arrival handler Flood packet Install rule and forward packet 15 0 Combining SE with Model Checking host send(pkt A) 1 host discover_packets 2 host send(pkt B) 3 Controller state changes discover_packets transition: 4 Controller state 1 Symbolic execution of packet_in handler New packets Enable new transitions: host / send(pkt B) host / send(pkt C) 16 8

Combating Huge Space of Orderings OpenFlow-specific search strategies for up to 20x state-space reduction: MC + SE NO-DELAY FLOW-IR UNUSUAL 17 Input Unmodified OpenFlow Network topology NICE No bugs In Controller Execution -space search Output Traces of property violations Correctness properties (e.g., no loops) 18 9

Specifying App Correctness Library of common properties No forwarding loops No black holes Direct paths (no unnecessary flooding) Etc Correctness is app-specific in nature 19 API to Define App-Specific Properties 0 ctrl packet_in(pkt A) 1 Execute after transitions Register callbacks to observe transitions def init(): init local vars register( packet_in ) def on_packet_in(): check system-wide state 20 10

Prototype Implementation Built a NICE prototype in Python Target the Python API of NOX Unmodified OpenFlow NICE Stub NOX API Controller state & transitions 21 Experiences Tested 3 unmodified NOX OpenFlow Apps MAC-learning switch LB: Web server load balancer [Wang et al., HotICE 11] TE: Energy-aware traffic engineering [CoNEXT 11] Setup Iterated with 1, 2 or 3-switch topologies; 1,2, pkts App-specific properties LB: All packets of same request go to same server replica TE: Use appropriate path based on network load 22 11

Results NICE found 11 property violations bugs Few secs to find 1 st violation of each bug (max 30m) Few simple mistakes (not freeing buffered packets) 3 insidious bugs due to network race conditions NICE makes corner cases as likely as normal cases 23 Thank Conclusions you! Questions? NICE automates the testing of OpenFlow Apps http://code.google.com/p/nice-of/ Explores state-space efficiently Tests unmodified NOX applications Helps to specify correctness Finds bugs in real applications SDN: a new role for software tool chains to make networks more dependable. NICE is a step in this direction! 24 12

Backup slides 25 Related Work (1/2) Model Checking SPIN [Holzmann 04], Verisoft [Godefroid 97], JPF [Visser 03] Musuvathi 04, MaceMC [Killian 07], MODIST [Yang 09] Symbolic Execution DART [Godefroid 05], Klee [Cadar 08], Cloud9 [Bucur 11] MC+SE: Khurshid 03 26 13

Related Work (2/2) OpenFlow ming Frenetic [Foster 11], NetCore [Monsanto 12] Network testing FlowChecker [Al-Shaer 10] OFRewind [Wundsam 11] Anteater [Mai 11] Header Space Analysis [Kazemian 12] 27 Micro-benchmark of full state-space search Single 2.6 GHz core 64 GB RAM Compared with SPIN: 7 pings out of memory JPF is 5.5 x slower Host A Switch 1 Pyswitch MAC-learning switch Switch 2 Host B Concurrent Layer-2 ping Pings Transitions Unique states Time 2 470 268 0.94 [s] 3 12,801 5,257 47.27 [s] 4 391,091 131,515 36 [m] 5 14,052,853 4,161,335 30 [h] 28 14

space reduction by heuristics Single 2.6 GHz core 64 GB RAM Compared to base model checking Switch 1 Pyswitch MAC-learning switch Switch 2 Host A Host B 29 Transitions # / run time [s] to 1 st property violation of each bug 30 15

OpenFlow Switch Model Example: adding Rule 1 and Rule 2 1) Flow Table 1 switch process_of 2) Flow Table Rule 1 2 4 Flow Table (4 Rule 2 3) Flow Table Rule 1 Rule 2 install Rule 2 3 5 install Rule 1 Flow Table Rule 2 Rule 1 (5 31 MAC-learning switch (3 bugs) OpenFlow Host A 1 2 2 1 Host B A->B port 2 3 A->B port 1 BUG-I: Host unreachable after moving 32 16

MAC-learning switch (3 bugs) OpenFlow Host A 1 2 2 1 Host B 3 B->A port 1 B->A port 2 A->B port 2 A->B port 1 BUG-I: Host unreachable after moving BUG-II: Delayed direct path 33 MAC-learning switch (3 bugs) OpenFlow Host A 1 2 2 1 3 2 1 3 BUG-I: Host unreachable after moving BUG-II: Delayed direct path BUG-III: Excess flooding 34 17

Web Server Load Balancer (4 bugs) OpenFlow Host A 1 3 Server 1 Host B 2 4 Server 2 Custom property: all packets of same request go to same server replica BUG-IV: Next TCP packet always dropped after reconfiguration BUG-V: Some TCP packets dropped after reconfiguration BUG-VI: ARP packets forgotten during address resolution BUG-VII: Duplicate SYN packets during transitions 35 Energy-Efficient TE (4 bugs) Precompute 2 paths per <origin,dest.> Always-on and on-demand Make online decision: Use the smallest subset of network elements that satisfies current demand BUG-VIII: The first packet of a new flow is dropped BUG-IX: The first few packets of a new flow can be dropped BUG-X: Only on-demand routes used under high load BUG-XI: Packets can be dropped when the load reduces 36 18

Results Why were mistakes easy to make? Centralized ming model only an abstraction Why the mer could not detect them? Bugs don t always manifest TCP masks transient packet loss Platform lacks runtime checks Why NICE easily found them? Makes corner cases as likely as normal cases 37 Example: MAC-learning Switch 1 ctrl_state = {} # of the controller is a global variable (a hashtable) 2 def packet_in(sw_id, inport, pkt, bufid): # Handles packet arrivals 3 mactable = ctrl_state[sw_id] 4 is_bcast_src = pkt.src[0] & 1 5 is_bcast_dst = pkt.dst[0] & 1 6 if not is_bcast_src: 7 mactable[pkt.src] = inport 8 if (not is_bcast_dst) and (mactable.has_key(pkt.dst)): 9 outport = mactable[pkt.dst] 10 if outport!= inport: 11 match = {DL SRC: pkt.src, DL DST: pkt.dst, DL TYPE: pkt.type, IN PORT: inport} 12 actions = [OUTPUT, outport] 13 install_rule(sw_id, match, actions, soft_timer=5, hard_timer=permanent) 14 send_packet_out(sw_id, pkt, bufid) 15 return 16 flood_packet(sw_id, pkt, bufid) 38 19

Causes of Corner Cases (Examples) Multiple packets of a flow reach controller No atomic update across multiple switches Previously-installed rules limit visibility Composing functions that affect same packets Assumptions about end-host protocols & SW 39 20