1. OpenBox: A Software-Defined Framework for Developing, Deploying, and Managing Network Functions
David Hay
The Hebrew University of Jerusalem
Joint work with Anat Bremler-Barr and Yotam Harchol
Appeared in ACM SIGCOMM 2016
This research was supported by the European Research Council ERC Grant agreement no , the Israeli Centers of Research Excellence (I-CORE) program (Center No. 4/11), and the Neptune Consortium.

2. Outline Middleboxes and Network Functions
The OpenBox framework [SIGCOMM’16]
Data plane
Controller
(Few) implementation details
Case Study: DPI as a service [coNEXT’14]
Either stand-alone or within OpenBox
Important benefit: Making DPI resilient to complexity attack [ANCS’12/ToN’16]
Joint works with Yehuda Afek (TAU) Anat Bremler-Barr (IDC), Yotam Harchol (HUJI), and Yaron Koral (AT&T)

3. Network Functions (Middleboxes)
Monolithic closed black-boxes
High cost
Limited provisioning and scalability
Firewall
Load Balancer
NFs, or middleboxes, have been traditionally implemented as closed hardware appliances.
Intrusion Prevention System
Network Function Virtualization (NFV):
Reduce cost (by moving to software)
Improve provisioning and scalability (by virtualizing software NFs)

4. Network Functions (Middleboxes)
High cost
Limited provisioning and scalability
Limited and separate management
Different vendors
No standards
Separate control plane
However, NFs, virtual or physical, still have other problems

5. Network Functions (Middleboxes)
Actually, many of these black-boxes are very modular
Network Function
High cost
Limited provisioning and scalability
Limited and separate management
Limited functionality and limited innovation (High entry barriers)
Similar complex processing steps, no re-use
high entry barriers – if someone wants to improve or change they need to do everything from scratch

6. OpenBox
github.com/OpenBoxProject
OpenBox: A new software-defined framework for network functions
Decouples network function control from their data plane
Unifies data plane of multiple network functions
Benefits:
Easier, unified control
Better performance
Scalability
Flexible deployment
Inter-tenant isolation
Innovation
OpenBox
Controller
להתלהב!
OpenBox is a new…
NFs now become applications on top of the OpenBox controller.
The OpenBox data plane realizes the packet processing as directed by the controller.
Packet processing remains in data plane.
The benefits we get are: …
WE IMPLEMENTED
OBI
OBI
OBI

7. Software Defined Networking
High cost of middleboxes
Limited provisioning and scalability of middleboxes
Limited management of middleboxes
Limited functionality and limited innovation
Complex processing steps
switches
distributed algorithms
OpenBox
Controller
OpenFlow
Controller
These problems I have been talking about are not new to middleboxes or NFs.
We had similar problems with the forwarding plane, for a similar reason – separate control plane.
The solution in the forwarding plane was SDN, or specifically, OpenFlow.
Studies has shown that 40-60% of the appliances in large scale networks are not forwarding devices. They are middleboxes. OpenBox takes a similar SDN approach for these appliances.
OBI
40%-60% of the appliances in large-scale networks are middleboxes!
[Sherry & Ratnasamy, ‘12]
OBI
OBI

8. OpenBox Service Instances
The OpenBox Framework
Network Functions:
OpenBox Applications
Northbound API
Logically-Centralized OpenBox Controller
Control Plane
OpenBox Protocol
Data Plane
Northbound API to specify NF logic
Logically-centralized controller that unifies logic of multiple network functions from multiple tenants
Communication protocol between controller and data plane
Specification of data plane instances that perform the actual packet processing (packets do not flow through the controller) (ADD EXAMPLE)
OpenBox Service Instances
Additionally:
Isolation between NFs / multiple tenants
Support for hardware accelerators
Dynamically extend the protocol

9. Most network functions do very similar processing steps
Observation:
Most network functions do very similar processing steps
But there is no re-use…
The design the OpenBox framework is based on this observation

10. Network Function Decomposition
Firewall:
Read Packets
Header Classifier
Drop
Alert
Output
Load Balancer:
Read Packets
Header Classifier
Rewrite Header
Output
We use Click-like notation to decompose NF logic
Each block has its own configuration parameters
Intrusion Prevention System:
Read Packets
Header Classifier
Drop
Alert
DPI
Output

11. Northbound API Specify processing graph and block configuration NB API
Intrusion Prevention System
Load Balancer
Firewall
Read Packets
Header Classifier
Drop
Alert
Output
Rewrite Header
DPI
OpenBox
Applications
Specify processing graph and block configuration
Events,
Load information
NB API
OpenBox
Controller
Give example for events and load info
OpenBox Protocol
Control Plane
Data Plane
OpenBox Service Instances

12. Logically-Centralized Controller
Multiple tenants run multiple applications for multiple policies in the same network
Isolation between applications and tenants enforced by NB API
OpenBox
Applications
NB API
SDN Protocol
SDN Switches
SDN
Controller
Network-wide view
Automatic scaling, provisioning, placement, and steering
OpenBox
Controller
OpenBox Protocol
Control Plane
Data Plane
OpenBox Service Instances

13. Performance ≈ Diameter of Graph (# of classifiers)
Naïve Graph Merge
Firewall:
Read Packets
Header Classifier
Drop
Alert
Output
Concatenated Processing Graph:
Header Classifier
Drop
Alert
(IPS)
DPI
Output
Read Packets
(Firewall)
30μs
10μs
50μs
2μs
The performance is correlated with the diameter
Intrusion Prevention System:
Read Packets
Header Classifier
Drop
Alert
DPI
Output
Performance ≈ Diameter of Graph (# of classifiers)
Total: 134μs

14. Graph Merge Algorithm Merged Processing Graph:
Algorithm and details are in the paper
Alert (Firewall)
DPI
Alert (Firewall)
DPI
Read Packets
Header Classifier
Alert (Firewall)
DPI
Alert (IPS)
Output
In the paper we provide an algorithm that merges multiple processing graphs, and specifically merges classifiers to reduce the lengths of paths in the result graph. We show that this indeed improves data plane performance.
---
It may not always be good to merge, controller can determine when it is good
2μs
30μs
2μs
50μs
10μs
Alert (Firewall)
10μs
Drop
Shorter Diameter (less classifiers)
Total: 104μs (22% improvement)

15. OpenBox Data Plane Processing
Read Packets
Store Packet
Restore Packet
Caching
HTML Normalizer
JavaScript Normalizer
XML Normalizer
Normalization
Alert
Log
Reporting
Output
Drop
Terminals
Header Classifier
DPI
Classification
FIFO Queue
Front Drop Queue
RED Queue
Leaky Bucket
Queue Management
Gzip Decompress
Gzip Compress
De/compression
Begin Transaction
Rollback Transaction
Commit Transaction
Transactions
VLAN Pop
VLAN Push
Rewrite Header
Header Modification

16. OpenBox Data Plane Processing
Read Packets
Store Packet
Restore Packet
Caching
HTML Normalizer
JavaScript Normalizer
XML Normalizer
Normalization
Alert
Log
Reporting
Output
Drop
Terminals
Header Classifier
DPI
Classification
OpenBox Service Instance
Virtual or Physical
FIFO Queue
Front Drop Queue
RED Queue
Leaky Bucket
Queue Management
Gzip Decompress
Gzip Compress
De/compression
Begin Transaction
Rollback Transaction
Commit Transaction
Transactions
Provides data plane services to realize the logic of network functions
Controlled by the logically-centralized OpenBox controller
VLAN Pop
VLAN Push
Rewrite Header
Header Modification

17. Distributed Data Plane
Alert
DPI
Header Classifier
Rewrite Header
Metadata
OpenBox Service Instance
Hardware
(TCAM)
E.g., an OpenFlow switch with encapsulation features
(e.g., NSH, Geneve, FlowTags)
OpenBox Service Instance
Software

18. Split Processing Graph
HW Instance:
Read Packets
Header Classifier
Write Metadata
Encapsulate Metadata
Output
Drop
SW Instance:
DPI
IPS processing graph
DPI
Drop
Read Packets
Decapsulate Metadata
Read Metadata
DPI
Alert
Output

19. Extensible Data Plane Option 2: Software module injection NB API
Media Encoder
Option 2:
Software module injection
NEW APP
Custom
software module (signed)
NB API
OpenBox
Controller
On the fly
No need to recompile
No need to redeploy
OpenBox Protocol
Control Plane
Data Plane
OpenBox Service Instances
Option 1:
New hardware implementation
Supports encapsulation

20. Scalable & Reliable Data Plane
Scalability
Provisioning
Reliability
OpenBox
Controller
Provision
OBI
OBI
OBI
OBI
OBI
OBI
OBI
OBI
OBI
OBI
Hypervisor
OBI
OBI
Hypervisor

21. (Plug here other execution engines. E.g., ClickNP)
Implementation
github.com/OpenBoxProject FW
IPS
Load Balancer
. . .
Java-based OpenBox Controller
7500 LoCs
(Java)
Northbound API
REST client/server
Graph Aggregator
Network Manager
Management API
REST
Control Plane
REST API
Data Plane
Generic wrapper for execution engines (Python)
Software OpenBox Service Instance
Or the one we are working on now which is a hybrid SW-HW using a HW OpenFlow switch
5500 LoCs
(Python)
Translation Engine
Click-based execution engine (C++)
2400 LoCs for plugin (C++)
(Plug here other execution engines. E.g., ClickNP)

22. Performance Improvement
VM1
Firewall
VM2
IPS
Without OpenBox
VM1
OBI1: FW+IPS
VM2
OBI2: FW+IPS
With OpenBox
Standalone VM
NF Pipeline
-35%
Now for some performance measurments
We consider a simple scenario where packets go from one host through a firewall, then through an IPS, then to another host.
+86%
Without OpenBox
With OpenBox

23. Related Work Orthogonal to OpenBox: Similar Motivation:
NF traffic steering (e.g., SIMPLE [SIGCOMM ’14])
NF orchestration (e.g., Stratos, OpenMano, OpenStack)
Runtime platforms (e.g., xOMB [ANCS ‘12], ClickNP [SIGCOMM ‘16])
Similar Motivation:
CoMb [NSDI ‘12] – focuses on resource sharing and placement
E2 [SOSP ‘15] – composition framework for virtual NFs
Slick [SOSR ’15] – focuses on the placement of data plane units
Only OpenBox provides:
Core processing decomposition and reuse
Standardization and full decoupling of NF control and data planes

24. Case Study: DPI as a Service
Joint work with Anat Bremler-Barr, Yotam Harchol and Yaron Koral (AT&T)
Appeared in ACM coNEXT 2014
This research was supported by the European Research Council ERC Grant agreement no , and the Israeli Centers of Research Excellence (I-CORE) program (Center No. 4/11).

25. Motivation
Some middlebox/NF vendors may want to keep their middleboxes monolithic and doesn’t expose the inner blocks
OpenBox still works, but graph merging becomes trivial.
Sometime it might be beneficial to go only “half way”

26. Deep Packet Inspection (DPI)
Classify packets according to:
Packet payload (data)
Against known set of patterns: strings or regular expressions
Internet
IP packet
“Evil”
L7 Firewall
In Deep packet Inspection process the traffic is classified according to the payload of the packet, against known set of patterns.
The patterns can be strings or regular expressions. You can see here an example. A regular expression using by snort, an opensource IDS. And a string pattern used by CLamAV, an opensource antivirus.
DPI is a common task in middleboxes. Middleboxes are all the network devices which are not routers or switches.
Middleboxes are widely used today to meet security, performance and compliance requirements. In many network todays there are more Middleboxes than switches and routers, since networks become more sophisticated.
“Evil” ->

27. DPI-Based Middleboxes
Intrusion Detection System
Network Analytic
Traffic Shaper
A MB processes packet header or payload
The latter uses DPI engine
Network Anti-Virus
Copyright Enforcement
Lawful Interception
There is a wide range of middleboxes that uses DPI
L7 Firewall
L7 Load Balancer
Leakage Prevention System

28. Middleboxes Policy Chains
SDN technology allows easy deployment of service chains within the network that consist of several such middleboxes.
In this example three of the middleboxes perform DPI.
Still: <read bullets>
Each MB implements its own DPI engine (higher MB costs, reduced features)
Each packet is scanned multiple times causing waste of computation resources

29. Deep Pocket Inspection
66% of network equipment vendors define DPI as “a must have” technology today [Heavy Reading Survey, 2013]
DPI market is estimated $590 million in 2012 and is expected to reach US$3.8 billion by 2018 [Transparency Market Research, Dec. 2015]
Now I will do some Deep Pocket inspection to DPI market. Note the word game…
DPI market is an important market, that is estimated to increase with the years. … Since the network become more and more sophisticated.

30. DPI Engine – Complicated Challenge
DPI engine is considered a system bottleneck in many of todays MBs (30%-80%) [Laboratory simulations over real deployments of Snort and ClamAV]
Hundreds of academic papers over recent years
scalability
throughput
latency
power
resiliency
updates
compression

31. Major Challenges A well-studied problem in Computer Science
but with no sufficient solutions to current demands.
Scalability:
Rate - greater than 10 or even 100 Gbps
Memory - handling thousands of patterns
Handling non clear-text traffic
Compressed traffic
Security of the DPI itself:
resilient to Distributed Denial of Service (DDoS) attack
Opportunities: DPI in Software Defined Networks(SDN) and Network Function Virtualization(NFV)
So why there are still challenges in DPI. It seems like a…
The two revaluations impact how we designing middleboxes.
More over many people believe that SDN will push DPI makert forward. SDN enables treating cleverly flows, and provides new cabilities to route and manage them. Hence as a first step you will want to classify the flow using DPI.

32. Our Solution: DPI as a Service
Benefits:
Innovation – Lower entry barriers
Rich DPI functionality – Invest once for all MB
Reduced costs – Cheaper MB HW/SW
Improved performance - Scan each packet once
Our solution is to use a single DPI engine that provides service to all network functions.
By doing so we gain: <read bullets>

33. Architecture: Distributed Data Plane (as in OpenBox)
DPI service
ID: 139; Offset: 90
ID: 14; Offset: 109
ID: 723; Offset: 201 …
Metadata
DPI Service Instance
Middlebox/Virtual NF/OpenBox Service Instance
DPI Service Instance scans incoming packets against an aggregated pattern set
Each pattern has a unique ID
Result: <Pattern ID> + <Match Offset>
Each packet may contain several pattern matches
All pattern-match results are attached to the packet
Results header size
For security apps: mostly 0B (95% normal traffic)
Upon match: 99% use less than 200B

34. Important Question: Are DPI Algorithms Scalable?
Short answer: YES!
A bit longer answer: Yes, each input byte requires single lookup regardless the number of patterns!!
String
Matching
886f1f10123a e5f79547e6ad0100bd006f c
Regex
<\x21DOCTYPE\s+[^>]*SYSTEM[^>]*>.*\x2EparseError

35. String Matching: Aho-Corasick Algorithm
Build a Deterministic Finite Automaton (basic full-table variant)
Cost Function:
1 Mem. access per input byte
More patterns may results in a moderate performance reduction
Example: {E, BE, BD, BCD, CDBCAB, BCAA} s0 s7
s12 s1 s2 s3 s5 s4
s14
s13 s6 s8 s9
s10
s11 s0 B E C D C E D B A s2 s5
cache
main mem. s6 s9 B
The standard algorithm for exact string matching in DPI is Aho-Corasick
Its idea is to build a Deterministic Finite Automaton that when traversing it we recognize patterns
Each state corresponds to the longest prefix, that is the suffix of the current input
To build the automaton one builds a trie over the alphabet and it should contain all possible transitions
Usually, the automaton remains in the higher levels, under real-life traffic (about 10% of the states, 85% of the time)
s10
s11
Input: BCDBCAB
s12

36. Pattern Set Aggregation
This example shows pattern set aggregation
Pattern set 1
Pattern set 2
Both sets
Pattern Set 1
Pattern Set 2

37. Important Benefit: Address major challenges only once, by experts in DPI

38. Complexity DoS Attack Over NIDS
Regular operation
2 Steps attack:
normal
malicious
Attacker
heavy
Malicious packets aim to hurt the application
NIDS should be able to deal with them with no degradation in performance
Heavy packets aim to hurt the NIDS
They will do nothing to the application
1. Kill IPS/FW
We present "heavy" packets
Exploit the gap between the average and worst case performance
Internet
2. Launch original attack (e.g., steal credit cards)

39. Attack on Security Elements
Combined Attack: DDoS on Security Element exposed the network – theft of customers’ information

40. Deep Packet Inspection: the environment
High Capacity
Slow Memory
(D)RAM
Locality-based
Low Capacity
Fast Memory
Cache
Memory
In reality, in security middleboxes ,most memory accesses are done to the cache.
BUT
One can attack the implementation by reducing its locality, getting it out of cache - and making it much slower!
The environment we work in is…

41. Attack on Snort
Yehuda Afek, Anat Bremler-Barr, Yotam Harchol, David Hay, Yaron Koral, “MCA^2: Multi-Core Architecture for Mitigating Complexity Attacks”, in ACM/IEEE ANCS, 2012.

42. Detecting heavy packets
Solution Outline
Detecting heavy packets
NIC
Core #1 Q
Core #2 Q
Processor Chip
Core #8 Q
Dedicated Core B B Q B
Dedicated Core
Yehuda Afek, Anat Bremler-Barr, Yotam Harchol, David Hay, Yaron Koral, “Making DPI engines reslient to algorithmic complexity attacks”, in ACM/IEEE Transactions on networking, 2016. Q B

43. Conclusions
Network functions are currently a real challenge in large scale networks
OpenBox decouples the data plane processing from network function control logic and:
Reduces costs
Enhances performance
Improves scalability
Increases reliability
Provides multi-tenancy
Allows easier innovation
OpenBox
Applications
NB API
OpenBox
Controller
OpenBox Protocol
Control Plane
Data Plane
OpenBox Service Instances

44. Thank You! Questions? Play with OpenBox on a Mininet VM:
github.com/OpenBoxProject/openbox-mininet

45. THE END