Tag Archives: SDN

[ONF Blog] Open Innovation Pipeline: Described


ONF Executive Director Guru Parulkar introduces Foundation’s new game-changing Open Innovation Pipeline strategy.

Last fall, ONF and ON.Lab announced an agreement to become a single organization under the ONF name. Since that time, our aligned operations teams have been hard at work framing the go-forward strategy of the new ONF, an energizing and exciting planning initiative in preparation for our formal merger at the end of 2017.

Today, we have announced the new ONF Open Innovation Pipeline – a strategy that leverages open source platforms, network device disaggregation, and software defined standards to build high value use cases and solutions and to solidify pre-established paths for taking those solutions into operator PoCs, trials and deployment. This framework is the first and only one of its kind in the networking industry and we believe that it’s a game changing in terms of how SDN and NFV will get deployed in networks. It builds on ON.Lab’s advancements with CORD® and ONOS®, two platforms which successfully brought together operators, vendors and integrators to build solutions for carrier networks by leveraging SDN, NFV and Cloud technologies via an open source approach and disaggregated network devices in the form of white boxes. It also draws from ONF’s deep relationships with the operator community.

We understand that the SDN movement initiated by the ONF successfully set the disaggregation of networking devices and control software in motion. It has also fostered the emergence of a broad range open source platforms. We now believe that the industry needs a unifying effort to build solutions out of the numerous disaggregated components. We’re recognizing a trend – one where vendors are leveraging open source to build closed proprietary solutions – and warn that this only provides marginal benefit to the broader ecosystem. The ONF’s Open Innovation Pipeline is designed to counteract this.

Why is the Open Innovation Pipeline needed?

The SDN movement, first initiated by the ONF, has successfully set in motion the disaggregation of networking devices and control software and fostered the emergence of a broad range open source platforms. A trend has emerged where vendors leverage open source to build closed proprietary solutions, providing only marginal benefit to the broader ecosystem. Complexity still challenges many operators, who find building solutions involves the need to integrate many layers of technology, product, customization and integration.

Few players have the resources to invest in building such complex solutions. Innovative offerings have difficulty making it into operator networks because the only route to market is through closed vertically integrated “stovepipe” solutions that tightly integrate together a selection of technologies in ways that result in proprietary barriers to entry.

The industry needs a unifying effort to build solutions out of the numerous disaggregated components. An open platform and clear roadmap is needed to deliver on the promise of SDN and NFV.

ONF will also help a variety of vendors accelerate how an idea or innovation gets adopted into production networks, while operators and system integrators also stand to benefit from the Open Innovation Pipeline. The pipeline allows members of all types to bring their unique innovation and value into the solution. Operators, vendors and integrators all have a role to play, and the pipeline helps integrate these contributions into consumable solutions for operators.

How will the Open Innovation Pipeline accelerate innovation into deployment?

ONF will maintain an integrated open source platform, making it easy for new innovations to focus on where they add value. Vendors and integrators can add value and introduce offerings anywhere along the innovation pipeline. Additionally, to foster interoperability ONF will focus on developing open source interworking APIs and Models by working with the broader open source community. Additionally, data plane innovation will continue to be fostered through standards development for OpenFlow and future offerings.

Want to learn more about the Open Innovation Pipeline Strategy?

We understand that you may have questions about our new strategy. If you’d like to learn more, I encourage you to read this overview of our new Open Innovation Pipeline strategy.

And, if your travels take you to Mobile World Congress in Barcelona the week of February 27, we also encourage you to visit us at the show in Hall 5, Stand 5161 to learn more about this exciting new initiative.

– Guru Parulkar, Executive Director

SDN and Security – David Jorm




Introduction

Open source SDN is a “hot” technology, with development being driven by a wide range of commercial and non-profit entities. 2015 is emerging as the year when open source SDN starts to move from the lab to widespread deployment for production networks. This transition from development to deployment brings questions of stability, scalability, and security to the fore. If 2015 is the year when open source SDN goes mainstream, then 2015 is the year that we need to identify and resolve security flaws in SDN controllers and switches.

Attack surface

Traditional networks conflate the control and data planes on a physical device, which typically consists of proprietary hardware and software. Software-defined networks factor the control plane out to a SDN controller. The controller uses a protocol such as OpenFlow to control switches, which are now only responsible for handling the data plane. From a security perspective, this division of responsibility has both advantages and disadvantages. The ability to easily segregate the control plane network from the production data network is an obvious advantage. The SDN controller’s ability to control an entire network makes it a very high value target, which is a potential disadvantage compared to a traditional network with a more distributed control plane.

In addition to the control plane administration interfaces exposed by the SDN controller, it has another attack surface: the data plane of the switches it manages. When an OpenFlow switch encounters a packet that does not match any forwarding rules, it passes this packet to the controller for advice. As a result, it is possible for an attacker who is simply able to send data through an SDN switch to exploit a vulnerability on the controller.

Recent vulnerabilities

As SDN has begun to emerge as a mainstream technology, it has drawn the attention of security researchers. In the last few months, several new vulnerabilities affecting open source SDN controllers have been reported. We’ll look at three in particular that demonstrate the SDN attack surface, and provide examples of the kind of issues we’re likely to see in the future.

1) XML eXternal Entity (XXE) vulnerability in OpenDaylight netconf (CVE-2014-5035)

In late 2014 an XXE flaw was found in OpenDaylight’s netconf interface. Netconf allows for network configuration changes to be instigated using an XML vocabulary.  OpenDaylight’s netconf implementation did not disable external entities when processing user-supplied XML documents, thereby exposing an XXE flaw. This is a very common flaw in server-side processes that handle user-supplied XML, and is particularly common in Java applications.  A remote attacker, if able to interact with one of OpenDaylight’s netconf interfaces, could use this flaw to exfiltrate files on the OpenDaylight controller. This could include configuration details and plaintext credentials.

For an attacker to exploit this flaw, they need to have access to a netconf interface, which is part of the control plane. Strong access controls for control plane interfaces will greatly reduce the impact of flaws of this nature. To maximize their effectiveness, these access controls should be enabled by default. For more details on this flaw and how to apply a patch, see: https://wiki.opendaylight.org/view/Security_Advisories#.5BImportant.5D_CVE-2014-5035_netconf:_XML_eXternal_Entity_.28XXE.29_vulnerability

2) Denial-of-service (DoS) when deserializing malformed packets in ONOS (CVE-2015-1166)

In early 2015 an interesting DoS flaw was reported to the ONOS project. As mentioned earlier, when an OpenFlow switch encounters a packet that does not match any forwarding rules, it passes this packet to the controller for advice. It was found that the packet deserializers in ONOS would throw exceptions when handling malformed, truncated, or maliciously-crafted packets. The exceptions were not caught and handled, which would result in the relevant switch being disconnected because an exception occurred in an I/O thread. A remote attacker could use this flaw to perform a DoS attack by causing ONOS to disconnect switches.

For an attacker to exploit this flaw, they only need to be able to send malicious crafted packets through a switch controlled by ONOS. This is an example of how the data plane can be used to exploit a vulnerability on the controller. For more details on this flaw and how to apply a patch, see: https://jira.onosproject.org/browse/ONOS-605

3) Topology spoofing via host tracking

In mid-February 2015, another interesting flaw that can be exploited via the data plane was reported. Most SDN controllers include host tracking, allowing hosts to migrate between different physical locations in the network. This host tracking functionality is based on monitoring of Packet-In messages, and does not require any validation, authentication, or authorization. This makes it possible for an attacker to impersonate a host and make the SDN controller believe it has migrated to a physical network location controlled by the attacker.

For an attacker to exploit this flaw, they only need to be able to send malicious messages through a switch controlled by an SDN controller. The only prerequisite is that the attacker must know the MAC address of the target host. For more details on this flaw, see: http://www.internetsociety.org/sites/default/files/10_4_2.pdf

Same same, but different

It is worth noting that while the three vulnerabilities discussed above are new, none of them are particularly novel. XXE is a very well established issue that has affected dozens of Java-based projects. DoS attacks based on triggering an unhandled exception are also common and well established. The topology spoofing flaw is novel in a sense, but it is closely related to MAC spoofing, which is a very old and well-known issue (http://en.wikipedia.org/wiki/MAC_spoofing). This highlights that while SDN is a new and novel technology, it is still just software, and a relatively small number of fundamental issues represent the vast majority of security flaws. As a result, applying tried and true countermeasures is likely to be effective for many of the security flaws that will affect SDN.

Security response

The most important countermeasure for security flaws in any software project is an effective security response process. This process should be run by a dedicated team who can handle reports of security flaws discretely. At a minimum, a security response process should provide the following:

* A private channel for people to report security flaws

* The ability to drive the preparation of patches without any details of the flaw becoming publicly visible

* The ability to ship patches quickly

* Clear and concise advisories that communicate the impact of flaws to users, and provide details on how to apply patches

ONOS has now implemented a security response process, which is an important first step. For more details, see: https://wiki.onosproject.org/display/ONOS/Security

Defensive technology

Security response is reactive: a flaw is found, and it is addressed by a patch and a corresponding advisory. Of course, it is preferable to address security flaws in a proactive fashion. Several open source projects are now underway that aim to improve the security of SDN controllers, and limit the ability of an attacker to exploit any flaws that become known. We’ll look at two of these projects.

1) Security-mode ONOS

Security-mode ONOS is a new feature that is targeting the upcoming ONOS ‘Cardinal’ release. It is effectively a mandatory access control (MAC) implementation for ONOS applications. Applications can be constrained by a policy dictating which actions they are permitted to perform. This is an important development, as it means that a vulnerability in an ONOS application could not be exploited to perform actions that are not permitted by security-mode ONOS. This is similar to the protection SELinux provides for applications running on Linux systems. For more details, see: https://wiki.onosproject.org/display/ONOS/Security-Mode+ONOS

2) Topoguard

The same research team that reported the topology spoofing flaw noted above also developed a tool to mitigate it, called Topoguard. It works by verifying the conditions of a host migration. A legitimate host migration would involve a Port Down signal before the host migration finishes. It would also mean that the host would be unreachable at its old physical network location after the migration is complete. Topoguard verifies host migrations by ensuring that these conditions are met, effectively mitigating topology spoofing via host tracking. Topoguard is currently tightly coupled to the Floodlight controller, but it could be ported to other controllers. For more details, see: https://github.com/xuraylei/floodlight_with_topoguard

Next steps

When I first became involved in the open source SDN community in November 2014, very few meaningful security measures were in place. Since then, the community has started to audit SDN controllers and report flaws, security response processes have been documented and security response teams formed, and powerful defensive technology is starting to be developed. This is a very impressive and encouraging pace of development, and in my opinion open source SDN controllers are on track to provide that level of security that they need to go mainstream.

There are two thorny security problems that open source projects have struggled to handle, and I think ONOS and the wider open source SDN community is now in a position to tackle them.

1) Coordination of vulnerability disclosure

When multiple commercial vendors support a given project, each is incentivized to hold information about security flaws that the other vendors do not. This can be a major source of conflict. It is important that projects are able to coordinate the disclosure of vulnerabilities to all stakeholders simultaneously, without details leaking prior to an agreed upon embargo date.

2) Proactive secure engineering

The defensive technologies discussed above limit the ability of an attacker to exploit flaws, but they do not minimize the risk of security flaws entering the code base in the first place.This can be achieved by implementing measures such as the following:

  • Establishing automated QE/CI jobs to catch security flaws and regressions.
  • Establishing automated QE/CI jobs to catch known-vulnerable dependencies.
  • Documenting a threat model
  • Improving documentation to capture security best practices at installation and configuration time

I would like to challenge the vibrant and growing open source SDN community to tackle these problems. I’m ready and willing to help, so please reach out to me at djorm@iix.net if you’d like to get involved.