SDN: Extensions Middleboxes

1. SDN: ExtensionsMiddleboxes Ack: VyasSekar, Aaron Gember, Felipe Huici, ZafarQazi

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

3. Network Evolution today: Middleboxes! Data from a large enterprise: >80K users across tens of sites Just network security $10 billion

4. How many middleboxes do you deploy? Typically on par with # routers and switches.

5. How do administrators spend their time? Most administrators spent 1-5 hrs/week dealing with failures; 9% spent 6-10 hrs/week.

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

7. SDN Stack App Applications Controller Runtime Control Flow, Data Structures, etc. Controller Platform Switch API (OpenFlow) Switches

8. Outline • Why middleboxes? • SIMPLE • OpenMB • Slick

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

10. What makes this problem challenging? Centralized Controller Web Proxy Firewall IDS OpenFlow Proxy IDS Middleboxes introduce new dimensions beyond L2/L3 tasks. Achieve this with unmodifiedmiddleboxes and existingSDN APIs

11. SIMPLE overview Web Proxy Firewall IDS Policy enforcement layer for middlebox-specific “traffic steering” OpenFlow capable Legacy Middleboxes

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

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

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

15. New dimensions beyond Layer 2-3 tasks 1) Policy Composition  Potential loops 2) Resource Constraints  Switch + Middlebox 3) Dynamic Modifications  Correctness? Can we address these with unmodifiedmiddleboxes and existingSDN APIs?

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

17. Composition  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

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

19. Resource Constraints 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!

20. 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

21. Offline Stage: ILP based pruning • Feasible • Sufficient freedom Set of all possible middlebox load distributions Pruned Set Balance the middlebox load

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

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

24. SIMPLE Implementation Web FW IDS Proxy CPLEX Modifications Handler (Dynamic modifications) Resource Manager (Resource Constraint) Rule Generator (Policy Composition) POX extensions OpenFlow 1.0

25. 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)

26. Summary of SIMPLE • Middleboxes: Necessity and opportunity for SDN • Goal: Simplify middlebox-specific policy enforcement • Challenges: Composition, resource constraints, modifications • SIMPLE: policy enforcement layer • Does not modify middleboxes • No changes to SDN APIs • No visibility required into the internal of middleboxes • Scalable and offers 4-7X improvement in load balancing

27. Outline • Why middleboxes? • SIMPLE • OpenMB • Slick

28. Middlebox Deployment Models • Arbitrary middlebox placement • New forms of middlebox deployment (VMs, ETTM [NSDI 2011], CoMB[NSDI 2012])

29. Live Data Center Migration • Move between software-defined data centers • Existing VM and network migration methods • Unsuitable for changing underlying substrate Data Center A Data Center B • Programmatic control over middlebox state

30. Middlebox Scaling • Add or remove middlebox VMs based on load • Clone VM (logic, policy, and internal state) • Unsuitable for scaling down or some scaling up • Fine-grained control

31. Contributions • Classify middlebox state, and discuss what should be controlled • Abstractions and interfaces • Representing state • Manipulating where state resides • Announcing state-related events • Control logic design sketches

32. Software-Defined Middlebox Networking SDN-like Middleboxes Today Controller Middlebox Middlebox IPS App App

33. Key Issues • How is the logic divided? • Where is state manipulated? • What interfaces are exposed? Controller Middlebox Middlebox App App

34. Middlebox State • Configuration input • + detailed internal records Src: HostA Server: B Proto: TCP Port: 22 Server: B CPU: 50% Balance Method: Round Robin Cache size: 100 State: ESTABSeq #: 3423 Hash: 34225 Content: ABCDE • Significant state diversity

35. Classification of State Action Supporting Tuning Only affects performance, not correctness Src: HostA Server: B Proto: TCP Port: 22 Server: B CPU: 50% Balance Method: Round Robin Cache size: 100 State: ESTABSeq #: 3423 Hash: 34225 Content: ABCDE Internal & dynamic Many forms

36. How to Represent State? Per flow • Significant diversity 1010110 Proto: TCP Port: 22 Src: HostA Server: B 1000101 Server: B CPU: 50% • May be shared 1111000 1101010 State: ESTABSeq #: 3423 • Unknown structure Policy Language 0101001 Hash: 34225 Content: ABCDE • Commonality among middlebox operations Shared

37. State Representation • Key: protocol header field/value pairs identify traffic subsets to which state applies • Action: transformation function to change parts of packet to new constants • Supporting: binary blob Key Action Supporting Field1 = Value1 … FieldN=ValueN Offset1 → Const1 … OffsetN→ConstN Binary Blob • Only suitable for per-flow state • Not fully vendor independent

38. How to Manipulate State? • Today: only control some state • Constrains flexibility and sophistication • Manipulate all state at controller • Removes too much functionality from middleboxes Controller Middlebox

39. State Manipulation Determine wherestate resides • Control over state placement • Broad operations interface • Expose state-related events Controller Create and update state IPS 1 IPS 2

40. Operations Interface Key SrcIP = 10.10.0.0/16 DPort = 22 Key DstIP = 10.20.1.0/24 Action * Action DROP Filter SrcIP = 10.10.54.41 Filter … get ( , ) remove( , ) Key SrcIP = 10.10.54.41 DstIP = 10.20.1.23 SPort = 12983 DPort = 22 Supporting State = ESTAB • Need atomic blocks of operations • Potential for invalid manipulations of state add ( , )

41. Events Interface • Triggers • Created/updated state • Require state to complete operation • Contents • Key • Copy of packet? • Copy of new state? Controller Firewall Balance visibility and overhead

42. Conclusion get/add/remove ( , ) • Need fine-grained, centralized control over middlebox state to support rich scenarios • Challenges: state diversity, unknown semantics … Key Field1 = Value1 … Action Offset1 → Const1 … Supporting Binary Blob

43. Open Questions • Encoding supporting state/other actionstate? • Preventing invalid state manipulations? • Exposing events with sufficient detail? • Maintaining operation during state changes? • Designing a variety of control logics? • Providing middlebox fault tolerance?

44. Outline • Why middleboxes? • SIMPLE • OpenMB • Slick

45. Network Policies • Reachability • Alice can not send packets to Bob • Application classification • Place Skype traffic in the gold queue

46. Limitations of SDN Data Plane • Limited actions and matching • Match: Ethernet, IP, TCP/UDP port numbers • Action: forward, drop, rewrite header, etc. Match Action 10.2.3.4:10.2.3.3 Fwd Port 1 A2:e3:f1:ba:ea:23:* Drop

47. Extending SDN’s Data Plane • Expand the OpenFlow standards • Requires hardware support • Implement richer data plane in controller • Introduces additional latency to packets • Add new devices (Middleboxes)

48. Example: Detecting Network Attacks • Inspect all DNS traffic with a DPI device • If suspicious lookup takes place, send to traffic scrubber

49. Example: Detecting Network Attacks • Inspect all DNS traffic with a DPI device • If suspicious lookup takes place, send to traffic scrubber

50. Example: Detecting Network Attacks • Inspect all DNS traffic with a DPI device • If suspicious lookup takes place, send to traffic scrubber