idnits 2.17.1 draft-mrw-sdnsec-openflow-analysis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 17, 2013) is 4026 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Wasserman 3 Internet-Draft S. Hartman 4 Intended status: Informational Painless Security 5 Expires: October 19, 2013 7 April 17, 2013 9 Security Analysis of the Open Networking Foundation (ONF) OpenFlow 10 Switch Specification 11 draft-mrw-sdnsec-openflow-analysis-02 13 Abstract 15 This document discusses the security properties of the OpenFlow 16 Switch Specification version 1.3.0 (OpenFlow), a Software-Defined 17 Network (SDN) solution produced by the Open Networking Foundation 18 (ONF). It analyzes the suitability of OpenFlow for use in "the 19 cloud" or on the open Internet. It also makes some suggestions about 20 how OpenFlow could be made more secure for use in those environments. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on October 19, 2013. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. OpenFlow Security Features . . . . . . . . . . . . . . . . . 2 58 3. Specification Issues with OpenFlow Security . . . . . . . . . 3 59 3.1. Optional Security, Failure Path Unspecified . . . . . . . 3 60 3.2. No Certificate Details . . . . . . . . . . . . . . . . . 3 61 3.3. Importance of Checking Certificates on Both Sides . . . . 4 62 3.4. TLS 1.0 Vulnerabilities . . . . . . . . . . . . . . . . . 4 63 3.5. Failure Handling Solutions . . . . . . . . . . . . . . . 4 64 3.6. Solutions to Keep the Consistancy of Flow Policies . . . 4 65 4. Applicability of OpenFlow Security Mechanisms . . . . . . . . 5 66 4.1. One Controller per Switch Scenario . . . . . . . . . . . 5 67 4.2. Security in Other Scenarios . . . . . . . . . . . . . . . 5 68 4.2.1. Multiple Controllers per Switch . . . . . . . . . . . 5 69 4.2.2. Multiple Apps Talking to a Central Controller . . . . 6 70 5. Suggestions for Future Work . . . . . . . . . . . . . . . . . 6 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 73 8. Informative References . . . . . . . . . . . . . . . . . . . 6 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 76 1. Introduction 78 This document discusses the security properties of the OpenFlow 79 Switch Specificaiton (OpenFlow) version 1.3.0 [ref], a Software- 80 Defined Network (SDN) solution produced by the Open Networking 81 Foundation (ONF). It analyzes the suitability of OpenFlow for use in 82 "the cloud" or on the open Internet. It also makes some suggestions 83 about how OpenFlow could be made more secure for use in those 84 environments. 86 TBD: Add a short overview of OpenFlow. 88 2. OpenFlow Security Features 90 To quote the OpenFlow specification, "The switch and controller may 91 communicate through a TLS connection. The TLS connection is 92 initiated by the switch on startup to the controller, which is 93 located by default on TCP port 6633 . The switch and controller 94 mutually authenticate by exchanging certificates signed by a site- 95 specific private key. Each switch must be user-configurable with one 96 certificate for authenticating the controller (controller 97 certificate) and the other for authenticating to the controller 98 (switch certificate)." 100 In other words, OpenFlow includes an optional security feature that 101 allows the use of TLS on an OpenFlow control channel. This mechanism 102 provides for authentication of the switch and the controller (if 103 certificates are properly checked in both directions) to prevent 104 attackers from impersonating a switch or a controller. It also 105 allows for encryption of the control channel to prevent 106 eavesdropping. 108 The OpenFlow specification mentions that auxiliary connections can 109 use UDP with DTLS, but there is no further discussion of how DTLS 110 will be used. Presumably it would use the same certificate-based 111 authentication as is described for connections using TCP and TLS. 113 3. Specification Issues with OpenFlow Security 115 OpenFlow security is minimally specified, to the point where the 116 differences between multiple OpenFlow implementations could cause 117 operational complexity, interoperability issues or unexpected 118 security vulnerabilities. This section outlines some of the issues 119 in the OpenFlow specification that it might be useful to address in a 120 later version of the specification. 122 3.1. Optional Security, Failure Path Unspecified 124 OpenFlow security is optional, requiring that implementations include 125 support for non-secure control connections to ensure 126 interoperability. Furthermore, there is no indication about whether 127 implementations should fall back to insecure operation if 128 authentication fails, or whether the connection should be closed 129 after an authentication failure. 131 Also, as the OpenFlow specification states, "when using plain TCP, it 132 is recommended to use alternative security measures to prevent 133 eavesdropping, controller impersonation or other attacks on the 134 OpenFlow channel." However, the specification gives no indication of 135 what sort of alternative security measures are needed to prevent 136 those attacks. 138 3.2. No Certificate Details 140 The OpenFlow document does not specify what certificate format will 141 be used for the certificates that are exchanged between the switch 142 and the controller, nor does it indicate what field(s) in the 143 certificate will be used for naming. This could lead to operational 144 complexity (if different names need to be used in different 145 implementations to indicate the same device), or to a lack of 146 interoperability. 148 3.3. Importance of Checking Certificates on Both Sides 150 Although the OpenFlow specification indicates that certificates will 151 be exchanged in both directions, it does not explicitly state that 152 the certificates must be checked on both ends of the connection. 153 There are many TLS implementations that do not currently check client 154 certificates, and if a similar approach was used in OpenFlow, it 155 could result in vulnerability to man-in-the-middle attacks. 157 3.4. TLS 1.0 Vulnerabilities 159 The security text in the OpenFlow specification refers to "TLS", 160 without any reference or version number. The failure to specify a 161 TLS version number could results in non-interoperable implementations 162 if some OpenFlow implementations include TLS 1.0 and others include 163 TLS 1.1. Also, there are security vulnerabilities in TLS 1.0 that 164 have been fixed in TLS 1.1. So, OpenFlow implementations that use 165 TLS 1.0 may be subject to man-in-the-middle attacks, as well as other 166 attacks against TLS 1.0. It would be advisable to mandate the use of 167 TLS 1.1. 169 3.5. Failure Handling Solutions 171 After a switch loses contact with all controllers, a switch will 172 enter the either "fail secure mode" in which the switch transfer 173 packets according to the existing records in the flow table or "fail 174 standalone mode" in which the switch acts as a normal switch or 175 router, depending upon the switch implementation and configuration. 176 The OpenFlow specification does not support specifying such fail 177 modes at run time, and thus after a controller lost connections with 178 its switches it will not know how the packets will be processed by 179 the switches. This problem will introduce difficulties in damage 180 confinement or bring potential security issues. 182 In addition, in most scenarios, after generating a flow, the 183 controller needs to distribute the policies of the flow to all the 184 associated switches. During this procedure, if a switch meets any 185 problem in deploying the policies, all the other related switches 186 must not use these policies either. However, the current 187 specification does not discuss how to support this atomic 188 requirement. 190 3.6. Solutions to Keep the Consistancy of Flow Policies 191 The OpenFlow specification has not yet well analyzed the multiple 192 headed scenarios where multiple applications try to modify the 193 policies of the same flow concurrently. If multiple applications 194 does not update the policies of the same flow in an well organized 195 way, errors may be raised. 197 4. Applicability of OpenFlow Security Mechanisms 199 4.1. One Controller per Switch Scenario 201 The OpenFlow specification was originally written with the idea that 202 there would be one controller (or a small set of tightly-coordinated 203 controllers in a redundant deployment) controlling a set of switches. 204 The OpenFlow specification correctly identifies two of the primary 205 security threats in this scenario as eavesdropping and controller 206 impersonation. The security mechanisms described in the OpenFlow 207 specification are well-suited to protect against those threats. With 208 some clarifications (as described above), the same mechanisms could 209 be effective against man-in-the-middle attacks, which are also a 210 signficant concern in this scenario. 212 4.2. Security in Other Scenarios 214 Recent SDN discussions have raised the idea that multiple, non- 215 tightly-coordinated processes might want to control the switching 216 behavior of a network. There are two high-level scenarios under 217 discussion to accomplish this goal, one where multiple controllers 218 are used to control the same set of switches, and another where the 219 needs of multiple control processes are mediated by a centralized 220 controller that controls a set of switches. This section explores 221 the applicability of the security mechanisms in the OpenFlow 222 protocol, as currently specified, to those scenarios. 224 4.2.1. Multiple Controllers per Switch 226 In this scenario, multiple control processes talk directly to a 227 single switch. OpenFlow security is poorly-suited to use in this 228 scenario for two reasons: lack of support for authorization, and a 229 lack of granular access/control. 231 OpenFlow authentication is, essentially, a binary process. An 232 authenticated controller has access to view or change the full 233 configuration of the switch. It also has access to all of the 234 traffic flowing through the switch. This is not desirable in a case 235 where mutliple control processes are being used to control different 236 portions of the network traffic. 238 4.2.2. Multiple Apps Talking to a Central Controller 240 This scenario effectively combines the two scenarios described above. 242 At the top-level, multiple control processes are talking to a single 243 centralized controller, each communicating its own needs. This is 244 akin to the "Multiple Controllers per Switch" scenario described in 245 the previous section. OpenFlow, as currently specified, is not well- 246 suited for use at this level, due to its lack of support for 247 authorization and fine-grained access control. 249 At the lower-level, a single, centralized controller is used to 250 control a group of switches. Ignoring the specification issues 251 raised earlier in this document, the security mechanisms defined in 252 the OpenFlow specification are well-suited for communication between 253 the centralized controller and the switches in this scenario. 255 5. Suggestions for Future Work 257 We would recommend that the IETF publish a document advising the ONF 258 about the current weaknesses in the OpenFlow security specification. 259 The document should also make specific suggestions for updates to the 260 OpenFlow specification that would address those weaknesses. This 261 document should focus on clarifications needed to ensure 262 interoperability, as well as changes needed to eliminate 263 vulnerabilities. The ONF could then decide when or if to include the 264 suggested changes in the OpenFlow specification. 266 We would also recommend that the IETF publish a document outlining 267 the security requirements for a protocol to run between applications 268 and an SDN controller, or between multiple SDN controllers and a set 269 of switches. This document would be useful for operators who are 270 deciding what protocols to use for their SDN deployments, or for 271 protocol designers (in the IETF, in the ONF or elsewhere) to use as 272 the basis for designing security mechanisms for protocols intended 273 for that purpose. 275 6. Security Considerations 277 TBD 279 7. Acknowledgements 281 This document was written using the xml2rfc tool described in RFC 282 2629 [RFC2629]. 284 8. Informative References 286 [RFC2629] Rose, M.T., "Writing I-Ds and RFCs using XML", RFC 2629, 287 June 1999. 289 Authors' Addresses 291 Margaret Wasserman 292 Painless Security 293 356 Abbott Street 294 North Andover, MA 01845 295 USA 297 Phone: +1 781 405 7464 298 Email: mrw@painless-security.com 299 URI: http://www.painless-secuirty.com 301 Sam Hartman 302 Painless Security 304 Email: hartmans-ietf@mit.edu