Design and Implementation of a Consolidated Middlebox Architecture

Design and Implementation of a Consolidated Middlebox Architecture Vyas Sekar Sylvia Ratnasamy Michael Reiter Norbert Egi Guangyu Shi 1

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

Network Evolution today: Middleboxes! Type of appliance Data from a large enterprise: >80 K users across tens of sites Just network security $10 billion Number Firewalls 166 NIDS 127 Media gateways 110 Load balancers 67 Proxies 66 VPN gateways 45 WAN Optimizers 44 Voice gateways 11 Total Middleboxes Total routers 636 ~900 3

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

Outline • Motivation • High-level idea: Consolidation • System design • Implementation and Evaluation 5

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

Consolidation at Platform-Level Today: Independent, specialized boxes Proxy Firewall IDS/IPS App. Filter Decouple Hardware and Software Commodity hardware: e. g. , Packet. Shader, Route. Bricks, Server. Switch, Switch. Blade Consolidation reduces capital expenses and sprawl 7

Consolidation reduces Cap. Ex Multiplexing benefit = Max_of_Total. Utilization / Sum_of_Max. Utilizations 8

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

Management consolidation enables flexible resource allocation Today: All processing at logical “ingress” Process (0. 4(P) P) N 1 Overload! Process (0. 3 P) N 2 N 3 P: N 1 N 3 Network-wide distribution reduces load imbalance 10

Outline • Motivation • High-level idea: Consolidation • Co. Mb: System design • Implementation and Evaluation 11

Co. Mb System Overview Network-wide Controller Logically centralized e. g. , NOX, 4 D General-purpose hardware: e. g. , Packet. Shader, Route. Bricks, Server. Switch, Existing work: simple, homogeneous routing-like workload Middleboxes: complex, heterogeneous, new opportunities 12

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

Capturing Reuse with Hyper. Apps Hyper. App: find the union of apps to run HTTP: 1+2 unit of CPU 1+3 units of mem HTTP UDP IDS 2 1 HTTP = IDS & Proxy HTTP NFS Proxy common CPU 1 CPU Footprint on resource Need per-packet policy, reuse dependencies! 4 Memory UDP = IDS 3 Memory CPU 3 3 1 Memory NFS = Proxy CPU 1 4 Memory Policy, dependency are implicit 14

Modeling Processing Coverage HTTP: Run IDS < Proxy 0. 4 IDS < Proxy 0. 3 HTTP N 1 N 3 N 1 N 2 N 3 What fraction of traffic of class HTTP from N 1 N 3 should each node process? 15

Network-wide Optimization 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 Hyper. App responsibilities per-path No explicit Dependency Policy A simple, tractable linear program Very close (< 0. 1%) to theoretical optimal 16

Co. Mb System Overview Network-wide Controller Logically centralized e. g. , NOX, 4 D General-purpose hardware: e. g. , Packet. Shader, Route. Bricks, Server. Switch, Existing work: simple, homogeneous routing-like workload Middleboxes: complex, heterogeneous, new opportunities 17

Co. Mb Platform Applications Policy Enforcer IDS < Proxy IDS … Proxy Core 1 … Core 4 Policy Shim (Pshim) Classification: HTTP NIC Traffic Challenges: Performance Parallelize Isolation Challenges: Lightweight Parallelize Challenges: No contention Fast classification 18

Parallelizing Application Instances App-per-core M 1 M 2 Core 1 Core 2 PShim Hyper. App-per-core M 3 Core 3 PShim - Inter-core communication - More work for PShim + No in-core context switch M 1 M 2 Core 1 PShim M 2 M 3 ✔ Core 2 PShim + Keeps structures core-local + Better for reuse - But incurs context-switch - Need replicas Hyper. App-per-core is better or comparable Contention does not seem to matter! 19

Co. Mb Platform Design Core-local processing Core 2 Core 1 M 1 Hyper App 1 M 2 Workload balancing M 3 M 1 M 4 Hyper App 2 Hyper App 3 PShim Q 1 Q 2 Q 3 NIC hardware Core 3 M 5 Hyper App 4 PShim Q 4 M 1 M 4 Hyper App 3 PShim Q 5 Parallel, core-local Contention-free network I/O 20

Outline • Motivation • High-level idea: Consolidation • System design: Making Consolidation Practical • Implementation and Evaluation 21

Implementation Network-wide Management Policy Shim Extensible apps Ported logic From Bro Click using CPLEX Kernel mode Click Standalone apps Protocol Memory mapped Or Virtual interfaces Session 8 -core Intel Xeon with Intel 82599 NIC 22

Consolidation is Practical • Low overhead for existing applications • Controller takes < 1. 6 s for 52 -node topology • 5 x better than VM-based consolidation 23

Benefits: Reduction in Maximum Load Max. Load. Today /Max. Load. Consolidated Consolidation reduces maximum load by 2. 5 -25 X 24

Benefits: Reduction in Provisioning Cost Provisioning. Today /Provisioning. Consolidated Consolidation reduces provisioning cost 1. 8 -2. 5 X 25

Discussion • Changes traditional vendor business – Already happening (e. g. , “virtual appliances”) – Benefits imply someone will do it! – May already have extensible stacks internally! • Isolation – Current: rely on process-level isolation – Get reuse-despite-isolation? 26

Conclusions • Network evolution occurs via middleboxes • Today: Narrow “point” solutions – High Cap. Ex, Op. Ex, and device sprawl – Inflexible, difficult to extend • Our proposal: Consolidated architecture – Reduces Cap. Ex, Op. Ex, and device sprawl – Extensible, general-purpose • More opportunities – Isolation – APIs (H/W—Apps, Management—Apps, App Stack) 27