Deep Packet Inspection of Next Generation Network Devices

Deep Packet Inspection of Next Generation Network Devices Prof. Anat Bremler-Barr IDC Herzliya www. deepness-lab. org This work was supported by European Research Council (ERC) Starting Grant no. 259085 , Kabrnit and Neptune consortium

Deep Packet Inspection (DPI) • Classify packets according to: – Packet payload (data) – Against known set of patterns: strings or regular expressions Internet IP packet “Evil” Firewall • Common task in Middleboxes “Evil” -> 2

DPI-Based Middleboxes DPI Intrusion Detection System Network Analytic Traffic Shaper Network Anti-Virus Copyright Enforcement Lawful Interception L 7 Load Balancer Leakage Prevention System L 7 Firewall 3

Deep Pocket Inspection • 66% of network equipment vendors define DPI as “a must have” technology today [Heavy Reading Survey, 2013] • DPI market is estimated $590 million in 2012 and is expected to reach US$3. 8 billion by 2018 [Transparency Market Research, Dec. 2015] 4

DPI Engine – Complicated Challenge • DPI engine is considered a system bottleneck in many of todays MBs (30%-80%) [Laboratory simulations over real deployments of Snort and Clam. AV] • Hundreds of academic papers over recent years scalability resiliency throughput updates latency power compression 5

Agenda • Overview on the challenges and opportunities in designing an efficient Deep Packet Inspection ( summary of 5 years study). • Deepness Lab was founded in November 2010 by Prof. Anat Bremler-Barr and Prof. David Hay • Deepness - DPI Engineering for Enhanced Performance of Network Elements and Security Systems • Funding: ERC starting grant and two Magnet (Kabrnit, Neptune) 6

Major Challenges • A well-studied problem in Computer Science but with no sufficient solutions to current demands. • Scalability: – Rate - greater than 10 or even 100 Gbps – Memory - handling thousands of patterns • Handling non clear-text traffic – Compressed traffic • Security of the DPI itself: – resilient to Distributed Denial of Service (DDo. S) attack Opportunities: DPI in Software Defined Networks(SDN) and Network Function Virtualization(NFV) 7

Challenge #1: Scalability 8

Regular expression – classical solutions: Deterministic vs. Non-Deterministic Finite Automaton a NFA 1 * Reg. Ex: (1). *a+bc (2). *bcd+ (3). *cde b a c 3/1 Text: d a b c d d b 0 2 4 c 5 d 6/2 c 7 d 8 e 9/3 a: 1 -10 DFA time 1 a NFA b 2 c b: 2 -10 b 0 4 c d 5 6/2 d e 8 c: 1, 3, 5 -10 memory d d c DFA 3/1 d 9 e 10/3 Potentially 2^NNFA In practical cases single DFA infeasible! 7/2

Feasiable Solutions to Regular expressions • Current middlebox common approach (e. g. Snort) implement two-phase approach: 1. String matching over all strings that appeared in the combined set of regular expressions 2. Running a single regular expression DFA <x 21 DOCTYPEs+[^>]*SYSTEM[^>]*>. *x 2 Eparse. Error <x 21 DOCTYPE SYSTEM x 2 Eparse. Error Multi Regex Matching • Other academic solutions: – Hybrid-solutions between DFA/NFA Multi String Matching + Single Regex Matching 10

The challenge in string-matching • Common algorithm Aho-Corasick • Common implementation full table DFA : |Σ|×|S| array – where Σ: alphabet and S: set of states • SNORT – 6. 5 K patterns 75 K states, Memory requirement: 73 MB • Clam. AV – 27 K patterns 1. 6 M states, Memory requirement: 1. 48 GB • Cannot be implemented fully in fast SRAM memory • Many efforts to solve this memory bottleneck [Tan , Sherwood], [van Lunteren], [Lin, Liu], [Tuck, Sherwood, Calder, Varghese] [Yu, Katz, Lakshman], [Weinsberg, Tzur-David, Dolev, Anker] [Hua, Song, Lakshman]… Anat Bremler-Barr, Yaron Koral, David Hay, "Compact. DFA: Scalable Pattern Matching using Longest Prefix Match Solutions", In IEEE/ACM Transactions on Networking, 2013 , INFOCOM 2010 11

Challenge #2: Compressed Traffic 12

Motivation: Compressed HTTP • 84. 1% of the top 1, 000 sites & 60% of all the sites compress traffic. • Goal: reduce Bandwidth ! • Data compression is done by adding references (pointers) to repeated data: GZIP (+Huffman) • Current security tools do not deal with compressed traffic due to the high challenges in time and space 13

Compressed Traffic : Time Challenge • Need to decompress prior to pattern matching – HTTP compression is an adaptive compression • The same string will be encoded differently depending on its location in the text • General belief: Decompression + pattern matching >> pattern matching 14

Our solution: Accelerating DPI • Compression is done by compressing repeated sequences of bytes, so store information about the pattern matching results • No need to fully perform again pattern matching on repeated sequences which were already scanned • x 2 -3 time reduction • • Decompression + pattern matching << pattern matching A. Bremler-Barr, Y. Koral " Accelerating Multi-patterns Matching on Compressed HTTP Traffic ", in INFOCOM, 2009, To. N 2011 M. Becchi, A. Bremler-Barr, D. Hay, Omer Kochba, and Yaron Koral: “Accelerating Regular Expression Matching Over Compressed HTTP”. Accepted to IEEE Infoocm, 2015 15

The Other Side of the Coin: Acceleration by Identifying repetitions in uncompressed Traffic There are repetitions in uncompressed HTTP traffic – Entire files (e. g. , images) – Parts of the files (e. g. , HTML tags, javascripts) We keep scanning again and again the same thing (and get the same scanning results. . ) 1. Identify frequently repeated data 2. Perform DPI on the data once and remember the results 3. When encountering a repetition, recover the state without rescanning Anat Bremler-Barr, Shimrit Tzur David, Yotam Harchol, and David Hay: “Leveraging Traffic Repetitions for High-Speed Deep Packet Inspection”. Accepted to IEEE Infocom, 2015 16

Compressed Traffic : Space Challenge • Thousands of concurrent sessions Compressed traffic: 32 KB/session DPI unzip

Our solution: Space Reduction • Observation: The 32 KB needed for decompression are not used most of the time • Key idea: therefore the 32 KB can be kept in compressed form most of the time – Some light version on the compressed form of the traffic • x 5 space reduction • Overall: Improve • Space Time 80% 40% Yehuda Afek, Anat Bremler-Barr, Yaron Koral, "Efficient Processing of Multi-Connection Compressed Web Traffic", in NETWOKING, 2011, Computer Communication 2012 18

Challenge #3: Securing the DPI 19

Complexity DDo. S Attack Over IDS • Easy to craft – very hard to process packets • 2 Steps attack: 1. Kill IPS/FW Attacker Internet 2. Sneak into the network

Attack on Security Elements Combined Attack: DDo. S on Security Element exposed the network – theft of customers’ information

Deep Packet Inspection: the environment High Capacity Slow Memory (D)RAM Locality-based Low Capacity Fast Memory Cache Memory In reality, in security middleboxes , most memory accesses are done to the cache. BUT One can attack the implementation by reducing its locality, getting it out of cache - and making it much slower! 22

Attack on Snort Heavy packets rate In the paper we present a multi-core (multi- VMs) system architecture, which is robust against complexity DDo. S attacks Yehuda Afek, Anat Bremler-Barr, Yotam Harchol, David Hay, Yaron Koral, “MCA^2: Multi-Core Architecture for Mitigating Complexity Attacks”, in ACM/IEEE ANCS, 2012

DPI - current status • DPI is a complicated task – Gain from complex algorithms • Yet every company designs its own DPI engine 24

Opportunity: DPI in SDN & NFV 25

Two current revolutions: • Software Defined Networks (SDN): – The possibility to control the routing easily • Network Function Virtualization(NFV): – From HW SW 26

Software Defined Networks (SDN): Serivce Chain In a network: traffic go through several middleboxes (service chain) Dst Classical routing: Src Firewall IDS Proxy SDN: Src S 1 S 2 Dst 27

Network Function Virtualization(NFV) Load balancer Firewall DDo. S protection IDS 28

NFV: Hardware MB Software MB • Hardware Middlebox – – – • Software Middlebox Not Flexible Expensive Hard to manage (many vendors) Not multi-tenants Difficult to add new features Constraining innovation: higher entry barrier – Performance penalty • Commodity Servers • VMs • No hardware accelerators We suggest a new MB architecture that improves performance and innovation using NFV and SDN 29

Middleboxes Service Chains • Each packet is scanned multiple times causing waste of computation resources • Each MB implements its own DPI engine (higher MB costs, reduced features) 30

Our Solution: DPI as a Service Contribution: The idea of having a centralized DPI service instead of multiple instances of it at each Middlebox Benefits: • Innovation – Lower entry barriers • Reduced costs – Cheaper MB HW/SW • Improved performance - Scan each packet once • Rich DPI functionality – Invest once for all MB • Enhanced data-plane – Potential to enhance switches 31

Service chain of MBs in NFV Traffic Steering SDN Controller VM AV 1 VM TS S 2 S 1 S 4 S 3 AV 2 IDS 2 VM VM VM IDS 1 L 7 FW 1 VM

DPI as a Service Traffic Steering Modified Service Chain: DPI SDN Controller AV 1 TS IDS 1 L 7 FW 1 DPI S 2 S 1 S 4 S 3 AV 2 IDS 1 L 7 FW 1

Architecture Overview DPI Controller Traffic Steering New elements: • DPI controller - Divide the patterns to different sets of DPI instances • Multiple DPI instances SDN Controller AV 1 TS DPI 1 DPI 2 S 1 S 4 S 3 AV 2 IDS 1 L 7 FW 1 34

Solution outline • Architecture aspects of DPI as a service – DPI controller • Divide the patterns to different sets of DPI instances – Mechanism for passing results from the DPI to the MBs: • Network Service Header (NSH) • Scalable DPI algorithm – Beneficial if the time requirement is sub linear with the number of patterns Anat Bremler-Barr, Yotam Harchol, David Hay, Yaron Koral, "Deep Packet Inspection as a Service". in ACM Co. NEXT, December 2014

Related Industry solution: Qosmos • Application aware classification – Qosmos suggests a NFV service that classifies the traffic • Skype/IM/Vo. IP/FTP/Video/Social Networks… 36

DPI: Conclusion • Evolving area • SDN & NFV will change the field of middleboxes and among other the DPI area Thank You!!! 37