toward practical convergence of middleboxes and software -defined networking
DESCRIPTION
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. - PowerPoint PPT PresentationTRANSCRIPT
Toward Practical Convergence of Middleboxes and
Software-Defined NetworkingVyas Sekar
Joint work with: Seyed Kaveh Fayazbakhsh, Zafar Qazi,
Luis Chiang, Rui Miao, William Tu,Jeff Mogul, Minlan Yu
Network “101” vs. Reality
2
Traditional view: “Dumb” network
Reality: Lots of in-network processingAppliances or Middleboxes:IDS, Firewall, Proxies, Application Gateways ….
Type of appliance NumberFirewalls 166NIDS 127Media gateways 110Load balancers 67Proxies 66VPN gateways 45WAN Optimizers 44Voice gateways 11Total Middleboxes 636Total routers ~900
Middleboxes Galore!Data from a large enterprise Survey across 57 network operators
3
Just network security $10 billion (2016)
4
Middlebox management is hard!
Critical for security, performance, complianceBut expensive, complex and difficult to manage
5
Can SDN help middlebox management?
Centralized Controller
“Flow” FwdAction… …
“Flow” FwdAction… …
OpenFlow
Proxy IDS
Necessity and an Opportunity: Incorporate functions markets views as important
[Metzler 2012]
Firewall IDS ProxyWeb
6
What makes SDN + MB challenging?Centralized Controller
“Flow” FwdAction… …
“Flow” FwdAction… …
OpenFlow
Proxy IDS
New dimensions beyond simple forwarding:e.g., Policy-based “steering” composition
New resource management Packet transformations/hidden actions
Firewall IDS ProxyWeb
7
Our work on SDN-middlebox convergence
FlowTags: Handling dynamic middlebox actionsNew APIs + minimal extensions to
middleboxes
SIMPLE: SDN-based traffic steering Unmodified middleboxes, current SDN APIs
8
Talk Outline• Motivation
• Design of SIMPLE (SIGCOMM 2013)
• Design of FlowTags (NSDI 2014)
• Other middlebox research
Firewall IDS ProxyWeb
SIMPLE: High-level view
LegacyMiddleboxes
OpenFlow capable
Flow Action… …
Flow Action… …
9
Policy enforcement layer for middlebox-specific traffic steering
10
Challenge: Policy Composition
S1 S2
Firewall Proxy IDS
Firewall IDS Proxy*Policy Chain:
Forward Pkt to IDS or Dst?
Dst
“Loops” Simple flow rules don’t work
11
Rule Generator Tag Processing StateFirewall IDS Proxy
*Policy Chain:
S1 S2
Firewall Proxy IDS
DstORIGINAL Post-Firewall
Post-IDSPost-Proxy
Fwd to Dst
Insight: Distinguish different instances of the same packet
12
Challenge: Resource Constraints
S1
S2S4
S3
ProxyFirewall
IDS1 = 50%
IDS2 = 50%
Enough TCAM space for traffic split?
Can we set up “feasible” forwarding rules and load balance optimally?
Flow Action… …
Flow Action… …
13
Resource manager Joint Optimization
Resource Manager
Topology & Traffic
Switch TCAM
MiddleboxCapacity + Footprints
Policy Spec
Optimal & Feasible load balancing
Theoretically hardNot obvious if some configuration is feasible
14
Offline + Online Decomposition
Offline Stage Online Step
Deals with Switch constraints Deals with only load balancing
Resource Manager
Network Topology
Switch TCAM
Policy Spec
TrafficMatrix
Mbox Capacity + Footprints
15
S1Proxy
S2User 1
User 2
Proxy may modify flows
Actually a more fundamental problemWill revisit in FlowTags
Challenge: Dynamic Modifications
Firewall
User1: Proxy FirewallUser2: Proxy
16
Modifications Handler Flow correlation
Correlate flows
Install rules
S1Proxy
S2User 1
User 2 Firewall
User1: Proxy FirewallUser2: Proxy
Payload Similarity
17
Rule GeneratorAvoid Loops
Resource ManagerHandle resource constraints
Modifications HandlerDeal w/ flow modifications
SIMPLE System Overview
LegacyMiddleboxes
OpenFlow capable
Flow Action… …
Flow Action… …
Firewall IDS ProxyWeb
18
SIMPLE = Optimal Load balancing
4-7X better that status quo
Optimal
19
Talk Outline• Motivation
• Design of SIMPLE (SIGCOMM 2013)
• Design of FlowTags (NSDI 2014)
• Other middlebox research
20
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
21
Attribution is hard
NAT hides the true packet sources
S1 S2
NIDSNAT
Internet
H2
H1
NIDS: Flag host if it creates too many connections
22
Network Diagnosis is difficult
Difficult to correlate network logs for diagnosis
S1 S2
Load BalancerFirewall
H2
H1
Server 2
Server 1
H1 sees very high web server delay – but what’s causing it?
23
Policy violations may occur
S1 S2
Proxy
Internet
H2
H1
Web ACL: Block H2 xyz
Get xyz.com
Get xyz.com
Cached response
Response
Lack of visibility into the middlebox context
Cached response
24
Seemingly natural (non)solutions
Ideas Attributione.g., NAT
Diagnosise.g., Load Balancer
Policy violatione.g., cache
Placement Yes No YesTunneling No Even harder! NoConsolidation No NoCorrelation(SIMPLE)
Not 100% accurate and high overhead
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
S1 S2
Firewall NAT
Internet
H1 192.168.1.1
H2192.168.1.2
H3192.168.1.3
SrcIP Tag192.168.1.1 1192.168.1.2 2192.168.1.3 3
Tag OrigSrcIP1 192.168.1.13 192.168.1.3
Block 192.168.1.1Block 192.168.1.3
NAT Add Tags Decode Tags Firewall Config w.r.t original principals
Tag Forward1,3 FW2 Internet
S2 FlowTable
Example of FlowTags in actionTag
Generation
Tag Consumption
Tag Consumption
26
Control Appse.g., steering, verification
Control Appse.g., routing, traffic eng.
Network OS
Control
Data
SDN Switches
FlowTableFlowTags
EnhancedMiddleboxes
FlowTagsTables
Control Appse.g., steering, verification
Admin
MboxConfig
FlowTags APIs
Existing APIse.g., OpenFlow
Legacy interface
Newinterface
FlowTags Architecture
27
“Produce” + “consume” FlowTagsOnly “consume” FlowTags
28
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?
29
Semantics: Dynamic Policy Graph
Proxy ACL
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 DPGIn practice: temporal reuse, spatial reuse, policy classes etc
30
• 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
FlowTags-enhanced Controller
31
Extending middleboxes to support FlowTags
Minimal code modification needed
Middlebox Total LOC Modified LOC
Squid 216,000 75
Snort 336,000 45Balance 2000 60PRADS 15000 25
Scalability of FlowTags controller
32
33
Talk Outline• Motivation
• Design of SIMPLE
• Design of FlowTags
• Other middlebox research
Broader Research Agenda
34
High Capital costsDevice Sprawl
High management complexity
Inflexible, difficult to extend need for new boxes
ConsolidatedArchitecture[CoMbNSDI ‘12]
Cloud Outsourcing[APLOMBSIGCOMM ’12]
SDN Integration[SIMPLE, FlowTags,this talk]
35
New challenges and opportunities• Policy languages/graph generation?
• Automating middlebox extensions?
• New testing/verification tools?
• Better hardware/software platforms?
• …
36
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