Presentation on theme: "Toward Practical Integration of SDN and Middleboxes"— Presentation transcript:
1 Toward Practical Integration of SDN and Middleboxes Vyas SekarStony Brook UniversityJoint work withZafar Qazi, William Tu, Luis Chiang, Stony Brook UniversityRui Miao, Minlan YuUSC
2 High capital and management costs Little flexibility Middleboxes Galore!Data from a large enterpriseSurvey across 57 network operatorsType of applianceNumberFirewalls166NIDS127Media gateways110Load balancers67Proxies66VPN gateways45WAN Optimizers44Voice gateways11Total Middleboxes636Total routers~900Refer to guru’s slideHigh capital and management costs Little flexibility
3 Our past work in MB space CoMb [NSD1 ‘12]Consolidate hardware-softwareConsolidate managementAplomb [SIGCOMM ‘12]Outsource middleboxes to the cloudNIDS/NIPS Load Balancing [CoNext ‘10 ‘12]Network-wide load balancing
4 Two crucial missing links Can we deal with existing middleboxes?Legitimate technical and business reasons(Over)simplified or assumed away the problem?Use custom API, not SDN interfacesIn spite of the obvious parallelsWhy haven’t we seen a practical integrationbetween SDN and existing middleboxes?“…policy might require packets to pass through an intermediate middlebox….” Casado et al, SIGCOMM ‘07
5 Goal of this work Centralized management with open interfaces MiddleboxesIDS, Firewall, Load balancer, VPNWAN optimizer, Proxy, etcCentralized managementwith open interfacese.g., NOX/OpenFlowCentralized management with open interfacese.g., NOX/OpenFlowIDS, Firewall, Load balancer, VPNWAN optimizer, Proxy, etc
6 What this work is NOT New vision for SDN New vision for middlebox A new L4-L7 programmable data planeNew northbound APIs for middleboxesLook for practical, incremental convergence
8 Middlebox “policy chain” F1I1FirewallIDS*S2S4S5S1S3I2Here .. Sequence not just composition and spatial, not just single box/signle controllerF2Implication: Proactive set up of routing rulesImplication: New verification requirements
9 Flow rules may not suffice? HTTP: Firewall IDS ProxyOpenFlow forward: Pkt header, Interface Forwarding interfaceHTTP, S1—S2 ??FirewallProxyIDS1234S2S15HTTPReturn path?Stateful!Implication: More flexible forwarding abstractionsImplication: loop-free at logical level, not physical
10 Middlebox load balancing F1 = 0.5I1 = 0.25F2 =0.5I2 = 0.75PolicySrc, Dst, Input,NextHop10.1.0/17,*,*,S2/17,*,*,S3/17,*,S1,M3/17,*,M3,S410.1.0/17,*,S1,M110.1.0/18,*,M1,M2/18,*,M1,S410.1.0/18,*,M2,S410.1.0/18,*,S2,S5/18,*,S2,M4/17,*,S3,M4/18,*,M4,S5/17,*,M4,S5FirewallIDS10.1/16*Src = /16S2S4S5S1S3Implication: Unified view of MB and switch resources
11 Middlebox introduce packet mods NAT rewrites headersProxy, WanOPT coalesces sessionsDynamic invocation?Something like the conditional composition ..Implication: Visibility and scalability challenges
17 Data plane: Virtual Packet State HTTP: Firewall IDS ProxyFirewallProxyIDS1234S1S25HTTPAnalogous to the virtual packet idea from jen controller, realization is via “VLAN” – packet carries its logical state somehowEach segment gets a logical tagCan implement this with VLAN tags/tunnels
19 Joint configuration of MB + Switch Topology,TrafficPolicySpecResourceConstraintsMiddleboxbehaviorSDN-MBControllerJointoptimizationForwardingRulesProcessingDistributionChallenge: Impact of MB load balancing on switches?i.e., is a given load balancing strategy feasible?
21 Verification properties Policy compliance: Every packet goes through correct policyNo extra processing: A packet should not traverse a middlebox, if the policy does not dictate it.No spurious traffic:Packets that would be dropped otherwise, should not be allowedHave needs, don’t yet have solutions ..
22 Dynamic middlebox transformations? What we do know how to doTaxonomy of existing middleboxesCapture typical packet transformationsNo comprehensive solution yet …
23 Roadmap Motivation for this talk Challenges with SDN-MB integration Promising startsReflections..
24 Some reflections on SDN-MB synergy Aug ONF report on new initiativesintegrate an SDN into production networksAPIs for functions the market views as importantDevelopment of next generation forwarding planeMiddlebox as a concrete use-case can inform these initiatives!
25 More reflections on SDN-MB synergy Survey reports on key factors on SDN adoption [Metzler 2012]use cases that justify deployment ..fits in with both the existing infrastructure..“ SDN tended to focus on the physical network elements that comprised the network layers (e.g., Layer 2 and Layer 3) …add a focus on Layer 4 through Layer 7 functionality … it shows a change in the perceived value of SDN.”Middleboxes are a necessity and an opportunity!
26 Talk summary Can we achieve “incremental” SDN-MB integration? Several challenges, but promising startsComposition, resource management, dynamicsImplications for data, control plane, and control appsMB can be an informative and concrete use-caseLonger-term evolution?SDN gets rid of MBs?MB becomes integrated into dataplane?