1. SDN: Extensions Middleboxes 1 Ack: Vyas Sekar, Aaron Gember, Felipe Huici, Zafar Qazi

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

3. 3 Type of applianceNumber Firewalls166 NIDS127 Media gateways110 Load balancers67 Proxies66 VPN gateways45 WAN Optimizers44 Voice gateways11 Total Middleboxes636 Total routers~900 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? Misconfig.OverloadPhysical/ Electrical Firewalls67.3%16.3% Proxies63.2%15.7%21.1% IDS54.45%11.4%34% Most administrators spent 1-5 hrs/week dealing with failures; 9% spent 6-10 hrs/week.

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

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

8. Outline Why middleboxes? SIMPLE OpenMB Slick 8

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

10. What makes this problem challenging? Centralized Controller “ Flow ” FwdAction …… “ Flow ” FwdAction …… OpenFlow 10 Proxy IDS Middleboxes introduce new dimensions beyond L2/L3 tasks. Achieve this with unmodified middleboxes and existing SDN APIs Firewall IDS Proxy Web

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 26

27. Outline Why middleboxes? SIMPLE OpenMB Slick 27

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

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

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

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 31

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

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

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

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

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

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 KeyActionSupporting Binary Blob Field1 = Value1 … FieldN = ValueN 37 Offset1 → Const1 … OffsetN → ConstN Only suitable for per-flow state Not fully vendor independent Only suitable for per-flow state Not fully vendor independent

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

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

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

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

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

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

44. Outline Why middleboxes? SIMPLE OpenMB Slick 44

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 10.2.3.4:10.2.3.3 Fwd Port 1 A2:e3:f1:ba:ea:23:* Drop Match Action Limited actions and matching – Match: Ethernet, IP, TCP/UDP port numbers – Action: forward, drop, rewrite header, etc.

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 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 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 Inspect all DNS traffic with a DPI device If suspicious lookup takes place, send to traffic scrubber

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

52. Challenges Specify network policies across middleboxes – Difficult to automatically react to middlebox events Dynamically place sophisticated middleboxes – Difficult to determine efficient placement – Difficult to adjust placement to traffic patterns Support for arbitrary middlebox functionality – Difficult to capture hardware requirements

53. Slick Contributions Abstraction for programming middleboxes – Simplifies the development of network policies – Separates specification of intent from implementation Dynamic placement of middlebox functionality – Online resource allocation algorithm Support for heterogeneous devices – Maintains performance profiles of middlebox

54. Slick Architecture Slick Controller Middlebox Element Middlebox Element Middlebox Element Middlebox Element Application Encodes network policy Provides handlers for triggers Encodes network policy Provides handlers for triggers Piece of code encapsulating middlebox functions Your network operator 3 rd party element developers Programmable device: NetFPGA, x86 server Virtual Switch Triggers from elements

55. Slick Architecture Slick Controller Application Runs applications Runs resource allocation algo. Places middlebox elements Steers traffic through middleboxes Configures switches Runs applications Runs resource allocation algo. Places middlebox elements Steers traffic through middleboxes Configures switches Installs/uninstalls middlebox functions Deploy Middlebox code Middlebox Element Middlebox Element Middlebox Element Middlebox Element Programmable device: NetFPGA, x86 server Virtual Switch

56. Resource Allocation Heuristic Resource allocation heuristic Resource allocation heuristic Traffic Steering OpenFlow Controller OpenFlow Controller Placement Decisions Traffic matrix And topology Network policies in applications Middlebox perf profile Hardware constraints Programmable device Virtual Switch Programmable device Virtual Switch Objective: minimize latency (path lengths)

57. Summary Slick: control plane for middleboxes – Presented an initial architecture – Discussed algorithmic challenge Slick is implemented in python – Slick controller as a module on NoX 0.5.0 – Developed 2 applications and 3 middlebox elements Open questions – How can developers help guide placement? – What is the optimal solution for resource allocation?

58. Discussion: Likes/dislikes? 58