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