Securing the Software-Defined Network Control Layer

Transcription

1 Securing the Software-Defined Network Control Layer Speaker: Yuyan Lin 2017/5/9 P. Porras, S. Cheung, M. Fong, K. Skinner, and V. Yegneswaran, Securing the Software Defined Network Control Layer, In NDSS, pp.1-15, 2015.

2 Outline Introduction Challenge Design Conclusion

3 Introduction the SDN community lacks a secure control-layer to manage the interactions between the application layer and the switch infrastructure security extensions at the control layer to provide the security management and arbitration of conflicting flow rules that arise when multiple applications are deployed within the same network

4 Introduction We present a prototype of our design as a Security Enhanced version of the widely used OpenFlow Floodlight Controller, which we call SE-Floodlight SE-Floodlight extends Floodlight with a securityenforcement kernel (SEK) layer, whose functions are also directly applicable to other OpenFlow controllers

5 Introduction SEK : authentication service role-based authorization permission model for mediating all configuration change requests to the data-plane inline flow-rule conflict resolution security audit service

6 Outline Introuduction Challenge Design Conclusion

7 challenge Challenge 1: Application Co-existence

8 challenge Google s OpenFlow-based B4 private WAN network manager

9 challenge Challenge 2: Flow Constraints vs. Flow Circuits Set action empowers apps to instruct a switch to rewrite the header attributes of a matching flow Output to table indicates that once the set operation is performed, the result should continue evaluation among the remaining flow rules

10 challenge Challenge 3: An Application Permission Model In addition to creating flow rules, OpenFlow provides apps with a wide range of switch commands and probes. For example, applications may reconfigure a switch in a manner that changes how the switch processes flow rules. While network operators might choose to run a third party OF app, OpenFlow offers them no ability to constrain which commands and requests the apps will issue to the switch

11 challenge Challenge 4: Application Accountability The absence of design considerations for multi-app support in OpenFlow also results in a lack of ability for the control layer to verify which app has issued which flow rule

12 challenge Challenge 5: Privilege separation privilege separation dictates that the element responsible for security mediation should operate independently from those elements it mediates. Thus, for the OpenFlow control layer to operate as a truly independent mediator, applications should not be instantiated in the same process context as the controller.

13 Northbound API Northbound API : an API defined to transmit messages between the OpenFlow application and control layers, where each operates in a separate process context The most unique and important aspect of this Northbound API specification is its ability to assign an authenticated application credential to every OpenFlow message that passes through the API.

14 Outline Introduction Challenge Design Conclusion

15 Designing an openflow mediation policy

16 Designing an openflow mediation policy APP :intended primarily for (non-security-related) traffic engineering applications, and provides sufficient permissions for most such flow-control applications. SEC :intended for applications that implement security services ADMIN : intended for applications such as the operator console app.

17 Designing an openflow mediation policy Global read represents data-plane events that are streamed to all interested applications who care to receive them Selected read operations refer to individual events for which an application can register through the controller to receive switch state-change notifications Permission :perform direct alterations to the network flow policies implemented by the switch, or enable the operator to control switch configuration or to test switch accessibility

18 Design of a secure control mediation layer

19 Design of a secure control mediation layer

20 Conflict Detection and Resolution OpenFlow rule r

21

22 RCA Algorithm Step 1: Testing for direct conflict Step 2: Detect a tail(head)-chaining candidate rule Tail chaining occurs with a resident rule, r, when r.action ==O_t and r.set mods matches rc.criteria (the criteria of our candidate rule). Head Chaining is the complementary case, where rc.action == O_t and rc.set mods matches r.criteria. Step 3: Chained rule conflict analysis Matching Precedence Policy

23 Test case: Rule rejection due to insufficient priority

24 Security audit service Ndb : postcard-based strategy NetSight : tracking packet traversal history through the network SE-Floodlight :tracking all security-relevant events which are visible to the control plane

25 Performance evalution

26 Outline Introduction Challenge Design Conclusion

27 conclusion Introduce the notion of OF-app security roles Rule-chain Conflict Analysis algorithm Northbound API that provides authenticated per-message credentials application-layer audit subsystem