HEX Switch: Hardware-assisted security extensions of OpenFlow - - PowerPoint PPT Presentation

HEX Switch: 


Hardware-assisted security extensions of OpenFlow

Taejune Park / KAIST / taejune.park@kaist.ac.kr Zhaoyan Xu / StackRox Inc. / z@stackrox.com Seungwon Shin / KAIST / claude@kaist.ac.kr

/36

Software-Defined Networking

• Centralized management
• Dynamic traffic engineering
• Programable network operation
• High-compatibility with

virtualized environments

2

/36

Software-Defined Networking

• Centralized management
• Dynamic traffic engineering
• Programable network operation
• High-compatibility with

virtualized environments

Security is still required

3

/36

Security in Software-Defined Networking

Data-Plane Layer Control-Plane Layer Network Application Network Application Network Application Network Control Apps.

Standard Protocol (e.g., OpenFlow)

Security Apps. Network Application Network Application Security Application Middle-box

4

/36

Security in Software-Defined Networking

Data-Plane Layer Control-Plane Layer Network Application Network Application Network Application Network Control Apps.

Standard Protocol (e.g., OpenFlow)

Security Apps. Network Application Network Application Security Application Middle-box

• Security applications on a control plane
• Applying security features network-widely
• Cheap price
• Easy to manage

5

/36

Security in Software-Defined Networking

Data-Plane Layer Control-Plane Layer Network Application Network Application Network Application Network Control Apps.

Standard Protocol (e.g., OpenFlow)

Security Apps. Network Application Network Application Security Application Middle-box

• Security applications on a control plane
• Applying security features network-widely
• Cheap price
• Easy to manage

6

• Limitation
• Simple security only available
• Slow-path for inspection
• Controller overhead

/36

Security in Software-Defined Networking

Data-Plane Layer Control-Plane Layer Network Application Network Application Network Application Network Control Apps.

Standard Protocol (e.g., OpenFlow)

Security Apps. Network Application Network Application Security Application Middle-box

• Middle-boxes on a data plane
• Better performance
• Rich features such as payload inspection
• No controller overhead

7

/36

Security in Software-Defined Networking

Data-Plane Layer Control-Plane Layer Network Application Network Application Network Application Network Control Apps.

Standard Protocol (e.g., OpenFlow)

Security Apps. Network Application Network Application Security Application Middle-box

• Middle-boxes on a data plane
• Better performance
• Rich features such as payload inspection
• No controller overhead

8

• Limitation
• Network overhead by traffic detouring (Taking extra hops)
• Require flow steering for NFs
• Additional control channels for NFs

/36

Summary

Category SDN Applications Middle-boxes

Flexibility Management Deployability Performance Functionality

9

/36

Related works: 
 Extending SDN architecture to support security

• Mekky, Hesham, et al. "Network function

virtualization enablement within SDN data plane.” IEEE INFOCOM 2017 (Also, HotSDN 2014)

• Sonchack, John, et al. "Enabling Practical

Software-defined Networking Security Applications with OFX." NDSS 2016.

10

/36

Related works: 
 Extending SDN architecture to support security

• Mekky, Hesham, et al. "Network function

virtualization enablement within SDN data plane.” IEEE INFOCOM 2017 (Also, HotSDN 2014)

• Sonchack, John, et al. "Enabling Practical

Software-defined Networking Security Applications with OFX." NDSS 2016.

11

• Their security functions are not fully consolidated

into a data plane

• Application module, Tap-based interface…

/36

Related works: 
 Extending SDN architecture to support security

• Mekky, Hesham, et al. "Network function

virtualization enablement within SDN data plane.” IEEE INFOCOM 2017 (Also, HotSDN 2014)

• Sonchack, John, et al. "Enabling Practical

Software-defined Networking Security Applications with OFX." NDSS 2016.

12

• In essence, they are NOT different from the middle-box structure!
• It's just a scale down!

/36

Related works: UNISAFE: A union of security actions for software switches

• Fully integrated security functions into a data plane, not modular one
• Security functions as a set of OpenFlow actions

UNISAFE (based on Open vSwitch) Lookup Flow table Execute actions Security actions Flow table

MATCH Actions Flow_A sec_dos(mbps=100), output:2 Flow_B sec_dos(mbps=500),sec_scan(…),output:3 Proceedings of the 2016 ACM International Workshop on Security in Software Defined Networks & Network Function Virtualization. ACM, 2016

13

/36

Security actions of UNISAFE

• High-compatibility with common OpenFlow actions
• actions=sec_dos(mbps=1000),set_nw_src(…),output:2
• Fine-grained security enforcement per a flow
• in_port=1,nw_src=10.0.0.1,tp_dst=80,actions=sec_dos(…),…
• in_port=2,nw_dst=10.0.1.2,actions=sec_dpi(…),…
• Easy configuration for a security service chaining
• actions=sec_dos(…),sec_scan(…),sec_dpi(…),…

14

/36

Performance in UNISAFE

• Achieve line-rate latency for all security
• But, lack of throughput in some actions
• Payload Inspection (DPI) throughput
• Throughput less than 100Mbps on 1Gbps

Bandwidth(Mbps) 1 10 50 100 500 1000 Throughput(%) 10 20 30 40 50 60 70 80 90 100 110 Throughput forwarding dos scan1 scan5 dpi100 dpi500 dpi1000

15

/36

Performance in UNISAFE

• Achieve line-rate latency for all security
• But, lack of throughput in some actions
• Payload Inspection (DPI) throughput
• Throughput less than 100Mbps on 1Gbps

Bandwidth(Mbps) 1 10 50 100 500 1000 Throughput(%) 10 20 30 40 50 60 70 80 90 100 110 Throughput forwarding dos scan1 scan5 dpi100 dpi500 dpi1000

16

Challenge 1: Performance limitation

/36

• Manual operation for security violations by an administrator

Security operation in UNISAFE

17

Manual Operation Controller

?

/36

• Manual operation for security violations by an administrator

Security operation in UNISAFE

18

Manual Operation Controller

?

Challenge 2: Security operation

/36

HEX Switch: 
 Hardware-assisted security extensions of OpenFlow

• Hardware-based approach for UNISAFE
• Using NetFPGA
• Providing line-rate performance with configurability

19

Security Actions Security Policy Controller 
 communication

/36

Design

• Security Processor between the packet processing sequence.
• Six-stages pipeline: Mainly consist of data storage and inspection logic
• Flow table controller forwards flow keys, stats and action key after matching

20

Packet preprocessor

• Intf. 0
• Intf. 1
• Intf. 2
• Intf. 3

Host Intf. Flow Table Controller < HEX Security Processor > Buffering (Input selection)

Read Data Storage Update Data Storage

Inspection

• Intf. 0
• Intf. 1
• Intf. 2
• Intf. 3

Host Intf. Action processor

F l

• w

k e y Packet

Packet buffer

Input

• utput

Data Storage (BRAM)

A l e r t M s g

F l

• w

k e y , s t a t s & A c t i

• n

k e y Stage 1 Stage 2 Stage 3 Stage 4-5

Input Arbiter + Output queue Policy Decision (Forwarding)

Stage 6

/36

Design

• Security Processor between the packet processing sequence.
• Six-stages pipeline: Mainly consist of data storage and inspection logic
• Flow table controller forwards flow keys, stats and action key after matching

21

Packet preprocessor

• Intf. 0
• Intf. 1
• Intf. 2
• Intf. 3

Host Intf. Flow Table Controller < HEX Security Processor > Buffering (Input selection)

Read Data Storage Update Data Storage

Inspection

• Intf. 0
• Intf. 1
• Intf. 2
• Intf. 3

Host Intf. Action processor

F l

• w

k e y Packet

Packet buffer

Input

• utput

Data Storage (BRAM)

A l e r t M s g

F l

• w

k e y , s t a t s & A c t i

• n

k e y Stage 1 Stage 2 Stage 3 Stage 4-5

Input Arbiter + Output queue Policy Decision (Forwarding)

Stage 6

Flow Table Controller

/36

Design

• Security Processor between the packet processing sequence.
• Six-stages pipeline: Mainly consist of data storage and inspection logic
• Flow table controller forwards flow keys, stats and action key after matching

22

Packet preprocessor

• Intf. 0
• Intf. 1
• Intf. 2
• Intf. 3

Host Intf. Flow Table Controller < HEX Security Processor > Buffering (Input selection)

Read Data Storage Update Data Storage

Inspection

• Intf. 0
• Intf. 1
• Intf. 2
• Intf. 3

Host Intf. Action processor

F l

• w

k e y Packet

Packet buffer

Input

• utput

Data Storage (BRAM)

A l e r t M s g

F l

• w

k e y , s t a t s & A c t i

• n

k e y Stage 1 Stage 2 Stage 3 Stage 4-5

Input Arbiter + Output queue Policy Decision (Forwarding)

Stage 6

Read Data Storage Update Data Storage

Data Storage (BRAM)

/36

Design

• Security Processor between the packet processing sequence.
• Six-stages pipeline: Mainly consist of data storage and inspection logic
• Flow table controller forwards flow keys, stats and action key after matching

23

Packet preprocessor

• Intf. 0
• Intf. 1
• Intf. 2
• Intf. 3

Host Intf. Flow Table Controller < HEX Security Processor > Buffering (Input selection)

Read Data Storage Update Data Storage

Inspection

• Intf. 0
• Intf. 1
• Intf. 2
• Intf. 3

Host Intf. Action processor

F l

• w

k e y Packet

Packet buffer

Input

• utput

Data Storage (BRAM)

A l e r t M s g

F l

• w

k e y , s t a t s & A c t i

• n

k e y Stage 1 Stage 2 Stage 3 Stage 4-5

Input Arbiter + Output queue Policy Decision (Forwarding)

Stage 6

Inspection

/36

Security Action Processing

• All security actions are performed in parallel
• Forward the data storage data to inspection logic through the wide data bus.
• Challenge
• Pattern list for payload inspection


requires width bandwidth => Transfer the address first 
 and read directly memory


24

Scanning Inspection Logic DoS Inspection Logic Anomaly Inspection Logic Read Pkt. Payload Deep Packet Inspection Logic

Data storage

F l

• w

K e y , S t a t s & A c t i

• n

K e y

HEX Action Input Selector

Wide Data Bus

Address of large data Pattern list

/36

After Processing: Applying Policy

• Actions can handle violated packets according to a policy
• e.g., actions=sec_dos(mbps=1000,policy=redirect:2)

=> If the current bps exceeds 1000 Mbps, redirect the flow to port 2.

• Four polices
• Neglect: Ignores the violation
• Alert: Send an alert msg to a controller
• Discard: Terminates the packet processing 


and drop the packet

• Redirect: Forward packets 


to an alternative port

25

Policy handler

Discard Alert Redirect

Inspection Logic

/36

[HEX Switch]

Processing Sequence (abbreviated)

[Host Software]

Msg Handler

OpenFlow Parser / Flow table Mgmt.

OpenFlow Protocol Device Driver

<Registers>

Flow Table Registers To Controller Others... (stats, ctrl, …) Flow Table Controller Read

• Msg. Registers

HEX Security Processor

Communication with a controller

• By the host device with its software
• The host device and the HEX switch are bound by the device driver

Host device and software Device driver

26

/36

[HEX Switch]

Processing Sequence (abbreviated)

[Host Software]

Msg Handler

OpenFlow Parser / Flow table Mgmt.

OpenFlow Protocol Device Driver

<Registers>

Flow Table Registers To Controller Others... (stats, ctrl, …) Flow Table Controller Read

• Msg. Registers

HEX Security Processor

Communication with a controller: Transferring an alert message

• The device driver reads the registers and the HEX handler transfers it to a controller

through a OpenFlow channel

• A controller provides a handler API to process the alert message

27

/36

Communication with a controller: Deploying security actions:

• The security actions are deployed by flow_mod messages
• Security actions are compatible with common OpenFlow actions

28

[HEX Switch]

Processing Sequence (abbreviated)

[Host Software]

Msg Handler

OpenFlow Parser / Flow table Mgmt.

OpenFlow Protocol Device Driver

<Registers>

Flow Table Registers To Controller Others... (stats, ctrl, …) Flow Table Controller Read

• Msg. Registers

HEX Security Processor

/36

Challenge in flow-level security deployment

• The flow-level security cannot represent a security policy across multiple flows
• Simple example:

HEX Switch (Capacity: 1000Mbps) Flow A 800Mbps Flow B 700Mbps Flow A Flow B Actions Flow A sec_dos(mbps=1000),output:1 sec_dos(mbps=1000),output:2 Match Flow B

The total incoming bandwidth from Flow A/B evidently exceeds 1000 Mbps,
 but the DoS detectors never trigger an alert!

29

/36

… Actions C B

sec_xyz (id = 10, …)

Match

sec_xyz (id = 10, …)

A …

sec_xyz (id = 10, …)

sec_xyz

Action Clustering

• Security actions have a cluster ID in their parameter
• The actions that use the same cluster ID are considered to belong to the same cluster
• The clustered action works as the integrated single action across different flow rules
• Implementing by sharing the data storage by the cluster map

30

Data Storage

A c t i

• n

k e y & C l u s t e r I D s

DoS Action Cluster Map Hash Hash

… … 5555,6666 Data 0xBB Address 3333,4444 0xAA 0xCC 1111,2222

DPI Action Cluster Map

… … @DPI_30 Data 0xFF Address @DPI_20 0xEE 0x11 @DPI_10

Data storage Distributor

aaaa Patterns 2 Num patterns 1 … vulnerable bbbb Patterns 2 Num patterns 1 … vulnerable list Patterns 2 Num patterns 1 … vulnerable

DPI_10

Build Bus Data

U p d a t e D a t a

/36

• Applying the action clustering to the previous example

DoS detector can successfully detect the bandwidth excess and alert this.

HEX Switch (Capacity: 1000Mbps) Flow A 800Mbps Flow B 700Mbps Flow A Flow B Actions Flow A sec_dos(mbps=1000,id=10),… sec_dos(mbps=1000,id=10),… Match Flow B

Applying Action Clustering

700 + 800

ID

… 10 Data …

DoS Data section

Flow A 800Mbps Flow B 700Mbps

DoS Inspection logic

Detected

(Mbps > 1000) ? true : false

31

/36

Implementation

• NetFPGA-1G-CML
• Based on Reference NIC 


and OpenFlow switch
 from the NetFPGA project
 (https://github.com/NetFPGA)

• Support DoS Detector 


and Deep Packet Inspector 
 (Payload inspector)

32 JTAG via 5-pin USB Power cable Power switch Intf 0 Intf 1 Intf 2 Intf 3 PCIe Gen2 x4

/36

Evaluation

• Measure throughput and latency

1) Performance of the HEX switch 2) Performance of simple forwarding by the normal OpenFlow switch 3) Performance of OVS based implementation (i.e., UNISAFE)

33

HEX Switch

h1

1 GbE 1 GbE

h2

1 GbE 1 GbE

OpenFlow Switch (NetFPGA-1G-CML)

h1

1 GbE 1 GbE

h2

1 GbE 1 GbE

Reference NIC (NetFPGA-1G-CML)

h1

1 GbE 1 GbE

h2

1 GbE 1 GbE

OVS (UNISAFE)

/36

Evaluation Result

• Throughput

20 40 60 80 100 200 400 600 800 1000 Throughput (%) Bandwidth (Mbps) HEX (DoS+DPI) Native O.F. OVS simple OVS DoS OVS DPI 20 40 60 80 100 200 400 600 800 1000 Throughput (%) Bandwidth (Mbps) 0.2 0.4 0.6 0.8 1 0.2 0.25 0.3 0.35 0.4 0.45 CDF Latency (ms) HEX (DoS+DPI) Native O.F. OVS simple OVS DoS OVS DPI

• Latency

34

HEX & Simple Fwd. UNISAFE HEX & Simple Fwd. UNISAFE

/36

Conclusion

• The HEX switch that embeds security functions
• Using NetFPGA
• As as a set of actions
• Support security policy and controller APIs
• Achieves line-rate performance without overhead.

35

Thank you! Questions?