1. Toward Practical Convergence of Middleboxes and Software-Defined Networking Vyas Sekar Joint work with: Seyed Kaveh Fayazbakhsh, Zafar Qazi, Luis Chiang, Rui Miao, William Tu, Jeff Mogul, Minlan Yu

2. Network “101” vs. Reality 2 Traditional view: “Dumb” network Reality: Lots of in-network processing Appliances or Middleboxes: IDS, Firewall, Proxies, Application Gateways ….

3. Type of applianceNumber Firewalls166 NIDS127 Media gateways110 Load balancers67 Proxies66 VPN gateways45 WAN Optimizers44 Voice gateways11 Total Middleboxes636 Total routers~900 Middleboxes Galore! Data from a large enterprise Survey across 57 network operators 3 Just network security  $10 billion (2016)

4. Middlebox management is hard! 4 Critical for security, performance, compliance But expensive, complex and difficult to manage

5. Can SDN help middlebox management? Centralized Controller “ Flow ” FwdAction …… “ Flow ” FwdAction …… OpenFlow 5 Proxy IDS Necessity and an Opportunity: Incorporate functions markets views as important [Metzler 2012] Firewall IDS Proxy Web

6. What makes SDN + MB challenging? Centralized Controller “ Flow ” FwdAction …… “ Flow ” FwdAction …… OpenFlow 6 Proxy IDS New dimensions beyond simple forwarding: e.g., Policy-based “steering” composition New resource management Packet transformations/hidden actions Firewall IDS Proxy Web

7. Our work on SDN-middlebox convergence 7 FlowTags: Handling dynamic middlebox actions New APIs + minimal extensions to middleboxes SIMPLE: SDN-based traffic steering Unmodified middleboxes, current SDN APIs

8. Talk Outline Motivation Design of SIMPLE (SIGCOMM 2013) Design of FlowTags (NSDI 2014) Other middlebox research 8

9. Firewall IDS Proxy Web SIMPLE: High-level view Legacy Middleboxes OpenFlow capable FlowAction …… FlowAction …… 9 Policy enforcement layer for middlebox-specific traffic steering

10. Challenge: Policy Composition S1 S2 10 Firewall Proxy IDS FirewallIDSProxy * Policy Chain: Forward Pkt to IDS or Dst? Dst “Loops”  Simple flow rules don’t work

11. Rule Generator  Tag Processing State 11 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

12. Challenge: Resource Constraints S1 S2 S4 S3 Proxy Firewall IDS1 = 50% IDS2 = 50% Enough TCAM space for traffic split? Can we set up “feasible” forwarding rules and load balance optimally? 12 FlowAction …… FlowAction ……

13. Resource manager  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 13

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

15. 15 S1 Proxy S2 User 1 User 2 Proxy may modify flows Actually a more fundamental problem Will revisit in FlowTags Challenge: Dynamic Modifications Firewall User1: Proxy  Firewall User2: Proxy

16. Modifications Handler  Flow correlation 16 Correlate flows Install rules S1 Proxy S2 User 1 User 2 Firewall User1: Proxy  Firewall User2: Proxy Payload Similarity

17. Rule Generator Avoid Loops Resource Manager Handle resource constraints Modifications Handler Deal w/ flow modifications SIMPLE System Overview Legacy Middleboxes OpenFlow capable FlowAction …… FlowAction …… 17 Firewall IDS Proxy Web

18. SIMPLE = Optimal Load balancing 4-7X better that status quo 18 Optimal

19. Talk Outline Motivation Design of SIMPLE (SIGCOMM 2013) Design of FlowTags (NSDI 2014) Other middlebox research 19

20. Middlebox actions violate SDN tenets Revisit SDN tenets from Ethane [SIGCOMM 07] Origin Binding: There should be a strong binding between a packet and its “origin” Paths follow policy: Explicit policy should determine the paths that packets follow 20

21. Attribution is hard NAT hides the true packet sources 21 S1 S2 NIDS NAT Internet H2 H1 NIDS: Flag host if it creates too many connections

22. Network Diagnosis is difficult Difficult to correlate network logs for diagnosis 22 S1 S2 Load BalancerFirewall H2 H1 Server 2 Server 1 H1 sees very high web server delay – but what’s causing it?

23. Policy violations may occur S1S2 Proxy Internet H2 H1 Web ACL: Block H2  xyz Get xyz.com Cached response Response Lack of visibility into the middlebox context 23 Cached response

24. Seemingly natural (non)solutions IdeasAttribution e.g., NAT Diagnosis e.g., Load Balancer Policy violation e.g., cache PlacementYesNoYes TunnelingNoEven harder!No ConsolidationNo Correlation (SIMPLE) Not 100% accurate and high overhead 24

25. High-level idea Middleboxes “help” restore SDN tenets – Possibly only option for correctness Add missing contextual information as FlowTags – E.g., NAT or Load balancer give IP mappings; Proxy gives cache hit/miss state SDN+ Controller controls tagging logic – For both switches and middleboxes 25

26. S1S1 S2S2 Firewall NAT Internet H1 192.168.1.1 H2 192.168.1.2 H3 192.168.1.3 SrcIPTag 192.168.1.11 192.168.1.22 192.168.1.33 TagOrigSrcIP 1192.168.1.1 3192.168.1.3 Block 192.168.1.1 Block 192.168.1.3 NAT Add Tags Decode Tags Firewall Config w.r.t original principals TagForward 1,3FW 2Internet S2 FlowTable Example of FlowTags in action Tag Generation Tag Consumption 26

27. Control Apps e.g., steering, verification Control Apps e.g., routing, traffic eng. Network OS Control Data SDN Switches FlowTable FlowTags Enhanced Middleboxes FlowTags Tables Control Apps e.g., steering, verification Admin Mbox Config FlowTags APIs Existing APIs e.g., OpenFlow Legacy interface New interface FlowTags Architecture 27 “Produce” + “consume” FlowTags Only “consume” FlowTags

28. Challenges in realizing FlowTags vision What semantics should FlowTags capture? Can we build a practical FlowTags controller? How easy is it to modify middleboxes? Can we encode FlowTags in packets? 28

29. Semantics: Dynamic Policy Graph 29 Proxy ACL Drop {H1}; Blocked H1 H2 {H1}; - {H2}; - {H1}; Hit {H1}; Miss {H1}; {H2}; Miss {H1}; Internet {H2}; Hit Conceptually need a tag in this DPG In practice: temporal reuse, spatial reuse, policy classes etc

30. Translate DPG to find a data-plane realization Middlebox event handlers: – Handle tag Consume and Generate events Switch and flow expiry handlers: – Similar to traditional OpenFlow handlers – The tag is used to look up the forwarding entries 30 FlowTags-enhanced Controller

31. Extending middleboxes to support FlowTags Minimal code modification needed 31 MiddleboxTotal LOCModified LOC Squid216,00075 Snort336,00045 Balance200060 PRADS1500025

32. Scalability of FlowTags controller 32

33. Talk Outline Motivation Design of SIMPLE Design of FlowTags Other middlebox research 33

34. Broader Research Agenda 34 High Capital costs Device Sprawl High management complexity Inflexible, difficult to extend  need for new boxes Consolidated Architecture [CoMb NSDI ‘12] Cloud Outsourcing [APLOMB SIGCOMM ’12] SDN Integration [SIMPLE, FlowTags, this talk]

35. New challenges and opportunities Policy languages/graph generation? Automating middlebox extensions? New testing/verification tools? Better hardware/software platforms? … 35

36. Conclusions Middleboxes: Necessity and opportunity for SDN New challenges in SDN: Composition, resource constraints, modifications First steps in practical SDN + middlebox integration – SIMPLE for traffic steering – FlowTags to handle dynamic/hidden middlebox actions Broader agenda -- “Middlebox Manifesto” Rethink middlebox design and management 36

37. Consolidating Middleboxes [NSDI 2012] 37 ProxyFirewallIDS/IPS AppFilter Today: Independent, specialized boxes Decouple Hardware and Software Commodity hardware: e.g., PacketShader, RouteBricks, ServerSwitch, SwitchBlade Consolidation reduces capital expenses and sprawl

38. Internet Cloud Provider + Economies of scale, pay-per use + Simplifies configuration & deployment 38 Outsourcing Middleboxes [SIGCOMM 2012]

39. Overhead: Reconfiguration Time Around 125 ms to reconfigure, most time spent in pushing rules 39 33 node topology including 11 switches

40. 40 S1 Proxy S2 User 1 User 2 Proxy may modify flows Actually a more fundamental problem Revisit Dynamic Modifications Firewall User1: Proxy  Firewall User2: Proxy

41. Modifications Handler  Flow correlation 41 Correlate flows Install rules S1 Proxy S2 User 1 User 2 Firewall User1: Proxy  Firewall User2: Proxy Payload Similarity

42. Entire backbone runs on SDN SDN: New Trend in Network Management Bought for $1.2 x 10 9 42

43. Quick Intro to SDN Centralized Controller “ Flow ” Action …… “ Flow ” Action …… Open API e.g., OpenFlow 43 Traditional network: Closed hardware + Management embedded in routing state SDN: Switch/router actions can be “programmed” Management logic is consolidated 1.2.3.4  * : Block 4.5.6.7  5.6.7.8 : Use low congestion path

44. Need for Network Innovation 44 New devices New application drivers Evolving threats Policy constraints Security Performance Compliance

45. Consolidation is practical Low overhead for existing applications (0.7%) Controller takes < 1.6s for 52-node topology – Strawman-LP takes 9000s 5x better than VM-based consolidation Do not need very “beefy” nodes 45

46. Challenges in Cloud Outsourcing Minimal Complexity Functional equivalence e.g., Stateful connection Low Overhead i.e., Latency, bandwidth 46 VPN tunnel Off-the-shelf DNS based fwding Intelligent PoP selection Generic compression

47. New challenges and opportunities Policy languages/graph generation? Automating middlebox extensions? New testing/verification tools? Better hardware/software platforms? … 47

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

49. Broader Research Agenda 49 High Capital costs Device Sprawl High management complexity Inflexible, difficult to extend  need for new boxes Consolidated Architecture [NSDI ‘12] Software Defined Networking [this talk]