Extensions Middleboxes 1 Ack Vyas Sekar Aaron Gember Felipe Huici Zafar Qazi Need for Network Evolution 2 New devices New applications Evolving threats Policy ID: 539089
Download Presentation The PPT/PDF document "SDN:" 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
SDN: ExtensionsMiddleboxes
1
Ack
:
Vyas
Sekar
, Aaron
Gember
,
Felipe
Huici
,
Zafar
QaziSlide2
Need for Network Evolution
2
New devices
New applications
Evolving
threats
Policy
constraints
Performance, Security,
ComplianceSlide3
3
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
636
Total routers
~900
Network Evolution today:
Middleboxes
!
Data from a large enterprise:
>80K users across tens of sites
Just network security
$10 billionSlide4
How many middleboxes do you deploy?
Typically on par with # routers and switches.Slide5
How do administrators spend their time?
Misconfig
.
Overload
Physical/
Electrical
Firewalls
67.3%
16.3%
16.3%
Proxies
63.2%
15.7%
21.1%
IDS
54.45%
11.4%
34%
Most administrators spent 1-5 hrs/week dealing with failures; 9% spent 6-10 hrs
/week.Slide6
6
S
pecialized
boxes
Narrow
interfaces
“Point”
solutions!
Increases capital expenses & sprawl
Increases operating expenses
Limits extensibility and flexibility
Management
Management
Management
Key “pain points”
Slide7
Controller Platform
Switch API
(
OpenFlow
)
Controller
Switches
App
Runtime
SDN Stack
Control Flow, Data Structures, etc.
7
ApplicationsSlide8
OutlineWhy middleboxes
?SIMPLE OpenMB
Slick
8Slide9
Can SDN simplify middlebox management?
Centralized Controller
“
Flow
”
FwdAction
…
…
“
Flow
”
FwdAction
…
…
OpenFlow
9
Proxy
IDS
Necessity + Opportunity:
Incorporate functions markets views as important
Scope
: Enforce middlebox-specific steering policies
Firewall
IDS
Proxy
WebSlide10
What makes this problem challenging?
Centralized Controller
“
Flow
”
FwdAction
…
…
“
Flow
”
FwdAction
…
…
OpenFlow
10
Proxy
IDS
Middleboxes introduce new dimensions beyond L2/L3 tasks.
Achieve this with
unmodified
middleboxes and
existing
SDN APIs
Firewall
IDS
Proxy
WebSlide11
Firewall
IDS
Proxy
Web
SIMPLE overview
Legacy
Middleboxes
OpenFlow
capable
Flow
Action
…
…
Flow
Action
…
…
11
P
olicy
enforcement layer
for
middlebox
-specific “traffic steering” Slide12
Challenge: Policy Composition
S1
S
2
12
Firewall
Proxy
IDS
Firewall
IDS
Proxy
*
Policy Chain:
Oops! Forward
Pkt
to IDS or
Dst
?
Dst
“Loops”
Traditional flow rules may not suffice!Slide13
Challenge: Resource Constraints
S1
S2
S4
S3
Proxy
Firewall
IDS1 = 50%
IDS2 = 50%
S
pace for
t
raffic split?
Can we set up “feasible” forwarding rules?
13Slide14
14
S1
Proxy
S2
User 1
User 2
Proxy may modify flows
Are forwarding rules at S2 correct?
Challenge: Dynamic Modifications
Firewall
User1: Proxy
Firewall
User2: ProxySlide15
New dimensions beyond Layer 2-3 tasks
1) Policy Composition
Potential loops
3) Dynamic Modifications
Correctness?
2) Resource Constraints
Switch + Middlebox
15
Can we address these with
unmodified
middleboxes and
existing
SDN APIs?Slide16
Rule Generator
Resource Manager
Modifications Handler
SIMPLE System Overview
Legacy
Middleboxes
OpenFlow
capable
Flow
Action
…
…
Flow
Action
…
…
16
Firewall
IDS
Proxy
WebSlide17
Composition
Tag Processing State17
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 packetSlide18
Rule Generator
Resource Manager
Modifications Handler
SIMPLE System Overview
Legacy
Middleboxes
OpenFlow
capable
Flow
Action
…
…
Flow
Action
…
…
18
Firewall
IDS
Proxy
WebSlide19
Resource Constraints
Joint Optimization
Resource Manager
Topology & Traffic
Switch
TCAM
Middlebox
Capacity + Footprints
Policy
Spec
Optimal & Feasible
load balancing
Theoretically hard!
Not obvious if some configuration is feasible!
19Slide20
Offline + Online Decomposition
20
Offline Stage
Online Step
Deals with Switch constraints
Deals with only load balancing
Resource Manager
Network
Topology
Switch
TCAM
Policy
Spec
Traffic
Matrix
Mbox
Capacity
+ FootprintsSlide21
Offline Stage: ILP based pruning
21
Set of all possible middlebox load distributions
Pruned Set
Balance the middlebox load
Feasible
Sufficient freedomSlide22
FW
IDS
Proxy
Web
Rule Generator
Resource Manager
Modifications Handler
SIMPLE System Overview
Legacy
Middleboxes
OpenFlow
capable
Flow
Action
…
…
Flow
Action
…
…
22Slide23
Modifications
Infer flow correlations23
Correlate
flows
Install rules
S1
Proxy
S2
User 1
User 2
Firewall
User1: Proxy
Firewall
User2: Proxy
Payload SimilaritySlide24
FW
IDS
Proxy
Web
Rule Generator
(Policy Composition)
Resource Manager
(Resource Constraint)
Modifications Handler
(Dynamic modifications)
SIMPLE Implementation
OpenFlow 1.0
Flow
Tag
/Tunnel
Action
…
…
Flow
Tag
/Tunnel
Action
…
…
POX extensions
24
CPLEXSlide25
Evaluation and Methodology
What benefits SIMPLE offers? l
oad 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)
25Slide26
Summary of SIMPLE
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
26Slide27
OutlineWhy middleboxes
?SIMPLE OpenMB
Slick
27Slide28
Middlebox Deployment Models
Arbitrary middlebox placement
New forms of middlebox deployment
(VMs, ETTM
[NSDI 2011]
,
CoMB
[NSDI 2012]
)
28Slide29
Move between software-defined data centers
Existing VM and network migration methodsUnsuitable for changing underlying substrate
Live Data Center Migration
Data Center A
Data Center B
Programmatic control over middlebox state
29Slide30
Add or remove middlebox VMs based on loadClone VM (logic, policy, and internal state)
Unsuitable for scaling down or some scaling up
Middlebox Scaling
Fine-grained control
30Slide31
ContributionsClassify middlebox state, and discuss what should be controlled
Abstractions and interfacesRepresenting stateManipulating where state resides
Announcing state-related eventsControl logic design sketches
31Slide32
Controller
Middlebox
App
App
Middlebox
SDN-like Middleboxes
IPS
Software-Defined Middlebox Networking
Today
32Slide33
Controller
Key Issues
33
Middlebox
How is the logic divided?
Where is state manipulated?
What interfaces
are exposed?
App
App
MiddleboxSlide34
Configuration input
Middlebox State
34
State: ESTAB
Seq
#: 3423
Server: B
CPU: 50%
Hash: 34225
Content: ABCDE
Significant state diversity
+ detailed internal records
Balance Method:
Round Robin
Cache size: 100
Src
:
HostA
Server: B
Proto: TCP
Port: 22Slide35
Balance Method:
Round Robin
Cache size: 100
Src
:
HostA
Server: B
Proto: TCP
Port: 22
Classification of State
35
State: ESTAB
Seq
#: 3423
Server: B
CPU: 50%
Hash: 34225
Content: ABCDE
Action
Supporting
Tuning
Internal & dynamic
Many forms
Only affects performance, not correctnessSlide36
Policy
Language
Src
:
HostA
Server: B
Proto: TCP
Port: 22
State: ESTAB
Seq
#: 3423
Server: B
CPU: 50%
Hash: 34225
Content: ABCDE
How to Represent State?
36
Unknown structure
Significant diversity
May be shared
Per flow
Shared
Commonality among middlebox operations
1000101
1101010
0101001
1111000
1010110Slide37
State Representation
Key: protocol header field/value pairs identify traffic subsets to which state applies
Action:
transformation function to change parts of packet to new constants
Supporting:
binary blob
Key
Action
Supporting
Binary Blob
Field1
=
Value1
…
FieldN
=
ValueN
37
Offset1
→ Const1…OffsetN → ConstN
Only suitable for per-flow state
Not fully vendor independentSlide38
Controller
Middlebox
How to Manipulate State?
Today: only control some state
Constrains flexibility and sophistication
Manipulate all state at controller
Removes too much functionality from middleboxes
38Slide39
State Manipulation
Control over state placementBroad operations interface
Expose state-related events
39
Controller
IPS 1
IPS 2
Create and
update state
Determine where
state residesSlide40
Action
*
Key
SrcIP
= 10.10.0.0/16
DPort
= 22
Key
SrcIP
= 10.10.54.41
DstIP
= 10.20.1.23
SPort
= 12983
DPort
= 22
State =
ESTAB
Supporting
Operations Interface
get
( , )
Filter
SrcIP
= 10.10.54.41
add
( , )
Action
DROP
KeyDstIP = 10.20.1.0/24SourceDestinationProto
OtherAction
*10.20.1.0/24
TCP
*
DROP
remove
( , )
Filter
…
Need atomic blocks of operations
Potential for invalid manipulations of state
40Slide41
Firewall
Events Interface
Triggers
Created/updated state
Require state to complete operation
Contents
Key
Copy of packet?
Copy of new state?
41
Controller
Balance visibility and overheadSlide42
ConclusionNeed fine-grained, centralized control over middlebox state to support rich scenarios
Challenges: state diversity, unknown semantics
42
get/add/remove
( , )
…
Action
Offset1
→
Const1
…
Key
Field1
=
Value1
…
Supporting
Binary BlobSlide43
Open Questions
Encoding supporting state/other action state?Preventing invalid state manipulations?
Exposing events with sufficient detail?Maintaining operation during state changes? Designing a variety of control logics?
Providing middlebox fault tolerance?
43Slide44
OutlineWhy middleboxes
?SIMPLE OpenMB
Slick
44Slide45
Network PoliciesReachability
Alice can not send packets to BobApplication classificationPlace Skype traffic in the gold queueSlide46
Limitations of SDN Data Plane
10.2.3.4:10.2.3.3
Fwd
Port 1
A2:e3:f1:ba:ea:23:*
Drop
Match
Action
Limited actions and matching
Match:
E
thernet, IP, TCP/UDP port numbers
Action: forward, drop, rewrite header, etc.Slide47
Extending SDN’s Data PlaneExpand the
OpenFlow standardsRequires hardware support
Implement richer data plane in controllerIntroduces additional latency to packets
Add new devices (Middleboxes)Slide48
Example: Detecting Network Attacks
Inspect all DNS traffic with a DPI device
If suspicious lookup takes place,
send to
traffic scrubberSlide49
Example: Detecting Network Attacks
Inspect all DNS traffic with a DPI device
If suspicious lookup takes place,
send to
traffic scrubberSlide50
Example: Detecting Network Attacks
Inspect all DNS traffic with a DPI device
If suspicious lookup takes place,
send to
traffic scrubberSlide51
Example: Detecting Network Attacks
Inspect all DNS traffic with a DPI device
If suspicious lookup takes place,
send to
traffic scrubberSlide52
Challenges
Specify network policies across middleboxes
Difficult to automatically react to middlebox events
Dynamically place sophisticated middleboxes
Difficult to
determine efficient placement
Difficult
to
adjust placement to traffic patterns
Support for arbitrary middlebox functionality
Difficult to capture hardware requirementsSlide53
Slick ContributionsAbstraction for programming middleboxes
Simplifies the development of network policies
Separates specification of intent from implementation
Dynamic placement of middlebox
functionality
O
nline resource allocation algorithm
Support for heterogeneous devices
Maintains performance profiles of middleboxSlide54
Slick Architecture
Slick Controller
Middlebox
Element
Middlebox
Element
Application
Encodes network policy
Provides handlers for triggers
Piece of code encapsulating middlebox functions
Your network operator
3
rd
party element
developers
Programmable device:
NetFPGA
, x86 server
Virtual Switch
Triggers from elementsSlide55
Slick Architecture
Slick Controller
Application
Runs applications
Runs resource allocation
algo
.
Places middlebox elements
Steers traffic through middleboxes
Configures switches
Installs/uninstalls middlebox functions
Deploy
Middlebox code
Middlebox
Element
Middlebox
Element
Programmable device:
NetFPGA
, x86 server
Virtual SwitchSlide56
Resource Allocation Heuristic
Resource allocation heuristic
Traffic Steering
OpenFlow
Controller
Placement
Decisions
Traffic matrix
And topology
Network policies in
applications
Middlebox
perf
profile
Hardware
constraints
Programmable device
Virtual Switch
Programmable device
Virtual Switch
Objective: minimize latency (path lengths)Slide57
Summary
Slick: control plane for middleboxesPresented an initial architecture
Discussed algorithmic challengeSlick is implemented in python
Slick controller as a module on
NoX
0.5.0
Developed 2 applications and 3
middlebox
elements
Open questionsHow
can developers help guide placement?What is the optimal solution for resource allocation?Slide58
Discussion: Likes/dislikes?
58