* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download slides - DEEPNESS Lab
Survey
Document related concepts
Zero-configuration networking wikipedia , lookup
Computer network wikipedia , lookup
Piggybacking (Internet access) wikipedia , lookup
Multiprotocol Label Switching wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Asynchronous Transfer Mode wikipedia , lookup
Airborne Networking wikipedia , lookup
Network tap wikipedia , lookup
List of wireless community networks by region wikipedia , lookup
Packet switching wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Wake-on-LAN wikipedia , lookup
Transcript
Opportunities in Middlebox Virtualization Prof. Anat Bremler-Barr IDC Herzliya www.deepness-lab.org Supported by European Research Council (ERC) Starting Grant no. 259085 , Kabrnit and Neptune consortium Network: Router & Switches Internet • Goal: Forwarding packets • Standard protocols & closed API Reality: Many Middleboxes (MBs) Firewall Internet Proxy • Need: Security, performance and compliance • Solution: add appliances middleboxes 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 Load balancer Firewall IDS DDoS protection Ad insertion 7 High operating expenses • High operating expenses – Complex, error-prone – Mostly misconfiguration – There are also overloads and electrical and physical problems Survey across 57 network operators (J. Sherry et al. SIGCOMM 2012) 8 Limited Innovation • Closed API • Vendor lock-in • MB is complex: high barrier to market entry Load balancer Firewall IDS DDoS protection Ad insertion 9 Placement limitations Placement Limitations Service chain: IDS A C FW B D • Service chain: traffic goes through several middleboxes • Classical routing : MB placement in-path 10 Placement limitations Scalability problems A B C D • Not scalable: Need more BW more boxes (peak load) – Backup MBs: to deal with physical and overload failures 11 Key Pain Points: • • • • • • High Capital Expenses Management adversity High operating expenses Limited innovation Placement limitations Scalability problems We need to think outside the box about Middlebox 12 My angle • Former chief scientist and founder of riverhead (2000-2004) – Denial of Service mitigation middlebox • Founding of in 2010. – 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 Management system Proxy Management system Firewall Management system IDS/IPS Management system AppFilter Management system Commodity hardware • 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 15 Consolidation reduces CapEx Multiplexing benefit = Max_of_TotalUtilization / Sum_of_MaxUtilizations 16 Consolidation Enables Extensibility VPN Web Mail IDS Proxy Firewall Protocol Parsers Contribution of reusable modules: 30 – 80 % Session Management In the industry: widely used – motivation to expand the market. Disadvantage vendor lock-in 17 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 Cloud Provider Internet Industry: • Scrubbing Center for Denial of Service attacks: For example Prolxiec (Akamai). Revolutions: SDN & NFV 21 Two revolutions : SDN & NVF Increase flexibility and innovation Switches/Routers Software Defined Networking 2009- Middleboxes Network Function Virtualization 2012- Rethinking MiddleBox Architecture 22 Revolution I: Network Function Virtualization (NFV) 23 Network Function Virtualization(NFV) Network Operators: “we want to enjoy the IT revolution and cloud world” Hardware appliances (MB) Virtualized Network Function(VNF) Load balancer Firewall DDoS protection IDS 24 NFV advantages (& Disadvantage) • 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. 25 Revolution II: Software Defined Networking (SDN) Based on Jennifer Rexford’s slides “Software Defined Networking” 2010 26 Traditional Computer Networks Control plane: Distributed protocols, Track topology changes, Compute routes, Install forwarding rules Data plane: Packet streaming - Forward, Filter, Buffer, Mark, Ratelimit and Measure packets Traditional Computer Networks Management plane: Human time scale Collect measurements and configure the equipment, Limited CLI, Closed API Software Defined Networking (SDN) Smart, Slow Logically-centralized controller running on commodity server API to the data plane (e.g., OpenFlow) Dumb, fast Switches 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” AppAppAppAppAppAppAppAppAppAppApp Specialized Applications Specialized Operating System Specialized Hardware Vertically integrated, Closed proprietary, Slow innovation, Small industry Open Interface Windows (OS) or Linux or Mac OS Open Interface Microprocessor Open interfaces, Rapid innovation, Huge Industry From Nick McKeown’s talk “Making SDN Work” at the Open Networking Summit, 2012 Vision: Routers/Switches -> SDN AppAppAppAppAppAppAppAppAppAppApp Specialized Features Specialized Control Plane Specialized Hardware Vertically integrated, Closed proprietary, Slow innovation Open Interface Control Plane openflow Control or Plane Control or Plane Open Interface Merchant Switching Chips Open interfaces, Rapid innovation 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=10.1.2.3, 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 Traffic Steering Policy Chain: SDN Controller Firewall * Firewall IDS Proxy IDS Proxy Fwd to Dst S1 ORIGINAL S2 Dst Post-Firewall Post-Proxy Post-IDS Using tagging and SDN match rule to implement efficiently policy chain 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 34 NFV + SDN advantages • 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. 35 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 Internet IP packet “Evil” Firewall • Common task in Middleboxes “Evil” -> 38 DPI-Based Middleboxes Intrusion Detection System Network Analytic Traffic Shaper Network Anti-Virus Copyright Enforcement Lawful Interception L7 Load Balancer Leakage Prevention System L7 Firewall 39 DPI Engine – Complicated Challenge • Pattern set size varies between 102-105 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 scalability resiliency throughput updates latency power compression 40 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) 41 Our Solution: DPI as a Service 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 42 Service chain of MBs in NFV Traffic Steering SDN Controller VM AV1 VM TS S2 S1 S4 S3 AV2 IDS2 VM VM VM IDS1 L7 FW1 VM DPI as a Service Traffic Steering Modified Service Chain: DPI SDN Controller AV1 TS AV1 TS IDS1 L7 FW1 DPI S2 S1 S4 S3 AV2 IDS2 IDS1 L7 FW1 Architecture Overview (SDN) DPI Update Service Controller Traffic Steering Chain SDN Controller AV1 TS Register Add Patterns Patterns New elements: • DPI controller • Multiple DPI instances DPI1 hello DPI2 S2 S1 S4 hello S3 hello IDS1 L7 FW1 AV2 IDS2 45 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: <MB ID> + <Pattern ID> + <Match Offset> • 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 MB: MB: MB: MB: … 1 2 3 4 ID: ID: ID: ID: 139; Offset: 90 14; Offset: 109 723; Offset: 201 221; Offset: 507 DPI Instance 47 Are DPI Algorithms Scalable? Sublinear? • Yes, each input byte requires a single lookup almost regardless the number of patterns!! – Lookup can be 1 memory access or 1 cache access AV1 IDS1 DPI1 IDS1 DPI2 AV1 Latency traditional: Latency DPI as a services: 21.5us/p 13.8us/p 48 String Matching: Aho-Corasick Algorithm • Build a Deterministic Finite Automaton (basic full-table variant) s0 E B s2 s1 s3 s4 A s13 Input: BCDBCAB s7 D DC E • Example: {E, BE, BD, BCD, CDBCAB, BCAA} C s5 s8 D s6 B B s9 C A s14 s10 A s11 • Each byte requires a single memory reference. B s12 49 Pattern Set Aggregation Pattern set 0 Pattern set 1 Both sets Pattern set 1 Pattern set 2 Both sets MB 0: Pattern Set 0 MB 1: Pattern Set 1 50 Generalization: MB Data plane Data plane tasks: each MB application performs more or less a set of the same MB modules (in pipeline). Packet Classification Application Classification Session Reconstruction Decrypt/Decompress Traffic Normalizer DPI Traffic Measurement • Wire speed • Module: Software (VM) or Hardware (Accelerator) 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. Filter FIlterX Example: DDOS protection ICMP Packet Classification new module IP anti-spoofing DPI X is an attacker Traffic Measurement Our vision: control tasks MB as an application with 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 FIlterX Filter ICMP Packet Classification IP anti-spoofing DPI X is an attacker Traffic Measurement • Service chain optimization – use the same service one time in a service chain Improved performance 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 Check if there is “evil” in the packet • Enhance MB: SDN switches can perform the packet classification module Filter flow: src x to dst y IDS1 55 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. Shriram Rajagopalan, Dan Williams, Hani Jamjoom, and Andrew Warfield. Split/merge: System support for elastic execution in virtual middleboxes. In NSDI,2013 60 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. Thank You!!! 62