Software Defined Networking COMS 6998-8, Fall 2013 Instructor: Li Erran Li 6998-8SDNFall2013/

Slides:



Advertisements
Similar presentations
Fraunhofer FOKUS 2007 VoIP Defender The Future of VoIP Protection Fraunhofer FOKUS Institute, Germany.
Advertisements

Openflow App Testing Chao SHI, Stephen Duraski. Motivation Network is still a complex stuff ! o Distributed mechanism o Complex protocol o Large state.
Frenetic: A High-Level Language for OpenFlow Networks Nate Foster, Rob Harrison, Matthew L. Meola, Michael J. Freedman, Jennifer Rexford, David Walker.
Umut Girit  One of the core members of the Internet Protocol Suite, the set of network protocols used for the Internet. With UDP, computer.
Slick: A control plane for middleboxes Bilal Anwer, Theophilus Benson, Dave Levin, Nick Feamster, Jennifer Rexford Supported by DARPA through the U.S.
A SOFT Way for OpenFlow Interoperability Testing Marco Canini TU Berlin / T-Labs [CoNEXT’12]
A SOFT Way for OpenFlow Interoperability Testing Maciej Kuźniar, Peter Perešini, Marco Canini†, Daniele Venzano, Dejan Kostić‡ EPFL †TU Berlin/T-Labs ‡IMDEA.
An Overview of Software-Defined Network Presenter: Xitao Wen.
UDP & TCP Where would we be without them!. UDP User Datagram Protocol.
OpenFlow-Based Server Load Balancing GoneWild
11 TROUBLESHOOTING Chapter 12. Chapter 12: TROUBLESHOOTING2 OVERVIEW  Determine whether a network communications problem is related to TCP/IP.  Understand.
I Know What Your Packet Did Last Hop: Using Packet Histories to Troubleshoot Networks Nikhil Handigol With Brandon Heller, Vimal Jeyakumar, David Mazières,
CSCI 530 Lab Firewalls. Overview Firewalls Capabilities Limitations What are we limiting with a firewall? General Network Security Strategies Packet Filtering.
Troubleshooting SDNs Peyman Kazemian. Why SDN Troubleshooting SDN decouples software (control plane) from hardware (data plane). Opens doors for innovation.
SDN and Openflow.
Scalable Flow-Based Networking with DIFANE 1 Minlan Yu Princeton University Joint work with Mike Freedman, Jennifer Rexford and Jia Wang.
Flowspace revisited OpenFlow Basics Flow Table Entries Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot L4 sport L4 dport Rule Action.
Page: 1 Director 1.0 TECHNION Department of Computer Science The Computer Communication Lab (236340) Summer 2002 Submitted by: David Schwartz Idan Zak.
An Overview of Software-Defined Network
Applying Dynamic Analysis to Test Corner Cases First Penka Vassileva Markova Madanlal Musuvathi.
Bro: A System for Detecting Network Intruders in Real-Time Presented by Zachary Schneirov CS Professor Yan Chen.
OpenFlow Switch Limitations. Background: Current Applications Traffic Engineering application (performance) – Fine grained rules and short time scales.
An Overview of Software-Defined Network Presenter: Xitao Wen.
Presenter: Chi-Hung Lu 1. Problems Distributed applications are hard to validate Distribution of application state across many distinct execution environments.
FIREWALL TECHNOLOGIES Tahani al jehani. Firewall benefits  A firewall functions as a choke point – all traffic in and out must pass through this single.
Formal checkings in networks James Hongyi Zeng with Peyman Kazemian, George Varghese, Nick McKeown.
EPFL 25Apr ’12. Software-Defined Networking (SDN) 2 Enables new functionality through programmability … Third-party program 25 Apr 2012NSDI'12.
OpenFlow: Enabling Technology Transfer to Networking Industry Nikhil Handigol Nikhil Handigol Cisco Nerd.
Frenetic: A Programming Language for Software Defined Networks Jennifer Rexford Princeton University Joint work with Nate.
Software-Defined Networks Jennifer Rexford Princeton University.
Institute of Computer and Communication Network Engineering OFC/NFOEC, 6-10 March 2011, Los Angeles, CA Lessons Learned From Implementing a Path Computation.
Where is the Debugger for my Software-Defined Network? [ndb]
VeriFlow: Verifying Network-Wide Invariants in Real Time
Traffic Management - OpenFlow Switch on the NetFPGA platform Chun-Jen Chung( ) Sriram Gopinath( )
Geneva, Switzerland, 11 June 2012 Switching and routing in Future Network John Grant Nine Tiles
Fundamentals of Proxying. Proxy Server Fundamentals  Proxy simply means acting on someone other’s behalf  A Proxy acts on behalf of the client or user.
Scanning & Enumeration Lab 3 Once attacker knows who to attack, and knows some of what is there (e.g. DNS servers, mail servers, etc.) the next step is.
1 COPYRIGHT © 2015 ALCATEL-LUCENT. ALL RIGHTS RESERVED. Cognitive Security: Security Analytics and Autonomics for Virtualized Networks Lalita Jagadeesan.
Jennifer Rexford Princeton University MW 11:00am-12:20pm Measurement COS 597E: Software Defined Networking.
Denial of Service Sharmistha Roy Adversarial challenges in Web Based Services.
Programming Languages for Software Defined Networks Jennifer Rexford and David Walker Princeton University Joint work with the.
Open-Eye Georgios Androulidakis National Technical University of Athens.
Traffic Management - OpenFlow Switch on the NetFPGA platform Chun-Jen Chung( ) Sriram Gopinath( )
Switch Features Most enterprise-capable switches have a number of features that make the switch attractive for large organizations. The following is a.
Improving Network Management with Software Defined Network Group 5 : z Xuling Wu z Haipeng Jiang z Sichen Wu z Aparna Sanil.
Lecture 4 Mechanisms & Kernel for NOSs. Mechanisms for Network Operating Systems  Network operating systems provide three basic mechanisms that support.
DoS/DDoS attack and defense
1 Software Reliability in Wireless Sensor Networks (WSN) -Xiong Junjie
Jennifer Rexford Princeton University MW 11:00am-12:20pm Data-Plane Verification COS 597E: Software Defined Networking.
UDP & TCP Where would we be without them!. UDP User Datagram Protocol.
NetEgg: Scenario-based Programming for SDN Policies Yifei Yuan, Dong Lin, Rajeev Alur, Boon Thau Loo University of Pennsylvania 1.
1 Kyung Hee University Chapter 11 User Datagram Protocol.
Jennifer Rexford Princeton University MW 11:00am-12:20pm Testing and Debugging COS 597E: Software Defined Networking.
Verifying & Testing SDN Data & Control Planes: Header Space Analysis.
SDN controllers App Network elements has two components: OpenFlow client, forwarding hardware with flow tables. The SDN controller must implement the network.
Programming SDN 1 Problems with programming with POX.
SDN and Security Security as a service in the cloud
Software Defined Networking for Wireless Networks
Network Anti-Spoofing with SDN Data plane Authors:Yehuda Afek et al.
Martin Casado, Nate Foster, and Arjun Guha CACM, October 2014
ETHANE: TAKING CONTROL OF THE ENTERPRISE
Introduction to Networking
CS 31006: Computer Networks – The Routers
Software Defined Networking (SDN)
DDoS Attack Detection under SDN Context
Implementing an OpenFlow Switch on the NetFPGA platform
Programmable Networks
SDN + NetSec Vyas Sekar.
Transport Layer 9/22/2019.
Chapter 4: outline 4.1 Overview of Network layer data plane
Presentation transcript:

Software Defined Networking COMS , Fall 2013 Instructor: Li Erran Li SDNFall2013/ 11/26/2013: SDN Debugging and Security

Outline Review on SDN Wireless Networks – Data Plane Abstraction – Controller Design SDN Debugging – Data Plane Approach (Breakpoints + Packet Trace): NDB – Control Plane Approach (Model Checking + Symbolic Execution): NICE SDN Security – Defense again Control Plane Attacks – Security as a Service (Next Lecture) 11/26/13 Software Defined Networking (COMS ) 2

Review of Previous Lecture: Data Plane Abstraction Programmable wireless dataplane using off-the- shelf components – Single platform capable of LTE, 3G, WiMax, WiFi – OpenFlow for Layer 3 – Inexpensive ($ ) Control CPU Forwarding Dataplane Baseband & Layer 2 DSP RF Exposes a match/action interface to program how a flow is forwarded, scheduled & encoded Source: Katti, Stanford 11/26/13 Software Defined Networking (COMS ) 3

Review of Previous Lecture: Data Plane Abstraction-Modular Declarable Interface Inserting RULESComposing ACTIONS Blocks OFDM Demod A Demap (BPSK) B Demap (64QAM) C Deinterleave (WiFi) D Deinterleave (UEP) E Decode (1/2) F Decode (3/4) G Descramble H CRC Check I Hdr Parse J A B D F H I J A C D G H I J A C E G H I J F H J 6M54M UEP A B D F H I J 6M A B D F H I J C G 6M, 54M Rules: Branching logic Data flow Control flow Actions: DAGs of blocks Source: Katti, Stanford 11/26/13 Software Defined Networking (COMS ) 4

Review of Previous Lecture: Data Plane Abstraction: State machines & deadlines Rules and actions encode the protocol state machine – Rules define state transitions – Each state has an associated action Deadlines are expressed on state sequences deadline A C B D G F H I J Start decoding Finish decoding 5 Source: Katti, Stanford 11/26/13 Software Defined Networking (COMS ) 5

Review of Previous Lecture: Controller Abstraction and Architecture RADIO ELEMENTS CONTROLLER Radio Element API Controller API Interference Map Flow Records Bytes Rate Queue Size Network Operator Inputs QoS Constraints RAN Information Base Radio Resource Management Algorithm POWER FLOW Time Frequency Radio Element 3D Resource Grid Periodic Updates 11/26/13 Software Defined Networking (COMS ) 6

Outline Review on SDN Wireless Networks – Data Plane Abstraction – Controller Design SDN Debugging – Data Plane Approach (Breakpoints + Packet Backtrace): ndb – Control Plane Approach (Model Checking + Symbolic Execution): NICE SDN Security – Defense again Control Plane Attacks – Security as a Service 11/26/13 Software Defined Networking (COMS ) 7

Bug story: incomplete handover A B Switch X WiFi AP YWiFi AP Z 11/26/13 Software Defined Networking (COMS ) 8 Source: Handigol, et al., Stanford

Debugging SDNs Bugs can be anywhere in the SDN stack – Hardware, control plane logic, race conditions Switch state might change rapidly Bugs might show up rarely 11/26/13 Software Defined Networking (COMS ) 9 Source: Handigol, et al., Stanford

How can we exploit the SDN architecture to systematically track down the root cause of bugs? 11/26/13 Software Defined Networking (COMS ) 10 Source: Handigol, et al., Stanford

ndb : Network Debugger Goal – Capture and reconstruct the sequence of events leading to the errant behavior Allow users to define a Network Breakpoint – A (header, switch) filter to identify the errant behavior Produce a Packet Backtrace – Path taken by the packet – State of the flow table at each switch 11/26/13 Software Defined Networking (COMS ) 11

Debugging software programs Function A(): i = …; j = …; u = B(i, j) Function A(): i = …; j = …; u = B(i, j) Function B(x, y): k = …; v = C(x, k) Function B(x, y): k = …; v = C(x, k) Function C(x, y): … w = abort() Function C(x, y): … w = abort() Breakpoint “line 25, w = abort() ” Backtrace File “A”, line 10, Function A () File “B”, line 43, Function B () File “C”, line 21, Function C () Breakpoint “line 25, w = abort() ” Backtrace File “A”, line 10, Function A () File “B”, line 43, Function B () File “C”, line 21, Function C () 11/26/13 Software Defined Networking (COMS ) 12 Source: Handigol, et al., Stanford

Breakpoint “ICMP packets A->B, arriving at X, but not Z” Backtrace Switch X: { inport: p0, outports: [p1] mods: [...] matched flow: 23 [...] matched table version: 3 } Switch Y: { inport p1, outports: [p3] mods: } Breakpoint “ICMP packets A->B, arriving at X, but not Z” Backtrace Switch X: { inport: p0, outports: [p1] mods: [...] matched flow: 23 [...] matched table version: 3 } Switch Y: { inport p1, outports: [p3] mods: } Y X Debugging networks A B Switch X WiFi AP Y WiFi AP Z 11/26/13 Software Defined Networking (COMS ) 13

Using ndb to debug common issues Reachability – Symptom: A is not able to talk to B – Breakpoint: “Packet A->B, not reaching B” Isolation – Symptom: A is talking to B, but it shouldn’t – Breakpoint: “Packet A->B, reaching B” Race conditions – Symptom: Flow entries not reaching on time – Breakpoint: “Packet-in at switch S, port P” 11/26/13 Software Defined Networking (COMS ) 14 Source: Handigol, et al., Stanford

So, how does ndb work? 11/26/13 Software Defined Networking (COMS ) 15

Control Plane Flow Table State Recorder Match ACT Match ACT Postcard Collector 11/26/13 Software Defined Networking (COMS ) 16 Source: Handigol, et al., Stanford

Postcard Collector Control Plane Flow Table State Recorder … 7. … … 7. … … 7. … … 7. … … 7. … … 7. … … 7. … … 7. … 11/26/13 Software Defined Networking (COMS ) 17 Source: Handigol, et al., Stanford

Postcard Collector Control Plane Flow Table State Recorder 11/26/13 Software Defined Networking (COMS ) 18 Source: Handigol, et al., Stanford

Who benefits Network developers – Programmers debugging control programs Network operators – Find policy errors – Send error report to switch vendor – Send error report to control program vendor 11/26/13 Software Defined Networking (COMS ) 19 Source: Handigol, et al., Stanford

Performance and scalability Control channel – Negligible overhead – No postcards – Extra flow-mods Postcards in the datapath – Single collector server for the entire Stanford backbone – Selective postcard generation to reduce overhead – Parallelize postcard collection 11/26/13 Software Defined Networking (COMS ) 20 Source: Handigol, et al., Stanford

ndb : Network Breakpoint + Packet Backtrace Systematically track down root cause of bugs Practical and deployable today Summary 11/26/13 Software Defined Networking (COMS ) 21 Source: Handigol, et al., Stanford

Outline Review on SDN Wireless Networks – Data Plane Abstraction – Controller Design SDN Debugging – Data Plane Approach (Breakpoints + Packet Backtrace): ndb – Control Plane Approach (Model Checking + Symbolic Execution): NICE SDN Security – Security as a service 11/26/13 Software Defined Networking (COMS ) 22

Software Faults Will make communication unreliable Major hurdle for success of SDN We need effective ways to test SDN networks NICE: automatically testing OpenFlow Apps 11/26/13 Software Defined Networking (COMS ) 23 Source: Canini, et al.

OpenFlow Quick OpenFlow 101 Host BHost A Switch 2 Flow Table Rule 1 Rule 2 Rule N Switch 1 Packet OpenFlow program Controller Install rule; forward packet Default: forward to controller MatchActionsCounters Dst: Host BFwd: Switch 2pkts / bytes System is distributed and asynchronous  can misbehave under corner cases Execute packet_in event handler 11/26/13 Software Defined Networking (COMS ) 24 Source: Canini, et al.

Bugs in OpenFlow Apps OpenFlow program Host BHost A Switch 2 Controller Switch 1 Packet Install rule ? Goal: systematically test possible behaviors to detect bugs Install rule Delayed! Drop packet Inconsistent distributed state! 11/26/13 Software Defined Networking (COMS ) 25 Source: Canini, et al.

State-space exploration via Model Checking (MC) Systematically Testing OpenFlow Apps Target system Unmodified OpenFlow program Complex environment Environment model Switch 1 Switch 2 Host AHost B Carefully-crafted streams of packets Many orderings of packet arrivals and events 11/26/13 Software Defined Networking (COMS ) 26 Source: Canini, et al.

Scalability Challenges Huge space of possible packets Huge space of possible event orderings Data-plane drivenComplex network behavior Enumerating all inputs and event orderings is intractable Equivalence classes of packets Domain-specific search strategies 11/26/13 Software Defined Networking (COMS ) 27 Source: Canini, et al.

Network topology Correctness properties (e.g., no loops) Traces of property violations InputOutput NICE State-space search N o bugs I n C ontroller E xecution NICE found 11 bugs in 3 real OpenFlow Apps Unmodified OpenFlow program 11/26/1328 Software Defined Networking (COMS )

Network topology Correctness properties (e.g., no loops) Traces of property violations InputOutput NICE N o bugs I n C ontroller E xecution Unmodified OpenFlow program State-space search 11/26/13 Software Defined Networking (COMS ) 29

Model Checking State-Space Model State 0 State 2 State 6 State 7 State 4 State 9 State 1 State 3 State 5 State 8 11/26/1330

System State State Controller (global variables) Environment: Switches (flow table, OpenFlow agent) Simplified switch model End-hosts (network stack) Simple clients/servers Communication channels (in-flight pkts) 11/26/13 Software Defined Networking (COMS ) 31 Source: Canini, et al.

Transition System State 0 State 2 State 6 State 7 State 4 State 9 State 1 State 3 ctrl packet_in(pkt A) host send switch process_of switch process_pkt ctrl packet_in(pkt B) Run actual packet_in handler State 5 State 8 Data-dependent transitions! 11/26/1332

Combating Huge Space of Packets Packet arrival handler is dst broadcast? Flood packet Install rule and forward packet dst in mactable? Equivalence classes of packets: 1.Broadcast destination 2.Unknown unicast destination 3.Known unicast destination yes no yes Code itself reveals equivalence classes of packets pkt 11/26/13 Software Defined Networking (COMS ) 33 Source: Canini, et al.

Code Analysis: Symbolic Execution (SE) Packet arrival handler is λ.dst broadcast? yesno Symbolic packet λ Flood packet λ.dst ∈ {Broadcast} λ.dst in mactable? no yes λ.dst ∉ {Broadcast} Install rule and forward packet λ.dst ∉ {Broadcast} ∧ λ.dst ∉ mactable λ.dst ∉ {Broadcast} ∧ λ.dst ∈ mactable 1 path = 1 equivalence class of packets = 1 packet to inject 11/26/13 Software Defined Networking (COMS ) 34 Source: Canini, et al.

New packets Enable new transitions: host / send(pkt B) host / send(pkt C) Symbolic execution of packet_in handler State 0 State 1 Controller state 1 State 2 host discover_packets State 3 host send(pkt B) State 4 host send(pkt C) discover_packets transition: Combining SE with Model Checking Controller state changes host send(pkt A) 11/26/13 Software Defined Networking (COMS ) 35 Source: Canini, et al.

Combating Huge Space of Orderings MC + SE PKT-SEQ FLOW-IR NO-DELAY UNUSUAL OpenFlow-specific search strategies for up to 20x state-space reduction: 11/26/13 Software Defined Networking (COMS ) 36 Source: Canini, et al.

Network topology Traces of property violations InputOutput NICE N o bugs I n C ontroller E xecution Unmodified OpenFlow program State-space search Correctness properties (e.g., no loops) 11/26/1337

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 11/26/13 Software Defined Networking (COMS ) 38 Source: Canini, et al.

API to Define App-Specific Properties State 0 State 1 ctrl packet_in(pkt A) def init(): init local vars register(“packet_in”) def on_packet_in(): check system-wide state Register callbacks to observe transitions Execute after transitions 11/26/13 Software Defined Networking (COMS ) 39 Source: Canini, et al.

Prototype Implementation Built a NICE prototype in Python Target the Python API of NOX Unmodified OpenFlow program Stub NOX API NICE Controller state & transitions 11/26/13 Software Defined Networking (COMS ) 40 Source: Canini, et al.

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 11/26/13 Software Defined Networking (COMS ) 41 Source: Canini, et al.

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 11/26/13 Software Defined Networking (COMS ) 42 Source: Canini, et al.

MAC-learning switch (3 bugs) OpenFlow program Host A A->B | port A->B | port 1 Host B BUG-I: Host unreachable after moving 3 11/26/13 Software Defined Networking (COMS ) 43 Source: Canini, et al.

MAC-learning switch (3 bugs) OpenFlow program Host A B->A | port B->A | port 2 Host B BUG-I: Host unreachable after moving 3 BUG-II: Delayed direct path A->B | port 2A->B | port 1 11/26/13 Software Defined Networking (COMS ) 44 Source: Canini, et al.

MAC-learning switch (3 bugs) OpenFlow program Host A 1221 BUG-I: Host unreachable after moving 3 BUG-II: Delayed direct path BUG-III: Excess flooding /26/13 Software Defined Networking (COMS ) 45 Source: Canini, et al.

Web Server Load Balancer (4 bugs) OpenFlow program Host A 13 Host B 24 Server 1 Server 2 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 Custom property: all packets of same request go to same server replica 11/26/13 Software Defined Networking (COMS ) 46 Source: Canini, et al.

Conclusions NICE automates the testing of OpenFlow Apps 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! 11/26/13 Software Defined Networking (COMS ) 47 Source: Canini, et al.

Outline Review on SDN Wireless Networks – Data Plane Abstraction – Controller Design SDN Debugging – Data Plane Approach (Breakpoints + Packet Trace): NDB – Control Plane Approach (Model Checking + Symbolic Execution): NICE SDN Security – Defense against Control Plane Attacks – Security as a Service 11/26/13 Software Defined Networking (COMS ) 48 Source: S. Shin, et al.

Avant-Guard Security extension to the OpenFlow data plane Connection migration To address scalability issue Actuating trigger To address responsiveness issue Control Plane Interface Flow Table (TCAM and SRAM) Flow Table Lookup Packet Processing Control Plane Data Plane Connection Migration Actuating Trigger Avant-Guard 11/26/13 Software Defined Networking (COMS ) 49 Source: S. Shin, et al.

Connection Migration - Idea Inspired by TCP SYN Cookie Concept TCP connection will stat from a SYN packet, and an initiator will wait for TCP SYN/ACK packet TCP-handshake does not issue any kind of data delivery Then, how about treating this TCP-handshake at network devices instead of target hosts SYN SYN/ACK ACK SYN SYN/ACK ACK 11/26/13 Software Defined Networking (COMS ) 50 Source: S. Shin, et al.

Connection Migration – Access Table List of visiting clients Format Client IP address: # of TCP connection trials # of TCP connection trials include wrong trials (ACK, FIN, and RST) Simple data structure : 6 bytes (4 bytes for IP and 2 bytes for counter) Overhead 1,000,000 client IP addresses  less than 6 MB of memory A controller application can read this table IP Address Counter 11/26/13 Software Defined Networking (COMS ) 51 Source: S. Shin, et al.

Connection Migration – State Diagram 4 state Classification Distinguish useful TCP connections Report Report to a controller Migration Migrate a TCP connection if it is a useful (or valid) connection Relay Relay all TCP packets between a connection source and a destination Classification stage Report stage Report stage Migration stage Migration stage Replay stage Replay stage TCP sessions Failed TCP sessions Then, Ignore Established TCP sessions Allow Migration Success or Failure Allow Relay 11/26/13 Software Defined Networking (COMS ) 52 Source: S. Shin, et al.

Connection Migration – Flow Chart Flow chart - The case of receiving TCP SYN/RST/FIN packet Flow chart - The case of receiving TCP ACK packet 53

Connection Migration – Packet Diagram A A B B Control Plane (1) TCP SYN (2) TCP SYN/ACK (3) TCP ACK (6) TCP SYN (7) TCP SYN/ACK (8) TCP ACK (11) TCP ACK TCP Data (12) TCP ACK TCP Data (4) (5) (9) (10) A-1: A --> B: Migrate A-2: A --> B: Relay Data Plane Classification stage Relay stage Migration stage Relay stage Report stage 11/26/13 Software Defined Networking (COMS ) 54 Source: S. Shin, et al.

Delayed Connection Migration Concept Delay Connection Migration until the data plane receives (a) data packet(s) Why? Good for reducing the effects of some advanced attacks E.g., fake TCP connection setup A A B B Control Plane (1) TCP SYN (2) TCP SYN/ACK (3) TCP ACK (7) TCP SYN (8) TCP SYN/ACK (9) TCP ACK (4) TCP ACK TCP Data (12) TCP ACK TCP Data (5) (6) (10) (11) A-1: A --> B: Migrate A-2: A --> B: Relay Data Plane Classification stage Migration stage Relay stage Report stage 55

Actuating Trigger - Idea Two functions Report the following items to the control plane asynchronously Network status Payload information Activate flow rules based on some predefined conditions Security application can use this feature to turn on security policies without delay 11/26/13 Software Defined Networking (COMS ) 56 Source: S. Shin, et al.

Activating Trigger – Operations 4 main operations In the control plane Define a condition Register the condition In the data plane Check the condition When the condition is satisfied, Report a network status or payload Activate a flow rule Flow Rule Condition Predefined Flow Rule Control Plane Host (1) Define condition (2) Register condition (3) Check condition (4-2) Activate a flow rule (4-1) Report status Data Plane match 11/26/13 Software Defined Networking (COMS ) 57 Source: S. Shin, et al.

Activating Trigger - Example Example of reporting payload 1) defined a condition : want to see payloads of packet from ) register this condition to the data plane 3) packet is delivered from ) payload is delivered to the control plane  * 1: Condition for payload Control Plane (1) Data Plane (2) (3) (4) 11/26/13 Software Defined Networking (COMS ) 58 Source: S. Shin, et al.

Implementation Data plane Implemented in the Software-based OpenFlow reference switch Covers OpenFlow spec Control plane Implemented in the POX controller Extend OpenFlow protocols for Connection migration E.g., OFPFC_MIGRATE, … Actuating trigger E.g., OFPFC_REG_PAYLOAD, … Please refer to our paper for more information (Table 1) 11/26/13 Software Defined Networking (COMS ) 59 Source: S. Shin, et al.

Evaluation – Use Case Network saturation attack case A normal client sends HTTP requests to a web server An attacker tries a SYN flooding attack to a web server Test ScenarioPacket delivered rate to a web server Nearly 0 loss Normal Attacker OF switch POX Controller Web Server Normal Attacker OF switch (Avant- Guard) OF switch (Avant- Guard) Modified POX Controller Modified POX Controller Web Server 11/26/13

Evaluation – Use Case Detecting SYN flooding/scanning Approach SYN flooding packets are automatically rejected Network scanning attackers will be confused by our response packets They may think that all network hosts are alive and all network ports are open (a kind of White hole) SYN SYN/ACK (1) (2) No packet delivery SYN SYN/ACK (1) (2) SYN Flooding Network Scanner No packet delivery Attacker receives SYN/ACK packets even though there are no hosts  White hole 11/26/13 Software Defined Networking (COMS ) 61

Evaluation – Use Case Intelligent Honeynet Approach When we try to do connection migration, If we can not find a real target host, we may consider this connection as suspicious Then, a security application can redirect this connection to our honeynet automatically Finally, this attacker will perform malicious operations inside a honenet SYN SYN/ACK ACK SYN (1) (2) (3) (4) No host SYN (5) SYN/ACK (6) (7) ACK attacker honeynet 11/26/13 Software Defined Networking (COMS ) 62 Source: S. Shin, et al.

Evaluation - Overhead Connection migration normalconnection migration overhead us us0,626 % Actuating trigger itemtime Traffic-rate based condition check us Payload based condition check = 0 Rule activation1.697 us 11/26/13 Software Defined Networking (COMS ) 63 Source: S. Shin, et al.

Summary Avant-Guard New data plane architecture for addressing the problems of OpenFlow, when devising network security applicatons Address the scalability issue with the connection migration scheme Address the responsiveness issue with the actuating trigger scheme Can be a new candidate architecture of the future data plane for SDN 11/26/13 Software Defined Networking (COMS ) 64Source: S. Shin, et al.

Questions? 11/26/13 Software Defined Networking (COMS ) 65