1. Software Defined Networking COMS 6998-8, Fall 2013 Guest Speaker: Seyed Kaveh Fayazbakhsh Stony Brook University 11/12/2013: SDN and Middleboxes

2. Need for Network Evolution 2 New devices New applications Evolving threats Policy constraints Performance, Security

3. 3 Type of applianceNumber Firewalls166 NIDS127 Media gateways110 Load balancers67 Proxies66 VPN gateways45 WAN Optimizers44 Voice gateways11 Total Middleboxes636 Total routers~900 Network Evolution today: Middleboxes! Data from a large enterprise: >80K users across tens of sites Just network security $10 billion (Sherry et al, SIGCOMM’ 12)

4. There are many middleboxes! Survey across 57 enterprise networks (Sherry et al, SIGCOMM’ 12) 10/22/13 Software Defined Networking (COMS 6998-8) 4

5. Things to keep in mind about middleboxes A middlebox is any traffic processing device except for routers and switches. Why do we need them? – Security – Performance Deployments of middlebox functionalities: – Embedded in switches and routers (e.g., packet filtering) – Specialized devices with hardware support of SSL acceleration, DPI, etc. – Virtual vs. Physical Appliances – Local (i.e., in-site) vs. Remote (i.e., in-the-cloud) deployments They can break end-to-end semantics (e.g., load balancing) 510/22/13 Software Defined Networking (COMS 6998-8)

6. Controller Platform Switch API Controller Switches App Runtime SDN Stack Control Flow, Data Structures, etc. 6 Applications Where do middleboxes logically fit in?

7. Outline Recent trends in middlebox design/deployment – Middlebox Consolidation (CoMb) – Extensible Software Middlebox Architecture (xOMB) Middleboxes/SDN Integration – Elastic Execution (Split/Merge) – Policy enforcement (SIMPLE) – Handling dynamic traffic modification (FlowTags) 710/22/13 Software Defined Networking (COMS 6998-8)

8. Outline Recent trends in middlebox design/deployment – Middlebox Consolidation (CoMb) – Extensible Software Middlebox Architecture (xOMB) Middleboxes/SDN Integration – Elastic Execution (Split/Merge) – Policy enforcement (SIMPLE) – Handling dynamic traffic modification (FlowTags) 810/22/13 Software Defined Networking (COMS 6998-8)

9. Design and Implementation of a Consolidated Middlebox Architecture 9 Vyas SekarSylvia RatnasamyMichael ReiterNorbert Egi Guangyu Shi Ack: Vyas Sekar

10. 10 Specialized boxes Narrow interfaces “Point” solutions! Increases capital expenses & sprawl Increases operating expenses Limits extensibility and flexibility Management Key “pain points” 

11. Network-wide Controller Key idea: Consolidation 2. Consolidate Management 1. Consolidate Platform Two levels corresponding to two sources of inefficiency 11

12. Consolidation at Platform-Level 12 ProxyFirewallIDS/IPS AppFilter Today: Independent, specialized boxes Decouple Hardware and Software

13. Consolidation reduces CapEx 13 Multiplexing benefit = Sum_of_MaxUtilizations/ Max_of_TotalUtilization

14. Consolidation Enables Extensibility 14 Session Management Protocol Parsers VPN Web Mail IDS Proxy Firewall Contribution of reusable modules: 30 – 80 %

15. Management consolidation enables flexible resource allocation 15 N1 N3 N2 P: N1  N3 Process (0.4 P) Today: All processing at logical “ingress” Overload! Network-wide distribution reduces load imbalance Process (0.3 P) Process (P)

16. Network-wide Controller CoMb System Overview 16 General-purpose hardware Logically centralized e.g., NOX, 4D Existing work: simple, homogeneous routing-like workload Middleboxes: complex, heterogeneous, new opportunities

17. Network-wide Controller Processing responsibilities CoMb Management Layer Policy Constraints Resource Requirements Routing, Traffic Goal: Balance load across network. Leverage multiplexing, reuse, distribution 17

18. Capturing Reuse with HyperApps 18 IDSProxy common Footprint on resource HTTP UDP HTTP NFS 2 3 11 Memory CPU HTTP = IDS & Proxy 43 Memory UDP = IDS NFS = Proxy 13 4 1 CPU Memory CPU HyperApp: find the union of apps to run Need per-packet policy, reuse dependencies! HTTP HTTP: 1+2 unit of CPU 1+3 units of mem

19. Modeling Processing Coverage 19 HTTP N1  N3 N1N2 N3 What fraction of traffic of class HTTP from N1  N3 should each node process? IDS < Proxy 0.4 HTTP: Run IDS -> Proxy IDS < Proxy 0.3 IDS < Proxy 0.3

20. Network-wide Optimization 20 Minimize Maximum Load, Subject to Processing coverage for each class of traffic  Fraction of processed traffic adds up to 1 Load on each node  Sum over HyperApp responsibilities per-path A simple, tractable linear program Very close (< 0.1%) to theoretical optimal No explicit Dependency Policy

21. Network-wide Controller CoMb System Overview 21 General-purpose hardware Logically centralized e.g., NOX, 4D Existing work: simple, homogeneous routing-like workload Middleboxes: complex, heterogeneous, new opportunities

22. CoMb Platform 22 NIC Policy Shim (Pshim) Core1 Core4 IDS … … Proxy Traffic Applications Policy Enforcer Classification: HTTP IDS -> Proxy Challenges: Performance Parallelize Isolation Challenges: Lightweight Parallelize Challenges: No contention Fast classification

23. Parallelizing Application Instances 23 M1 M2 PShim App-per-core Core3 M3 PShim Core1 Core2 HyperApp-per-core M2M3 PShim M1M2 PShim Core1 Core2 - Inter-core communication - More work for PShim + No in-core context switch + Keeps structures core-local + Better for reuse - But incurs context-switch - Need replicas ✔ HyperApp-per-core is better or comparable Contention does not seem to matter!

24. CoMb Platform Design 24 Hyper App1 Hyper App2 Hyper App4 Hyper App3 Hyper App3 PShim M1M4M1M4M2M3 Q1 Q3 Q2Q4Q5 M1M5 Core 1Core 3Core 2 NIC hardware Contention-free network I/O Core-local processing Parallel, core-local Workload balancing

25. Benefits: Reduction in Maximum Load 25 Consolidation reduces maximum load by 2.5-25X MaxLoad Today /MaxLoad Consolidated

26. Benefits: Reduction in Provisioning Cost 26 Consolidation reduces provisioning cost 1.8-2.5X Provisioning Today /Provisioning Consolidated

27. Outline Recent trends in middlebox design/deployment – Middlebox Consolidation (CoMb) – Extensible Software Middlebox Architecture (xOMB) Middleboxes/SDN Integration – Elastic Execution (Split/Merge) – Policy enforcement (SIMPLE) – Handling dynamic traffic modification (FlowTags) 2710/22/13 Software Defined Networking (COMS 6998-8)

28. xOMB: Extensible Open Middleboxes with Commodity Servers James Anderson, Ryan Braud, Rishi Kapoor, George Porter and Amin Vahdat 28 Ack: Rishi Kapoor

29. xOMB CoMb focused on consolidated deployment of middleboxes and simplifying network deployment. xOMB is a framework for programmable middleboxes using commodity servers. Provides low-level functionality necessary for high performance processing User defined functionality on top of basic xOMB blocks 29

30. xOMB Framework 30 Client Connections Hardware Switch LAN F(N) G(N) F(N) G(N) F(N) G(N) Controller Backend Servers 30

31. xOMB Architecture Socket I/O Control Plane Connection Manager Message Reorder Buffer Client TCP Buffer Manager Backend TCP xOMB Modules or User Defined Pipeline 31 Basic Functionality

32. Outline Recent trends in middlebox design/deployment – Middlebox Consolidation (CoMb) – Extensible Software Middlebox Architecture (xOMB) Middleboxes/SDN Integration – Elastic Execution (Split/Merge) – Policy enforcement (SIMPLE) – Handling dynamic traffic modification (FlowTags) 3210/22/13 Software Defined Networking (COMS 6998-8)

33. Split / Merge System Support for Elastic Execution in Virtual Middleboxes Shriram RAJAGOPALAN IBM Research & UBC Dan WILLIAMS IBM Research Hani JAMJOOM IBM Research Andrew WARFIELD UBC Ack: Shriram Rajagopalan

34. Elastic Apps Need Elastic Middleboxes Elastic App Tier Flows SDN IDS/IPS Firewall Clients Virtual Middleboxes LB VPN Accelerator

35. Alleviating Hotspots M1M2 Solution: When M1 is overloaded, provision more middlebox(es) to serve new flows. Virtual Middleboxes Elastic App Tier SDN

36. Scaling Inefficiencies Lead to Poor Utilization. M1M2 M3M4 Virtual Middleboxes Elastic App Tier SDN Alleviating Hotspots

37. Flow State is Naturally Partitioned Flow M1 Table Split/Merge Insight Virtual Middleboxes Elastic App Tier SDN

38. Intuition: Dynamic partitioning of flow states among replicas enables elastic execution. Flow Table Flow Table Split/Merge Insight Virtual Middleboxes Elastic App Tier SDN

39. State Inside a Middlebox Output Flows Caches Other processes … Internal to a replica Threshold Non-critical countersstatistics Middlebox VM Flow Table KeyValue 5-tuple[Flow State] Input Flows May be shared among replicas (coherent) Partitionable among replicas

40. Split/Merge: A State-Centric Approach to Elasticity VM Virtual Network Interface Internal Coherent Partitionable (Flow States)

41. VM Virtual Network Interface Split Replica 1Replica 2 VM Internal Coherent Partitionable (Flow States) Replica 3 VM 1 23 Split/Merge: A State-Centric Approach to Elasticity

42. Virtual Network Interface! Split Replica 1 VM Internal VM Coherent Partitionable (Flow States) Replica 2Replica 3 VM Unchanged 123 Coherency is Interfaces! maintained Merge Replica 1Replica 2+3 VM 1 2 Split/Merge: A State-Centric Approach to Elasticity

43. Implementation

44. VM Internal Coherent Partitionable (Flow States) Replica 1Replica 2 VM 1 2 VMM Traffic to Middlebox Flow 1 Flow 2 FreeFlow

45. Replica 1Replica 2 — Need to manage VM application state 1 2 VMM Traffic to Middlebox Flow 1 Flow 2 FreeFlow

46. — Need to manage application state — Need to ensure flows are routed to the correct replica Replica 1 1 VMM Flow 1 FreeFlow Module Controller Replica 2 VM 2 VMM Flow 2 Traffic to Middlebox VM FreeFlow

47. — Need to manage application state — Need to ensure flows are routed to the correct replica — Need to decide when to split or merge a replica 1 VMM Flow 1 Orchestrator FreeFlow Module Controller 2 VMM Flow 2 Traffic to Middlebox Replica 1Replica 2 VM VM FreeFlow

48. Annotating State using FreeFlow API create_flow (flow_key, size) delete_flow (flow_key) flow_state get_flow (flow_key) put_flow (flow_key) Partitioned State API flow_timer (flow_key, timeout, callback) Coherent State API create_shared (key, size, cb) delete_shared (key) state get_shared (key, flags) // synch | pull |local put_shared (key, flags) // synch | push |local

49. Forwarding Flows Correctly using OpenFlow 1.1.1.1 (de:ad:be:ef:ca:fe) Flow Table OpenFlow Table port 1 port 2 … OpenFlow Table port 1 port 1 … port 1 Virtual Switch! OpenFlow Table … Middlebox Replica 1! 1.1.1.1 (de:ad:be:ef:ca:fe) Flow Table OpenFlow Switch! port 2 port 1 … Virtual Switch!port 1 … Middlebox Replica 2! Open Flow SW MBox Replica 1 MBox Replica 2

50. Flow Migration 1.1.1.1 (de:ad:be:ef:ca:fe) Migrating from replica 2 to replica 1 OpenFlow Table port 1 port 2 … OpenFlow Table port 1 port 1 … OpenFlow Table Flow Table … Middlebox Replica 1! 1.1.1.1 (de:ad:be:ef:ca:fe) Flow Table port 1 … Virtual Switch!port 1 … Middlebox Replica 2! Open Flow SW MBox Replica 1 MBox Replica 2 port 1 Virtual Switch! port 2

51. 1.1.1.1 (de:ad:be:ef:ca:fe) 1. Suspend flow and buffer packets OpenFlow Table port 1 controller port 2 … OpenFlow Table port 1 port 1 … OpenFlow Table Flow Table … Middlebox Replica 1! 1.1.1.1 (de:ad:be:ef:ca:fe) Flow Table port 1 …! Virtual Switch!port 1 ! … Middlebox Replica 2! Flow Migration Open Flow SW MBox Replica 1 MBox Replica 2 port 1 Virtual Switch! port 2

52. 1.1.1.1 (de:ad:be:ef:ca:fe) Flow Table 2. Move flow state to target OpenFlow Table controller port 2 … OpenFlow Table port 1 port 1 … port 1 Virtual Switch! OpenFlow Table! … Middlebox Replica 1! 1.1.1.1 (de:ad:be:ef:ca:fe) Flow Table! port 1 … Virtual Switch! port 1! … Middlebox Replica 2! Flow Migration <c Open Flow SW MBox Replica 1 MBox Replica 2 port 2 port 1

53. 1.1.1.1 (de:ad:be:ef:ca:fe) Flow Table 3. Release buffer and resume flow OpenFlow Table port 1 port 2 … OpenFlow Table port 1 port 1 port 1 … port 1 Virtual Switch! OpenFlow Table … Middlebox Replica 1! 1.1.1.1 (de:ad:be:ef:ca:fe) Flow Table OpenFlow Switch! port 2 port 1 … Virtual Switch! port 1.. Middlebox Replica 2! Flow Migration Open Flow SW MBox Replica 1 MBox Replica 2

54. Managing Coherent State create_shared (key, size, cb) delete_shared (key) state get_shared (key, flags) // synch | pull |local put_shared (key, flags) // synch | push |local

55. Strong Consistency create_shared(“foo”, 4, NULL) while (1) process_packet() p_foo = get_shared(“foo”, synch) Distributed lock for every update val = (*p_foo)++ put_shared(“foo”, synch) if (val > threshold) bar() Middlebox applications rarely need strong consistency! Managing Coherent State

56. Eventual Consistency create_shared(“foo”, 4, merge_fn) while (1) process_packet() p_foo = get_shared(“foo”, local) Hi frequency local updates Periodic global updates val = (*p_foo)++ put_shared(“foo”, local) if (val > threshold) bar() put_shared(“foo”, push) Managing Coherent State

57. Eliminating Hotspots by Shedding Load

59. Outline Recent trends in middlebox design/deployment – Middlebox Consolidation (CoMb) – Extensible Software Middlebox Architecture (xOMB) Middleboxes/SDN Integration – Elastic Execution (Split/Merge) – Policy enforcement (SIMPLE) – Handling dynamic traffic modification (FlowTags) 5910/22/13 Software Defined Networking (COMS 6998-8)

60. SIMPLE-fying Middlebox Policy Enforcement Using SDN Zafar Ayyub Qazi Cheng-Chun Tu Luis Chiang Vyas Sekar Rui Miao Minlan Yu

61. Can SDN simplify middlebox management? Centralized Controller “ Flow ” FwdAction …… “ Flow ” FwdAction …… OpenFlow 61 Proxy IDS Necessity + Opportunity: Incorporate functions markets views as important Scope: Enforce middlebox-specific steering policies Firewall IDS Proxy Web

62. What makes this problem challenging? Centralized Controller “ Flow ” FwdAction …… “ Flow ” FwdAction …… OpenFlow 62 Proxy IDS Middleboxes introduce new dimensions beyond L2/L3 tasks. Achieve this with unmodified middleboxes and existing SDN APIs Firewall IDS Proxy Web

63. Firewall IDS Proxy Web Our Work: SIMPLE Legacy Middleboxes OpenFlow capable FlowAction …… FlowAction …… 63 Policy enforcement layer for middlebox-specific “traffic steering”

64. Challenge: Policy Composition S1 S2 64 Firewall Proxy IDS FirewallIDSProxy * Policy Chain: Oops! Forward Pkt to IDS or Dst? Dst “Loops” Traditional flow rules may not suffice!

65. Challenge: Resource Constraints S1 S2 S4 S3 Proxy Firewall IDS1 = 50% IDS2 = 50% Space for traffic split? Can we set up “feasible” forwarding rules? 65

66. 66 S1 Proxy S2 User 1 User 2 Proxy may modify flows Are forwarding rules at S2 correct? Challenge: Dynamic Modifications Firewall User1: Proxy  Firewall User2: Proxy

67. Rule Generator Resource Manager Modifications Handler SIMPLE System Overview Legacy Middleboxes OpenFlow capable FlowAction …… FlowAction …… 67 Firewall IDS Proxy Web

68. Composition  Tag Processing State 68 FirewallIDSProxy * Policy Chain: S1 S2 Firewall Proxy IDS Dst ORIGINAL Post-Firewall Post-IDS Post-Proxy Fwd to Dst Insight: Distinguish different instances of the same packet

69. Rule Generator Resource Manager Modifications Handler SIMPLE System Overview Legacy Middleboxes OpenFlow capable FlowAction …… FlowAction …… 69 Firewall IDS Proxy Web

70. Resource Constraints  Joint Optimization Resource Manager Topology & Traffic Switch TCAM Middlebox Capacity + Footprints Policy Spec Optimal & Feasible load balancing Theoretically hard! Not obvious if some configuration is feasible! 70

71. Offline + Online Decomposition 71 Offline StageOnline Step Deals with Switch constraints Deals with only load balancing Resource Manager Network Topology Switch TCAM Policy Spec Traffic Matrix Mbox Capacity + Footprints

72. FW IDS Proxy Web Rule Generator Resource Manager Modifications Handler SIMPLE System Overview Legacy Middleboxes OpenFlow capable FlowAction …… FlowAction …… 72

73. Modifications  Infer flow correlations 73 Correlate flows Install rules S1 Proxy S2 User 1 User 2 Firewall User1: Proxy  Firewall User2: Proxy Payload Similarity

74. FW IDS Proxy Web Rule Generator (Policy Composition) Resource Manager (Resource Constraint) Modifications Handler (Dynamic modifications) SIMPLE Implementation OpenFlow 1.0 FlowTag/Tun nel Action …… FlowTag/Tun nel Action …… POX extensions 74 CPLEX

75. Evaluation and Methodology What benefits SIMPLE offers? load balancing? How scalable is the SIMPLE optimizer? How close is the SIMPLE optimizer to the optimal? How accurate is the dynamic inference? Methodology – Small-scale real test bed experiments (Emulab) – Evaluation over Mininet (with up to 60 nodes) – Large-scale trace driven simulations (for convergence times) 75

76. Benefits: Load balancing 4-7X better load balancing and near optimal 76 Optimal

77. Outline Recent trends in middlebox design/deployment – Middlebox Consolidation (CoMb) – Extensible Software Middlebox Architecture (xOMB) Middleboxes/SDN Integration – Elastic Execution (Split/Merge) – Policy enforcement (SIMPLE) – Handling dynamic traffic modification (FlowTags) 7710/22/13 Software Defined Networking (COMS 6998-8)

78. FlowTags: Enforcing Network-Wide Policies in the Presence of Dynamic Middlebox Actions Seyed K. Fayazbakhsh Vyas Sekar Jeff MogulMinlan Yu 78

79. Network OS Data Plane Control Apps “Flow”Action …… Physical View Logical view: Specify policy goals Admin Middleboxes complicate policy enforcement in SDN 79 Policy routing Access control Diagnostics Forensics Dynamic traffic-dependent modifications! e.g., NATs, proxies

80. Example: Policy Routing S1S2 NAT Internet H2 H1 IDS H1: NAT  Firewall H2: NAT  IDS Firewall How do we setup correct forwarding rules? 80

81. Example: Dynamic Dependence S1S2 Proxy Internet H2 H1 Web ACL: Block H2  xyz Get xyz.com Cached response Response Cached responses may violate policy 81 Cached response

82. Strawman Solutions Careful placement? (i.e., manual) – May not always be feasible Consolidating middleboxes? (e.g., CoMb) – Just “punting” the problem Inferring flow mappings? (e.g., SIMPLE) – Hard to reason about accuracy + high overhead 82 Key missing piece: Lack of “visibility” into middlebox context

83. FlowTags: High-level Idea Middleboxes “help” with the lack of visibility Add FlowTags to packets to bridge gaps – NAT gives IP mappings; Proxy gives cache hit/miss Middleboxes “produce” + “consume” FlowTags Switches only “consume” FlowTags 83

84. FlowTags Architecture Overview Controller Existing Interfaces e.g., OpenFlow SDN enabled Switches FlowTable Control Apps FlowTags API FlowTags API FlowTags Enhanced Middleboxes FlowTags Config FlowTags Config 84 e.g., NAT exposes mappings Proxy gives hit/miss state IDS uses tags to disambiguate “decouple”

85. Policy Implementation via FlowTags S1 S2 Proxy Internet H2 H1 InputTagOut Proxy2H1 Proxy1,3,4S2 TagSrcAction 4H2Block H1, MISS  1 H1, HIT  2 H2, MISS  3 H2, HIT  4 InputTagOut S11,3,4ACL 4S1 ACL1,3Internet ACL Policy: Block H2  xyz 85 TagsFlowTableTagsActionTable

86. FlowTags Proof-of-Concept Using Squid (> over 100,000 lines of code) About 30 lines of code to add FlowTags support – Manually identify code chokepoints Validated use-cases with examples 86