idnits 2.17.1 draft-hartman-sdnsec-requirements-01.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 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 26 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 332: '...uthentication is REQUIRED to the contr...' RFC 2119 keyword, line 333: '... SHOULD support existing credentials...' RFC 2119 keyword, line 336: '...e SDN controller MUST support authoriz...' RFC 2119 keyword, line 340: '...e SDN controller MUST provide faciliti...' RFC 2119 keyword, line 343: '...roller interface MUST support a contro...' (10 more instances...) 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 4021 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-abfab-arch-03 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Hartman 3 Internet-Draft M. Wasserman 4 Intended status: Informational Painless Security 5 Expires: October 19, 2013 D. Zhang 6 Huawei Technologies co. ltd 7 April 17, 2013 9 Security Requirements in the Software Defined Networking Model 10 draft-hartman-sdnsec-requirements-01 12 Abstract 14 Software defined/driven networks provide new dimensions of 15 flexibility in network design. This document analyzes security 16 requirements as we design protocols to support multiple network 17 applications on an SDN in an open manner. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 19, 2013. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Moving Beyond a Single Application . . . . . . . . . . . . . . 3 55 2.1. Class 1: Network Sensitive Applications . . . . . . . . . 3 56 2.2. Class 2: Services for the Network . . . . . . . . . . . . 4 57 2.3. Class 3: Packaged Network Services . . . . . . . . . . . . 5 58 3. Authentication, Authorization and Multiple Organizations . . . 6 59 4. Security Requirements . . . . . . . . . . . . . . . . . . . . 8 60 4.1. Nested Application Security . . . . . . . . . . . . . . . 9 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 63 7. Informative References . . . . . . . . . . . . . . . . . . . . 10 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 66 1. Introduction 68 This document analyzes the security of SDN architectures as we work 69 to build SDN frameworks supporting multiple applications at the same 70 time. The assumption of this protocol is that protocols like 71 Openflow will be used between a SDN controller and switches. However 72 this document assumes that there will be additional protocols between 73 controllers and between controllers and applications. That is the 74 focus for the current analysis. 76 2. Moving Beyond a Single Application 78 Openflow defines a protocol between a physical switch and a 79 controller. Several factors motivate a layer between the controller 80 and applications. For example [I-D.nadeau-sdn-problem-statement] 81 discusses a model where managed service providers (MSPs) provide 82 networking services to applications. This model involves the 83 following attributes that significantly impact SDN security analysis: 85 o An application in one organization may use an MSP in another 87 o MSPs may be nested; one MSP may use the services of another 89 o Privacy concerns may limit what information should be exposed 91 o Applications require significant authorization and policy 93 The remainder of this section examines a few classes of applications 94 in order to identify characteristics of SDN use cases that affect 95 security. 97 2.1. Class 1: Network Sensitive Applications 99 Some applications require particular characteristics from the 100 network. For example an application might need access to ports in a 101 particular isolation domain/vlan. An application might require a 102 path with particular characteristics. An application might require 103 that traffic stay within a certain jurisdiction, travel only over 104 certain equipment, or similar constraints. An application might want 105 to monitor the cost of certain traffic or flows. And application 106 might require that flows be discarded to mitigate a DOS attack or 107 accepted in order to run a service. 109 Applications in this class will typically wish to provision aspects 110 of the network using some API. They may wish to collect information 111 from the network for monitoring, auditing or accounting. 113 Applications may not be aware of each others' requests. the SDN 114 controller needs to make sure that one application does not 115 negatively interact with another. Isolation of applications may be a 116 security requirement. In this case the controller needs to make sure 117 that even a malicious application cannot interact badly with another. 119 In most cases authorization will be important. The network may have 120 resources that are not appropriate for one application or another and 121 may wish to enforce authorization between them. 123 Multiple organizations may be involved within providing network 124 services to such an application. For example, an application may 125 request a network connection within a particular isolation domain. 126 However that isolation domain may include resources within an 127 enterprise, a cloud provider and a transit network between the 128 enterprise and cloud provider. Authorization and authentication are 129 likely to be handled by proxies in at least the simpler cases. For 130 example, an application in the enterprise network requests access to 131 the application domain from some controller in the enterprise. That 132 controller has necessary credentials to request access from the 133 transit network and cloud provider. Authentication and authorization 134 may be more complex when an application in the cloud environment 135 requests access to the isolation domain. Does it contact the 136 enterprise controller or does it contact a resource in the cloud that 137 has sufficient privilege to grant access to the enterprise aspect of 138 the isolation domain. Debugging of multi-organization environments 139 is facilitated by exposing information about all the environments. 140 For example it is likely that for monitoring and debugging purposes 141 enterprise applications would want visibility into the cloud 142 environment and the parts of the transit network that the enterprise 143 is allowed to see. Obviously the transit network and cloud provider 144 would want to limit visibility into their internal structure but 145 would want to make available information about resources controlled 146 by that customer. for example the cloud provider would typically 147 allow customers to see their own instances and virtual networks. 148 Going through a proxy to authenticate requests for debugging and 149 monitoring may not be ideal; it may be desirable for the application 150 to collect debugging and monitoring information directly from the 151 transit network and cloud provider. If so, the authentication and 152 authorization needs to be flexible enough to permit this. 154 2.2. Class 2: Services for the Network 156 An application may provide a service such as a firewall, content 157 inspection or intrusion detection to the entire network. In this 158 case, the security model is similar to the security model between the 159 SDN controller and switch; there is one key exception that will be 160 discussed shortly. The primary role of the separation between the 161 SDN controller and application for this class of applications is to 162 permit multiple applications to co-exist. So, isolation of resources 163 is still important. 165 The security model for this class of application is similar to one of 166 the common models for routing protocols and network management. 167 Strong defense against outside attacks is required. It would be a 168 significant attack if an attacker could impersonate an authorized 169 application and gain the ability to reconfigure or monitor the 170 network. However, inside attacks are not generally considered in 171 scope for the threat analysis. 173 One key consideration with this type of security model is protecting 174 the boundary between inside and outside and supporting multiple zones 175 of trust. As an example, a border firewall application does not need 176 the ability to reconfigure the interior of the network or to examine 177 traffic inside interior isolation domains not destined for the border 178 of the network. So, even in this model authorizing what resources an 179 application is permitted to see and manipulate is important. This 180 contrasts somewhat with the security model between the controller and 181 switch, where the controller is permitted to manipulate all OpenFlow 182 resources on the switch. 184 2.3. Class 3: Packaged Network Services 186 This class combines the previous two classes. Consider an 187 application of class 1 that wishes for all traffic leaving a certain 188 isolation domain to pass through a particular border firewall 189 service. In effect an application is requesting an instantiation of 190 another application be created as a virtual element in the network. 191 This class of application permits abstraction and re-use of network 192 applications. There is obvious value in the cloud space. However 193 even within an organization, configuration re-use may have 194 significant value. 196 To discuss the security we will say that an outer application nests a 197 nested application within the network. The nested application may 198 involve network resources (virtual or real) as well as compute and 199 other resources. 201 This class involves classic security concerns such as authentication 202 and authorization. What applications is the outer application 203 permitted to nest? How is auditing and accounting handled? The IETF 204 SDN architecture needs to permit these questions to be answered in a 205 secure manner. 207 There may be multiple instances of a nested application, nested into 208 either the same or different outer applications. There are 209 significant issues related to the sharing of information between 210 instances of a nested application. For example, it is quite common 211 for e-mail filtering services to collect information from multiple 212 customers in order to better detect unwanted e-mail. However leaking 213 proprietary information from one customer to another would be 214 undesirable. To a large extent appropriate information sharing is a 215 matter for application design and is out of scope for the SDN 216 architecture. However the SDN architecture needs to support tracking 217 of instance-specific information as well as global information and 218 needs to facilitate design of applications that supports isolation of 219 instances. This parallels virtual computing architectures, where the 220 decision about how to split a problem is application specific, but 221 the virtualization platform provides facilities to share information 222 in a controlled manner and to manage large numbers of instances of 223 applications. 225 Authentication may be more complex in the nested application 226 situation. The permissions that a nested application has will depend 227 on which outer application it is working on-behalf of; the 228 authentication approach will need to account for this. 230 Multiple organizations may be involved with this class of 231 application. As an example, the nested application may be provided 232 by an MSP. Also, the nested application may use an MSP in providing 233 the application. 235 Balancing which resources are visible to the outer application will 236 be tricky. As with class 1 applications, debugging argues for 237 visibility where possible. however, resources may be shared between 238 instances of a nested application. Also, visibility into the nested 239 application might provide proprietary information or provide an 240 attacker with potential advantages. For example, understanding what 241 flow filters were in place on a firewall application might expose 242 information that would be valuable in getting around the firewall. 244 There's a similar concern with the nested application's visibility 245 into the outer application. That visibility can be valuable for 246 optimization and debugging. However, it may provide proprietary 247 information or otherwise compromise the privacy goals of the outer 248 application. 250 3. Authentication, Authorization and Multiple Organizations 252 In looking at needs of the various classes of applications, support 253 for applications and network resources spanning multiple 254 organizations appeared as a requirement multiple times. This 255 requirement is interesting from a security standpoint. This section 256 explores how authentication and authorization can be handled between 257 organizations. 259 One approach is for an organization to proxy connections to other 260 organizations. The controller in one organization has credentials on 261 behalf of the organization that it uses with other organizations. 262 The local application talks to the local controller. When the 263 controller realizes that it needs resources from another organization 264 it talks to that organization's controller. This approach has been 265 used fairly effectively in SIP [RFC3261] and other protocols with 266 trusted intermediates. A significant advantage of this approach is 267 that it permits the organization to enforce organization-level 268 policy. It also permits the organization to hide information. For 269 example, consider the class 1 example where the enterprise's 270 isolation domain is split between a cloud, transit network and domain 271 inside the enterprise. That split might be unimportant to the 272 application; the organization's controller might try and present a 273 unified network to applications. In such a case a proxy approach can 274 work well. 276 The proxy approach has some disadvantages. There is no end-to-end 277 security including integrity or data-origin authentication. The 278 proxy becomes a very sensitive target. Because of the lack of end- 279 to-end integrity, if the proxy is compromised, then the attacker can 280 impersonate other network resources from the view of elements behind 281 the proxy. The proxy may make deploying new features more difficult. 282 To the extent that the proxy needs to understand a new feature before 283 it is used, the proxy makes it more expensive to deploy the feature. 285 Another approach is for applications to directly have credentials in 286 another organization. For example, this might work if an application 287 wishes to use a particular external MSP. The advantage of this 288 approach is that it provides flexibility to the application. The 289 disadvantage is that it leaves open the question of how the two 290 organizations' resources are glued together to form a consistent 291 network. In some cases the application could manage this. In other 292 cases, for example where changes are required in flow tables based on 293 dynamic responses from the other organization, this may not be 294 practical. Other disadvantages include increased complexity and 295 difficulty in enforcing organization-level policy. 297 A third approach is to use some sort of federated/delegated 298 authentication approach such as oauth [I-D.ietf-oauth-v2] or ABFAB 299 [I-D.ietf-abfab-arch] to permit applications to obtain credentials 300 that can be used in other organizations. This sort of delegation and 301 federation could facilitate the following use cases: 303 o Permit applications to obtain credentials for debugging and 304 monitoring while attaching constraints to those credentials 305 limiting resources the application can see 307 o Preset credentials so applications can talk to foreign 308 controllers; for example the cloud application talking to the 309 enterprise controller to gain access to the enterprise isolation 310 domain 312 o Permit nested applications to be delegated access to some outer 313 application resources 315 o Grant outer applications access to nested application resources 316 for debugging, monitoring or application-specific reasons 318 Another concern when multiple organizations are involved is auditing 319 and accountability. Digital signatures and other mechanisms can be 320 used to provide end-to-end accountability. However, this needs to be 321 balanced against the need to hide information. It seems like the SDN 322 use case may be one where end-to-end accountability is rarely an 323 option. 325 4. Security Requirements 327 This section captures a variety of security requirements for layers 328 on top of SDN controllers. These requirements are based on the 329 discussion of potential applications as well as multi-organization 330 considerations. 332 REQ1: Authentication is REQUIRED to the controller. Authentication 333 SHOULD support existing credentials that are likely to be used in the 334 datacenter. 336 REQ2: The interface to the SDN controller MUST support authorizing 337 specific network resources to applications and manipulating the 338 authorizations of applications. 340 REQ3: The SDN controller MUST provide facilities to isolate one 341 application from another. XXX more discussion of this 343 REQ 4: The SDN controller interface MUST support a controller acting 344 as a proxy on behalf of applications. 346 REQ 4a: The SDN interface SHOULD support a way of associating an 347 audit ID or other tracking ID so that requests can be correlated with 348 an original application when a proxy acts on behalf of an 349 application. 351 REQ 5: The SDN controller interface MUST provide mechanisms for 352 operators and applications to enforce privacy. 354 REQ 6: The SDN controller interface MUST support delegating access to 355 a subset of resources; as part of delegation new authorization and 356 privacy constraints MAY be supplied. This supports the security 357 needs of the debugging use case, aspects of the nested application 358 use case, and facilitates other inter-organization uses. 360 4.1. Nested Application Security 362 This section captures requirements for nested application support. 364 REQ N1: The SDN controller interface MUST support controlling 365 authorization for what nested applications an outer application can 366 nest. 368 REQ N2: The controller MUST separate authorizations held by one 369 instance of a nested application from authorizations help by other 370 instances of the same nested application. This is more about defense 371 from bugs and operational mistakes than maintaining isolation of 372 authorizations even if the nested application tries to circumvent the 373 authorizations. However, it should be possible to write a nested 374 application that maintains isolation sufficiently that compromise of 375 one instance of the application will not lead to compromise of other 376 instances. Obviously doing so places constraints on what resources 377 need to be duplicated between instances of an application. 379 REQ N3: The SDN controller interface SHOULD provide outer 380 applications a way to learn a nested application's policy for sharing 381 information between instances. 383 REQ N4: Nested applications MUST be able to authenticate on behalf of 384 a specific outer application. This facilitates authorization, 385 accounting and auditing. 387 REQ N5: Nested applications MUST be able to specify privacy policy 388 for what resources are visible to the outer application. 390 REQ N6: Outer applications MUST be able to specify privacy policy and 391 authorizations with regard to what outer resources the nested 392 application can interact with. 394 5. Security Considerations 396 This document provides discussion of the security implications of SDN 397 architectures supporting multiple applications. 399 6. IANA Considerations 401 IANA is requested to make the internet secure. Note to someone: re- 402 word this section before IANA reviews it. 404 7. Informative References 406 [I-D.ietf-abfab-arch] 407 Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J. 408 Schaad, "Application Bridging for Federated Access Beyond 409 Web (ABFAB) Architecture", draft-ietf-abfab-arch-03 (work 410 in progress), July 2012. 412 [I-D.ietf-oauth-v2] 413 Hardt, D., "The OAuth 2.0 Authorization Framework", 414 draft-ietf-oauth-v2-31 (work in progress), August 2012. 416 [I-D.nadeau-sdn-problem-statement] 417 Nadeau, T. and P. Pan, "Software Driven Networks Problem 418 Statement", draft-nadeau-sdn-problem-statement-01 (work in 419 progress), October 2011. 421 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 422 A., Peterson, J., Sparks, R., Handley, M., and E. 423 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 424 June 2002. 426 Authors' Addresses 428 Sam Hartman 429 Painless Security 431 Email: hartmans-ietf@mit.edu 433 Margaret 434 Painless Security 436 Email: mrw@painless-security.com 437 Dacheng Zhang 438 Huawei Technologies co. ltd 439 Huawei Building No.3 Xinxi Rd., Shang-Di Information Industrial Base Hai-Dian District, Beijing 440 China 442 Email: zhangdacheng@huawei.com