SIMPLE-fying Middlebox Policy
Enforcement Using SDN
Zafar Ayyub Qazi, Cheng-Chun Tu, Luis Chiang,
Rui Miao, Vyas Sekar, Minlan Yu
Presenter: Chen Qian
Middleboxes are important
Security Network Function
Firewall
IDS
Acceleration Network Function
WAN Optimizer
Proxy
Hardware and software middleboxes
IDS
WAN Optimizer
Proxy
Hardware
Software
How middleboxes process network
traffic
• 1. The specified network traffic should go
through a sequence of middlebox before
reaching the destination
– Firewall - IDS - Proxy
• 2. Middlebox policies (types and orders of
MBs) should be strictly reinforced
4
Middleboxes management is hard!
Survey across 57 network operators (J. Sherry et al. SIGCOMM 2012)
e.g., a network with
~2000 middleboxes
required 500+ operators
Critical for security, performance, compliance
But expensive, complex and difficult to manage
5
How SDN helps middleboxes
• SDN can effectively configure flow paths so
that a flow can go through a number of
middleboxes in a given order
• SDN can assign different flows to different
middleboxes so that the load on middleboxes
can be balanced
6
Can SDN simplify middlebox management?
Centralized Controller
Web
Firewall
IDS
Proxy
“Flow”
FwdAction
…
…
Proxy
OpenFlow
“Flow”
FwdAction
…
…
IDS
Scope: Enforce middlebox-specific steering policies
Necessity + Opportunity:
Incorporate functions markets views as important
7
What makes this problem challenging?
Centralized Controller
Web
Firewall
IDS
Proxy
“Flow”
FwdAction
…
…
Proxy
OpenFlow
“Flow”
FwdAction
…
…
IDS
Middleboxes introduce new dimensions beyond L2/L3 tasks.
Achieve this with unmodified middleboxes and existing SDN APIs
8
SIMPLE
Web
Firewall
IDS
Proxy
Policy enforcement layer for
middlebox-specific “traffic steering”
Legacy
Middleboxes
Flow
Action
…
…
Flow
Action
…
…
OpenFlow
capable
9
Outline
• Motivation
• Challenges
• SIMPLE Design
• Evaluation
• Conclusions
10
Challenge: Policy Composition
Policy Chain:
Firewall
S1
*
IDS
Proxy
Firewall
IDS
Proxy
Oops!
Forward Pkt
to IDS or Dst?
S2
Dst
“Loops”
Traditional flow rules may not suffice!
11
Challenge: Resource Constraints
Firewall
Proxy
Space for
traffic split?
S2
S1
S3
S4
IDS1 = 50%
IDS2 = 50%
Can we set up “feasible” forwarding rules?
12
Challenge: Dynamic Modifications
User1: Proxy  Firewall
User2: Proxy
User 1
Proxy
S1
User 2
Proxy may
modify
flows
S2
Firewall
Are forwarding rules at S2 correct?
13
New dimensions beyond Layer 2-3 tasks
1) Policy Composition  Potential loops
2) Resource Constraints  Switch + Middlebox
3) Dynamic Modifications  Correctness?
Can we address these with unmodified
middleboxes and existing SDN APIs?
14
Outline
• Motivation + Context for the Work
• Challenges
• SIMPLE Design
• Evaluation
• Conclusion
15
SIMPLE System Overview
Web
Firewall
IDS
Proxy
Modifications Handler
Resource Manager
Rule Generator
Legacy
Middleboxes
Flow
Action
…
…
Flow
Action
…
…
OpenFlow
capable
16
High-level input
• The network administrators specify the
processing policies to the resource manager,
without worrying about where the process occur.
• The network topology and traffic information are
input to the resource manager
• Resource constraints are input to the resource
manager
– 1. packet processing resources (CPU, memory,
accelerators) for different middleboxes
– 2. TCAM available for installing forwarding rules
17
Composition  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
18
Inter-switch tunnels
19
SIMPLE System Overview
Web
Firewall
IDS
Proxy
Modifications Handler
Resource Manager
Rule Generator
Legacy
Middleboxes
Flow
Action
…
…
Flow
Action
…
…
OpenFlow
capable
20
Resource Constraints 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!
21
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
22
Offline Stage: ILP based pruning
23
Offline Stage: ILP based pruning
• Feasible
• Sufficient freedom
Set of all possible middlebox
Set
loadPruned
distributions
Balance the middlebox load
(online, LP)
24
SIMPLE System Overview
Web
FW
IDS
Proxy
Modifications Handler
Resource Manager
Rule Generator
Legacy
Middleboxes
Flow
Action
…
…
Flow
Action
…
…
OpenFlow
capable
25
Modifications  Infer flow correlations
Correlate
flows
Install
rules
Payload
Similarity Proxy
User 1
S1
User 2
S2
Firewall
User1: Proxy  Firewall
User2: Proxy
26
27
When a middlebox changes everything
• Payloads still have a significant amount of
partial overlap.
– For the proxy case, the web content still matches.
•
• Use Rabin fingerprints to calculate the
similarity.
28
29
SIMPLE Implementation
Web
Resource Manager
(Resource Constraint)
FW
IDS
Proxy
Modifications Handler
(Dynamic modifications)
CPLEX
Rule Generator
(Policy Composition)
POX
extensions
OpenFlow 1.0
Flow
…
Tag/Tun
nel
Action
…
Flow
…
Tag/Tun
nel
Action
…
30
Outline
• Motivation + Context for the Work
• Challenges
• SIMPLE Design
• Evaluation
• Conclusion
31
Evaluation and Methodology
•
•
•
•
•
What benefits SIMPLE offers? load balancing?
How scalable is the SIMPLE optimizer?
How close is the SIMPLE optimizer to the optimal?
How accurate is the dynamic inference?
Methodology
– Small-scale real test bed experiments (Emulab)
– Evaluation over Mininet (with up to 60 nodes)
– Large-scale trace driven simulations (for convergence times)
32
Compare to Ingress-based method
• The middleboxes closest to the ingress are
selected.
33
Benefits: Load balancing
Optimal
4-7X better load balancing and near optimal
34
Overhead: Reconfiguration Time
33 node topology
including 11 switches
Around 125 ms to reconfigure, most time spent in pushing rules
35
Fraction of sequences with loops
36
Time of execution
37
Other Key Results
• LP solving takes 1s for a 252 node topology
– 4-5 orders of magnitude faster than strawman
• 95 % accuracy in inferring flow correlations
• Scalability of pruning: 1800s  110s
38
Conclusions
• Middleboxes: Necessity and opportunity for SDN
• Goal: Simplify middlebox-specific policy enforcement
• Challenges: Composition, resource constraints, modifications
• SIMPLE: policy enforcement layer
– Does not modify middleboxes
– No changes to SDN APIs
– No visibility required into the internal of middleboxes
• Scalable and offers 4-7X improvement in load balancing
39