sfa: stateful forwarding abstraction in sdn data plane
TRANSCRIPT
Towards a Reliable SDN Firewall
Hongxin Hu Delaware State University
Gail-Joon Ahn, Wonkyu Han and Ziming Zhao
Arizona State University
2
SDN Security Apps
Existing security appliances have to be
re-designed and implemented as
compatible SDN applications
Firewall
IDS/IPS
DDoS detection
Scan detection
and more…
17:12
SDN Controller
FW IDS/IPS DDoS
3
Challenges in Building SDN Firewalls
Examining Dynamic Network Policy Updates
A traditional firewall is only a packet filter
An SDN firewall is both
A Packet Filter (flow packet violation)
– The first packet of each flow goes through the controller and is filtered
by the firewall
– The subsequent packets of the flow directly match the flow policy
A Policy Checker (flow policy violation)
– Existing flow policies may violate the firewall policy
Flow policy update
Firewall policy update
Flow policies can be proactively installed in the switches
17:12
4
Challenges in Building SDN Firewalls (cont’d)
Checking Indirect Security Violations
Firewalls can be bypassed
Dynamic packet modification
– OpenFlow allows an action, Set-Field, which can
rewrite the values of respective header fields in
flow packets
E.g. a load balancer may need to dynamically change
flow paths
Rule dependency
– Flow and firewall rules may overlap each other
17:12
5
Challenges in Building SDN Firewalls (cont’d)
Architecture Option
Centralized SDN firewall
Firewall policy is centrally defined and enforced at the
controller
Limitation: cannot deal with partial policy violations
Distributed SDN firewall
Firewall policy is defined centrally, but propagated and
enforced at each individual flow entry (ingress switch)
Limitation: needs a complicated revocation and
repropagation mechanism to handle dynamic policy
updates
17:12
6
State Of The Art
SDN Firewall App
Built-in firewall application in Floodlight
Limited to check flow packet violations and unable to examine flow
policy violations
Policy Conflict Detection and Resolution
VeriFlow [Khurshid’13] and NetPlumber [Kazemian’13]
Lack of automatic, effective and real-time violation resolution
Pyretic [Monsanto’13]
Cannot discover and resolve indirect security violations
FortNOX [Porras’12]
Only conducts pairwise conflict analysis without considering rule
dependencies in flow tables and firewall policies
17:13
8
Violation Detection
Flow Path Space Analysis
Flow tracking (NetPlumber [Kazemian’13])
Dynamic packet modification
Rule dependency
Flow path space calculation
Incoming space
Outgoing space
Tracked space
17:13
9
Violation Detection (cont’d)
Firewall Authorization Space Partition
Decouple dependency relations between
“allow” rules and “deny” rules in the firewall
policy
Denied authorization space
Allowed authorization space
17:13
10
Violation Detection (cont’d)
Space Comparison
Compare Tracked Flow Space against Firewall Denied Authorization Space
Entire Violation
– Denied authorization space includes whole tracked space
Partial Violation
– Denied authorization space partially includes tracked space
17:13
12
Implementation & Evaluation
Prototype of FlowGuard
Floodlight V 0.90
Evolution Environment
Real-world network topology
Stanford backbone network [kazemian’13]
Mininet 2.0
Violation Detection and Resolution
Table 1: Detection and resolution elapsed time (ms) for different resolution strategies
17:13
14
On-going Work
Investigate a more sophisticated flow
tracking mechanism
Implement stateful SDN firewalls
Design a high-level policy language for SDN
firewalls
Develop various toolkits for visualization,
optimization, migration, and integration of
SDN firewalls
17:13