Using Event-Driven SDN for Dynamic DDoS Mitigation Craig Hill Distinguished SE, US Federal crhill@cisco.com CCIE #1628 1
Concept and Content Creators The Cisco Engineering Team: Jason King Steven Carter Chris Hocker Tae Hwang Jim Kotantoulas 2
Business Imperative Cost per Object must Agility must Operations must Adapt Virtualization = explosion in Objects 50%+ of outages from mis-config Speed to activation too slow Mechanization of logic in CCIE brains Peering of Controller & Network Element Intelligence Evolving choices in abstraction CLI API GUI Easy Button 3
Traditional Control Plane Architecture (Distributed) Control plane is tightly coupled to the network device Minimal application programmability of network devices (CLI, SNMP, NETCONF) EX: Cisco Routers, Catalyst L2/L3 switches, Nexus switches, etc Application Distributed Control Plane Centralized Control Plane Data Plane APIs 4
SDN Control Plane Architecture (Centralized) OpenFlow Control plane is centralized Control plane abstracted from the forwarding HW Communications channel exists between control plane and forwarding HW (OpenFlow agent on device) EX: OpenFlow Model (controller, agent on network element) Application Distributed Control Plane Centralized Control Plane Data Plane APIs 5
Hybrid Control Plane Models Source: ONF Hybrid WG Centralize When Needed, Default Distributed Control Plane for All Else Applications Network Devices: On-Box Control Plane Application Distributed Control Plane Centralized Control Plane Data Plane APIs 6
Hybrid SDN Model Distributed and Centralized (via controller) Control Plane + Standards Data Plane SDN Control Plane Architecture (Hybrid) NB API s Communication Channel To Network Element IP/MPLS BGP/OSPF Packet Hardware + CP Packet Hardware + CP Packet Hardware + CP Network Element (Phy, Virt), with Distributed CP + programming capabilities through Southbound API 2013 Cisco Systems, Inc. All rights reserved.
Hybrid SDN Model Distributed and Centralized (via controller) Control Plane + Standards Data Plane SDN Control Plane Architecture (Hybrid) NB API s Communication Channel To Network Element Controller Operating System controlling specific functions of the network IP/MPLS BGP/OSPF Packet Hardware + CP Packet Hardware + CP Packet Hardware + CP Network Element (Phy, Virt), with Distributed CP + programming capabilities through Southbound API 2013 Cisco Systems, Inc. All rights reserved.
Hybrid SDN Model Distributed and Centralized (via controller) Control Plane + Standards Data Plane SDN Control Plane Architecture (Hybrid) NB API s Communication Channel To Network Element Controller South Bound control and API Operating System controlling specific functions of the network NETCONF, BGPLS, PCEP, OpenFlow, OVSDB, CLI IP/MPLS BGP/OSPF Packet Hardware + CP Packet Hardware + CP Packet Hardware + CP Network Element (Phy, Virt), with Distributed CP + programming capabilities through Southbound API 2013 Cisco Systems, Inc. All rights reserved.
Hybrid SDN Model Distributed and Centralized (via controller) Control Plane + Standards Data Plane SDN Control Plane Architecture (Hybrid) App App App App Applications layered on top NB API s Communication Channel To Network Element North Bound control and API Controller South Bound control and API (AAA Auth) REST Operating System controlling specific functions of the network NETCONF, BGPLS, PCEP, OpenFlow, OVSDB, CLI IP/MPLS BGP/OSPF Packet Hardware + CP Packet Hardware + CP Packet Hardware + CP Network Element (Phy, Virt), with Distributed CP + programming capabilities through Southbound API 2013 Cisco Systems, Inc. All rights reserved.
Programmability: Network Automation Interfaces Application Frameworks, Management Systems, Controllers,... OnePK C/Java Python NETCONF REST OpenFlow ACI Fabric OpenStack Puppet Protocols RESTful Management Orchestra8on Network Services Control Device Puppet Neutron OpFlex OpenFlow XML/JSON Network Device Plug-Ins API (OnePK) and Data Models (YANG) Opera8ng Systems IOS / NX-OS / IOS-XR YANG Protocols BGP, PCEP,... 11
Hybrid SDN Model What Are Examples These Applications? SDN Control Plane Architecture (Hybrid) App App App App Applications layered on top NB API s Communication Channel To Network Element IP/MPLS BGP/OSPF 2013 Cisco Systems, Inc. All rights reserved. WAN Automation Application QoS, Plug n Play, PathTrace OpenFlow, NETCONF, BGPLS, config tool Cloud Platform API s (OpenStack Neutron) Integrated Services Engine (ISE) 3 rd party developed interfacing to published REST API s Eco-System Applications Splunk, Lancope, LiveAction Orchestration engines (Tail-f)
Expose Network Intelligence Bi-Directionally Analyze data and response with action Workflow and Intent Applications (Splunk) Network Intelligence, Guidance Harvest Network Intelligence, Telemetry, and Events Services Orchestration (Traffic Steering, Blocking) Policy (Application + Network + Security) Analytics (Splunk) Program for Blocking and Steering of Traffic to End-points Programmability Network Statistics, States, Objects and Events 16
Event-Driven SDN - Solution Overview 17
Event-Driven SDN for DDoS - Concept Event Driven = no operator intervention to react to a vulnerability Leverage the automation, programmability, and open API s to simplify a multi-system and multi-operator process in the network Leverage open source and open standard across the system Trigger system automation based on events in the application (Splunk) Leverage customers existing investment application (Splunk in this case) Target other 3 rd party solutions/partners to leverage similar components (ODL, routers, switches) Options to leverage other protocols and SDN agents that exist Designers can tailor the system to their specific IA requirements 18
SDN DDoS Reference Implementation Commodity Internet Internet2/AL2S Next Genera=on Firewall Commodity: In-Line Internet 2: In-Line or OOB w/steering BGP Nexus 3K BGP Null Routes ASR 1K ASR 9K High-Throughput Science Networks DMZ Nexus 9K Flow No8fica8on Ac8ve Blocking REST API Secure Corporate Networks Compute DTN ASA 5585 Event Correlation Log Storage Auditing Analysis Corporate DC Campus External Services Open DayLight Controller 20
Cisco Open SDN Controller Open platform for SDN app development Single Northbound REST Interface Multiple Southbound Interfaces 21
Splunk as an SDN Application What is Splunk? Software for searching, monitoring, and analyzing machine-generated big data, via a web-style interface. Splunk captures, indexes and correlates real-time data in a searchable repository from which it can generate graphs, reports, alerts, dashboards and visualizations. Actions from these searches allow a variation of programmability to open API s and other correlation engines, as well as SDN controllers 23
Event-Driven SDN DDoS Mitigation Solution Overview Blocking and steering are the two main functions needed for this solution Splunk uses data flow notification from Globus to inform OSC to steer the elephant flow around the IDS OSC sends commands to the N3K to bypass the IDS via OpenFlow Splunk uses events from security devices to inform OSC to block bad source IP addresses Splunk Alerts REST SourceFire OSC Mirrored Traffic Steer Block WAN N3K Tap ASR 9K OSC sends commands to the ASR9K via netconf to block bad IP addresses using RTBH Data Flow Notification Globus 25
OoB IDS with Active Steering and DDoS Blocking #1: non FTP traffic sends all non- FTP traffic to the IDS. All non-ftp traffic is steered to the IDS (controlled via OpenFlow) The IDS then sends its anomaly detection messages to Splunk. When certain anomaly s are detected, Splunk triggers an action to be taken to start blocking traffic (REST call to OSC via a Python script) OSC sends these requests to the ASR9K router, to block specific source IP addresses that need to be blocked from transmission (in this case, OSC uses NETCONF to send these specific IP addresses and requests to the ASR9K router) Splunk Alerts REST SourceFire OSC Mirrored Traffic Steer Block WAN N3K Tap ASR 9K Globus 26
FTP Steering for IDS Bypass #2: FTP events from Globus in this case, flow source/destination are sent to Splunk (uses Globus data flow notification) upon FTP transfer initiation Globus sends Splunk a basic 5-tuple of these flows (dest/src IP, prot #, src/dest prot #) Splunk calls the OSC controller, requesting the source/destination IP address of the FTP flow be programmed into the Nexus 3K, with a source/destination and output port (OpenFlow format) The Nexus 3K prioritizes these flows via OF, by giving them a priority of 200 (overriding the current 100 priority programmed for the other flows Splunk Alerts REST SourceFire OSC Mirrored Traffic Steer WAN N3K Tap ASR 9K So, in this case, OF is active, and it dictates what traffic goes to IDS, vs. bypass IDS. Data Flow Notification Globus 30
OpenFlow Data Flow Steering Example! Flow start notification: Jun 10 10:53:43 localhost splunk_odl_action: log_level=info, action=start, flow=199.66.189.10:50368-128.55.29.41:42600, status_code=200!! Flows added to Nexus 3000: Flow: 4! Match: tcp,in_port=54,nw_src=199.66.189.10,nw_dst=128.55.29.41,tp_src=50368,tp_dst=42600! Actions: output:52!! Priority: 200! Flow: 5! Match: tcp,in_port=52,nw_src=128.55.29.41,nw_dst=199.66.189.10,tp_src=42600,tp_dst=50368! Actions: output:54! Priority: 200! Flow stop notification: Jun 10 10:54:51 localhost splunk_odl_action: log_level=info, action=stop, flow=199.66.189.10:50368-128.55.29.41:42600, status_code=200! 37
Remotely Triggered Black Hole Routing Static routes added by COSC through Netconf on ASR 9000: router static! address-family ipv4 unicast! 1.0.184.115/32 Null0 tag 666! 1.161.169.139/32 Null0 tag 666! 2.25.74.127/32 Null0 tag 666! 2.50.153.67/32 Null0 tag 666! 12.197.32.116/32 Null0 tag 666!! Export the Null routes setting next-hop to black hole IP: route-policy as-11017-out! if tag is 666 then! set next-hop 192.0.2.1! set community (no-export) additive! pass! else! pass! endif! end-policy! Enable urpf on WAN interface on ASR 9000: ipv4 verify unicast source reachable-via any allow-default! Route Black Hole IP to NULL 0 on other border routers: ip route 192.0.2.1 255.255.255.255 Null0! Enable urpf on WAN interface on ASR 1000: ip verify unicast source reachable-via any! 38
Summary Leverage the automation, programmability, and open API s to simplify a multi-system and multi-operator DDoS mitigation solution Leverage open source and open standard across to create an Event Driven system Leverage COTS applications, with API s, to mix a variation of components using SDN Target other 3 rd party solutions/partners to leverage similar components (OSC, routers, switches) Network designers and Security operations teams can leverage specific applications tailored to their environment and IA requirements 46
Thank You 47