Transcript 02_20_14 - Stanford University Networking Seminar

Toward Practical Convergence of
Middleboxes and
Software-Defined Networking
Vyas Sekar
Joint work with:
Seyed Kaveh Fayazbakhsh, Zafar Qazi,
Luis Chiang, Rui Miao, William Tu,
Jeff Mogul, Minlan Yu
Network “101” vs. Reality
Traditional view: “Dumb” network
Reality: Lots of in-network processing
Appliances or Middleboxes:
IDS, Firewall, Proxies, Application Gateways ….
2
Middleboxes Galore!
Data from a large enterprise
Type of appliance
Number
Firewalls
166
NIDS
127
Media gateways
110
Load balancers
67
Proxies
66
VPN gateways
45
WAN Optimizers
44
Voice gateways
11
Total Middleboxes
Total routers
Survey across 57 network operators
636
~900
Just network security  $10 billion (2016)
3
Middlebox management is hard!
Critical for security, performance, compliance
But expensive, complex and difficult to manage
4
Can SDN help middlebox management?
Centralized Controller
Web
Firewall
IDS
“Flow”
…
Proxy
Proxy
FwdAction
…
OpenFlow
“Flow”
FwdAction
…
…
IDS
Necessity and an Opportunity:
Incorporate functions markets views as important
[Metzler 2012]
5
What makes SDN + MB challenging?
Centralized Controller
Web
Firewall
IDS
Proxy
“Flow”
FwdAction
…
…
OpenFlow
“Flow”
FwdAction
…
…
Proxy
IDS
New dimensions beyond simple forwarding:
e.g., Policy-based “steering” composition
New resource management
Packet transformations/hidden actions
6
Our work on SDN-middlebox convergence
SIMPLE: SDN-based traffic steering
Unmodified middleboxes, current SDN APIs
FlowTags: Handling dynamic middlebox actions
New APIs + minimal extensions to middleboxes
7
Talk Outline
• Motivation
• Design of SIMPLE (SIGCOMM 2013)
• Design of FlowTags (NSDI 2014)
• Other middlebox research
8
SIMPLE: High-level view
Web
Firewall
IDS
Proxy
Policy enforcement layer for
middlebox-specific traffic steering
Legacy
Middleboxes
Flow
Action
…
…
Flow
Action
…
…
OpenFlow
capable
9
Challenge: Policy Composition
Policy Chain:
Firewall
S1
*
IDS
Proxy
Firewall
IDS
Proxy
Forward Pkt
to IDS or Dst?
S2
Dst
“Loops”  Simple flow rules don’t work
10
Rule Generator  Tag Processing State
Policy Chain:
Firewall
*
Firewall
IDS
Proxy
IDS
Proxy
Fwd to
Dst
S1
ORIGINAL
S2
Dst
Post-Firewall
Post-Proxy
Post-IDS
Insight: Distinguish different instances of the same packet
11
Challenge: Resource Constraints
Firewall
Proxy
Enough TCAM space for
traffic split?
S2
Flow
Action
…
…
S4
S1
Flow
Action
…
…
S3
IDS1 = 50%
IDS2 = 50%
Can we set up “feasible” forwarding rules
and load balance optimally?
12
Resource manager  Joint Optimization
Topology &
Traffic
Middlebox
Capacity +
Footprints
Switch
TCAM
Policy
Spec
Resource Manager
Optimal & Feasible
load balancing
Theoretically hard
Not obvious if some configuration is feasible
13
Offline + Online Decomposition
Policy
Spec
Network
Topology
Switch
TCAM
Mbox Capacity
+ Footprints
Traffic
Matrix
Resource Manager
Offline Stage
Deals with Switch constraints
Online Step
Deals with only load balancing
14
Challenge: Dynamic Modifications
User1: Proxy  Firewall
User2: Proxy
User 1
Proxy
S1
User 2
Proxy may
modify
flows
S2
Firewall
Actually a more fundamental problem
Will revisit in FlowTags
15
Modifications Handler  Flow correlation
Correlate
flows
Payload
Similarity
User 1
Install
rules
Proxy
S1
User 2
S2
Firewall
User1: Proxy  Firewall
User2: Proxy
16
SIMPLE System Overview
Web
Firewall
IDS
Proxy
Modifications Handler
Deal w/ flow modifications
Resource Manager
Handle resource constraints
Rule Generator
Avoid Loops
Legacy
Middleboxes
Flow
Action
…
…
Flow
Action
…
…
OpenFlow
capable
17
SIMPLE = Optimal Load balancing
Optimal
4-7X better that status quo
18
Talk Outline
• Motivation
• Design of SIMPLE (SIGCOMM 2013)
• Design of FlowTags (NSDI 2014)
• Other middlebox research
19
Middlebox actions violate SDN tenets
• Revisit SDN tenets from Ethane [SIGCOMM 07]
• Origin Binding:
There should be a strong binding between a
packet and its “origin”
• Paths follow policy:
Explicit policy should determine the paths that
packets follow
20
Attribution is hard
NIDS: Flag host if it creates too many connections
NAT
NIDS
H1
Internet
S1
S2
H2
NAT hides the true packet sources
21
Network Diagnosis is difficult
H1 sees very high web server delay – but what’s causing it?
Firewall
Load Balancer
Server 1
H1
S1
H2
S2
Server 2
Difficult to correlate network logs for diagnosis
22
Policy violations may occur
Proxy
H1
Web ACL:
Block H2  xyz
Cached
response
Internet
H2
S1
S2
Lack of visibility into the middlebox context
23
Seemingly natural (non)solutions
Ideas
Attribution
e.g., NAT
Diagnosis
e.g., Load
Balancer
Policy
violation
e.g., cache
Placement
Tunneling
Consolidation
Correlation
(SIMPLE)
Yes
No
Yes
No
Even harder! No
No
No
Not 100% accurate and high overhead
24
High-level idea
• Middleboxes “help” restore SDN tenets
– Possibly only option for correctness
• Add missing contextual information as FlowTags
– E.g., NAT or Load balancer give IP mappings;
Proxy gives cache hit/miss state
• SDN+ Controller controls tagging logic
– For both switches and middleboxes
25
Example of FlowTags in action
Tag
Generation
H1
192.168.1.1
H2
192.168.1.2
NAT Add Tags
SrcIP
192.168.1.1
192.168.1.2
192.168.1.3
Tag
1
2
3
Decode Tags
Tag
1
3
OrigSrcIP
192.168.1.1
192.168.1.3
Firewall Config w.r.t
original principals
Tag
Consumption
Firewall
NAT
Block 192.168.1.1
Block 192.168.1.3
Internet
S1
S2
S2 FlowTable
H3
192.168.1.3
Tag
1,3
2
Forward
FW
Internet
Tag
Consumption
26
FlowTags Architecture
Legacy
interface
New
interface
Control
Apps
Control
Apps
Control
Apps
e.g.,
steering,
verification
e.g.,
routing,
traffic
eng.
e.g., steering, verification
Admin
Network OS
Control
Data
SDN
Switches
Existing APIs
e.g., OpenFlow
FlowTable
Only “consume” FlowTags
FlowTags
APIs
FlowTags
Tables
Mbox
FlowTags
Config Enhanced
Middleboxes
“Produce” + “consume” FlowTags
27
Challenges in realizing FlowTags vision
• What semantics should FlowTags capture?
• Can we build a practical FlowTags controller?
• How easy is it to modify middleboxes?
• Can we encode FlowTags in packets?
28
Semantics: Dynamic Policy Graph
{H1}; <Allowed,Hit>
Drop
H1
Proxy
H2
{H1}; Hit
{H1}; Miss
ACL
{H2}; Miss
Internet
{H2}; Hit
Conceptually need a tag <per-flow, per-edge> in this DPG
In practice: temporal reuse, spatial reuse, policy classes etc
29
FlowTags-enhanced Controller
• Translate DPG to find a data-plane realization
• Middlebox event handlers:
– Handle tag Consume and Generate events
• Switch and flow expiry handlers:
– Similar to traditional OpenFlow handlers
– The tag is used to look up the forwarding entries
30
Extending middleboxes
to support FlowTags
Middlebox
Total LOC
Modified LOC
Squid
216,000
75
Snort
336,000
45
Balance
2000
60
PRADS
15000
25
Minimal code modification needed
31
Scalability of FlowTags controller
32
Talk Outline
• Motivation
• Design of SIMPLE
• Design of FlowTags
• Other middlebox research
33
Broader Research Agenda
High Capital costs
Device Sprawl
Inflexible, difficult to extend
 need for new boxes
Cloud
Outsourcing
Consolidated
Architecture
[CoMb
NSDI ‘12]
High management complexity
[APLOMB
SIGCOMM ’12]
SDN
Integration
[SIMPLE,
FlowTags,
this talk]
34
New challenges and opportunities
• Policy languages/graph generation?
• Automating middlebox extensions?
• New testing/verification tools?
• Better hardware/software platforms?
• …
35
Conclusions
• Middleboxes: Necessity and opportunity for SDN
• New challenges in SDN:
Composition, resource constraints, modifications
• First steps in practical SDN + middlebox integration
– SIMPLE for traffic steering
– FlowTags to handle dynamic/hidden middlebox actions
• Broader agenda -- “Middlebox Manifesto”
Rethink middlebox design and management
36