- 1 Welcome to CrossProject OpenDaylight Security Analysis Page
- 1.1 Introduction
- 1.1.1 OpenDaylight Controller Security
- 188.8.131.52 Overall Controller Security
- 184.108.40.206 Controller Load/Runtime
- 220.127.116.11 OpenDaylight Controller’s Plugins Security
- 18.104.22.168 AAA for External Users
- 22.214.171.124 Secure Device/Controller BootStrap, Authentication and Authorization
- 126.96.36.199 Controller Clustering and Security
- 188.8.131.52 Overall Recommendations
- 184.108.40.206 OpenDaylight Security Analysis Team
- 220.127.116.11 References
- 1.1.1 OpenDaylight Controller Security
- 1.2 Meeting Notes
- 1.1 Introduction
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.
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.
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.
|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|
|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, 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
- 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 <email@example.com>
- Anthony Gagliardi <firstname.lastname@example.org>
- Bryan Kirchenbauer <Bryan.Kirchenbauer@us.fujitsu.com>
- Jamie Goodyear <email@example.com>
- Junhui Liu <firstname.lastname@example.org>
- Ken Beck < email@example.com>
- Madhu Venugopal <firstname.lastname@example.org>
- Meenakshi Kaushik <email@example.com>
- Mike Geller <<firstname.lastname@example.org>
- Narayana Reddy <email@example.com>
- Susanta Nanda <Susanta_Nanda@symantec.com>
- Wojciech Dec <firstname.lastname@example.org>
* 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