Design and Implementa/on of a Consolidated Middlebox Architecture. Vyas Sekar Sylvia Ratnasamy Michael Reiter Norbert Egi Guangyu Shi

Transcription

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

2 Need for Network Evolu/on New applica/ons Evolving threats Performance, Security, Compliance Policy constraints New devices 2

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

4 Key pain points Management Management Management Narrow interfaces Specialized boxes Point solu/ons! è Increases capital expenses & sprawl Increases opera/ng expenses Limits extensibility and flexibility 4

5 Outline Mo/va/on High- level idea: Consolida?on System design Implementa/on and Evalua/on 5

6 Consolida/on at Pla[orm- Level Today: Independent, specialized boxes Proxy Firewall IDS/IPS AppFilter Decouple Hardware and Soaware e.g., FlowStream (UCL/Lancaster) Consolida/on reduces capital expenses and sprawl 6

7 Consolida/on reduces CapEx 1 Normalized utilization (%) WAN optimizer Proxy Load Balancer Firewall 07-09,06: ,17: ,04: ,15: ,02:00 Time (mm-dd,hr) Mul/plexing benefit = Max_of_TotalU/liza/on / Sum_of_MaxU/liza/ons 7

8 Consolida/on Enables Extensibility VPN Web Mail IDS Proxy Firewall Protocol Parsers Session Management e.g., xomb (UCSD) Bro Contribu/on of reusable modules: % 8

9 Consolida/ng Management Network- Wide Management Logically centralized High- level interfaces e.g., SDN, OpenFlow, 4D Simplifies management to reduce opera/ng expenses 9

10 Consolida/on enables flexible resource management Today: All processing at logical ingress Process Process (0.4(P) P) Process (0.3 P) N1 Overload! Process (0.3 P) N2 P: N1à N3 N3 Distribu/on reduces load imbalance 10

11 Outline Mo/va/on High- level idea: Consolida/on CoMb: System design Implementa/on and Evalua/on 11

12 CoMb System Overview Network- wide Controller Logically centralized e.g., NOX, 4D Soaware- centric e.g., PacketShader, RouteBricks, ServerSwitch, SwitchBlade Exis/ng work: simple, homogeneous rou/ng- like workload Middleboxes: complex, heterogeneous, new opportuni/es 12

13 CoMb Management Layer Goal: Balance load across network Exploit mul/plexing, reuse, distribu/on Policy Constraints HTTP: IDS < Proxy Resource Requirements Network- wide Controller Rou/ng, Traffic Processing responsibili/es 13

14 Capturing Policy and Reuse Efficiently IDS Proxy 2 3 CPU HTTP: 1+2 unit of CPU 1+3 units of mem 1 HTTP UDP HTTP NFS common 1 Memory HTTP: IDS < Proxy Footprint on resource Need per- packet policy, reuse dependencies! HyperApp: union of apps to run CPU CPU CPU HTTP = IDS & Proxy 3 4 UDP = IDS 3 1 NFS = Proxy 1 4 Memory Memory Memory Policy, dependency are implicit Needs small brute- force step 14

15 Network- wide Op/miza/on Minimize Maximum Load, Subject to Processing coverage for each class of traffic à Frac/on of processed traffic adds up to 1 Load on each node à sum over HyperApp responsibili/es per- path No explicit Dependency Policy A simple, tractable linear program Very close (< 0.1%) to theore/cal op/mal 15

16 CoMb Pla[orm Applica/ons IDS Proxy Realize Hyperapp Parallelize Core1 Core4 Policy Enforcer IDS < Proxy Policy Shim (Pshim) Lightweight Parallelize Classifica?on: HTTP NIC Traffic No conten/on Fast classifica/on 16

17 Parallelizing Applica/on Instances App Per core HyperApp1: M1 < M2 HyperApp2: M2 < M3 HyperApp per core M1 M2 M3 M1 M2 M2 M3 Core1 Core2 Core3 Core1 Core2 PShim PShim PShim PShim - Inter- core communica/on - More work for PShim + No in- core context switch + Keeps structures core- local + Beter for reuse - But incurs context- switch - Need replicas HyperApp- per- core is beter or comparable 17

18 CoMb Pla[orm Design Core- local processing Workload balancing M1 Hyper App1 Core 1 Core 2 Core 3 M2 M3 Hyper App2 M1 M4 M5 M1 M4 Hyper App3 Hyper App4 Hyper App3 PShim PShim PShim PShim PShim Q1 Q2 Q3 Q4 Q5 NIC hardware Conten/on- free network I/O Parallel, core- local 18

19 Outline Mo/va/on High- level idea: Consolida/on System design: Making Consolida/on Prac/cal Implementa?on and Evalua?on 19

20 CoMb Implementa/on Network- wide Management using CPLEX Ported logic From Bro à Click Extensible apps Protocol Session Policy Shim Kernel mode Click Standalone apps Memory mapped Or Virtual interfaces 8- core Intel Xeon with Intel NIC 20

21 Consolida/on is Prac/cal Low overhead for exis/ng applica/ons Controller takes < 1.6s for 52- node topology 5x beter than VM- based consolida/on 21

22 Benefits: Reduc/on in Maximum Load 25 MaxLoad Today /MaxLoad Consolidated Relative savings Abilene Geant Enterprise AS1221 AS3257 AS1239 Consolida/on reduces maximum load by X Consolida/on reduces provisioning cost X 22

23 Discussion Isola/on Current: rely on process- level isola/on Leverage user- space networking Get reuse- despite- isola/on? Changes vendor business models Already happening (e.g., virtual appliances ) Benefits imply someone will do it! May already have extensible stacks 23

24 Conclusions Most network evolu/on today occurs via middleboxes Today: Narrow, point solu/ons High CapEx, OpEx, and device sprawl Inflexible, difficult to extend Our proposal: Consolidated architecture Extensible, general- purpose Reduces CapEx, OpEx, and device sprawl More opportuni/es Isola/on APIs (H/W Apps, Management Apps, App Stack) 24