Opportunities in Middlebox Virtualization Prof. Anat Bremler-Barr IDC Herzliya Supported by European Research Council (ERC) Starting Grant no , Kabrnit and Neptune consortium

Network: Router & Switches Internet Goal: Forwarding packets Standard protocols & closed API

Reality: Many Middleboxes (MBs) Internet Need: Security, performance and compliance Solution: add appliances  middleboxes Firewall Proxy

My Goal To present a clear picture about MBs. Pain points in traditional MBs Two revolutions: NFV and SDN and the influence on the design of MBs Going over new research works and trends 4

Pain Points in traditional middleboxes 5

High capital expenses & sprawl Many middleboxes are deployed:  Typically on par with # routers and switches at enterprise networks High Capital Expenses & sprawl  Power consumption The life cycle of HW appliances becomes shorter Survey across 57 network operators (J. Sherry et al. SIGCOMM 2012)

Management Adversity Many types of Middleboxes: Firewall, NIDS, NIPS, NAT, L2 Load Balancer, L2 Traffic Shaper, Web Application, Network Anti Virus, DDoS mitigation tools, Data Leakage Prevention, IPv6 Translator, VPN gateway, WAN optimizer, Voice gateways, Proxies, Media gateway … Many types, many companies, many appliances (boxes)  many management systems 7 DDoS protection Firewall IDS Load balancer Ad insertion

High operating expenses – Complex, error-prone – Mostly misconfiguration – There are also overloads and electrical and physical problems 8 Survey across 57 network operators (J. Sherry et al. SIGCOMM 2012)

Limited Innovation Closed API Vendor lock-in MB is complex: high barrier to market entry 9 DDoS protection Firewall IDS Load balancer Ad insertion

10 Placement limitations A B D Placement Limitations Service chain: traffic goes through several middleboxes Classical routing : MB placement in-path IDSFW Service chain: C

11 Placement limitations A B C Scalability problems Not scalable: Need more BW  more boxes (peak load) – Backup MBs: to deal with physical and overload failures D

Key Pain Points: 12 High Capital Expenses Management adversity High operating expenses Limited innovation Placement limitations Scalability problems We need to think outside the box about Middlebox

My angle Former chief scientist and founder of riverhead ( ) – Denial of Service mitigation middlebox Founding of in – Deep Packet Inspection(DPI) for next generation networks, a key component in many MBs. 13

Thinking outside the box about Middlebox 14

Approach 1: Consolidation 15 ProxyFirewallIDS/IPS AppFilter Commodity hardware Management system Vyas Sekar, Norbert Egi, Sylvia Ratnasamy, Michael K Reiter, and Guangyu Shi. Design and implementation of a consolidated middlebox architecture. In NSDI, pages 24–38, 2012.Pm

Consolidation reduces CapEx 16 Multiplexing benefit = Max_of_TotalUtilization / Sum_of_MaxUtilizations

Consolidation Enables Extensibility 17 Session Management Protocol Parsers VPN Web Mail IDS Proxy Firewall In the industry: widely used – motivation to expand the market. Disadvantage vendor lock-in Contribution of reusable modules: 30 – 80 %

Consolidation advantages (& Disadvantages) 18 High capital expenses Reduced capital expenses. Commodity servers. Management adversity Consolidated management. High operating expenses Limited innovation: - Vendor lock-in Placement limitations Scalability problems Reduced. Multiplexing.

Approach 2: Making Middleboxes Someone Else’s Problem Internet Justine Sherry, Shaddi Hasan, Colin Scott, Arvind Krishnamurthy, Sylvia Ratnasamy, and Vyas Sekar. Making middleboxes someone else’s problem: network processing as a cloud service. In SIGCOMM, 2012.

Network Processing as a Cloud Service Internet Cloud Provider Industry: Scrubbing Center for Denial of Service attacks: For example Prolxiec (Akamai).

Revolutions: SDN & NFV 21

Two revolutions : SDN & NVF Increase flexibility and innovation 22 Software Defined Networking Network Function Virtualization Rethinking MiddleBox Architecture Switches/RoutersMiddleboxes

Revolution I: Network Function Virtualization (NFV) 23

Network Function Virtualization(NFV) 24 DDoS protection Firewall IDS Load balancer Network Operators: “we want to enjoy the IT revolution and cloud world” Hardware appliances (MB)  Virtualized Network Function(VNF)

NFV advantages (& Disadvantage) 25 High capital expenses Reduced capital expenses. Commodity servers. Management adversity High operating expenses Reduced operating expenses. Software. Limited innovation Software. Easy to experiment Placement limitations Scalability problems Auto scaling. Performance problem: No hardware accelerators. VM.

Revolution II: Software Defined Networking (SDN) 26 Based on Jennifer Rexford’s slides “Software Defined Networking” 2010

Traditional Computer Networks Control plane: Distributed protocols, Track topology changes, Compute routes, Install forwarding rules Data plane: Packet streaming - Forward, Filter, Buffer, Mark, Rate- limit and Measure packets

Traditional Computer Networks Collect measurements and configure the equipment, Limited CLI, Closed API Management plane: Human time scale

Software Defined Networking (SDN) API to the data plane (e.g., OpenFlow) Logically-centralized controller running on commodity server Switches Smart, Slow Dumb, fast Decoupling control plane from data plane: Simpler cheaper switches, Simpler managment, Easier interoperability, Faster pace of innovation

Network researchers: “The switches and routers industry need to be like the microprocessor industry” Vertically integrated, Closed proprietary, Slow innovation, Small industry Specialized Operating System Specialized Operating System Specialized Hardware Specialized Hardware App Specialized Applications Specialized Applications Open interfaces, Rapid innovation, Huge Industry Microprocessor Open Interface Linux Mac OS Mac OS Windows (OS) Windows (OS) or Open Interface From Nick McKeown’s talk “Making SDN Work” at the Open Networking Summit, 2012

Vision: Routers/Switches -> SDN Vertically integrated, Closed proprietary, Slow innovation App Open interfaces, Rapid innovation Control Plane Control Plane Control Plane Control Plane Control Plane Control Plane or Open Interface Specialized Control Plane Specialized Control Plane Specialized Hardware Specialized Hardware Specialized Features Specialized Features Merchant Switching Chips Merchant Switching Chips Open Interface openflow From Nick McKeown’s talk “Making SDN Work” at the Open Networking Summit, 2012

Data-Plane: Simple Packet Handling Simple packet-handling rules – Pattern: match packet header bits – Actions: drop, forward, modify, send to controller – Priority: disambiguate overlapping patterns – Counters: #bytes and #packets 1.src=1.2.*.*, dest=3.4.5.*  drop 2.src = *.*.*.*, dest=3.4.*.*  forward(2) 3. src= , dest=*.*.*.*  send to controller 1.src=1.2.*.*, dest=3.4.5.*  drop 2.src = *.*.*.*, dest=3.4.*.*  forward(2) 3. src= , dest=*.*.*.*  send to controller

Vision: Unifies Different Kinds of Boxes also MBs Router – Match: longest destination IP prefix – Action: forward out a link Switch – Match: destination MAC address – Action: forward or flood Firewall – Match: IP addresses and TCP/UDP port numbers – Action: permit or deny NAT – Match: IP address and port – Action: rewrite address and port 33

No limitation on the Placement 34 FirewallIDSProxy * Policy Chain: S1 S2 Firewall Proxy IDS Dst ORIGINAL Post-Firewall Post-IDS Post-Proxy Fwd to Dst Using tagging and SDN match rule to implement efficiently policy chain SDN Controller Traffic Steering Zafar Ayyub Qazi, Cheng-Chun Tu, Luis Chiang, Rui Miao, Vyas Sekar, and Minlan Yu. SIMPLE-fying middlebox policy enforcement using SDN. In SIGCOMM, 2013

NFV + SDN advantages 35 High capital expenses Reduced capital expenses. Commodity servers. Management adversity High operating expense Reduced operating expenses. Software. Limited innovation Software. Easy to experiment Placement limitations No limitations with SDN. Scalability problems Auto scaling. Performance – No hardware accelerators. VM.

NFV+SDN: Thinking outside the box about Middlebox 36

Our approach: MB common modules as a service Break MB architecture to common data-plane modules – Many MBs use Deep Packet Inspection (DPI) – MB application performs more or less a set of the same MB modules Provide data-plane modules as a service – DPI as an example Anat Bremler-Barr, Yotam Harchol, David Hay and Yaron Koral, "Deep Packet Inspection as a Service". in ACM CoNEXT, December 2014 Anat Bremler-Barr, Yotam Harchol and David Hay, "OpenBox: Enabling Innovation in Middlebox Applications", in ACM SIGCOMM HotMiddleboxes, August 2015

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

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

DPI Engine – Complicated Challenge Pattern set size varies between patterns DPI engine is considered a system bottleneck in many of todays MBs (30%-80%) [Laboratory simulations over real deployments of Snort and ClamAV] Hundreds of academic papers over recent years 40 scalability throughput latency power resiliency updates compression

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

Our Solution: DPI as a Service 42 Contribution: a logically centralized DPI service instead of multiple instances at each Middlebox Benefits: Innovation – Lower entry barriers Reduced costs – Cheaper MB HW/SW Improved performance - Scan each packet once, improve latency, throughput Rich DPI functionality – Invest once for all MB

Service chain of MBs in NFV L7 FW1 IDS1 IDS2 AV2 AV1 TS S1 S2 S3 S4 VM Traffic Steering SDN Controller

DPI as a Service L7 FW1 IDS1 DPI IDS2 AV2 AV1 TS S1 S2 S3 S4 AV1 TS IDS1 L7 FW1 Modified Service Chain: DPI Traffic Steering SDN Controller

DPI2 Architecture Overview (SDN) 45 L7 FW1 IDS1 DPI1 IDS2 AV2 AV1 TS S1 S2 S3 S4 SDN Controller Traffic Steering DPI Controller hello Register Patterns Add Patterns Update Service Chain New elements: DPI controller Multiple DPI instances

Details Mechanism for passing results: – Network Service Header (NSH) Scalable DPI algorithm – Beneficial if the time complexity is sub linear(#patterns)

Details: Passing Results Use a dedicated new header in packet – A common need by many network services – Network Service Header (NSH) – IETF draft (cisco’s vPath) Each pattern & each MB has a unique ID Result: + + Each packet may contain several pattern matches – Results header size: For security apps - mostly 0B (95% normal traffic), upon match - 99% use less than 200B 47 MB: 1 ID: 139; Offset: 90 MB: 2 ID: 14; Offset: 109 MB: 3 ID: 723; Offset: 201 MB: 4 ID: 221; Offset: 507 … DPI Instance

Are DPI Algorithms Scalable? Sublinear? Yes Yes, each input byte requires a single lookup almost regardless the number of patterns!! – Lookup can be 1 memory access or 1 cache access 48 IDS1 AV1 DPI1 DPI2 IDS1 Two separate DPIs DPI as a Service Two Latency traditional: 21.5us/p Latency DPI as a services: 13.8us/p AV1

String Matching: Aho-Corasick Algorithm Build a Deterministic Finite Automaton (basic full-table variant) Example: {E, BE, BD, BCD, CDBCAB, BCAA} Each byte requires a single memory reference. 49 s0s0 s7s7 s 12 s1s1 s2s2 s3s3 s5s5 s4s4 s 14 s 13 s6s6 s8s8 s9s9 s 10 s 11 C C E D B E D D B C A B A A B Input: BCDBCAB s0s0 s 12 s2s2 s5s5 s6s6 s9s9 s 10 s 11

Pattern Set Aggregation 50 MB 0: Pattern Set 0MB 1: Pattern Set 1 Pattern set 1 Pattern set 2 Both sets Pattern set 0 Pattern set 1 Both sets

Generalization: MB Data plane Data plane tasks: each MB application performs more or less a set of the same MB modules (in pipeline). Wire speed Module: Software (VM) or Hardware (Accelerator) Packet Classification Application Classification Session Reconstruction Decrypt/Decompress Traffic Normalizer DPI Traffic Measurement

Our vision: Thin MB with MB Services The main difference between MBs: the control level. MB modules will be implemented as services in the network. Traffic travels between the services. Example: DDOS protection IP anti-spoofing Packet Classification DPI Traffic Measurement new module FIlter ICMP Filter X X is an attacker

Our vision: control tasks Configure the flow between MB modules Configure each of the MB modules Dynamic changes due to measurements Scale up and scale out of modules (orchestration) DDOS protection IP anti-spoofing Packet Classification DPI Traffic Measurement FIlter ICMP X is an attacker Filter X Service chain optimization – use the same service one time in a service chain  Improved performance MB as an application with control tasks:

Vision: Benefits Improve performance – Service chain scenario – Services from HW accelerators Innovation enablers: – Lower entry barriers If the modules are services one can tailor a MB by using off-the shelf modules  Cheaper MB HW/SW – Richer functionality Companies will specialize in specific MB modules 54

Vision: Enhancement with service modules Enhance Switch: example use DPI service to tag packets to drive policies in switches Enhance MB: SDN switches can perform the packet classification module 55 Check if there is “evil” in the packet IDS1 Filter flow: src x to dst y

Related Industry solution: Qosmos Application aware classification – Qosmos suggests a NFV service that classifies the traffic Skype/IM/VoIP/FTP/Video/Social Networks… 56

The future 57

P4: Future SDN Switches The SDN wish list: – Configurable packet parser Not tied to a specific header format, – General actions primitives (copy, remove, modify) New generation of switch ASICs: programmable switches – Intel FlexPipe, RMT [SIGCOMM’13], Cisco Doppler, ? ? P4 high-level language for programming switches 58

SDN+MB: Open questions Q1: Can we implement a whole MB/ or a part of MB using programmable switch ? – Generic platform with fast data-plane Q2: What will be the standard management language for MB? – Abstraction of MB API  increase flexibility Q3: Will variation on P4 be a standard also for MB? 59

NFV current status Currently MB companies move to NFV naively – They take the software that ran on HW appliances with some small modifications and just move it to VM. – This is not optimal MB architecture Auto-scaling feature: need to move flow with its state. 60  Shriram Rajagopalan, Dan Williams, Hani Jamjoom, and Andrew Warfield. Split/merge: System support for elastic execution in virtual middleboxes. In NSDI,2013

NFV+MB: Open Questions Q1: What will be the common architecture of VNFs? – VNF - virtualized network function former implemented by MBs – Fresh rethinking Q2: What will be the “OS” of NFV. – Features ? Openstack ? Q3: Is NFV cost-effective to all types of MBs? – Are there MBs that must have HW accelerators ? Q4: How do you combine most effectively HW and NFV? – The service module ? 61

Conclusion Middlebox area - evolving area, very dynamic SDN & NFV change the field of MBs. 62 Thank You!!!