idnits 2.17.1 draft-pastor-i2nsf-access-usecases-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 date (October 25, 2014) is 3471 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Pastor 3 Internet-Draft D. Lopez 4 Intended status: Experimental Telefonica I+D 5 Expires: April 28, 2015 October 25, 2014 7 Access Use Cases for an Open OAM Interface to Virtualized Security 8 Services 9 draft-pastor-i2nsf-access-usecases-00 11 Abstract 13 This document describes the use cases for providing network security 14 as a service in the access network environment. It considers both 15 mobile and residential access. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 28, 2015. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 4 53 3. Actors in the Access Environment . . . . . . . . . . . . . . . 4 54 4. Operator-Managed Security Functions . . . . . . . . . . . . . . 4 55 4.1. vNSF Deployment . . . . . . . . . . . . . . . . . . . . . . 5 56 4.2. vNSF Customer Provisioning . . . . . . . . . . . . . . . . 5 57 5. Customer-Managed Security Functions . . . . . . . . . . . . . . 5 58 5.1. Self-Provisioning . . . . . . . . . . . . . . . . . . . . . 5 59 5.2. Validation . . . . . . . . . . . . . . . . . . . . . . . . 5 60 6. Policies and Configuration . . . . . . . . . . . . . . . . . . 6 61 7. Security Functions at the Access Network . . . . . . . . . . . 7 62 7.1. Traffic Inspection . . . . . . . . . . . . . . . . . . . . 7 63 7.2. Traffic Manipulation . . . . . . . . . . . . . . . . . . . 7 64 7.3. Impersonation . . . . . . . . . . . . . . . . . . . . . . . 7 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 69 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 This document describes the use cases for an open OAM interfce to 75 virtualized network security services in residential and mobile 76 network access. 78 Not only enterprise customers, but also residential and mobile ones 79 are becoming more and more aware of the need for security, just to 80 find that security services are hard to operate and become expensive 81 in the case of reasonably sophisticated ones. This general trend has 82 caused that numerous operators and security vendors start to leverage 83 cloud-based models to deliver security solutions. In particular, the 84 methods around Network Function Virtualization (NFV) are meant to 85 facilitate the management of various resources for the benefit of 86 customers, who may not own or physically host those network 87 functions. 89 This document analyzes the use cases for the provision, operation and 90 management of virtualized Network Security Function (vNSF) in the 91 access network environment, as shown in the following figure. 93 Customer + Access + Core 94 | | +--------+ 95 | ,-----+--. |Network | 96 | ,' | `-|Operator| 97 +-----------+ | /+----+ | |Mgmt Sys| 98 |Residential|-+------/-+vCPE+----+ +--------+ 99 +-----------+ | / +----+ | \ : 100 | / | \ | 101 | ; | +----+ | 102 | | | |vNSF| | 103 | : | +----+ | 104 | : | / | 105 +--------+ | : +----+ | / ; 106 |Mobile |-+-----\--+vEPC+----+ / 107 +--------+ | \ +----+ | ISP ,-' 108 | `--. | _.-' 109 | `----+----'' 110 + + 112 Figure 1: Customer Access Network 114 2. Requirements Language 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 In this document, these words will appear with that interpretation 121 only when in ALL CAPS. Lower case uses of these words are not to be 122 interpreted as carrying RFC-2119 significance. 124 3. Actors in the Access Environment 126 Different types of actors can use an open OAM interface to the vNSFs 127 to allocate and operate network security functions. The envisioned 128 actors are: 130 o Network operators that provide and manage vNSF in their 131 administrative domain or through external providers. 133 o Customers, accessing through the Network Operator, and requiring a 134 security service implemented by one or more vNSF. 136 The access network technology environment also defines the 137 characteristics of the type of access in each use case: 139 o Closed environments where there is only one administrative network 140 domain. More permissive access controls and lighter validation 141 shall be allowed inside the domain because of the protected 142 environment. Integration with existing identity management 143 systems is also possible. 145 o Open environments where some vNSFs can be hosted in external 146 administrative domains, and more restrictive security controls are 147 required. The interfaces to the vNSFs must use trusted channels. 148 Identity frameworks and federations are common models for 149 authentication and Authorization. 151 4. Operator-Managed Security Functions 153 The Virtual CPE described in [NFVUC] use cases #5 and #7 cover the 154 model of virtualization for mobile and residential access, where the 155 operator may offload security services from the customer local 156 environment (or even the terminal) to the operator infrastructure 157 supporting the access network. 159 This use case defines the operator interaction with vNSF through 160 automated interfaces, typically by B2B communications performed by 161 the operator management systems (OSS/BSS). 163 4.1. vNSF Deployment 165 The deployment process consists of instantiating a vNSF on a 166 Virtualization Infrastructure (NFVI), within the operator 167 administrative domain(s) or an external domain. This is a required 168 step before a customer can subscribe to a security service supported 169 in the vNSF. 171 4.2. vNSF Customer Provisioning 173 Once a vNSF is deployed, any customer can subscribe to it. The 174 provisioning lifecycle includes: 176 o Customer enrollment and cancellation of the subscription to a 177 vNSF. 179 o Configuration of the vNSF, based on specific configurations or 180 derived from common security policies defined by the operator. 182 o Retrieve and list of the vNSF functionalities, extracted from a 183 manifest or a descriptor. The network operator management systems 184 can demand this information to offer detailed information through 185 the commercial channels to the customer. 187 5. Customer-Managed Security Functions 189 This is an alternative use case where the management is delegated 190 directly to the customer. The open OAM interface permits direct 191 interactions between the vNSF and the customer. This allows 192 customers to have dynamic and flexible interactions with security 193 services, more adequate for dynamic allocation of these virtualized 194 security services. 196 5.1. Self-Provisioning 198 This process allows a residential or mobile customer to enroll on its 199 own to a security service provided by a vNSF or a set of vNSF. The 200 open OAM interface must support the enrollment process. 202 5.2. Validation 204 Customers MAY require to validate vNSF availability, provenance, and 205 its correct execution. The validation process includes at least: 207 o Integrity of the vNSF. The vNSF is not manipulated. 209 o Isolation. The execution of the vNSF is self-contained for 210 privacy requirements in multi-tenancy scenarios. 212 6. Policies and Configuration 214 vNSF configurations can vary from simple rules (i.e. block a DDoS 215 attack) to very complex configuration ( i.e. define a user firewall 216 rules per application, protocol, source and destination port and 217 address). The possibility of using configuration templates per vNSF 218 type is a common option as well. 220 The operator can push security policies using complex configurations 221 in their managed vNSF through its management system. The open OAM 222 interface has to accommodate this application-driven behavior. 224 Computer-savvy customers may pursue a similar application-driven 225 configuration through the open OAM interface, but standard 226 residential and mobile customers may prefer to use the definition of 227 security policies in the form of close-to-natural-language sentences 228 with high-level directives or a guide configuration process. The 229 representation for these policies will be of the form: 231 +-------+ +------+ +------+ +------------------+ 232 |Subject| + |Action| + |Object| + |Field_type = Value| 233 +-------+ +------+ +------+ +------------------+ 235 Figure 2: High-Level Security Policy Format 237 Subject indicates the customer or device in the access. 239 Action can include a variety of actions: check, redirect, allow, 240 block, record, inspect... 242 Object can be optional and specifies the nature of the action. The 243 default is all the customer traffic, but others possible values are 244 connections and connections attempts. 246 Field_type allows to create fine-grained policies, including 247 destinations list (i.e. IPs, domains), content types (i.e. files, 248 emails), windows of time (i.e. weekend), protocol or network service 249 (i.e. HTTP). 251 An example of a customer policy is: 253 "My son is allowed to access Facebook from 18:30 to 20:00" 255 7. Security Functions at the Access Network 257 This section collects a representative list of use cases of possible 258 vNSFs that requires an open OAM interface for control and management. 260 7.1. Traffic Inspection 262 A common use case for customers accessing the Internet or additional 263 services through it is security supervision. Some examples are: 265 o Intrusion detection systems 267 o Deep packet inspection 269 o Data leakage protection 271 An open OAM interface will allow the configuration of the vNSF 272 inspection features: signatures updates, behavioral parameters or 273 type of traffic to supervise. 275 7.2. Traffic Manipulation 277 A more intrusive use case of vNSF includes the capacity of manipulate 278 the traffic at the access network segment. Some examples are: 280 o Redirect traffic, as in the case of captive portals 282 o Block traffic: Firewalls, intrusion prevention system, anti-DoS 283 mechanisms... 285 o Encrypt traffic: VPN services that encapsulate and encrypt the 286 user traffic. A SSL VPN is a representative example. 288 An open OAM interface will allow the configuration of the vNSF 289 manipulation features, such as redirect and block rules. 291 7.3. Impersonation 293 Some vNSFs can impersonate a customer service or Internet service to 294 provide security functions. Some examples are: 296 o Honeypots, impersonating customer services, such as HTTP, NetBios 297 or SSH 299 o Anonymization services, hiding the source identity, as in the case 300 of TOR 302 An open OAM interface will allow the configuration of the vNSF 303 impersonation features, like the service to impersonate. 305 8. Security Considerations 307 TBD 309 9. IANA Considerations 311 This document requires no IANA actions. 313 10. References 315 10.1. Normative References 317 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 318 Requirement Levels", BCP 14, RFC 2119, March 1997. 320 10.2. Informative References 322 [NFVUC] "ETSI NFV Group Specification, Network Functions 323 Virtualization (NFV) Use Cases", . 327 Authors' Addresses 329 Antonio Pastor 330 Telefonica I+D 331 Don Ramon de la Cruz, 82 332 Madrid, 28006 333 Spain 335 Phone: +34 913 128 778 336 Email: antonio.pastorperales@telefonica.com 337 Diego R. Lopez 338 Telefonica I+D 339 Don Ramon de la Cruz, 82 340 Madrid, 28006 341 Spain 343 Phone: +34 913 129 041 344 Email: diego.r.lopez@telefonica.com