SDN Security Design Challenges

Transcription

1 Nicolae Paladi SDN Security Design Challenges SICS Swedish ICT! Lund University In Multi-Tenant Virtualized Networks

2 Multi-tenancy Multiple tenants share a common physical infrastructure.

3 Multi-tenancy A tenant corresponds to a customer using a particular virtual network. Organization A

4 Multi-tenancy Tenants may belong to different administrative domains. Organization A Organization B

5 Multi-tenancy Tenants expect network isolation of their domain. Domain B Domain A

6 Multi-tenancy Physical resource sharing is fully abstracted, with tenants unaware of other neighbours. Tenant A Tenant B Tenant C

7 Multi-tenancy Tenants may create multiple distinct virtual network instances and topologies.

8 Network Slicing A. Bandwidth B. Topology C. Traffic D. Device CPU E. Forwarding tables (aka forwarding information base)

9 Software Defined Networking A network architecture which decouples the network forwarding functionality from the control and management logic!

10 SDN System Model Management applications are used by network administrators to express their network configuration goals using a set of high-level comments. May include components such as firewalls, intrusion detection systems, traffic shapers, etc. Control plane is a logically distributed abstraction layer that transforms high-level network operator goals into discrete routing policies based on a global network view. Southbound API is a vendor-agnostic set of instructions implemented by the routing equipment on the data plane. The data plane contains both hardware and software rout- ing equipment. This component implements the routing policies that satisfy the goals of the network administrator. Management Applications Network Hypervisor Global network view Network Operating System (e.g. NOX, Rosemary, etc.) Southbound API

11 Scenario

12 Scenario Large-scale enterprise network infrastructure (e.g. one or multiple datacenters)! Multiple tenants share the virtualised infrastructure! Tenants set up their own topology! Provider allocates quotas, manages routing, handles conflicts and service disruptions

13 SDN Adversarial Model Who is the adversary?! What are the capabilities of the adversary?! What are the threat vectors?

14 Security of SDN infrastructure! vs.! Security capabilities enabled by SDN

15 Security of SDN infrastructure! vs.! Security capabilities enabled by SDN

16 Adversarial Model Assumptions Assume hardware integrity Assume physical security Assume cryptographic security

17 Adversary Capabilities Overhear, intercept, and synthesise messages. Analyse the traffic patterns in the network Disrupt or degrade network connectivity. Send valid tenant packages with an arbitrary content and frequency to the components it can reach. Attempt to impersonate other tenants. Install arbitrary management applications and issue policies within its network domain. Attempt to decrypt intercepted network traffic that is sent and received by other tenants. Attack the network communication of the SDN-based infrastructure. Attempt to impersonate network infrastructure components. Issue malicious policies aiming to either monitor, distort or disrupt network traffic. Attempt to decrypt intercepted network traffic that is sent and received by other network infrastructure components.

18 Attack Vectors A.Vulnerabilities in the control plane B. Attacks on control plane communications C. Lack of a trust chain between the management applications and the data plane D. Attacks on policies and rules in programmable networks E. Resource limit violations F. Attacks on virtual switches and network gateways G. Weak bandwidth isolation as attack vehicle Management Applications Network Hypervisor Global network view Network Operating System (e.g. NOX, Rosemary, etc.) Southbound API C E A/B/C D F/G

19 Security Requirements A: Access control model to limit effect of vulnerabilities in controllers. A: Policy verification prior to deployment. B: Authenticated communication between control plane components; secure enrolment mechanism for management applications and data plane devices. C: Traceability and non-repudiation for all configuration commands and policies issued by network management applications. D: A mechanism for network policy isolation, such that the effects of policies in a certain tenant domain have no effect on other domains. Management Applications Network Hypervisor Global network view Network Operating System (e.g. NOX, Rosemary, etc.) Southbound API C E A/B/C D F/G

20 Security Requirements (continued) D: New network management policies must run through an integration verification engine prior to deployment. E: Mechanism to ensure that network management applications do not allocate resources beyond the assigned quota. F: Verified integrity of virtual network components prior to deployment; keys protected with a hardware root of trust. G: Policy-based routing decisions immune to vulnerabilities in bandwidth isolation between tenants. G: Software and hardware network components must offer equally strong bandwidth isolation properties. Management Applications Network Hypervisor Global network view Network Operating System (e.g. NOX, Rosemary, etc.) Southbound API C E A/B/C D F/G

21 Upcoming Work (Setting up the infrastructure) 1. Integrity verification of virtual network components prior to deployment.! 2. Authenticated communication between control plane components.! 3. Secure enrolment mechanism for management applications and data plane devices.! 4. Configuration policy grammar suitable for integration verification.

22 Upcoming Work (Ramping up security guarantees) 1. Access control model for network operating systems.! 2. Additional mechanisms for quota enforcement and monitoring.! 3. Scalable model-based policy integration verification prior to deployment on data plane. Bodiam Castle

23 Recommended Reading A. Greenberg, G. Hjalmtysson, D. A. Maltz, A. Myers, J. Rexford, G. Xie, H. Yan, J. Zhan, and H. Zhang, A clean slate 4D approach to network control and management, ACM SIGCOMM Computer Communication Review, vol. 35, no. 5, pp , M. Casado, M. J. Freedman, J. Pettit, J. Luo, N. McKeown, and S. Shenker, Ethane: taking control of the enterprise, in ACM SIGCOMM Computer Communication Review, vol. 37, pp. 1 12, ACM, M. Casado, N. Foster, and A. Guha, Abstractions for software-defined networks, Communications of the ACM, vol. 57, no. 10, pp , N. Gude, T. Koponen, J. Pettit, B. Pfaff, M. Casado, N. McKeown, and S. Shenker, NOX: towards an operating system for networks, ACM SIGCOMM Computer Communication Review, vol. 38, no. 3, pp , T. Koponen, M. Casado, N. Gude, J. Stribling, L. Poutievski, M. Zhu, R. Ramanathan, Y. Iwata, H. Inoue, T. Hama, et al., Onix: A Distributed Control Platform for Large-scale Production Networks., in OSDI, vol. 10, pp. 1 6, P. Porras, S. Shin, V. Yegneswaran, M. Fong, M. Tyson, and G. Gu, A security enforcement kernel for OpenFlow networks, in Proceedings of the first workshop on Hot topics in software defined networks, pp , ACM, S. Shin, Y. Song, T. Lee, S. Lee, J. Chung, P. Porras, V. Yegneswaran, J. Noh, and B. B. Kang, Rosemary: A Robust, Secure, and High- Performance Network Operating System, in Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security, pp , ACM, D. Kreutz, F. Ramos, and P. Verissimo, Towards secure and dependable software-defined networks, in Proceedings of the second ACM SIGCOMM workshop on Hot topics in software defined networking, pp , ACM, Lasserre, M., et al. Framework for Data Center (DC) Network Virtualization. No. RFC Hartman, S., Zhang, D., Wasserman, M., Qiang, Z., Mingui, Z. Security Requirements of NVO3, draft-ietf-nvo3-security-requirements-04.