DPI as a Service: Controller Prototype and Traffic Steering Application

The DPIaaS Controller Prototype DPI AS A SERVICE DEEPNESS LAB This research was supported by the European Research Council under the European Union s Seventh Framework Programme (FP7/2007-2013)/ERC Grant agreement no259085.

Overview DPI as a Service Reminder The DPIaaS Controller prototype Traffic Steering Application (TSA) Evaluation Discussion

DPI as a Service CONEXT 2014

Middleboxes Policy Chains Each MB implements its own DPI engine (higher MB costs, reduced features) Each packet is scanned multiple times causing waste of computation resources DPI Engine is considered a system bottleneck in many of todays MBs (30%-80%) 4

Our Solution: DPI as a Service 5

The Advantages The idea of having a centralized DPI service instead of multiple instances of it at each Middlebox Rich Functionality Invest once for all MB Reduced Costs Cheaper MB HW/SW Improved performance Scan each packet once aggregate MatchRules Innovation Lower entry barriers

System Overview Register Rules Update Policy Chain Add Patterns DPI Traffic Steering Controller SDN Controller TS AV1 DPI1 hello DPI2 S2 S1 S4 hello S3 AV2 IDS2 hello IDS1 L7 FW1 7

The DPIaaS Controller Prototype

The Project goals Design and implement DPIaaS controller prototype Design and implement a simple TSA Deploy a functioning DPIaaS network Test the systems in complex networks Evaluate performance and compare to the article

Architecture Overview

The TSA (Traffic Steering Application) based on the SIMPLE-fying Middlebox Policy Enforcement Using SDN (SIGCOMM 2013): Network Composition Middlebox Load-balancing Support Packet Modifications Resource constraints Switch TCAM capacity

Simple TSA Network Composition Middlebox Load-balancing Support Packet Modifications Resource constraints Switch TCAM capacity

TSA - implementation Some technical issues Each policy has a unique OpenFlow Match and hosts (IP) chain Using vlan-id tags TSA make no changes the packets Should only affect policy chain traversal

TSA Configuration

TSA pseudo Code ->2 ID=1 | ->3 hello ID=2 ->3 ID=NONE ->2 10.0.0.1 Id:2 hello 1 Id:1 hello hello 10.0.0.5 2 2 1 3 3 ->2 ID=2 | ->1 10.0.02 Id = 1 RT | ->2 10.0.0.6 1 2 ID=NONE ->1 hello Id = 1 ->2 Id = 2 RT | ->4 3 4 ID=NONE ->1 10.0.0.3 10.0.0.4

TSA pseudo Code Loop problem ->2 ID=2 | ->3 ID=3 ->3 ->1,ID=1 ->2 | RT 10.0.0.1 1 10.0.0.5 2 2 1 3 3 ->2 ID=3 | ->1 10.0.02 Id = 2 RT | ->2 10.0.0.6 1 2 Id = 2 ->2 -> 3 ID = 1 |->1 Id = 3 RT | ->4 ->3 ID=4|->1 3 4 ID = 1 ->1 10.0.0.3 10.0.0.4

The DPI Controller Server for middleboxes and instances Global Match-Rules set of all the middleboxes Managing available instances Negotiating with TSA Reacting to changes

DPI Controller Strategies Rules dividing strategies Balanced Policy-chain across instances Instances placement strategy The assigned instance in the beginning of each chain

Evaluation

Two types of evaluation Functional evaluation using Mininet Performance evaluation using virtual machines and real OF switch

Additional Tools Necessary in order to evaluate Correctness and Performance Mocks Wrappers DPIaaS mininet creation script

Functional evaluation Testing the DPIaaS correctness in a large Fat-Tree network

Functional evaluation 2 6 8 4 1 5 7 3

Performance evaluation Deploy and Test the system in a real environment, using a real OF Switch Comparing Full system performance to the Paper s preliminary results

Evaluation setup

Testing scenario Host-1 IDS1 IDS2 Host-2 HTTP Host-1 DPI IDS1 IDS2 Host-2 Instance

Results Paper s results Full-system results

Results Paper s results Full-system results

Further Investigation Virtualization related Drops Divide and conquer experiments Using only physical servers Not using network The libpcap issue

Conclusion and Future work We have a functioning system, now what Verify the results ODL impressions DPI controller implement better strategies TSA improve TCAM utilization Load-balancing