idnits 2.17.1 draft-zarny-i2nsf-data-center-use-cases-00.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 25, 2014) is 3470 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7297' is defined on line 327, but no explicit reference was found in the text == Unused Reference: 'PS' is defined on line 332, but no explicit reference was found in the text == Unused Reference: 'GS-NFV' is defined on line 335, but no explicit reference was found in the text == Unused Reference: 'Boucadair-framework' is defined on line 338, but no explicit reference was found in the text == Unused Reference: 'SC-MobileNetwork' is defined on line 342, but no explicit reference was found in the text == Unused Reference: 'Application-SDN' is defined on line 345, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Zarny 3 Internet Draft Goldman Sachs 4 Intended Status: Informational S. Magee 5 F5 6 N. Leymann 7 Deutsche Telecom 8 L. Dunbar 9 Huawei 11 Expires: April 28, 2015 October 25, 2014 13 I2NSF Data Center Use Cases 14 draft-zarny-i2nsf-data-center-use-cases-00 16 Abstract 18 This document describes data center use cases and their requirements 19 that a common Interface to Network Security Functions (I2NSF) needs 20 to take into account. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that other 29 groups may also distribute working documents as Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/1id-abstracts.html 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 Copyright and License Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions used in this document . . . . . . . . . . . . . . . 3 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. On-demand, elastic deployment of firewalls . . . . . . . . . . 4 63 4.1 On demand virtual firewall deployment in cloud data 64 centers . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 5. Firewall policy deployment automation . . . . . . . . . . . . . 6 66 5.1 Client-specific security policy in cloud VPNs . . . . . . . 6 67 6. Key requirements for the use cases . . . . . . . . . . . . . . 6 68 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 8. Security considerations . . . . . . . . . . . . . . . . . . . . 8 70 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 8 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 10.1 Normative references . . . . . . . . . . . . . . . . . . . 8 73 10.2 Informative references . . . . . . . . . . . . . . . . . . 8 74 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 75 12. Authors' addresses . . . . . . . . . . . . . . . . . . . . . . 8 77 1. Introduction 79 Enterprises today increasingly consume cloud-based network security 80 functions. The reasons are the same as those for the move toward 81 cloud computing: greater economies of scale; faster service delivery; 82 greater flexibility to respond to changing requirements; faster 83 deployment of more sophisticated solutions; among others. 85 The cloud security services can in theory be offered in a number of 86 ways. They can be operated by service providers or enterprises 87 themselves; they can be run on shared or dedicated infrastructure; 88 they can be deployed off- or on-premises; or any combination thereof. 89 In practice, however, since most firms today possess neither the 90 expertise nor resources to build and manage clouds, most firms that 91 consume cloud-based security services do so on off-premise provider- 92 managed clouds. 94 In response, providers and security vendors offer cloud-based models 95 to deliver security solutions. Providers in particular are striving 96 to standardize the offering methodologies through efforts like 97 Network Functions Virtualization (NFV). 99 I2NSF is an IETF effort to standardize the interface for network 100 security functions offered on any kind of cloud regardless of its 101 location or operator. Since the term "network security service" can 102 mean many things, we will limit the term to include only the 103 following services in this draft. 105 * Firewall 107 * DDOS/Anti-DOS (Distributed Denial-of-Service/Anti-Denial-of- 108 Service) 110 * AAA (Authentication, Authorization, Accounting) 112 * Remote identity management 114 * Secure key management 116 * IDS/IPS (Intrusion Detection System/Intrusion Prevention System) 118 2. Conventions used in this document 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [RFC2119]. 124 3. Terminology 126 Cloud-scale network resources: Networked resources which provide 127 various functions (related to infrastructure, platform, software, 128 etc.) in a scalable, automated and secure fashion. Resources in 129 the cloud may be fully owned, operated, and used by a single 130 organization; dedicated to a single client and managed by a 131 provider; shared amongst several clients; hosted on-premises or 132 off-premises of an organization; or a combination thereof. In the 133 context of this draft, a cloud offers network security services. 135 DC: Data Center 137 Domain relationships: The term "Domain" in this draft has different 138 connotations in different scenarios: 140 Client <-> Provider relationship, i.e. a client requesting network 141 service functions from its provider; 143 Domain A <-> Domain B relationship, i.e. one operator domain 144 requesting network service functions from another operator domain; 145 or 147 Applications <-> Network relationship, an application (e.g., 148 cluster of servers) requesting some functions from network. 150 Network function: In the context of I2NSF, the term "network 151 function" describes services that provide network functions 152 including L4-L7 functions. The network service functions may not 153 necessarily be owned or hosted by consumers of those functions. 154 Furthermore, the network functions may be hosted on physical 155 appliances, inside containers, or inside VMs instantiated on 156 common compute servers (e.g., the ETSI NFV defined Virtualized 157 Network Functions). 159 Virtual Security Function: A security function that can be requested 160 by one domain but may be owned or managed by another domain. 162 Cloud-based security functions: Used interchangeably with the 163 "Virtual Security Functions" in this draft. 165 4. On-demand, elastic deployment of firewalls 167 Network security devices such as firewalls may need to be added or 168 removed dynamically for a number of reasons. It may have been 169 explicitly requested by the user, or triggered by a pre-agreed-upon 170 service level agreement (SLA) between the user and the provider of 171 the service. For example, the service provider may be required to add 172 more firewall capacity within a set timeframe whenever the bandwidth 173 utilization hits a certain threshold for a specified period. This 174 capacity expansion could result in adding new instances of firewalls. 175 Likewise, a service provider may need to provision a new firewall 176 instance in a completely new environment due to a new requirement. 178 The on-demand, dynamic nature of deployment essentially requires that 179 the network security "devices" be in software or virtual form 180 factors, rather than in a physical appliance form. (This is a 181 provider-side concern. Users of the firewall service are agnostic, as 182 they should, as to whether or not the firewall service is run on a VM 183 or any other form factor. Indeed, they may not even be aware that 184 their traffic traverses firewalls.) 186 Furthermore, new firewall instances need to be placed in the "right 187 zone" (domain). The issue applies not only to multi-tenant 188 environments where getting the tenant right is of paramount 189 importance but also to environments owned and operated by a single 190 organization with its own service segregation policies. For example, 191 an enterprise may mandate that firewalls serving Internet traffic and 192 business-to-business (B2B) traffic be separate; or that IPS/IDS 193 services for investment banking and non-banking traffic be separate 194 for regulatory reasons. 196 4.1 On demand virtual firewall deployment in cloud data centers 198 A service provider operated cloud data center could serve tens of 199 thousands of clients. Clients' compute servers are typically hosted 200 on virtual machines (VMs), which could be deployed across different 201 server racks located in different parts of the data center. It is 202 often not technically and/or financially feasible to deploy dedicated 203 physical firewalls to suit each client's myriad security policy 204 requirements. What is needed is the ability to dynamically deploy 205 virtual firewalls for each client's set of servers based on 206 established security policies and underlying network topologies. 208 ---+-----------------------------+----- 209 | | 210 +---+ +-+-+ 211 |vFW| |vFW| 212 +---+ +-+-+ 213 | Client #1 | Client #2 214 ---+-------+--- ---+-------+--- 215 +-+-+ +-+-+ +-+-+ +-+-+ 216 |vM | |vM | |vM | |vM | 217 +---+ +---+ +---+ +---+ 219 5. Firewall policy deployment automation 221 Firewall configuration today is a highly complex process that 222 involves consulting established security policies, translating those 223 policies into firewall rules, further translating those rules into 224 vendor-specific configuration sets, identifying all the firewalls, 225 and pushing configurations to those firewalls. 227 This is often a time consuming, complex and error-prone process even 228 within a single organization/enterprise framework. It becomes far 229 more complex in provider-owned cloud networks that serve myriad 230 customers. 232 Automation can help address many of these issues. Automation works 233 best when it can leverage a common set of standards that will work 234 across multiple entities. 236 5.1 Client-specific security policy in cloud VPNs 238 Clients of service provider operated cloud data centers need not only 239 secure virtual private networks (VPNs) but also virtual security 240 functions that enforce the clients' security policies. The security 241 policies may govern communications within the clients' own virtual 242 networks and those with external networks. For example, VPN service 243 providers may need to provide firewall and other security services to 244 their VPN clients. Today, it is generally not possible for clients to 245 dynamically view, much less change, what, where and how security 246 policies are implemented on their provider-operated clouds. Indeed, 247 no standards-based framework that allows clients to retrieve/manage 248 security policies in a consistent manner across different providers 249 exists. 251 6. Key requirements for the use cases 253 The I2NSF framework should provide a set of standard interfaces that 254 facilitate: 256 * Dynamic creation, enablement, disablement, and removal of 257 network security applications; 259 * Policy-driven placement of new service instances in the right 260 administrative domain; 262 * Attachment of appropriate security and traffic policies to the 263 service instances 264 * Management of deployed instances in terms of fault monitoring, 265 utilization monitoring, event logging, inventory, etc. 267 Moreover, an I2NSF must support different deployment scenarios: 269 * Single and multi-tenant environments: The term multi-tenant does 270 not mean just different companies subscribing to a provider's 271 cloud offering. It can for instance cover administrative 272 domains/departments within a single firm that require different 273 security and traffic policies. 275 * Premise-agnostic: Said network security services may be deployed 276 on premises or off premises of an organization. 278 The I2NSF framework should provide a standard set of interfaces that 279 enable: 281 * Translation of security policies into functional tasks. Security 282 policies may be carried out by one or more security service 283 functions. For example, a security policy may be translated into 284 an IDS/IPS policy and a firewall policy for a given application 285 type. 287 * Translation of functional tasks into vendor-specific 288 configuration sets. For example, a firewall policy needs to be 289 converted to vendor-specific configurations. 291 * Retrieval of information such as configuration, utilization, 292 status, etc. Such information may be used for monitoring, 293 auditing, troubleshooting purposes. The above functions should be 294 available in single- or multi-tenant environments as well as on- 295 premise or off-premise clouds. 297 7. Conclusion 299 The need for common interfaces to network service functions goes 300 beyond network security functions described here. Efforts like NFV 301 will drive efforts to address this broad need. This draft covers 302 common network security functions deployed in data centers as a way 303 to scope the problem set. The use cases here are relevant to service 304 provider and large enterprise networks, and they can all benefit 305 significantly from an I2NSF. 307 We recommend the IETF to start a program to establish a common 308 framework for network security functions that will address the issues 309 raised here. 311 8. Security considerations 313 TBD. 315 9. IANA considerations 317 This document requires no IANA actions. RFC Editor: Please remove 318 this section before publication. 320 10. References 322 10.1 Normative references 324 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 325 Requirement Levels", BCP 14, RFC 2119, March 1997. 327 [RFC7297] Boucadair, M., "IP Connectivity Provisioning Profile", 328 RFC7297, April 2014. 330 10.2 Informative references 332 [PS] Dunbar, et al, "Dynamic Network Security as a Service Problem 333 Statement", , July 2014. 335 [GS-NFV] ETSI NFV Group Specification, Network Functions 336 Virtualizsation (NFV) Use Cases. ETSI GS NFV 001v1.1.1, 2013. 338 [Boucadair-framework] Boucadair, M., et al, "Differentiated Service 339 Function Chaining Framework", ; Aug 2013 342 [SC-MobileNetwork] Haeffner, W. and N. Leymann, "Network Based 343 Services in Mobile Network", IETF87 Berlin, July 29, 2013 345 [Application-SDN] Giacomonni, J., "Application Layer SDN", Layer 123 346 ONF Presentation, Singapore, June 2013 348 11. Acknowledgments 350 We would like to acknowledge Andrew Malis for his review and 351 contribution. 353 12. Authors' addresses 355 Myo Zarny 356 Goldman Sachs 357 Email: myo.zarny@gs.com 358 Sumandra Majee 359 F5 Netowrks 360 Email: lal2ghar@gmail.com 362 Nic Leymann 363 Deutsche Telekom 364 Email: n.leymann@telekom.de 366 Linda Dunbar 367 Huawei 368 Email: linda.dunbar@huawei.com