Internet DRAFT - draft-pastor-i2nsf-access-usecases
draft-pastor-i2nsf-access-usecases
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", <http://www.etsi.org/
deliver/etsi_gs/NFV/001_099/001/01.01.01_60/
gs_NFV001v010101p.pdf>.
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]
