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 Reality: Lots of in-network processing Appliances or Middleboxes: IDS, Firewall, Proxies, Application Gateways ….

2

Middleboxes Galore!

Data from a large enterprise Survey across 57 network operators

Type of appliance

Firewalls NIDS Media gateways Load balancers Proxies VPN gateways WAN Optimizers Voice gateways

Total Middleboxes

Number

166 127 110 67 66 45 44 11

636 Total routers ~900

Just network security  $10 billion (2016) 3

Middlebox management is hard!

Critical for security, performance, compliance But expensive, complex and difficult to manage 4

Can SDN help middlebox management?

Web Firewall IDS Centralized Controller Proxy OpenFlow Proxy …

“ Flow ”

…

FwdAction

…

“ Flow ”

…

FwdAction

IDS

Necessity and an Opportunity:

Incorporate functions markets views as important [Metzler 2012] 5

Web

What makes SDN + MB challenging?

Centralized Controller Firewall IDS Proxy OpenFlow …

“ Flow ”

…

FwdAction

…

“ Flow ”

…

FwdAction

Proxy New dimensions beyond simple forwarding: e.g., Policy-based “steering” composition New resource management Packet transformations/hidden actions IDS 6

Our work on SDN-middlebox convergence SIMPLE: SDN-based traffic steering Unmodified middleboxes, current SDN APIs FlowTags: Handling dynamic middlebox actions New APIs + minimal extensions to middleboxes 7

Talk Outline

• Motivation •

Design of SIMPLE (SIGCOMM 2013)

• Design of FlowTags (NSDI 2014) • Other middlebox research 8

SIMPLE: High-level view

Web Firewall IDS Proxy Policy enforcement layer for middlebox-specific traffic steering

Legacy Middleboxes

…

Flow

…

Action

…

Flow

…

Action

OpenFlow capable

9

Challenge: Policy Composition

Firewall

Policy Chain:

*

IDS Proxy Firewall Proxy IDS

Forward Pkt to IDS or Dst?

S1 S2

Dst

“Loops”  Simple flow rules don’t work 10

Rule Generator  Tag Processing State

Firewall IDS Proxy

Policy Chain:

*

Firewall Proxy

S1 ORIGINAL

IDS

S2 Post-IDS

Dst

Fwd to Dst Insight: Distinguish different instances of the same packet 11

Challenge: Resource Constraints

Firewall Proxy

Enough TCAM space for traffic split?

S2 …

Flow

…

Action

S4 …

Flow

S1 …

Action

S3

IDS1 = 50% IDS2 = 50%

Can we set up “feasible” forwarding rules and load balance optimally?

12

Resource manager  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 13

Offline + Online Decomposition

Policy Spec Network Topology Switch TCAM Mbox Capacity + Footprints Traffic Matrix Offline Stage Resource Manager Online Step Deals with Switch constraints Deals with only load balancing 14

Challenge: Dynamic Modifications

User1: Proxy  User2: Proxy Firewall Proxy may modify flows User 1

Proxy

S1 S2 User 2

Firewall

Actually a more fundamental problem Will revisit in FlowTags 15

Modifications Handler  Flow correlation User 1 Correlate flows S1 Payload Similarity

Proxy

Install rules S2 User 2

Firewall

User1: Proxy  User2: Proxy Firewall 16

SIMPLE System Overview

Web Firewall IDS Proxy

Resource Manager

Handle resource constraints

Rule Generator

Avoid Loops

Modifications Handler

Deal w/ flow modifications

Legacy Middleboxes

…

Flow

…

Action

…

Flow

…

Action

OpenFlow capable

17

SIMPLE = Optimal Load balancing

Optimal 4-7X better that status quo 18

Talk Outline

• Motivation • Design of SIMPLE (SIGCOMM 2013) •

Design of FlowTags (NSDI 2014)

• Other middlebox research 19

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 20

Attribution is hard

NIDS: Flag host if it creates too many connections NAT NIDS H1 Internet S1 S2 H2 NAT hides the true packet sources 21

Network Diagnosis is difficult

H1 sees very high web server delay – but what’s causing it?

Firewall Load Balancer H1 H2 S1 S2 Server 1 Server 2 Difficult to correlate network logs for diagnosis 22

H1 H2

Policy violations may occur

Proxy Web ACL: Block H2  xyz Cached response Internet S1 S2 Lack of visibility into the middlebox context 23

Seemingly natural (non)solutions

Ideas

Placement Tunneling

Attribution e.g., NAT

Yes No

Diagnosis e.g., Load Balancer

No

Policy violation e.g., cache

Yes Even harder! No Consolidation No Correlation (SIMPLE) No Not 100% accurate and high overhead 24

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

Example of FlowTags in action

Tag Generation H1 192.168.1.1

NAT Add Tags

SrcIP Tag

192.168.1.1 1 192.168.1.2 2 192.168.1.3 3 NAT

Decode Tags

Tag OrigSrcIP

1 3 192.168.1.1

192.168.1.3

Firewall

Firewall Config w.r.t

original principals

Block 192.168.1.1

Block 192.168.1.3

Tag Consumption H2 192.168.1.2

S 1 Internet H3 192.168.1.3

S 2

S2 FlowTable

Tag Forward

1,3 2 FW Internet Tag Consumption 26

Control

Legacy interface New interface

FlowTags Architecture

Control Apps e.g., steering, verification e.g., steering, verification Network OS Existing APIs e.g., OpenFlow FlowTags APIs

Data

SDN Switches FlowTable Only “consume” FlowTags Admin FlowTags Tables Mbox Config FlowTags Enhanced Middleboxes “Produce” + “consume” FlowTags 27

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?

28

Semantics: Dynamic Policy Graph

H1 {H1}; Proxy {H1}; Hit {H1}; Miss ACL Drop H2 {H2}; Miss Internet {H2}; Hit Conceptually need a tag in this DPG In practice: temporal reuse, spatial reuse, policy classes etc 29

FlowTags-enhanced Controller

• 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 30

Extending middleboxes to support FlowTags

Middlebox

Squid Snort Balance PRADS

Total LOC

216,000 336,000 2000 15000

Modified LOC

75 45 60 25 Minimal code modification needed 31

Scalability of FlowTags controller

32

Talk Outline

• Motivation • Design of SIMPLE • Design of FlowTags •

Other middlebox research

33

Broader Research Agenda High Capital costs Device Sprawl Inflexible, difficult to extend  need for new boxes High management complexity

Consolidated Architecture

[CoMb NSDI ‘12]

Cloud Outsourcing

[APLOMB SIGCOMM ’12]

SDN Integration

[SIMPLE, FlowTags, this talk] 34

New challenges and opportunities

• Policy languages/graph generation?

• Automating middlebox extensions?

• New testing/verification tools?

• Better hardware/software platforms?

• … 35

•

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 36