Network Working Group A. Pastor Internet-Draft D. Lopez Intended status: Experimental Telefonica I+D Expires: April 28, 2015 October 25, 2014 Access Use Cases for an Open OAM Interface to Virtualized Security Services draft-pastor-i2nsf-access-usecases-00 Abstract This document describes the use cases for providing network security as a service in the access network environment. It considers both mobile and residential access. 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 28, 2015. Copyright Notice Copyright (c) 2014 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 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. Pastor & Lopez Expires April 28, 2015 [Page 1] Internet-Draft Access Use Cases for I2NSF October 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 4 3. Actors in the Access Environment . . . . . . . . . . . . . . . 4 4. Operator-Managed Security Functions . . . . . . . . . . . . . . 4 4.1. vNSF Deployment . . . . . . . . . . . . . . . . . . . . . . 5 4.2. vNSF Customer Provisioning . . . . . . . . . . . . . . . . 5 5. Customer-Managed Security Functions . . . . . . . . . . . . . . 5 5.1. Self-Provisioning . . . . . . . . . . . . . . . . . . . . . 5 5.2. Validation . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Policies and Configuration . . . . . . . . . . . . . . . . . . 6 7. Security Functions at the Access Network . . . . . . . . . . . 7 7.1. Traffic Inspection . . . . . . . . . . . . . . . . . . . . 7 7.2. Traffic Manipulation . . . . . . . . . . . . . . . . . . . 7 7.3. Impersonation . . . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Pastor & Lopez Expires April 28, 2015 [Page 2] Internet-Draft Access Use Cases for I2NSF October 2014 1. Introduction This document describes the use cases for an open OAM interfce to virtualized network security services in residential and mobile network access. Not only enterprise customers, but also residential and mobile ones are becoming more and more aware of the need for security, just to find that security services are hard to operate and become expensive in the case of reasonably sophisticated ones. This general trend has caused that numerous operators and security vendors start to leverage cloud-based models to deliver security solutions. In particular, the methods around Network Function Virtualization (NFV) are meant to facilitate the management of various resources for the benefit of customers, who may not own or physically host those network functions. This document analyzes the use cases for the provision, operation and management of virtualized Network Security Function (vNSF) in the access network environment, as shown in the following figure. Customer + Access + Core | | +--------+ | ,-----+--. |Network | | ,' | `-|Operator| +-----------+ | /+----+ | |Mgmt Sys| |Residential|-+------/-+vCPE+----+ +--------+ +-----------+ | / +----+ | \ : | / | \ | | ; | +----+ | | | | |vNSF| | | : | +----+ | | : | / | +--------+ | : +----+ | / ; |Mobile |-+-----\--+vEPC+----+ / +--------+ | \ +----+ | ISP ,-' | `--. | _.-' | `----+----'' + + Figure 1: Customer Access Network Pastor & Lopez Expires April 28, 2015 [Page 3] Internet-Draft Access Use Cases for I2NSF October 2014 2. Requirements Language 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 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. 3. Actors in the Access Environment Different types of actors can use an open OAM interface to the vNSFs to allocate and operate network security functions. The envisioned actors are: o Network operators that provide and manage vNSF in their administrative domain or through external providers. o Customers, accessing through the Network Operator, and requiring a security service implemented by one or more vNSF. The access network technology environment also defines the characteristics of the type of access in each use case: o Closed environments where there is only one administrative network domain. More permissive access controls and lighter validation shall be allowed inside the domain because of the protected environment. Integration with existing identity management systems is also possible. o Open environments where some vNSFs can be hosted in external administrative domains, and more restrictive security controls are required. The interfaces to the vNSFs must use trusted channels. Identity frameworks and federations are common models for authentication and Authorization. 4. Operator-Managed Security Functions The Virtual CPE described in [NFVUC] use cases #5 and #7 cover the model of virtualization for mobile and residential access, where the operator may offload security services from the customer local environment (or even the terminal) to the operator infrastructure supporting the access network. This use case defines the operator interaction with vNSF through Pastor & Lopez Expires April 28, 2015 [Page 4] Internet-Draft Access Use Cases for I2NSF October 2014 automated interfaces, typically by B2B communications performed by the operator management systems (OSS/BSS). 4.1. vNSF Deployment The deployment process consists of instantiating a vNSF on a Virtualization Infrastructure (NFVI), within the operator administrative domain(s) or an external domain. This is a required step before a customer can subscribe to a security service supported in the vNSF. 4.2. vNSF Customer Provisioning Once a vNSF is deployed, any customer can subscribe to it. The provisioning lifecycle includes: o Customer enrollment and cancellation of the subscription to a vNSF. o Configuration of the vNSF, based on specific configurations or derived from common security policies defined by the operator. o Retrieve and list of the vNSF functionalities, extracted from a manifest or a descriptor. The network operator management systems can demand this information to offer detailed information through the commercial channels to the customer. 5. Customer-Managed Security Functions This is an alternative use case where the management is delegated directly to the customer. The open OAM interface permits direct interactions between the vNSF and the customer. This allows customers to have dynamic and flexible interactions with security services, more adequate for dynamic allocation of these virtualized security services. 5.1. Self-Provisioning This process allows a residential or mobile customer to enroll on its own to a security service provided by a vNSF or a set of vNSF. The open OAM interface must support the enrollment process. 5.2. Validation Customers MAY require to validate vNSF availability, provenance, and its correct execution. The validation process includes at least: Pastor & Lopez Expires April 28, 2015 [Page 5] Internet-Draft Access Use Cases for I2NSF October 2014 o Integrity of the vNSF. The vNSF is not manipulated. o Isolation. The execution of the vNSF is self-contained for privacy requirements in multi-tenancy scenarios. 6. Policies and Configuration vNSF configurations can vary from simple rules (i.e. block a DDoS attack) to very complex configuration ( i.e. define a user firewall rules per application, protocol, source and destination port and address). The possibility of using configuration templates per vNSF type is a common option as well. The operator can push security policies using complex configurations in their managed vNSF through its management system. The open OAM interface has to accommodate this application-driven behavior. Computer-savvy customers may pursue a similar application-driven configuration through the open OAM interface, but standard residential and mobile customers may prefer to use the definition of security policies in the form of close-to-natural-language sentences with high-level directives or a guide configuration process. The representation for these policies will be of the form: +-------+ +------+ +------+ +------------------+ |Subject| + |Action| + |Object| + |Field_type = Value| +-------+ +------+ +------+ +------------------+ Figure 2: High-Level Security Policy Format Subject indicates the customer or device in the access. Action can include a variety of actions: check, redirect, allow, block, record, inspect... Object can be optional and specifies the nature of the action. The default is all the customer traffic, but others possible values are connections and connections attempts. Field_type allows to create fine-grained policies, including destinations list (i.e. IPs, domains), content types (i.e. files, emails), windows of time (i.e. weekend), protocol or network service (i.e. HTTP). An example of a customer policy is: Pastor & Lopez Expires April 28, 2015 [Page 6] Internet-Draft Access Use Cases for I2NSF October 2014 "My son is allowed to access Facebook from 18:30 to 20:00" 7. Security Functions at the Access Network This section collects a representative list of use cases of possible vNSFs that requires an open OAM interface for control and management. 7.1. Traffic Inspection A common use case for customers accessing the Internet or additional services through it is security supervision. Some examples are: o Intrusion detection systems o Deep packet inspection o Data leakage protection An open OAM interface will allow the configuration of the vNSF inspection features: signatures updates, behavioral parameters or type of traffic to supervise. 7.2. Traffic Manipulation A more intrusive use case of vNSF includes the capacity of manipulate the traffic at the access network segment. Some examples are: o Redirect traffic, as in the case of captive portals o Block traffic: Firewalls, intrusion prevention system, anti-DoS mechanisms... o Encrypt traffic: VPN services that encapsulate and encrypt the user traffic. A SSL VPN is a representative example. An open OAM interface will allow the configuration of the vNSF manipulation features, such as redirect and block rules. 7.3. Impersonation Some vNSFs can impersonate a customer service or Internet service to provide security functions. Some examples are: o Honeypots, impersonating customer services, such as HTTP, NetBios or SSH Pastor & Lopez Expires April 28, 2015 [Page 7] Internet-Draft Access Use Cases for I2NSF October 2014 o Anonymization services, hiding the source identity, as in the case of TOR An open OAM interface will allow the configuration of the vNSF impersonation features, like the service to impersonate. 8. Security Considerations TBD 9. IANA Considerations This document requires no IANA actions. 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. 10.2. Informative References [NFVUC] "ETSI NFV Group Specification, Network Functions Virtualization (NFV) Use Cases", . Authors' Addresses Antonio Pastor Telefonica I+D Don Ramon de la Cruz, 82 Madrid, 28006 Spain Phone: +34 913 128 778 Email: antonio.pastorperales@telefonica.com Pastor & Lopez Expires April 28, 2015 [Page 8] Internet-Draft Access Use Cases for I2NSF October 2014 Diego R. Lopez Telefonica I+D Don Ramon de la Cruz, 82 Madrid, 28006 Spain Phone: +34 913 129 041 Email: diego.r.lopez@telefonica.com Pastor & Lopez Expires April 28, 2015 [Page 9]