Presentation on theme: "SIMPLE-fying Middlebox Policy Enforcement Using SDN"— Presentation transcript:
1 SIMPLE-fying Middlebox Policy Enforcement Using SDN Zafar Ayyub QaziCheng-Chun TuLuis ChiangVyas SekarRui MiaoMinlan YuHello everyone, I am Zafar, Today I will be talking about how we can simplify middlebox management using Software Defined networking. This is a joint work with collaborators from Stony Brook university and university of southern California.
2 Middleboxes management is hard! Survey across 57 network operators (J. Sherry et al. SIGCOMM 2012)e.g., a network with ~2000 middleboxes required 500+ operatorsMiddleboxes are widely used today to meet security, performance and compliance requirements. Even though they are a critical piece of the network infrastructure, there are expensive, complex and difficult to manage. A survey across 57 network operators showed that middlebox management is complex as significant manual effort is required for configuring them, as a result middleboxes are prone to failures due to misconfiguration and overload.Critical for security, performance, complianceBut expensive, complex and difficult to manage
3 Can SDN simplify middlebox management? Centralized ControllerFirewallIDSProxyWebOpenFlow“Flow”FwdAction…“Flow”FwdAction…ProxyIDSSDN on the other hand offers a promising alternative by using logically centralized management, decoupling of the data and control planes, and providing the ability to programmatically configure forwarding rules. In the scope of this work, we specifically consider the question that can we simplify middlebox-specific policy enforcement using SDN.This problem is also interesting because it provides both a necessity and an opportunity for SDN. It’s a necessity for SDN because in order to justify deployment into production networks it needs to incorporate functionalities that are viewed as important by the market. Its an opportunity because SDN has focused on L2/L3 tasks and middlebox requires higher layer functionalities.Scope: Enforce middlebox-specific steering policiesNecessity + Opportunity:Incorporate functions markets views as important
4 What makes this problem challenging? Centralized ControllerFirewallIDSProxyWebOpenFlow“Flow”FwdAction…“Flow”FwdAction…ProxyIDSThere are two key aspects which makes this problem challenging.One middleboxes introduce new dimensions that fall outside the scope of L2/L3 has traditionally focused on.One traditionally SDN has focused on L2/L3 tasks, however middleboxes require higher layer functionalities which introduce new dimensionsSecond, we already have a large number of middlebox deployments and middlebox implementations are proprietary in nature which makes it difficult to change middleboxes. We also want to use existing SDN APIs, whose minimalism has been a key driver for the adoption of SDN.Middleboxes introduce new dimensions beyond L2/L3 tasks.Achieve this with unmodified middleboxes and existing SDN APIs
5 Our Work: SIMPLE Policy enforcement layer for FirewallIDSProxyWebPolicy enforcement layer formiddlebox-specific “traffic steering”In order to address these challenges, we present a policy enforcement layer called SIMPLE. SIMPLE translates middlebox-specific policies into rules that can be installed on SDN switches while ensuring that load across middleboxes is balanced.LegacyMiddleboxesOpenFlowcapableFlowAction…FlowAction…
6 Outline Motivation Challenges SIMPLE Design Evaluation Conclusions Next we discuss in-detail the challenges in the management of middleboxes in SDN.6
7 Challenge: Policy Composition FirewallIDSProxy*Policy Chain:Oops! Forward Pkt to IDS or Dst?FirewallProxyIDSS1S2DstTypically middlebox policies require packets to traverse through a sequence of middleboxes. For instance, consider this example, where given this network of two switches and 3 middleboxes, we want to route all traffic through the policy chain Firewall-IDS-Proxy. To enforce this policy chain, the path that the packet should traverse has a loop. This is because switch S2 sees multiple instances of the same packet on the same interface.As a result when the packet reaches switch S2, it cannot determine whether to forward the packet to an IDS or the destination.As result traditional flow rules may not suffice to ensure correct forwarding in such scenarios.“Loops” Traditional flow rules may not suffice!
8 Challenge: Resource Constraints FirewallProxySpace fortraffic split?S2S4S1IDS1 = 50%IDS2 = 50%S3There are two key resource constraints here: middlebox processing constraint and limited TCAM space in SDN switches. Middleboxes involve complex processing to capture application level semantics or use deep packet inspection. In order to avoid scenarios of middlebox overload its important to balance the load across middleboxes. For instance in this network, we may want to spilt the load evenly across the two IDs. However when we split the traffic, each split needs to have forwarding rules to route the traffic to the correct physical middleboxes.In summary, besides the middlebox resource constraints, we also have to with switch TCAM space constraints.Can we set up “feasible” forwarding rules?
9 Challenge: Dynamic Modifications User1: Proxy FirewallUser2: ProxyProxy may modify flowsUser 1ProxyS1S2User 2FirewallMany middleboxes actively modify traffic headers and packet contents. To ensure that correct policies are enforced, we need to handle these transformations. Lets consider this example scenario, where we have a proxy receiving requests for the same content from two users. The proxy may combine these two requests and send it out as one packet. As the proxy modifies the flow, we need ensure that correct forwarding rules are installed in S2 to handle these transformations.Are forwarding rules at S2 correct?
10 New dimensions beyond Layer 2-3 tasks 1) Policy Composition Potential loops2) Resource Constraints Switch + Middlebox3) Dynamic Modifications Correctness?We have discussed three challenges in using SDN to simply middlebox management:Policy composition: enforce a policy that dictates that middleboxes route through a sequence of middleboxes.Resource constraints: while doing middlebox load balancing we need to take into account TCAM space in SDN switches.Many middleboxes dynamically modify flows, for correct routing of packets, these transformations should be taken into account.In summary, we observe that middleboxes introduce new challenges that fall outside the scope of L2/L3 tasks.Can we address these with unmodified middleboxes and existing SDN APIs?
11 Outline Motivation + Context for the Work Challenges SIMPLE Design EvaluationConclusionTo address these challenges we have designed a SIMPLE, a SDN-based policy enforcement layer for efficient middlebox-specific “traffic steering”. SIMPLE addresses these challenges without modifying the existing SDN APIs and without modifying middleboxes and without requiring an visibility into the internal state of middleboxes.
12 SIMPLE System Overview FirewallIDSProxyWebRule GeneratorResource ManagerModifications HandlerSIMPLE takes as input the middlebox specific policies corresponding to different traffic classes given a network of legacy middleboxes and SDN switches.Simple consists of a resource manger for load balancing across middleboxes subject to the middlebox and forwarding table capacity constraints, a modifications handler to account for dynamic middlebox induced transformations and the rule generator which enforces policy composition and outputs rules that can be installed in SDN switches using OpenFlow protocol.LegacyMiddleboxesOpenFlowcapableFlowAction…FlowAction…
13 Composition Tag Processing State FirewallIDSProxy*Policy Chain:FirewallProxyIDSFwd to DstS1S2DstPost-ProxyPost-FirewallORIGINALIn order to address the first challenge of policy composition, we introduce processing tags, which keep track of the processing state of the packet and help to disambiguate different instances of the same packet on the same switch interface. For instance in this example, S2 could not determine whether to forward packets to the IDS or destination using simple flow rules. However, now as the packet traverses a middlebox, the connected switch adds a tag to encode this information. The corresponding rules in the switches now take into account the state information encoded by the tag to take a forwarding decision. We can use an spare bits in IP header to encode this information.Post-IDSInsight: Distinguish different instances of the same packet
14 SIMPLE System Overview FirewallIDSProxyWebRule GeneratorResource ManagerModifications HandlerNext we discuss the Resource manager which balances the load across middleboxes while ensuring that TCAM space constraints in SDN switches are not exceeded.Drop the details of physical sequences discussion slide 19.LegacyMiddleboxesOpenFlowcapableFlowAction…FlowAction…
15 Resource Constraints Joint Optimization Topology & TrafficSwitchTCAMMiddleboxCapacity + FootprintsPolicySpecResource ManagerOptimal & Feasibleload balancingThe goal of the resource manager is to do optimal and feasible load balancing.The key challenge in the resource manager is the need to account for both the middlebox constraints and the flow table capacity of SDN switches. This makes the problem significantly more challenging compared to prior optimization models for middlebox load balancing. Unfortunately, this optimization problem is theoretically hard and is practically inefficient to solve for realistic scenariosTheoretically hard!Not obvious if some configuration is feasible!
16 Offline + Online Decomposition PolicySpecNetworkTopologySwitchTCAMMbox Capacity+ FootprintsTrafficMatrixResource ManagerOffline StageOnline StepWe handle this challenge by decomposing the optimization into two parts: (1) a slow offline stage where we tackle the switch constraints and (2) an online linear program formulation that only deals with load balancing. The offline pruning stage only needs to run when the network topology, switches, middlebox placements, or the network policy changes. The online load balancing stage runs more frequently when traffic patterns change on shorter timescales.Deals with Switch constraintsDeals with only load balancing
17 Offline Stage: ILP based pruning FeasibleSufficient freedomSet of all possible middlebox load distributionsPruned SetIn the offline stage, we prune the set of all physical sequences of middleboxes given all the policy chain, ensuring that the pruned set of physical sequences are feasible i.e., all policy chains will have at least one physical sequence and secondly there is sufficient freedom to ensure that there arre ample load balancing opportunities.Balance the middlebox load
18 SIMPLE System Overview FWIDSProxyWebRule GeneratorResource ManagerModifications HandlerNext, we discuss how we handle dynamic packet transformations induced by certain middleboxes.LegacyMiddleboxesOpenFlowcapableFlowAction…FlowAction…
19 Modifications Infer flow correlations CorrelateflowsInstall rulesPayload SimilarityUser 1ProxyS1S2In order to handle the dynamic transformations we correlate the incoming and outgoing flows from a middlebox.For example, in this network, we collect the first few packet of the incoming and outgoing flow from the proxy, then using payload similarity based algorithm to correlate these flows. Then we can install correct forwarding rules in the downstream switches which enforce the desired policy.User 2FirewallUser1: Proxy FirewallUser2: Proxy
20 SIMPLE Implementation FWIDSProxyWebRule Generator(Policy Composition)Resource Manager(Resource Constraint)Modifications Handler(Dynamic modifications)CPLEXPOX extensionsOpenFlow 1.0We implement SIMPLE as an extension to the POX controller. And we use openflow 1.0 protocol for talking to the controller.Note: Although we use OpenFlow 1.0, SIMPLE can use any other versions.Tunneling, we do other optimizationsFlowTag/TunnelAction…FlowTag/TunnelAction…
21 Outline Motivation + Context for the Work Challenges SIMPLE Design EvaluationConclusionNext, we describe how we evaluate the performance of SIMPLE and the evaluation results.
22 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?MethodologySmall-scale real test bed experiments (Emulab)Evaluation over Mininet (with up to 60 nodes)Large-scale trace driven simulations (for convergence times)There are a diverse set of measures that we use to evaluate SIMPLE’s performance.We evaluate the benefits that SIMPLE offers in terms of flexibility in middlebox placement by improving middlebox load balancing. We compare these with today’s ingress based middlebox deployments, where middleboxes closed to the ingress are selected as well as the optimal. How quickly it reacts to middlebox failure and traffic overload. We measure the time in configuring a network using SIMPLE and how close it is to the optimal. The accuracy in handling dynamic transformations.To evaluate these measures, we use a combination of evaluation in Emulab and Mininet (for large topologies) and trace driven simulations (for running optimizations on large network traces). Due to the lack of publicly available information on network topologies and middlebox-related policy, we use network topologies from past work.Given the time constraints, I am going to focus on SIMPLE’s Scalability and optimality
23 Benefits: Load balancing OptimalWe compare SIMPLE with today’s ingress-based middlebox deployments, where for each ingress-egress pair, the middleboxes closest to the ingress are selected. The y-axis shows the maximum middlebox load compared to the optimal. A load close to 1 is equal to the optimal. We see that besides 4-7X better load balancing as compared to the ingress based solution, we also see that SIMPLE is very close to the optimal.Public available educational backbonesRocket Fuel and enterprise, consolidate mBHow middleboxes are dsitrbuted? Randomly, arbitrarily?4-7X better load balancing and near optimal
24 Overhead: Reconfiguration Time 33 node topology including 11 switchesThe time that it takes to reconfigure rules using SIMPLE is given here for a topology consisting of 33 nodes including 11 switches. (Internet2).It takes around 125ms to reconfigure and most of that time is consumed in updating the rules at the switches.This is 4-5 orders of magnitude faster than naïve optimization solution, where we simply run an ILP to find an optimal load balancing solution.For some large topologies it takes a day.Around 125 ms to reconfigure, most time spent in pushing rules
25 Other Key Results LP solving takes 1s for a 252 node topology 4-5 orders of magnitude faster than strawman95 % accuracy in inferring flow correlationsScalability of pruning: 1800s 110s
26 Conclusions Middleboxes: Necessity and opportunity for SDN Goal: Simplify middlebox-specific policy enforcementChallenges: Composition, resource constraints, modificationsSIMPLE: policy enforcement layerDoes not modify middleboxesNo changes to SDN APIsNo visibility required into the internal of middleboxesScalable and offers 4-7X improvement in load balancingThe goal of this work was to determine whether we can use SDN to simplify the management of middleboxes.We observed that there are three main challenges in using SDN for middleboxes. These are policy composition, middlebox and TCM constraint in SDN switches, dynamic modifications induced by many middleboxes.Somewhat surprisingly we show that these challenges can be addressed using existing SDN APIs and without modifying middleboxes. We design SIMPLE, a policy enforcement layer for middlebox specific traffic steering. We show that it provides4-7X improvement over today’s middlebox deployments.This work is an initial attempt to integrate middleboxes in SDN. There are interesting future directions. For instance, in our ongoing work, we are investigating how the our dynamic handler we can deal with encrypted trafficPractical and offers benefits.We find that
28 Decompose Optimization: Slow Offline + Fast Online Steps TrafficMatrixLP with PrunedSetMboxCapacityOnline Load BalancingPrunedSetRuleModelPolicySpecEnumeratePhysicalSequencesPrune forFeasibleConfigsNetworkTopologyIn order to efficiently solve the optimization problem, we decompose the problem into a slow offline stage and fast online step.Offline stage that tackles the switch constraintsAn online step runs a linear program that only deals with load balancing.In the offline stage given a set of logical chains, we select a subset of the available physical sequences that will not violate the switch capacity constraints. The offline pruning stage only needs to run when the network topology, switches, middlebox placements, or the network policy changes. The online load balancing stage runs more frequently when traffic patterns change on shorter timescales.Offline Pruning
Your consent to our cookies if you continue to use this website.