Practical Convergence of Middleboxes and Software Defined Networking Vyas Sekar Joint work with Seyed Kaveh Fayazbakhsh Zafar Qazi Luis Chiang Rui Miao William Tu ID: 165437
Download Presentation The PPT/PDF document "Toward" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
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 YuSlide2
Network “101” vs. Reality2
Traditional view: “Dumb” network
Reality: Lots of in-network processing
Appliances or
Middleboxes:
IDS, Firewall, Proxies, Application Gateways ….Slide3
Type
of appliance NumberFirewalls166NIDS
127
Media gateways
110
Load balancers
67
Proxies
66
VPN
gateways
45
WAN Optimizers
44
Voice gateways
11
Total Middleboxes
636
Total routers
~900
Middleboxes Galore!
Data from a large enterprise
Survey across 57 network operators
3
Just network security
$10 billion (2016)Slide4
Middlebox management is hard!4
Critical for security, performance, complianceBut expensive, complex and difficult to manageSlide5
Can SDN help
middlebox management?Centralized Controller
“
Flow”
FwdAction
…
…
“
Flow
”
FwdAction
…
…
OpenFlow
5
Proxy
IDS
Necessity and an Opportunity:
Incorporate functions markets views as important
[Metzler 2012]
Firewall
IDS
Proxy
WebSlide6
What makes SDN + MB challenging?
Centralized Controller
“
Flow”
FwdAction
…
…
“
Flow
”
FwdAction
…
…
OpenFlow
6
Proxy
IDS
N
ew dimensions beyond simple forwarding:
e.g.,
P
olicy-based “steering” composition
New resource management
Packet transformations/hidden actions
Firewall
IDS
Proxy
WebSlide7
Our work on SDN-middlebox convergence
7FlowTags: Handling dynamic middlebox actions New APIs + minimal extensions to middleboxesSIMPLE: SDN-based traffic steering Unmodified middleboxes, current SDN APIs Slide8
Talk OutlineMotivation Design of SIMPLE (SIGCOMM 2013)
Design of FlowTags (NSDI 2014)Other middlebox research8Slide9
Firewall
IDS
Proxy
Web
SIMPLE: High-level view
Legacy
Middleboxes
OpenFlow
capable
Flow
Action
…
…
Flow
Action
…
…
9
P
olicy
enforcement layer
for
middlebox
-specific
traffic steering Slide10
Challenge: Policy Composition
S1S210
Firewall
Proxy
IDS
Firewall
IDS
Proxy
*
Policy Chain:
Forward Pkt to IDS or Dst?
Dst
“Loops”
Simple
flow rules don
’
t workSlide11
Rule Generator Tag Processing State
11
Firewall
IDS
Proxy
*
Policy Chain:
S1
S
2
Firewall
Proxy
IDS
Dst
ORIGINAL
Post-Firewall
Post-IDS
Post-Proxy
Fwd to Dst
Insight: Distinguish different instances of the same packetSlide12
Challenge: Resource Constraints
S1
S2
S4
S3
Proxy
Firewall
IDS1 = 50%
IDS2 = 50%
Enough TCAM space for
t
raffic split?
Can we set up “feasible” forwarding rules
and load balance optimally?
12
Flow
Action
…
…
Flow
Action
…
…Slide13
Resource manager Joint Optimization
Resource ManagerTopology & TrafficSwitch TCAMMiddleboxCapacity + Footprints
Policy
Spec
Optimal & Feasible
load balancing
Theoretically hard
Not obvious if some configuration is feasible
13Slide14
Offline + Online Decomposition14
Offline StageOnline Step
Deals with Switch constraints
Deals with only load balancing
Resource Manager
Network
Topology
Switch
TCAM
Policy
Spec
Traffic
Matrix
Mbox
Capacity
+ FootprintsSlide15
15
S1
Proxy
S2
User 1
User 2
Proxy may modify flows
Actually a more fundamental problem
Will revisit in
FlowTags
Challenge: Dynamic Modifications
Firewall
User1: Proxy
Firewall
User2: ProxySlide16
Modifications Handler Flow correlation
16
Correlate
flows
Install rules
S1
Proxy
S2
User 1
User 2
Firewall
User1: Proxy
Firewall
User2: Proxy
Payload SimilaritySlide17
Rule Generator
Avoid LoopsResource ManagerHandle resource constraintsModifications HandlerDeal w/ flow modifications
SIMPLE System Overview
Legacy
Middleboxes
OpenFlow
capable
Flow
Action
…
…
Flow
Action
…
…
17
Firewall
IDS
Proxy
WebSlide18
SIMPLE = Optimal Load balancing
4-7X better that status quo18
OptimalSlide19
Talk OutlineMotivation
Design of SIMPLE (SIGCOMM 2013)Design of FlowTags (NSDI 2014)Other middlebox research19Slide20
Middlebox actions violate SDN tenetsRevisit 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 follow20Slide21
Attribution is hard
NAT hides the true packet sources21
S1
S2
NIDS
NAT
Internet
H2
H1
NIDS: Flag host if it creates too many connectionsSlide22
Network Diagnosis is difficult
Difficult to correlate network logs for diagnosis22
S1
S2
Load Balancer
Firewall
H2
H1
Server 2
Server 1
H1 sees very high web server delay – but what’s causing it?Slide23
Policy violations may occur
S1
S2
Proxy
Internet
H2
H1
Web ACL:
Block H2 xyz
Get xyz.com
Get xyz.com
Cached response
R
esponse
Lack of visibility into the middlebox
context
23
Cached
responseSlide24
Seemingly natural (non)solutions
IdeasAttributione.g., NATDiagnosise.g., Load BalancerPolicy violatione.g., cachePlacementYesNoYesTunnelingNoEven harder!NoConsolidation
NoNo
Correlation(SIMPLE)Not 100% accurate and high overhead
24Slide25
High-level ideaMiddleboxes “help” restore SDN tenetsPossibly only option for correctness
Add missing contextual information as FlowTagsE.g., NAT or Load balancer give IP mappings; Proxy gives cache hit/miss stateSDN+ Controller controls tagging logicFor both switches and middleboxes25Slide26
S
1S2Firewall
NAT
Internet
H1 192.168.1.1
H2
192.168.1.2
H3
192.168.1.3
SrcIP
Tag
192.168.1.1
1
192.168.1.2
2
192.168.1.3
3
Tag
OrigSrcIP
1
192.168.1.1
3
192.168.1.3
Block 192.168.1.1
Block 192.168.1.3
NAT Add Tags
Decode Tags
Firewall Config
w.r.t
original principals
Tag
Forward
1,3
FW
2
Internet
S2 FlowTable
Example of FlowTags in action
Tag Generation
Tag Consumption
Tag
Consumption
26Slide27
Control Apps
e.g., steering, verificationControl Appse.g., routing, traffic eng.Network OS
Control
Data
SDN
Switches
FlowTable
FlowTags
Enhanced
Middleboxes
FlowTags
Tables
Control Apps
e.g., steering, verification
Admin
Mbox
Config
FlowTags
APIs
Existing AP
I
s
e.g., OpenFlow
Legacy interface
New
interface
FlowTags Architecture
27
“
Produce
” + “consume
”
FlowTags
O
nly
“consume”
FlowTagsSlide28
Challenges in realizing FlowTags visionWhat semantics should FlowTags capture?Can we build a practical FlowTags controller?
How easy is it to modify middleboxes?Can we encode FlowTags in packets?28Slide29
Semantics: Dynamic Policy Graph29
ProxyACL
Drop
{H1}; Blocked
H1
H2
{H1}; -
{H2}; -
{H1}; Hit
{H1}; Miss
{H1}; <Allowed,Miss>
{H2}; Miss
{H1}; <Allowed,Hit>
Internet
{H2}; Hit
Conceptually need a tag <per-flow, per-edge> in this DPG
In practice: temporal reuse, spatial reuse, policy classes etc Slide30
Translate DPG to find a data-plane realizationMiddlebox event handlers:Handle tag Consume and Generate events
Switch and flow expiry handlers:Similar to traditional OpenFlow handlersThe tag is used to look up the forwarding entries30FlowTags-enhanced ControllerSlide31
Extending middleboxes to support FlowTags
Minimal code modification needed31MiddleboxTotal LOCModified LOCSquid216,00075Snort336,000
45Balance2000
60PRADS
1500025Slide32
Scalability of FlowTags controller
32Slide33
Talk OutlineMotivation
Design of SIMPLEDesign of FlowTagsOther middlebox research33Slide34
Broader Research Agenda34
High Capital costsDevice SprawlHigh management complexityInflexible, difficult to extend need for new boxes
Consolidated
Architecture
[CoMbNSDI ‘12]
Cloud
Outsourcing
[APLOMB
SIGCOMM
’
12]
SDN
Integration
[SIMPLE,
FlowTags
,
this talk]Slide35
New challenges and opportunitiesPolicy languages/graph generation?Automating middlebox extensions?
New testing/verification tools?Better hardware/software platforms?…35Slide36
ConclusionsMiddleboxes: Necessity and opportunity for SDN
New challenges in SDN: Composition, resource constraints, modificationsFirst steps in practical SDN + middlebox integrationSIMPLE for traffic steeringFlowTags to handle dynamic/hidden middlebox actionsBroader agenda -- “Middlebox Manifesto”Rethink middlebox design and management36Slide37
Consolidating Middleboxes [NSDI 2012]37
Proxy
Firewall
IDS/IPS
AppFilter
Today: Independent, specialized boxes
Decouple
Hardware and
Software
Commodity hardware:
e.g., PacketShader, RouteBricks,
ServerSwitch, SwitchBlade
Consolidation reduces capital expenses and sprawlSlide38
Internet
Cloud Provider
+ Economies of scale, pay-per use
+ Simplifies configuration & deployment
38
Outsourcing Middleboxes
[SIGCOMM 2012]Slide39
Overhead: Reconfiguration Time
Around 125 ms to reconfigure, most time spent in pushing rules3933 node topology including 11 switchesSlide40
40
S1
Proxy
S2
User 1
User 2
Proxy may modify flows
Actually a more fundamental problem
Revisit Dynamic Modifications
Firewall
User1: Proxy
Firewall
User2: ProxySlide41
Modifications Handler Flow correlation
41
Correlate
flows
Install rules
S1
Proxy
S2
User 1
User 2
Firewall
User1: Proxy
Firewall
User2: Proxy
Payload SimilaritySlide42
Entire backbone
runs on SDNSDN: New Trend in Network ManagementBought for $1.2 x 109
42Slide43
Quick Intro to SDN
Centralized Controller “Flow”
Action
…
…
“
Flow
”
Action
…
…
Open API
e.g., OpenFlow
43
Traditional network:
Closed hardware
+ Management embedded in routing state
SDN:
Switch/router actions can be “programmed”
Management logic is consolidated
1.2.3.4
* : Block
4.5.6.7 5.6.7.8 : Use low congestion pathSlide44
Need for Network Innovation44
New devicesNew application drivers
Evolving
threats
Policy constraints
Security
Performance
ComplianceSlide45
Consolidation is practicalLow overhead for existing applications (0.7%)
Controller takes < 1.6s for 52-node topologyStrawman-LP takes 9000s5x better than VM-based consolidationDo not need very “beefy” nodes45Slide46
Challenges in Cloud OutsourcingMinimal Complexity
Functional equivalencee.g., Stateful connectionLow Overheadi.e., Latency, bandwidth46
VPN tunnel
Off-the-shelf
DNS based fwding
Intelligent PoP selection
Generic compressionSlide47
New challenges and opportunitiesPolicy languages/graph generation?Automating middlebox extensions?
New testing/verification tools?Better hardware/software platforms?…47Slide48
48
S1
Proxy
S2
User 1
User 2
Proxy may modify flows/packets
Are forwarding rules at S2 still correct?
Challenge: Dynamic Modifications
Firewall
User1: Proxy
Firewall
User2: ProxySlide49
Broader Research Agenda49
High Capital costsDevice SprawlHigh management complexityInflexible, difficult to extend need for new boxes
Consolidated
Architecture
[NSDI ‘12]
Software
Defined
Networking
[this talk]