Network Working Group M. Zarny Internet Draft Goldman Sachs Intended Status: Informational S. Magee F5 N. Leymann Deutsche Telecom L. Dunbar Huawei Expires: April 28, 2015 October 25, 2014 I2NSF Data Center Use Cases draft-zarny-i2nsf-data-center-use-cases-00 Abstract This document describes data center use cases and their requirements that a common Interface to Network Security Functions (I2NSF) needs to take into account. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. Zarny, et al Expires April 28, 2015 [Page 1] Internet-Draft I2NSF Data Center Use Cases October 25, 2014 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 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. Conventions used in this document . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. On-demand, elastic deployment of firewalls . . . . . . . . . . 4 4.1 On demand virtual firewall deployment in cloud data centers . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Firewall policy deployment automation . . . . . . . . . . . . . 6 5.1 Client-specific security policy in cloud VPNs . . . . . . . 6 6. Key requirements for the use cases . . . . . . . . . . . . . . 6 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Security considerations . . . . . . . . . . . . . . . . . . . . 8 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1 Normative references . . . . . . . . . . . . . . . . . . . 8 10.2 Informative references . . . . . . . . . . . . . . . . . . 8 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 12. Authors' addresses . . . . . . . . . . . . . . . . . . . . . . 8 Zarny, et al Expires April 28, 2015 [Page 2] Internet-Draft I2NSF Data Center Use Cases October 25, 2014 1. Introduction Enterprises today increasingly consume cloud-based network security functions. The reasons are the same as those for the move toward cloud computing: greater economies of scale; faster service delivery; greater flexibility to respond to changing requirements; faster deployment of more sophisticated solutions; among others. The cloud security services can in theory be offered in a number of ways. They can be operated by service providers or enterprises themselves; they can be run on shared or dedicated infrastructure; they can be deployed off- or on-premises; or any combination thereof. In practice, however, since most firms today possess neither the expertise nor resources to build and manage clouds, most firms that consume cloud-based security services do so on off-premise provider- managed clouds. In response, providers and security vendors offer cloud-based models to deliver security solutions. Providers in particular are striving to standardize the offering methodologies through efforts like Network Functions Virtualization (NFV). I2NSF is an IETF effort to standardize the interface for network security functions offered on any kind of cloud regardless of its location or operator. Since the term "network security service" can mean many things, we will limit the term to include only the following services in this draft. * Firewall * DDOS/Anti-DOS (Distributed Denial-of-Service/Anti-Denial-of- Service) * AAA (Authentication, Authorization, Accounting) * Remote identity management * Secure key management * IDS/IPS (Intrusion Detection System/Intrusion Prevention System) 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Zarny, et al Expires April 28, 2015 [Page 3] Internet-Draft I2NSF Data Center Use Cases October 25, 2014 3. Terminology Cloud-scale network resources: Networked resources which provide various functions (related to infrastructure, platform, software, etc.) in a scalable, automated and secure fashion. Resources in the cloud may be fully owned, operated, and used by a single organization; dedicated to a single client and managed by a provider; shared amongst several clients; hosted on-premises or off-premises of an organization; or a combination thereof. In the context of this draft, a cloud offers network security services. DC: Data Center Domain relationships: The term "Domain" in this draft has different connotations in different scenarios: Client <-> Provider relationship, i.e. a client requesting network service functions from its provider; Domain A <-> Domain B relationship, i.e. one operator domain requesting network service functions from another operator domain; or Applications <-> Network relationship, an application (e.g., cluster of servers) requesting some functions from network. Network function: In the context of I2NSF, the term "network function" describes services that provide network functions including L4-L7 functions. The network service functions may not necessarily be owned or hosted by consumers of those functions. Furthermore, the network functions may be hosted on physical appliances, inside containers, or inside VMs instantiated on common compute servers (e.g., the ETSI NFV defined Virtualized Network Functions). Virtual Security Function: A security function that can be requested by one domain but may be owned or managed by another domain. Cloud-based security functions: Used interchangeably with the "Virtual Security Functions" in this draft. 4. On-demand, elastic deployment of firewalls Network security devices such as firewalls may need to be added or removed dynamically for a number of reasons. It may have been explicitly requested by the user, or triggered by a pre-agreed-upon service level agreement (SLA) between the user and the provider of Zarny, et al Expires April 28, 2015 [Page 4] Internet-Draft I2NSF Data Center Use Cases October 25, 2014 the service. For example, the service provider may be required to add more firewall capacity within a set timeframe whenever the bandwidth utilization hits a certain threshold for a specified period. This capacity expansion could result in adding new instances of firewalls. Likewise, a service provider may need to provision a new firewall instance in a completely new environment due to a new requirement. The on-demand, dynamic nature of deployment essentially requires that the network security "devices" be in software or virtual form factors, rather than in a physical appliance form. (This is a provider-side concern. Users of the firewall service are agnostic, as they should, as to whether or not the firewall service is run on a VM or any other form factor. Indeed, they may not even be aware that their traffic traverses firewalls.) Furthermore, new firewall instances need to be placed in the "right zone" (domain). The issue applies not only to multi-tenant environments where getting the tenant right is of paramount importance but also to environments owned and operated by a single organization with its own service segregation policies. For example, an enterprise may mandate that firewalls serving Internet traffic and business-to-business (B2B) traffic be separate; or that IPS/IDS services for investment banking and non-banking traffic be separate for regulatory reasons. 4.1 On demand virtual firewall deployment in cloud data centers A service provider operated cloud data center could serve tens of thousands of clients. Clients' compute servers are typically hosted on virtual machines (VMs), which could be deployed across different server racks located in different parts of the data center. It is often not technically and/or financially feasible to deploy dedicated physical firewalls to suit each client's myriad security policy requirements. What is needed is the ability to dynamically deploy virtual firewalls for each client's set of servers based on established security policies and underlying network topologies. ---+-----------------------------+----- | | +---+ +-+-+ |vFW| |vFW| +---+ +-+-+ | Client #1 | Client #2 ---+-------+--- ---+-------+--- +-+-+ +-+-+ +-+-+ +-+-+ |vM | |vM | |vM | |vM | +---+ +---+ +---+ +---+ Zarny, et al Expires April 28, 2015 [Page 5] Internet-Draft I2NSF Data Center Use Cases October 25, 2014 5. Firewall policy deployment automation Firewall configuration today is a highly complex process that involves consulting established security policies, translating those policies into firewall rules, further translating those rules into vendor-specific configuration sets, identifying all the firewalls, and pushing configurations to those firewalls. This is often a time consuming, complex and error-prone process even within a single organization/enterprise framework. It becomes far more complex in provider-owned cloud networks that serve myriad customers. Automation can help address many of these issues. Automation works best when it can leverage a common set of standards that will work across multiple entities. 5.1 Client-specific security policy in cloud VPNs Clients of service provider operated cloud data centers need not only secure virtual private networks (VPNs) but also virtual security functions that enforce the clients' security policies. The security policies may govern communications within the clients' own virtual networks and those with external networks. For example, VPN service providers may need to provide firewall and other security services to their VPN clients. Today, it is generally not possible for clients to dynamically view, much less change, what, where and how security policies are implemented on their provider-operated clouds. Indeed, no standards-based framework that allows clients to retrieve/manage security policies in a consistent manner across different providers exists. 6. Key requirements for the use cases The I2NSF framework should provide a set of standard interfaces that facilitate: * Dynamic creation, enablement, disablement, and removal of network security applications; * Policy-driven placement of new service instances in the right administrative domain; * Attachment of appropriate security and traffic policies to the service instances Zarny, et al Expires April 28, 2015 [Page 6] Internet-Draft I2NSF Data Center Use Cases October 25, 2014 * Management of deployed instances in terms of fault monitoring, utilization monitoring, event logging, inventory, etc. Moreover, an I2NSF must support different deployment scenarios: * Single and multi-tenant environments: The term multi-tenant does not mean just different companies subscribing to a provider's cloud offering. It can for instance cover administrative domains/departments within a single firm that require different security and traffic policies. * Premise-agnostic: Said network security services may be deployed on premises or off premises of an organization. The I2NSF framework should provide a standard set of interfaces that enable: * Translation of security policies into functional tasks. Security policies may be carried out by one or more security service functions. For example, a security policy may be translated into an IDS/IPS policy and a firewall policy for a given application type. * Translation of functional tasks into vendor-specific configuration sets. For example, a firewall policy needs to be converted to vendor-specific configurations. * Retrieval of information such as configuration, utilization, status, etc. Such information may be used for monitoring, auditing, troubleshooting purposes. The above functions should be available in single- or multi-tenant environments as well as on- premise or off-premise clouds. 7. Conclusion The need for common interfaces to network service functions goes beyond network security functions described here. Efforts like NFV will drive efforts to address this broad need. This draft covers common network security functions deployed in data centers as a way to scope the problem set. The use cases here are relevant to service provider and large enterprise networks, and they can all benefit significantly from an I2NSF. We recommend the IETF to start a program to establish a common framework for network security functions that will address the issues raised here. Zarny, et al Expires April 28, 2015 [Page 7] Internet-Draft I2NSF Data Center Use Cases October 25, 2014 8. Security considerations TBD. 9. IANA considerations This document requires no IANA actions. RFC Editor: Please remove this section before publication. 10. References 10.1 Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC7297] Boucadair, M., "IP Connectivity Provisioning Profile", RFC7297, April 2014. 10.2 Informative references [PS] Dunbar, et al, "Dynamic Network Security as a Service Problem Statement", , July 2014. [GS-NFV] ETSI NFV Group Specification, Network Functions Virtualizsation (NFV) Use Cases. ETSI GS NFV 001v1.1.1, 2013. [Boucadair-framework] Boucadair, M., et al, "Differentiated Service Function Chaining Framework", ; Aug 2013 [SC-MobileNetwork] Haeffner, W. and N. Leymann, "Network Based Services in Mobile Network", IETF87 Berlin, July 29, 2013 [Application-SDN] Giacomonni, J., "Application Layer SDN", Layer 123 ONF Presentation, Singapore, June 2013 11. Acknowledgments We would like to acknowledge Andrew Malis for his review and contribution. 12. Authors' addresses Myo Zarny Goldman Sachs Email: myo.zarny@gs.com Zarny, et al Expires April 28, 2015 [Page 8] Internet-Draft I2NSF Data Center Use Cases October 25, 2014 Sumandra Majee F5 Netowrks Email: lal2ghar@gmail.com Nic Leymann Deutsche Telekom Email: n.leymann@telekom.de Linda Dunbar Huawei Email: linda.dunbar@huawei.com Zarny, et al Expires April 28, 2015 [Page 9]