Trusting SDN. Brett Sovereign Trusted Systems Research National Security Agency 28 October, 2015

Transcription

1 Trusting SDN Brett Sovereign Trusted Systems Research National Security Agency 28 October, 2015

2 Who I am 18 years experience in Cryptography, Computer and Network Security Currently work at Trust Mechanisms, Trusted Systems Research Group, National Security Agency Research areas: providing assurance to SDN and IoT architectures. Previously NSA/IAD Visiting Professor to Coast Guard Academy 2

3 SDN Definition The physical separation of the network control plane from the forwarding plane, and where the control plane controls several devices. Ref: opennetworking.org Key characteristics: Well-defined open standard API connects the data plane with the control plane. Network is controlled by software running on regular servers. 3

4 SDN Architecture North Bound Links South Bound Links Apps Apps Apps SDN Controller Application Layer Control Layer (Control Plane) OpenFlow Protocol Net Device Net Device Net Device Net Device Net Device Infrastructure Layer (Data Plane) 4

5 Example application:wireless Mobility See host sending traffic at new location Modify rules to reroute the traffic 5

6 Some general SDN Applications Seamless mobility and migration Server load balancing Full network utilization Dynamic access control Using multiple wireless access points Adaptive traffic monitoring (blocking DoS) Network virtualization/orchestration Steering traffic through middleboxes 6

7 SDN!= OpenFlow Network device management standards existed before OpenFlow! OpenFlow s origin as an API to the dataplane differentiates it from snmp, netconf, ovsdb, etc. Vendors have also developed alternatives/supplements to OpenFlow. (Cisco OpFlex) Overlay networks such as vxlan, STT, can be used to provide a programmable virtual network. 7

8 Issues with using SDN Multiple OpenFlow functions Two separate applications (load balancer and firewall) might conflict Early OF controllers required careful rewrite of two applications for safe composition. Later controllers automate/abstract this work. Network interoperability Many characteristics of Southbound connection not well defined either. 8

9 Issues with using SDN cont. OF network devices require a continuous control connection to work fail secure and fail standalone defined Failover or cluster of controllers needed Most work done for cloud/virtualization infrastructure software switches as much as hardware. 9

10 Security Issues Control Plane/Channels own the network in one step: SDN controllers and applications are software on a regular server. Single point of failure allowing control and reconnaissance of the entire network. SDN Applications can be malicious or buggy. MiTM on Northbound interface can be almost as useful to attacker. 10

11 Security Issues (continured) All SDN architectures are hybrid! Switch provisioning and discovery protocols such as LLDP and ONIE used for orchestration. Not specified in OpenFlow, but needed for SDN function. This is a potential avenue for compromise. Security functionality Relying on SDN-controlled flows to enforce traffic going through inspection and access control requires trust in the application and control software. 11

12 SDN Research: Application access control / Root of Trust Access control mechanisms on SDN controllers OpenDaylight and ONOS. Applications are authenticated and assigned control/monitor privileges. Based on SRI SEFloodlight work (Securing the Software-Defined Network Control Layer, Porras, Cheung, Fong, Skinner, Yegneswaran) Establishing a Root of Trust to Network Devices 12

13 Modular Controller Applications A module for each task Platform translates to protocol Monitor Route FW LB Compilation/Security Enforcement Controller OpenFlow, et al. Easier to program, test, and debug Greater reusability and portability 13

14 Conclusion SDN is a moving target Many L2/L3 network capabilities being tested and realized Security of control channel, controller, apps, problematic Enables programmable network management 14

15 15