Transcript slides - DEEPNESS Lab

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