idnits 2.17.1 draft-pastor-i2nsf-merged-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 (June 26, 2015) is 3227 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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: December 28, 2015 K. Wang 6 X. Zhuang 7 M. Qi 8 China Mobile 9 M. Zarny 10 Goldman Sachs 11 S. Majee 12 F5 Networks 13 N. Leymann 14 Deutsche Telekom 15 L. Dunbar 16 Huawei 17 M. Georgiades 18 PrimeTel 19 June 26, 2015 21 Use Cases and Requirements for an Interface to Network Security 22 Functions 23 draft-pastor-i2nsf-merged-use-cases-00 25 Abstract 27 This document describes use cases and requirements for a common 28 interface to Network Security Functions (NSF). It considers several 29 use cases, organized in two basic scenarios. In the access network 30 scenario, mobile and residential users access NSF capabilities using 31 their network service provider infrastructure. In the data center 32 scenario customers manage NSFs hosted in the data center 33 infrastructure. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on December 28, 2015. 51 Copyright Notice 53 Copyright (c) 2015 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 70 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 4. General Use Cases . . . . . . . . . . . . . . . . . . . . . . 5 72 4.1. Instantiation and Configuration of NSFs . . . . . . . . . 6 73 4.2. Updating of NSFs . . . . . . . . . . . . . . . . . . . . . 6 74 4.3. Collecting the Status of NSFs . . . . . . . . . . . . . . 6 75 4.4. Validation of NSFs . . . . . . . . . . . . . . . . . . . . 7 76 5. Access Network Scenario . . . . . . . . . . . . . . . . . . . 7 77 5.1. vNSF Deployment . . . . . . . . . . . . . . . . . . . . . 7 78 5.2. vNSF Customer Provisioning . . . . . . . . . . . . . . . . 7 79 6. Cloud Datacenter Scenario . . . . . . . . . . . . . . . . . . 8 80 6.1. On-Demand Virtual Firewall Deployment . . . . . . . . . . 8 81 6.2. Firewall Policy Deployment Automation . . . . . . . . . . 9 82 6.2.1. Client-Specific Security Policy in Cloud VPNs . . . . 9 83 7. Considerations on Policy and Configuration . . . . . . . . . . 10 84 7.1. Translating Policies into NSF Capabilities . . . . . . . . 11 85 8. Key Requirements . . . . . . . . . . . . . . . . . . . . . . . 12 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 87 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 90 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 93 1. Introduction 95 Not only enterprise customers, but also residential and mobile ones 96 are becoming more and more aware of the need for network security, 97 just to find that security services are hard to operate and become 98 expensive in the case of reasonably sophisticated ones. This general 99 trend has caused numerous operators and security vendors to start to 100 leverage on cloud-based models to deliver security solutions. In 101 particular, the methods around Network Function Virtualization (NFV) 102 are meant to facilitate the elastic deployment of software images 103 providing the network services, and require the management of various 104 resources by customers, who may not own or physically host those 105 network functions. 107 There are numerous benefits by defining such interfaces. Operators 108 could provide more flexible and customized security services for 109 specific users and this would provide more efficient and secure 110 protection to each user. 112 This document analyzes the use cases for the provisioning, operation 113 and management of Network Security Functions (NSF) in the access 114 network environment, and cloud-based services as shown in the 115 following figure. 117 Customer + Access + PoP/Datacenter 118 | | +--------+ 119 | ,-----+--. |Network | 120 | ,' | `-|Operator| 121 +-------------+ | /+----+ | |Mgmt Sys| 122 | Residential |-+------/-+vCPE+----+ +--------+ 123 +-------------+ | / +----+ | \ | : 124 | / | \ | | 125 +-------+ | ; +----+ | +----+ | 126 | Cloud |---+---+----+ vPE+--+----+ NSF| | 127 +-------+ | : +----+ | +----+ | 128 | : | / | 129 +--------+ | : +----+ | / ; 130 | Mobile |-+-----\--+vEPC+----+ / 131 +--------+ | \ +----+ | ,-' 132 | `--. | _.-' 133 | `----+----'' 134 + + 136 Figure 1: NSF and actors 138 2. Requirements Language 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 In this document, these words will appear with that interpretation 145 only when in ALL CAPS. Lower case uses of these words are not to be 146 interpreted as carrying RFC-2119 significance. 148 3. Terminology 150 Network Security Function (NSF): A functional block within a network 151 infrastructure to ensure integrity, confidentiality and availability 152 of network communications, to detect unwanted activity, and to deter 153 and block this unwanted activity or at least mitigate its effects on 154 the network 156 vNSF: Virtual Network Security Function: A network security function 157 that runs as a software image on a virtualized infrastructure, and 158 can be requested by one domain but may be owned or managed by another 159 domain. 161 NSFs considered in this draft include virtualized and non-virtualized 162 NSFs. 164 4. General Use Cases 166 User request security services through specific clients (a customer 167 app, the NSP BSS/OSS or management platform...) and the appropriate 168 NSP network entity will invoke the (v)NSFs according to the user 169 service request. We will call this network entity the security 170 controller. The interaction between the entities discussed above 171 (client, security controller, NSF) is shown in the following diagram: 173 +----------+ 174 +-------+ | | +-------+ 175 | | Interface 1 |Security | Interface 2 | NSF(s)| 176 |Client <--------------> <------------------> | 177 | | |Controller| | | 178 +-------+ | | +-------+ 179 +----------+ 181 Figure 2: Interaction between Entities 183 Interface 1 is used for receiving security requirements from client 184 and translating them into commands that NSFs can understand and 185 execute. Moreover, it is also responsible for giving feedback of the 186 NSF security statistics to client. Interface 2 is used for 187 interacting with NSFs according to commands, and collect status 188 information about NSFs. 190 4.1. Instantiation and Configuration of NSFs 192 Client sends collected security requirements through Interface 1 to 193 the security controller in the NSP network, which then translates 194 them into a a set of security functions. Then the corresponding NSFs 195 are instantiated and configured through Interface 2. 197 As an example, consider an enterprise user A who wants to prevent a 198 certain kind of traffic from flowing to their network. Such a 199 requirement is sent from client to security controller through 200 Interface 1. The security controller translates the requirement into 201 a firewall function plus a rules for filtering out TCP and/or UDP 202 data packets. Then it instantiates a firewall NSF through Interface 203 2. The corresponding filter rules are also configured onto this 204 firewall NSF through Interface 2. 206 4.2. Updating of NSFs 208 A user can direct the client to require the update of security 209 service functions, including adding/deleting a security service 210 function and updating configurations of former security service 211 function. 213 As an example, consider a user who has instantiated a security 214 service before and decides to enable an additional IDS service. This 215 requirement will be sent to the security controller through Interface 216 1 and be translated, so the security controller instantiates and 217 configures an IDS NSF through Interface 2. 219 4.3. Collecting the Status of NSFs 221 When users want to get the executing status of security service, they 222 can request the status statistics information of NSFs from the 223 client. The security controller will collect NSF status statistics 224 information through Interface 2, consolidate them, and give feedback 225 to client through Interface 1. This interface can be used to collect 226 not only individual service information, but also aggregated data 227 suitable for tasks like infrastructure security assessment. 229 4.4. Validation of NSFs 231 Customers may require to validate NSF availability, provenance, and 232 its correct execution. This validation process, especially relevant 233 for vNSFs, includes at least: 235 o Integrity of the NSF. Ensure that the NSF is not manipulated. 237 o Isolation. The execution of the NSF is self-contained for privacy 238 requirements in multi-tenancy scenarios. 240 In order to achieve this the security controller has to collect 241 security measurements and share them with an independent and trusted 242 third party, allowing the user to attest the NSF by using Interface 1 243 and the information of the trusted third party. 245 5. Access Network Scenario 247 This scenario describes use cases for users (enterprise user, network 248 administrator, residential user...) that request and manage security 249 services hosted in the network service provider (NSP) infrastructure. 250 Given that NSP customers are essentially users of their access 251 networks, the scenario is essentially associated with their 252 characteristics, as well as with the use of vNSFs. 254 The Virtual CPE described in [NFVUC] use cases #5 and #7 cover the 255 model of virtualization for mobile and residential access, where the 256 operator may offload security services from the customer local 257 environment (or even the terminal) to the operator infrastructure 258 supporting the access network. 260 These use cases defines the operator interaction with vNSFs through 261 automated interfaces, typically by B2B communications performed by 262 the operator management systems (OSS/BSS). 264 5.1. vNSF Deployment 266 The deployment process consists of instantiating a NSF on a 267 Virtualization Infrastructure (NFVI), within the NSP administrative 268 domain(s) or with other external domain(s). This is a required step 269 before a customer can subscribe to a security service supported in 270 the vNSF. 272 5.2. vNSF Customer Provisioning 274 Once a vNSF is deployed, any customer can subscribe to it. The 275 provisioning lifecycle includes: 277 o Customer enrollment and cancellation of the subscription to a 278 vNSF. 280 o Configuration of the vNSF, based on specific configurations, or 281 derived from common security policies defined by the NSP. 283 o Retrieve and list of the vNSF functionalities, extracted from a 284 manifest or a descriptor. The NSP management systems can demand 285 this information to offer detailed information through the 286 commercial channels to the customer. 288 6. Cloud Datacenter Scenario 290 In a datacenter, network security mechanisms such as firewalls may 291 need to be added or removed dynamically for a number of reasons. It 292 may be explicitly requested by the user, or triggered by a pre- 293 agreed-upon service level agreement (SLA) between the user and the 294 provider of the service. For example, the service provider may be 295 required to add more firewall capacity within a set timeframe 296 whenever the bandwidth utilization hits a certain threshold for a 297 specified period. This capacity expansion could result in adding new 298 instances of firewalls. Likewise, a service provider may need to 299 provision a new firewall instance in a completely new environment due 300 to a new requirement. 302 The on-demand, dynamic nature of deployment essentially requires that 303 the network security "devices" be in software or virtual form 304 factors, rather than in a physical appliance form. (This is a 305 provider-side concern. Users of the firewall service are agnostic, 306 as they should, as to whether or not the firewall service is run on a 307 VM or any other form factor. Indeed, they may not even be aware that 308 their traffic traverses firewalls.) 310 Furthermore, new firewall instances need to be placed in the "right 311 zone" (domain). The issue applies not only to multi-tenant 312 environments where getting the tenant right is of paramount 313 importance but also to environments owned and operated by a single 314 organization with its own service segregation policies. For example, 315 an enterprise may mandate that firewalls serving Internet traffic and 316 business-to-business (B2B) traffic be separate; or that IPS/IDS 317 services for investment banking and non-banking traffic be separate 318 for regulatory reasons. 320 6.1. On-Demand Virtual Firewall Deployment 322 A service provider operated cloud data center could serve tens of 323 thousands of clients. Clients' compute servers are typically hosted 324 on virtual machines (VMs), which could be deployed across different 325 server racks located in different parts of the data center. It is 326 often not technically and/or financially feasible to deploy dedicated 327 physical firewalls to suit each client's myriad security policy 328 requirements. What is needed is the ability to dynamically deploy 329 virtual firewalls for each client's set of servers based on 330 established security policies and underlying network topologies. 332 ---+-----------------------------+----- 333 | | 334 +---+ +-+-+ 335 |vFW| |vFW| 336 +---+ +-+-+ 337 | Client #1 | Client #2 338 ---+-------+--- ---+-------+--- 339 +-+-+ +-+-+ +-+-+ +-+-+ 340 |vM | |vM | |vM | |vM | 341 +---+ +---+ +---+ +---+ 343 Figure 3: NSF in DataCenter 345 6.2. Firewall Policy Deployment Automation 347 Firewall configuration today is a highly complex process that 348 involves consulting established security policies, translating those 349 policies into firewall rules, further translating those rules into 350 vendor-specific configuration sets, identifying all the firewalls, 351 and pushing configurations to those firewalls. 353 This is often a time consuming, complex and error-prone process even 354 within a single organization/enterprise framework. It becomes far 355 more complex in provider-owned cloud networks that serve myriad 356 customers. 358 Automation can help address many of these issues. Automation works 359 best when it can leverage a common set of standards that will work 360 across multiple entities. 362 6.2.1. Client-Specific Security Policy in Cloud VPNs 364 Clients of service provider operated cloud data centers need not only 365 secure virtual private networks (VPNs) but also virtual security 366 functions that enforce the clients' security policies. The security 367 policies may govern communications within the clients' own virtual 368 networks and those with external networks. For example, VPN service 369 providers may need to provide firewall and other security services to 370 their VPN clients. Today, it is generally not possible for clients 371 to dynamically view, much less change, what, where and how security 372 policies are implemented on their provider-operated clouds. Indeed, 373 no standards-based framework that allows clients to retrieve/manage 374 security policies in a consistent manner across different providers 375 exists. 377 7. Considerations on Policy and Configuration 379 NSF configurations can vary from simple rules (i.e. block a DDoS 380 attack) to very complex configuration ( i.e. define a user firewall 381 rules per application, protocol, source and destination port and 382 address). The possibility of using configuration templates per 383 control and management type is a common option as well. 385 A NSP can push security policies using complex configurations in 386 their managed vNSF through its management system. The open Control 387 and management interface has to accommodate this application-driven 388 behavior. 390 Computer-savvy customers may pursue a similar application-driven 391 configuration through the open Control and management interface, but 392 standard residential and mobile customers may prefer to use the 393 definition of security policies in the form of close-to-natural- 394 language sentences with high-level directives or a guide 395 configuration process. The representation for these policies will be 396 of the form: 398 +-------+ +------+ +------+ +------------------+ 399 |Subject| + |Action| + |Object| + |Field_type = Value| 400 +-------+ +------+ +------+ +------------------+ 402 Figure 4: High-Level Security Policy Format 404 Subject indicates the customer or device in the access. 406 Action can include a variety of intent-based actions: check, 407 redirect, allow, block, record, inspect... 409 Object can be optional and specifies the nature of the action. The 410 default is all the customer traffic, but others possible values are 411 connections and connections attempts. 413 Field_type allows to create fine-grained policies, including 414 destinations list (i.e. IPs, domains), content types (i.e. files, 415 emails), windows of time (i.e. weekend), protocol or network service 416 (i.e. HTTP). 418 An example of a customer policy is: 420 "My son is allowed to access Facebook from 18:30 to 20:00" 422 7.1. Translating Policies into NSF Capabilities 424 Policies expressed in the above model are suitable for what we 425 depicted as Interface 1 in Figure 2. In order to allow the security 426 controller to deal with the different NSFs an intermediate 427 representation used for expressing specific configurations in a 428 device-independent format is required. For this purpose, the 429 definition of a set of security capabilities provides a means for 430 categorizing the actions performed by network security functions. An 431 initial, high-level set of such capabilities consists of: 433 o Identity Management: Includes all services related with identity, 434 authentication and key management. Some examples are: 436 * AAA (Authentication, Authorization, Accounting) services 438 * Remote identity management 440 * Secure key management 442 o Traffic Inspection: A common use case for customers accessing the 443 Internet or additional services through it is security 444 supervision. Control and Management interfaces will allow the 445 configuration of the vNSF inspection features: signatures updates, 446 behavioral parameters or type of traffic to supervise. Some 447 examples are: 449 * IDS/IPS (Intrusion Detection System/Intrusion Prevention System 451 * Deep packet inspection 453 * Data leakage protection 455 o Traffic Manipulation: A more intrusive use case of NSF includes 456 the capacity of manipulate the client traffic. Control and 457 Management interfaces will allow the configuration of the NSF 458 manipulation features, such as redirect and block rules. Some 459 examples are: 461 * Redirect traffic, as in the case of captive portals 463 * Block traffic: Firewalls, intrusion prevention system, DDOS/ 464 Anti-DOS (Distributed Denial-of-Service/Anti-Denial-of-Service) 466 * Encrypt traffic: VPN services that encapsulate and encrypt the 467 user traffic. A SSL VPN is a representative example. 469 o Impersonation:Some NSFs can impersonate a customer service or 470 Internet service to provide security functions. Control and 471 Management interfaces will allow the configuration of the service 472 to impersonate and his behavioral. Some examples are: 474 * Honeypots, impersonating customer services, such as HTTP, 475 NetBios or SSH 477 * Anonymization services, hiding the source identity, as in the 478 case of TOR 480 Service Chain will allow for more than one of the aforementioned 481 functions to engage in a specific order to a particular flow 483 8. Key Requirements 485 The I2NSF framework should provide a set of standard interfaces that 486 facilitate: 488 o Dynamic creation, enablement, disablement, and removal of network 489 security functions; 491 o Policy-driven placement of new function instances in the right 492 administrative domain; 494 o Attachment of appropriate security and traffic policies to the 495 function instances 497 o Management of deployed instances in terms of fault monitoring, 498 utilization monitoring, event logging, inventory, etc. 500 Moreover, an I2NSF must support different deployment scenarios: 502 o Single and multi-tenant environments: The term multi-tenant does 503 not mean just different companies subscribing to a provider's 504 offering. It can for instance cover administrative domains/ 505 departments within a single firm that require different security 506 and traffic policies. 508 o Premise-agnostic: Said network security functions may be deployed 509 on premises or off premises of an organization. 511 The I2NSF framework should provide a standard set of interfaces that 512 enable: 514 o Translation of security policies into functional tasks. Security 515 policies may be carried out by one or more security functions. 516 For example, a security policy may be translated into an IDS/IPS 517 policy and a firewall policy for a given application type. 519 o Translation of functional tasks into vendor-specific configuration 520 sets. For example, a firewall policy needs to be converted to 521 vendor-specific configurations. 523 o Retrieval of information such as configuration, utilization, 524 status, etc. Such information may be used for monitoring, 525 auditing, troubleshooting purposes. The above functionality 526 should be available in single- or multi-tenant environments as 527 well as on-premise or off-premise clouds. 529 9. Security Considerations 531 The relationship between different actors define the security level 532 for the different use cases and must be associated with 533 administrative domains: 535 o Closed environments where there is only one administrative network 536 domain. More permissive access controls and lighter validation 537 shall be allowed inside the domain because of the protected 538 environment. Integration with existing identity management 539 systems is also possible. 541 o Open environments where some NSFs can be hosted in different 542 administrative domains, and more restrictive security controls are 543 required. The interfaces to the NSFs must use trusted channels. 544 Identity frameworks and federations are common models for 545 authentication and Authorization. Security controllers will be in 546 charge of this functionalities. 548 Virtualization applied to NSF environment (vNSF) generate several 549 concerns in security, being one of the most relevant the attestation 550 of the vNSF by the clients. A holistic analysis has been done in 551 [NFVSEC]. 553 10. IANA Considerations 555 This document requires no IANA actions. 557 11. References 558 11.1. Normative References 560 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 561 Requirement Levels", BCP 14, RFC 2119, March 1997. 563 11.2. Informative References 565 [NFVSEC] "ETSI NFV Group Specification, Network Functions 566 Virtualization (NFV) NFV Security; Problem Statement", . 570 [NFVUC] "ETSI NFV Group Specification, Network Functions 571 Virtualization (NFV) Use Cases", . 575 Authors' Addresses 577 Antonio Pastor 578 Telefonica I+D 579 Don Ramon de la Cruz, 82 580 Madrid, 28006 581 Spain 583 Phone: +34 913 128 778 584 Email: antonio.pastorperales@telefonica.com 586 Diego R. Lopez 587 Telefonica I+D 588 Don Ramon de la Cruz, 82 589 Madrid, 28006 590 Spain 592 Phone: +34 913 129 041 593 Email: diego.r.lopez@telefonica.com 595 Ke Wang 596 China Mobile 597 32 Xuanwumenxi Ave,Xicheng District 598 Beijing, 100053 599 China 601 Email: wangkeyj@chinamobile.com 602 Xiaojun Zhuang 603 China Mobile 604 32 Xuanwumenxi Ave,Xicheng District 605 Beijing, 100053 606 China 608 Email: zhuangxiaojun@chinamobile.com 610 Minpeng Qi 611 China Mobile 612 32 Xuanwumenxi Ave,Xicheng District 613 Beijing, 100053 614 China 616 Email: quiminpeng@chinamobile.com 618 Myo Zarny 619 Goldman Sachs 620 30 Hudson Street 621 Jersey City, NJ 07302 622 USA 624 Email: myo.zarny@gs.com 626 Sumandra Majee 627 F5 Networks 629 Email: lal2ghar@gmail.com 631 Nic Leymann 632 Deutsche Telekom 634 Email: n.leymann@telekom.de 636 Linda Dunbar 637 Huawei 639 Email: linda.dunbar@huawei.com 640 Michael Georgiades 641 PrimeTel 643 Email: michaelg@prime-tel.com