Security Analysis of the Open Networking Foundation (ONF) OpenFlow Switch Specification
draft-mrw-sdnsec-openflow-analysis-00

Network Working Group                                       M. Wasserman
Internet-Draft                                                S. Hartman
Intended status: Informational                         Painless Security
Expires: April 19, 2013                                         D. Zhang
                                                                  Huawei
                                                        October 16, 2012

   Security Analysis of the Open Networking Foundation (ONF) OpenFlow
                          Switch Specification
               draft-mrw-sdnsec-openflow-analysis-00.txt

Abstract

   This document discusses the security properties of the OpenFlow
   Switch Specification version 1.3.0 (OpenFlow), a Software-Defined
   Network (SDN) solution produced by the Open Networking Foundation
   (ONF).  It analyzes the suitability of OpenFlow for use in "the
   cloud" or on the open Internet.  It also makes some suggestions about
   how OpenFlow could be made more secure for use in those environments.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 19, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect

Wasserman, et al.        Expires April 19, 2013                 [Page 1]
Internet-Draft         OpenFlow Security Analysis           October 2012

   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  OpenFlow Security Features  . . . . . . . . . . . . . . . . . . 3
   3.  Specification Issues with OpenFlow Security . . . . . . . . . . 3
     3.1.  Optional Security, Failure Path Unspecified . . . . . . . . 4
     3.2.  No Certificate Details  . . . . . . . . . . . . . . . . . . 4
     3.3.  Importance of Checking Certificates on Both Sides . . . . . 4
     3.4.  TLS 1.0 Vulnerabilities . . . . . . . . . . . . . . . . . . 4
   4.  Applicability of OpenFlow Security Mechanisms . . . . . . . . . 5
     4.1.  One Controller per Switch Scenario  . . . . . . . . . . . . 5
     4.2.  Security in Other Scenarios . . . . . . . . . . . . . . . . 5
       4.2.1.  Multiple Controllers per Switch . . . . . . . . . . . . 5
       4.2.2.  Multiple Apps Talking to a Central Controller . . . . . 5
   5.  Suggestions for Future Work . . . . . . . . . . . . . . . . . . 6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   8.  Informative References  . . . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7

Wasserman, et al.        Expires April 19, 2013                 [Page 2]
Internet-Draft         OpenFlow Security Analysis           October 2012

1.  Introduction

   This document discusses the security properties of the OpenFlow
   Switch Specificaiton (OpenFlow) version 1.3.0 [ref], a Software-
   Defined Network (SDN) solution produced by the Open Networking
   Foundation (ONF).  It analyzes the suitability of OpenFlow for use in
   "the cloud" or on the open Internet.  It also makes some suggestions
   about how OpenFlow could be made more secure for use in those
   environments.

   TBD: Add a short overview of OpenFlow.

2.  OpenFlow Security Features

   To quote the OpenFlow specification, "The switch and controller may
   communicate through a TLS connection.  The TLS connection is
   initiated by the switch on startup to the controller, which is
   located by default on TCP port 6633 .  The switch and controller
   mutually authenticate by exchanging certificates signed by a site-
   specific private key.  Each switch must be user-configurable with one
   certificate for authenticating the controller (controller
   certificate) and the other for authenticating to the controller
   (switch certificate)."

   In other words, OpenFlow includes an optional security feature that
   allows the use of TLS on an OpenFlow control channel.  This mechanism
   provides for authentication of the switch and the controller (if
   certificates are properly checked in both directions) to prevent
   attackers from impersonating a switch or a controller.  It also
   allows for encryption of the control channel to prevent
   eavesdropping.

   The OpenFlow specification mentions that auxiliary connections can
   use UDP with DTLS, but there is no further discussion of how DTLS
   will be used.  Presumably it would use the same certificate-based
   authentication as is described for connections using TCP and TLS.

3.  Specification Issues with OpenFlow Security

   OpenFlow security is minimally specified, to the point where the
   differences between multiple OpenFlow implementations could cause
   operational complexity, interoperability issues or unexpected
   security vulnerabilities.  This section outlines some of the issues
   in the OpenFlow specification that it might be useful to address in a
   later version of the specification.

Wasserman, et al.        Expires April 19, 2013                 [Page 3]
Internet-Draft         OpenFlow Security Analysis           October 2012

3.1.  Optional Security, Failure Path Unspecified

   OpenFlow security is optional, requiring that implementations include
   support for non-secure control connections to ensure
   interoperability.  Furthermore, there is no indication about whether
   implementations should fall back to insecure operation if
   authentication fails, or whether the connection should be closed
   after an authentication failure.

   Also, as the OpenFlow specification states, "when using plain TCP, it
   is recommended to use alternative security measures to prevent
   eavesdropping, controller impersonation or other attacks on the
   OpenFlow channel."  However, the specification gives no indication of
   what sort of alternative security measures are needed to prevent
   those attacks.

3.2.  No Certificate Details

   The OpenFlow document does not specify what certificate format will
   be used for the certificates that are exchanged between the switch
   and the controller, nor does it indicate what field(s) in the
   certificate will be used for naming.  This could lead to operational
   complexity (if different names need to be used in different
   implementations to indicate the same device), or to a lack of
   interoperability.

3.3.  Importance of Checking Certificates on Both Sides

   Although the OpenFlow specification indicates that certificates will
   be exchanged in both directions, it does not explicitly state that
   the certificates must be checked on both ends of the connection.
   There are many TLS implementations that do not currently check client
   certificates, and if a similar approach was used in OpenFlow, it
   could result in vulnerability to man-in-the-middle attacks.

3.4.  TLS 1.0 Vulnerabilities

   The security text in the OpenFlow specification refers to "TLS",
   without any reference or version number.  The failure to specify a
   TLS version number could results in non-interoperable implementations
   if some OpenFlow implementations include TLS 1.0 and others include
   TLS 1.1.  Also, there are security vulnerabilities in TLS 1.0 that
   have been fixed in TLS 1.1.  So, OpenFlow implementations that use
   TLS 1.0 may be subject to man-in-the-middle attacks, as well as other
   attacks against TLS 1.0.  It would be advisable to mandate the use of
   TLS 1.1.

Wasserman, et al.        Expires April 19, 2013                 [Page 4]
Internet-Draft         OpenFlow Security Analysis           October 2012

4.  Applicability of OpenFlow Security Mechanisms

4.1.  One Controller per Switch Scenario

   The OpenFlow specification was originally written with the idea that
   there would be one controller (or a small set of tightly-coordinated
   controllers in a redundant deployment) controlling a set of switches.
   The OpenFlow specification correctly identifies two of the primary
   security threats in this scenario as eavesdropping and controller
   impersonation.  The security mechanisms described in the OpenFlow
   specification are well-suited to protect against those threats.  With
   some clarifications (as described above), the same mechanisms could
   be effective against man-in-the-middle attacks, which are also a
   signficant concern in this scenario.

4.2.  Security in Other Scenarios

   Recent SDN discussions have raised the idea that multiple, non-
   tightly-coordinated processes might want to control the switching
   behavior of a network.  There are two high-level scenarios under
   discussion to accomplish this goal, one where multiple controllers
   are used to control the same set of switches, and another where the
   needs of multiple control processes are mediated by a centralized
   controller that controls a set of switches.  This section explores
   the applicability of the security mechanisms in the OpenFlow
   protocol, as currently specified, to those scenarios.

4.2.1.  Multiple Controllers per Switch

   In this scenario, multiple control processes talk directly to a
   single switch.  OpenFlow security is poorly-suited to use in this
   scenario for two reasons: lack of support for authorization, and a
   lack of granular access/control.

   OpenFlow authentication is, essentially, a binary process.  An
   authenticated controller has access to view or change the full
   configuration of the switch.  It also has access to all of the
   traffic flowing through the switch.  This is not desirable in a case
   where mutliple control processes are being used to control different
   portions of the network traffic.

4.2.2.  Multiple Apps Talking to a Central Controller

   This scenario effectively combines the two scenarios described above.

   At the top-level, multiple control processes are talking to a single
   centralized controller, each communicating its own needs.  This is
   akin to the "Multiple Controllers per Switch" scenario described in

Wasserman, et al.        Expires April 19, 2013                 [Page 5]
Internet-Draft         OpenFlow Security Analysis           October 2012

   the previous section.  OpenFlow, as currently specified, is not well-
   suited for use at this level, due to its lack of support for
   authorization and fine-grained access control.

   At the lower-level, a single, centralized controller is used to
   control a group of switches.  Ignoring the specification issues
   raised earlier in this document, the security mechanisms defined in
   the OpenFlow specification are well-suited for communication between
   the centralized controller and the switches in this scenario.

5.  Suggestions for Future Work

   We would recommend that the IETF publish a document advising the ONF
   about the current weaknesses in the OpenFlow security specification.
   The document should also make specific suggestions for updates to the
   OpenFlow specification that would address those weaknesses.  This
   document should focus on clarifications needed to ensure
   interoperability, as well as changes needed to eliminate
   vulnerabilities.  The ONF could then decide when or if to include the
   suggested changes in the OpenFlow specification.

   We would also recommend that the IETF publish a document outlining
   the security requirements for a protocol to run between applications
   and an SDN controller, or between multiple SDN controllers and a set
   of switches.  This document would be useful for operators who are
   deciding what protocols to use for their SDN deployments, or for
   protocol designers (in the IETF, in the ONF or elsewhere) to use as
   the basis for designing security mechanisms for protocols intended
   for that purpose.

6.  Security Considerations

   TBD

7.  Acknowledgements

   This document was written using the xml2rfc tool described in RFC
   2629 [RFC2629].

8.  Informative References

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

Wasserman, et al.        Expires April 19, 2013                 [Page 6]
Internet-Draft         OpenFlow Security Analysis           October 2012

Authors' Addresses

   Margaret Wasserman
   Painless Security
   356 Abbott Street
   North Andover, MA  01845
   USA

   Phone: +1 781 405 7464
   Email: mrw@painless-security.com
   URI:   http://www.painless-secuirty.com

   Sam Hartman
   Painless Security

   Email: hartmans-ietf@mit.edu

   Dacheng Zhang
   Huawei
   Beijing,
   China

   Phone:
   Fax:
   Email: zhangdacheng@huawei.com
   URI:

Wasserman, et al.        Expires April 19, 2013                 [Page 7]