1 / 36

Toward Practical Convergence of Middleboxes and Software -Defined Networking

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. Network “101” vs. Reality. Traditional view: “Dumb” network.

vila
Download Presentation

Toward Practical Convergence of Middleboxes and Software -Defined Networking

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. Middleboxes Galore! Data from a large enterprise Survey across 57 network operators Just network security  $10 billion (2016)

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

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

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

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

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

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

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

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

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

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

  14. Offline + Online Decomposition MboxCapacity + Footprints Policy Spec Network Topology Switch TCAM Traffic Matrix Resource Manager Offline Stage Online Step Deals with Switch constraints Deals with only load balancing

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

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

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

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

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

  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

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

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

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

  24. Seemingly natural (non)solutions

  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

  26. Example of FlowTags in action NAT Add Tags Tag Generation Firewall Config w.r.t original principals Decode Tags Block 192.168.1.1 Block 192.168.1.3 H1 192.168.1.1 TagConsumption Firewall NAT H2 192.168.1.2 Internet S1 S2 S2 FlowTable H3 192.168.1.3 Tag Consumption

  27. FlowTags Architecture Legacy interface Control Apps e.g., steering, verification Admin Control Apps e.g., routing, traffic eng. Control Apps e.g., steering, verification New interface Network OS Control FlowTags APIs Existing APIs e.g., OpenFlow Data FlowTags Enhanced Middleboxes Mbox Config FlowTags Tables SDN Switches FlowTable “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?

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

  30. FlowTags-enhanced Controller • 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

  31. Extending middleboxes to support FlowTags Minimal code modification needed

  32. Scalability of FlowTags controller

  33. Talk Outline Motivation Design of SIMPLE Design of FlowTags Other middleboxresearch

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

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

  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 middleboxactions • Broader agenda -- “Middlebox Manifesto”Rethink middlebox design and management

More Related