Welcome to CrossProject OpenDaylight Security Analysis Page

Please note that information on this page may not be representative of the latest release of OpenDaylight. It is planned for a refresh to the current release of Nitrogen.

Introduction

The OpenDaylight security analysis captures what security features are present in OpenDaylight today. In addition, it provides some recommendations for security enhancements.

OpenDaylight Controller Security

Overall Controller Security

Controllers can theoretically be used to do anything, hence their compromise could have potentially endless threat implications. First and foremost, controllers, need to be secure, both physically and logically. This will require the controller technology, itself, to mature from a security standpoint, as well as IT personnel taking precautionary measures during deployments.

Security to controller occurs at multiple layers. The following sections capture what exists on OpenDayLight controller today and recommendations to increase security at different layers.

Controller Load/Runtime

The current unit of OpenDaylight deployment is OSGi bundles. Bundles provide some level of isolation with explicit code boundaries and package import/exports. The recommendation is to augment this at load time with bundle signature/permission verifiers and at runtime with bundle access security. In addition, the OSGi based runtime which provides a container should not open any security loopholes.

Application Bundle Security

Recommendations for the bundle security requirements

Application bundle insertion authentication and authorization: Bundle that can be deployed should come only from trusted, verifiable sources. Bundle may specify their local permissions, the maximum privileges that they need to function. Before installing the bundle, the local permissions can be authorized with the bundle permission resource.
Post activation application bundle resource authorization: Other components that bundle can communicate with. Are they authorized? What data in the URI tree can be accessed? Does the bundle have access to program flow to the network? For example, multiple applications in the OpenDaylight controller may introduce conflicts in the flow tables. Therefore, verification of policy compliance is required to address these issues.
Auditing: Application bundle authentication/authorization should be logged.

OSGi Runtime Container Security - OpenDaylight Apache Karaf Distribution

Apache Karaf is being considered as the OSGi runtime container environment. During the April 28, 2014 Tech Work Stream conference call concern was expressed regarding the security footprint deploying ODL into Karaf represents. The following key areas were discussed:

Karaf's Remote Shutdown Port.
SSHD default presence.
Webconsole access.
External JMX connectivity.

These remote management capabilities are present in Apache Karaf by default, however they can be disable via various configuration alterations. These configuration options may be applied during the construction of the ODL-Karaf distribution. Alternatively, ODL wikidocs may provide guidance and/or links to external documentation to allow users to lock down their deployment post installation.

Apache Karaf does provide various runtime security features that should become familiar to OpenDaylight developers and administrator. General security documentation at Karaf can be found here.

Further security advice can be found in the links below:

Role based JMX administration is discussed here.
Remote SSH access configuration is discussed here.
WebConsole access is discussed here.

Disablement of the remote shutdown port can be accomplished via the following: Set karaf.shutdown.port=-1 in etc/custom.properties or etc/config.properties

OpenDaylight Controller’s Plugins Security

The document here captures the existing northbound and southbound plugins. These plugins should provide secure communication access to the controller. The following table captures the state of the plugin’s transport layer security.

Plugins	Existing Security	Recommendations
RESTCONF	HTTPS
Neutron	HTTPS
VTN Coordinator	HTTP	HTTPS
D4A Protection	HTTP	HTTPS
GUI	HTTPS
OpenDove	HTTP	HTTPS
BGP-LS/PCEP	TCP	TCP-MD5, TLS 1.2
NETCONF	SSH / TCP	SSH / TLS 1.2
OpenFlow 1.0/1.3 (openflowjava)	TCP / TLS 1.2
OpenFlow 1.0 (openflowj)	TLS 1.2
OVSDB	TCP	TLS 1.2
SNMP	SNMP v2	SNMP v3
LISP	Encrypted Map Request / Map Reply

General recommendation for the plugins is as follows

DDoS attack protection on plugin expose ports
Utilize a common crypto key storage
Support a pluggable or built-in certificate authority

AAA for External Users

From security standpoint, direct access needs to be restricted; who and how users can interact with controllers needs to be clearly defined (best practice dictates access should be limited to only those admins who absolutely need it and be authenticated and logged). Although OpenDaylight supports secure communication access via the northbound APIs, it is desirable to further harden the security by providing role based access control for the external users. The recommendations for the security requirements are

User access authentication : OpenDaylight today allows configuration of username/password.
Access protocol authorization: e.g. a user can only access via HTTPS
Services / Resource authorization: e.g. a user has access to NETCONF and subsection of URI tree under NETCONF
Auditing access/authorization: useful for incident response analysis.
Pluggable AAA service

Secure Device/Controller BootStrap, Authentication and Authorization

Today, the discovery of OpenDaylight controller and devices it controls is manual. For example, in the case of OpenFlow, the devices/switches have to be configured with the controller’s IP address. It is desirable to automatically and securely bring up integrated set of network devices and controllers.

The following is the recommendation to support the zero touch secure bootstrap requirements

Controller automatically discovers devices, assigns IP address and establishes secure IP connectivity. If routing is required to reach the devices, the routing is also automatically established.
Controller has the ability to authenticate and authorize against a device registry.
For the devices to participate in the automatic bootstrap, the devices should require minimal bootstrap software.
A southbound syslog plugin should be added to capture bootstrap log information from the devices. This log information would be useful to correlate for incident response.

Controller Clustering and Security

Clustering provides scalability and availability. It is desirable that the clustering communication channel is secure. Current ODL controller clustering is built on top of Infinispan v5.3.0 distributed-caching/data-grid platform. Infinispan uses Jgroups as a reliable messaging layer for the cluster. Jgroups currently supports UDP, TCP, and Tunnel over TCP as the three transport protocol options. In standard configurations, UDP is used as the default transport protocol that uses IP multicast for sending 1-to-many messages to the cluster. TCP is used when there are cluster nodes outside a LAN and message needs to go through a router where IP multicast does not work. 1-to-many cluster messages are sent out as multiple TCP unicast messages. Tunneling over TCP is used when there are firewalls that prevent direct communication. In such situations, it uses a standard GossipRouter outside of the firewall to intermediate message exchanges.

OpenDaylight AD-SAL clustering uses TCP as the transport for Jgroups. It is recommended to configure Jgroups AUTH and ENCRYPT support for security. For MD-SAL clustering discussions are currently in progress.

Overall Recommendations

Overall, the OpenDaylight controller should have following components to build a secure framework.

Ongoing vulnerability analysis to pinpoint security flaws that can be exploited by the attackers
- It is recommended to have a special mechanism to report security bugs/issues to OpenDaylight. For example, the approach taken by OpenStack would be suitable. link
- In addition, a vulnerability management team similar to OpenStack would be beneficial. link
Robust incident response support for controller/devices/user. A southbound syslog plugin to incorporate capture logs from devices in incident analysis.
Secure communication channel to connect to plugins. Common trusted crypto key storage for all plugins. DDoS protection on plugins expose ports. Pluggable / Built-in Certificate Authority.
AAA service for applications/users/devices
Framework to securely discover, connect and configure the devices
Secure mechanism to cluster the controller for scalability and availability

OpenDaylight Security Analysis Team

Arash Eghtesadi <aeghtesadi@inocybe.ca>
Anthony Gagliardi <anthony.gagliardi@colorado.edu>
Bryan Kirchenbauer <Bryan.Kirchenbauer@us.fujitsu.com>
Jamie Goodyear <jamie.goodyear@gmail.com>
Junhui Liu <junhui.liu@ericsson.com>
Ken Beck < kebeck@cisco.com>
Madhu Venugopal <mavenugo@gmail.com>
Meenakshi Kaushik <mekaushi@cisco.com>
Mike Geller <<mgeller@cisco.com>
Narayana Reddy <narayana1208@iiitd.ac.in>
Susanta Nanda <Susanta_Nanda@symantec.com>
Wojciech Dec <wdec@cisco.com>

References

* Security implications of Software‐Defined Networks, By Sarah Sorensen, 2012 link.
* Netconf SSH config link
* LISP security link
* Bootstrapping Key Infrastructures link
* Jgroups Community Documentation link
* OpenDaylight Clustering link