opportunities in middlebox virtualization prof. anat bremler-barr idc herzliya supported by...
TRANSCRIPT
Opportunities in Middlebox Virtualization
Prof. Anat Bremler-BarrIDC Herzliya
www.deepness-lab.orgSupported 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)
Internet
• Need: Security, performance and compliance• Solution: add appliances middleboxes
Firewall
Proxy
4
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
5
Pain Points in traditional middleboxes
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 shorterSurvey across 57 network operators (J. Sherry et al. SIGCOMM 2012)
7
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
DDoS protection
FirewallIDS
Load balancer
Ad insertion
8
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)
9
Limited Innovation
• Closed API• Vendor lock-in• MB is complex: high barrier to market entry
DDoS protection
FirewallIDS
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
IDS FW
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
12
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
13
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.
14
Thinking outside the box about Middlebox
Approach 1: Consolidation
15
Proxy Firewall IDS/IPS AppFilter
Commodity hardware
Management system Management system Management system Management system
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 expandthe market. Disadvantage vendor lock-in
Contribution of reusable modules: 30 – 80 %
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).
21
Revolutions: SDN & NFV
22
Two revolutions : SDN & NVFIncrease flexibility and innovation
Software Defined Networking
Network Function Virtualization
Rethinking MiddleBox Architecture
Switches/Routers Middleboxes
2009- 2012-
23
Revolution I: Network Function Virtualization (NFV)
24
Network Function Virtualization(NFV)
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)
25
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.
26
Revolution II: Software Defined Networking (SDN)
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 controllerrunning 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
SpecializedOperatingSystem
SpecializedHardware
AppAppAppAppAppAppAppAppAppAppApp
SpecializedApplications
Open interfaces, Rapid innovation, Huge Industry
Microprocessor
Open Interface
Linux MacOS
Windows(OS) or 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
AppAppAppAppAppAppAppAppAppAppApp
Open interfaces,Rapid innovation
ControlPlane
ControlPlane
ControlPlane or or
Open Interface
SpecializedControlPlane
SpecializedHardware
SpecializedFeatures
MerchantSwitching Chips
Open Interfaceopenflow
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
34
No limitation on the PlacementFirewall IDS Proxy
*Policy Chain:
S1 S2
Firewall Proxy IDS
DstORIGINAL Post-Firewall
Post-IDSPost-Proxy
Fwd to Dst
Using tagging and SDN match rule to implement efficiently policy chain
SDN Controller
TrafficSteering
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
35
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.
36
NFV+SDN: Thinking outside the box about Middlebox
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
38
Deep Packet Inspection (DPI)
• Classify packets according to:– Packet payload (data)– Against known set of patterns: strings or regular expressions
• Common task in Middleboxes
InternetIP packet
“Evil”Firewall
“Evil” ->
39
DPI-Based Middleboxes
Intrusion Detection
System
Network Anti-Virus
L7 Firewall L7 Load BalancerLeakage
Prevention System
Network Analytic Traffic Shaper
Lawful Interception
Copyright Enforcement
DPI
40
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 throughput latency power
resiliency updates compression
41
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)
42
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
Service chain of MBs in NFV
L7 FW1
IDS1
IDS2AV2
AV1 TS
S1S2
S3
S4
VMVM
VM
VM
VMVM
TrafficSteering
SDN Controller
DPI as a Service
L7 FW1 IDS1
DPI
IDS2AV2
AV1 TS
S1S2
S3
S4
AV1 TS IDS1 L7 FW1
Modified Service Chain:
DPI
TrafficSteering
SDN Controller
45
DPI2
Architecture Overview (SDN)
L7 FW1 IDS1
DPI1
IDS2AV2
AV1 TS
S1S2
S3
S4
SDN Controller
TrafficSteering
DPIController
hello
hello
hello
Register PatternsAdd
PatternsUpdate 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: <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
47
MB: 1 ID: 139; Offset: 90MB: 2 ID: 14; Offset: 109MB: 3 ID: 723; Offset: 201MB: 4 ID: 221; Offset: 507… DPI
Instance
48
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
IDS1 AV1
DPI1
DPI2
IDS1IDS1
Two separate DPIs
DPI as a ServiceTwo
Latency traditional: 21.5us/pLatency DPI as a services: 13.8us/p
AV1
49
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.
s0
s7
s12
s1 s2
s3 s5s4
s14
s13 s6
s8
s9
s10
s11
C
C
E
D
B
E D
D B
C
A
B
A
A
B
Input: BCDBCAB
s0
s12
s2
s5
s6s9
s10
s11
50
Pattern Set Aggregation
MB 0: Pattern Set 0 MB 1: Pattern Set 1
Pattern set 1
Pattern set 2
Both sets
Pattern set 0Pattern set 1Both 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:
54
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
55
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
Check if there is “evil” in the
packet
IDS1
Filter flow: src x to dst y
56
Related Industry solution: Qosmos
• Application aware classification– Qosmos suggests a NFV service that classifies the
traffic • Skype/IM/VoIP/FTP/Video/Social Networks…
57
The future
58
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
59
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?
60
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
61
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 ?
62
Conclusion
• Middlebox area - evolving area, very dynamic • SDN & NFV change the field of MBs.
Thank You!!!