idnits 2.17.1 draft-ietf-i2nsf-problem-and-use-cases-03.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 (November 13, 2016) is 2720 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'NFVUC' is mentioned on line 689, but not defined == Unused Reference: 'RFC2119' is defined on line 1031, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netmod-acl-model' is defined on line 1047, but no explicit reference was found in the text == Unused Reference: 'I-D.lopez-i2nsf-packet' is defined on line 1064, but no explicit reference was found in the text == Unused Reference: 'I-D.zarny-i2nsf-data-center-use-cases' is defined on line 1086, but no explicit reference was found in the text == Unused Reference: 'RFC7277' is defined on line 1108, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-06 == Outdated reference: A later version (-05) exists of draft-jeong-i2nsf-sdn-security-services-01 -- Obsolete informational reference (is this intentional?): RFC 7277 (Obsoleted by RFC 8344) Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF S. Hares 3 Internet-Draft Huawei 4 Intended status: Standards Track D. Lopez 5 Expires: May 17, 2017 Telefonica I+D 6 M. Zarny 7 Goldman Sachs 8 C. Jacquenet 9 France Telecom 10 R. Kumar 11 Juniper Networks 12 J. Jeong 13 Sungkyunkwan University 14 November 13, 2016 16 I2NSF Problem Statement and Use cases 17 draft-ietf-i2nsf-problem-and-use-cases-03.txt 19 Abstract 21 This document describes the problem statement for Interface to 22 Network Security Functions (I2NSF) as well as some companion use 23 cases. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 17, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Challenges Facing Security Service Providers . . . . . . 5 63 3.1.1. Diverse Types of Security Functions . . . . . . . . . 5 64 3.1.2. Diverse Interfaces to Control and Monitor NSFs . . . 6 65 3.1.3. More Distributed NSFs and vNSFs . . . . . . . . . . . 7 66 3.1.4. More Demand to Control NSFs Dynamically . . . . . . . 7 67 3.1.5. Demand for Multi-Tenancy to Control and Monitor NSFs 7 68 3.1.6. Lack of Characterization of NSFs and Capability 69 Exchange . . . . . . . . . . . . . . . . . . . . . . 7 70 3.1.7. Lack of Mechanism for NSFs to Utilize External 71 Profiles . . . . . . . . . . . . . . . . . . . . . . 8 72 3.1.8. Lack of Mechanisms to Accept External Alerts to 73 Trigger Automatic Rule and Configuration Changes . . 8 74 3.1.9. Lack of Mechanism for Dynamic Key Distribution to 75 NSFs . . . . . . . . . . . . . . . . . . . . . . . . 9 76 3.2. Challenges Facing Customers . . . . . . . . . . . . . . . 10 77 3.2.1. NSFs from Heterogeneous Administrative Domains . . . 10 78 3.2.2. Today's Control Requests are Vendor Specific . . . . 10 79 3.2.3. Difficulty to Monitor the Execution of Desired 80 Policies . . . . . . . . . . . . . . . . . . . . . . 12 81 3.3. Difficulty to Validate Policies across Multiple Domains . 12 82 3.4. Lack of Standard Interface to Inject Feedback to NSF . . 13 83 3.5. Lack of Standard Interface for Capability Negotiation . . 13 84 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 4.1. Basic Framework . . . . . . . . . . . . . . . . . . . . . 14 86 4.2. Access Networks . . . . . . . . . . . . . . . . . . . . . 15 87 4.3. Cloud Data Center Scenario . . . . . . . . . . . . . . . 18 88 4.3.1. On-Demand Virtual Firewall Deployment . . . . . . . . 18 89 4.3.2. Firewall Policy Deployment Automation . . . . . . . . 19 90 4.3.3. Client-Specific Security Policy in Cloud VPNs . . . . 19 91 4.3.4. Internal Network Monitoring . . . . . . . . . . . . . 20 92 4.4. I2NSF Preventing Distributed DoS in Overlay Networks . . 20 93 5. Management Considerations . . . . . . . . . . . . . . . . . . 21 94 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 95 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 96 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 97 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . 22 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 99 10.1. Normative References . . . . . . . . . . . . . . . . . . 23 100 10.2. Informative References . . . . . . . . . . . . . . . . . 23 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 103 1. Introduction 105 This document describes the problem statement for Interface to 106 Network Security Functions (I2NSF) as well as some I2NSF use cases. 107 A summary of the state of the art in the industry and IETF which is 108 relevant to I2NSF work is documented in 109 [I-D.hares-i2nsf-gap-analysis]. 111 The growing challenges and complexity in maintaining a secure 112 infrastructure, complying with regulatory requirements, and 113 controlling costs are enticing enterprises into consuming network 114 security functions hosted by service providers. The hosted security 115 service is especially attractive to small and medium size enterprises 116 who suffer from a lack of security experts to continuously monitor 117 networks, acquire new skills and propose immediate mitigations to 118 ever increasing sets of security attacks. 120 According to [Gartner-2013], the demand for hosted (or cloud-based) 121 security services is growing. Small and medium-sized businesses 122 (SMBs) are increasingly adopting cloud-based security services to 123 replace on-premises security tools, while larger enterprises are 124 deploying a mix of traditional and cloud-based security services. 126 To meet the demand, more and more service providers are providing 127 hosted security solutions to deliver cost-effective managed security 128 services to enterprise customers. The hosted security services are 129 primarily targeted at enterprises (especially small/medium ones), but 130 could also be provided to any kind of mass-market customer. As a 131 result, the Network Security Functions (NSFs) are provided and 132 consumed in a large variety of environments. Users of NSFs may 133 consume network security services hosted by one or more providers, 134 which may be their own enterprise, service providers, or a 135 combination of both. This document also briefly describes the 136 following use cases summarized by 137 [I-D.pastor-i2nsf-merged-use-cases]: 139 o [I-D.pastor-i2nsf-access-usecases] (I2NSF-Access), 141 o [I-D.zarny-i2nsf-data-center-use-cases](I2NSF-DC), and 143 o [I-D.qi-i2nsf-access-network-usecase] (I2NSF-Mobile). 145 2. Terminology 147 ACL: Access Control List 149 B2B: Business-to-Business 151 Bespoke: Something made to fit a particular person, client or 152 company. 154 Bespoke security management: Security management which is made to 155 fit a particular customer. 157 DC: Data Center 159 FW: Firewall 161 IDS: Intrusion Detection System 163 IPS: Intrusion Protection System 165 I2NSF: interface to Network Security Functions. 167 NSF: Network Security Function. An NSF is a function that detects 168 abnormal activity and blocks/mitigates the effect of such abnormal 169 activity in order to preserve the availability of a network or a 170 service. In addition, the NSF can help in supporting 171 communication stream integrity and confidentiality. 173 Flow-based NSF: An NSF which inspects network flows according to a 174 security policy. Flow-based security also means that packets are 175 inspected in the order they are received, and without altering 176 packets due to the inspection process (e.g., MAC rewrites, TTL 177 decrement action, or NAT inspection or changes). 179 Virtual NSF: An NSF which is deployed as a distributed virtual 180 resource. 182 VNFPool: Pool of Virtual Network Functions. 184 3. Problem Space 186 The following sub-section describes the problems and challenges 187 facing customers and security service providers when some or all of 188 the security functions are no longer physically hosted by the 189 customer's adminstrative domain. 191 Security service providers can be internal or external to the 192 company. For example, an internal IT Security group within a large 193 enterprise could act as a security service provider for the 194 enterprise. In contrast, an enterprise could outsource all security 195 services to an external security service provider. In this document, 196 the security service provider function whether it is internal or 197 external, will be denoted as "service provider". 199 The "Customer-Provider" relationship may be between any two parties. 200 The parties can be in different firms or different domains of the 201 same firm. Contractual agreements may be required in such contexts 202 to formally document the customer's security requirements and the 203 provider's guarantees to fulfill those requirements. Such agreements 204 may detail protection levels, escalation procedures, alarms 205 reporting, etc. There is currently no standard mechanism to capture 206 those requirements. 208 A service provider may be a customer of another service provider. 210 3.1. Challenges Facing Security Service Providers 212 3.1.1. Diverse Types of Security Functions 214 There are many types of NSFs. NSFs by different vendors can have 215 different features and have different interfaces. NSFs can be 216 deployed in multiple locations in a given network, and perhaps have 217 different roles. 219 Below are a few examples of security functions and locations or 220 contexts in which they are often deployed: 222 External Intrusion and Attack Protection: Examples of this function 223 are firewall/ACL authentication, IPS, IDS, and endpoint 224 protection. 226 Security Functions in a DMZ: Examples of this function are 227 firewall/ACLs, IDS/IPS, one or all of AAA services NAT, forwarding 228 proxies, and application filtering. These functions may be 229 physically on-premise in a server provider's network at the DMZ 230 spots or located in a "virtual" DMZ. 232 Internal Security Analysis and Reporting: Examples of this function 233 are security logs, event correlation, and forensic analysis. 235 Internal Data and Content Protection: Examples of this function are 236 encryption, authorization, and public/private key management for 237 internal database. 239 Security gateways and VPN concentrators: Examples of these 240 functions are; IP-sec gateways, Secure VPN concentrators that 241 handle bridging secure VPNs, and Secure VPN controllers for data 242 flows. 244 Given the diversity of security functions, the contexts in which 245 these functions can be deployed, and the constant evolution of these 246 functions, standardizing all aspects of security functions is 247 challenging, and most probably not feasible. Fortunately, it is not 248 necessary to standardize all aspects. For example, from an I2NSF 249 perspective, there is no need to standardize how every firewall's 250 filtering is created or applied. Some features in a specific 251 vendor's filtering may be unique to the vendor's product so it is not 252 necessary to standardize these features. 254 What is needed is a standardized interface to control and monitor the 255 rule sets that NSFs use to treat packets traversing through. And 256 standardizing interfaces will provide an impetuous for standardizing 257 established security functions. 259 I2NSF may specify some filters, but these filters will be linked to 260 specific common functionality developed by I2NSF in informational 261 models or data models. 263 3.1.2. Diverse Interfaces to Control and Monitor NSFs 265 To provide effective and competitive solutions and services, Security 266 Service Providers may need to utilize multiple security functions 267 from various vendors to enforce the security policies desired by 268 their customers. 270 Since no widely accepted industry standard security interface exists 271 today, management of NSFs (device and policy provisioning, 272 monitoring, etc.) tends to be bespoke security management offered by 273 product vendors. As a result, automation of such services, if it 274 exists at all, is also bespoke. Thus, even in the traditional way of 275 deploying security features, there is a gap to coordinate among 276 implementations from distinct vendors. This is the main reason why 277 mono-vendor security functions are often deployed and enabled in a 278 particular network segment. 280 A challenge for monitoring is that an NSF cannot monitor what it 281 cannot view. Therefore, enabling a security function (e.g., firewall 282 [I-D.ietf-opsawg-firewalls]) does not mean that a network is 283 protected. As such, it is necessary to have a mechanism to monitor 284 and provide execution status of NSFs to security and compliance 285 management tools. There exist various network security monitoring 286 vendor-specific interfaces for forensics and troubleshooting. 288 3.1.3. More Distributed NSFs and vNSFs 290 The security functions which are invoked to enforce a security policy 291 can be located in different equipment and network locations. 293 The European Telecommunications Standards Institute (ETSI) Network 294 Function Virtualization (NFV) initiative creates new management 295 challenges for security policies to be enforced by distributed, 296 virtual, and network security functions (vNSF). 298 A vNSF has higher risk of failure, migrating, and state changes as 299 their hosting VMs are being created, moved, or decommissioned. 301 3.1.4. More Demand to Control NSFs Dynamically 303 In the advent of Software-Defined Networking (see 304 [I-D.jeong-i2nsf-sdn-security-services]), more clients, applications 305 or application controllers need to dynamically update their security 306 policies that are enforced by NSFs. The Security Service Providers 307 have to dynamically update their decision-making process (e.g., in 308 terms of NSF resource allocation and invocation) upon receiving 309 requests from their clients. 311 3.1.5. Demand for Multi-Tenancy to Control and Monitor NSFs 313 Service providers may need several operational units to control and 314 monitor the NSFs, especially when NSFs become distributed and 315 virtualized. 317 3.1.6. Lack of Characterization of NSFs and Capability Exchange 319 To offer effective security services, service providers need to 320 activate various security functions in NSFs or vNSFs manufactured by 321 multiple vendors. Even within one product category (e.g., firewall), 322 security functions provided by different vendors can have different 323 features and capabilities. For example, filters that can be designed 324 and activated by a firewall may or may not support IPv6 depending on 325 the firewall technology. 327 The service provider's management system (or controller) needs a way 328 to retrieve the capabilities of service functions by different 329 vendors so that it could build an effective security solution. These 330 service function capabilities can be documented in a static manner 331 (e.g., a file) or via an interface which accesses a repository of 332 security function capabilities which the NSF vendors dynamically 333 update. 335 A dynamic capability registration is useful for automation because 336 security functions may be subject to software and hardware updates. 337 These updates may have implications on the policies enforced by the 338 NSFs. 340 Today, there is no standard method for vendors to describe the 341 capabilities of their security functions. Without a common technical 342 framework to describe the capabilities of security functions, service 343 providers cannot automate the process of selecting NSFs by different 344 vendors to accommodate customer's requirements. 346 3.1.7. Lack of Mechanism for NSFs to Utilize External Profiles 348 Many security functions depend on signature files or profiles to 349 perform (e.g., IPS/IDS signatures, DOTS filters). Different policies 350 might need different signatures or profiles. Today, the construction 351 and use of black list databases can be a win-win strategy for all 352 parties involved. There might be Open Source-provided signature/ 353 profiles (e.g., by Snort or others) in the future. 355 There is a need to have a standard envelop (i.e., the format) to 356 allow NSFs to use external profiles. 358 3.1.8. Lack of Mechanisms to Accept External Alerts to Trigger 359 Automatic Rule and Configuration Changes 361 NSF can ask the I2NSF security controller to alter a specific rules 362 and/or configurations. For example, a DDoS alert could trigger a 363 change to the routing system to send traffic to a traffic scrubbing 364 service to mitigate the DDoS. 366 The DDoS protection has the following two parts: a) the configuration 367 of signaling of open threats and b) DDoS mitigation. DOTS controller 368 manages the signaling part of DDoS. I2NSF controller(s) would manage 369 the changing to the affected policies (e.g., forwarding and routing, 370 filtering, etc.). By monitoring the network alerts from DDoS, I2NSF 371 can feed an alerts analytics engine that could recognize attacks and 372 the I2NSF can thus enforce the appropriate policies. 374 DDoS mitigation is enhanced if the provider's network security 375 controller can monitor, analyze, and investigate the abnormal events 376 and provide information to the client or change the network 377 configuration automatically. 379 [I-D.zhou-i2nsf-capability-interface-monitoring] provides details on 380 how monitoring aspects of the flow-based Network Security Functions 381 (NSFs) can use the I2NSF interfaces to receive traffic reports and 382 enforce policy. 384 3.1.9. Lack of Mechanism for Dynamic Key Distribution to NSFs 386 There is a need for a controller to distribute various keys to 387 distributed NSFs. To distribute various keys, the keys must be 388 created and managed. While there are many key management methods and 389 cryptographic uites (e.g. encryptoni algorithms, key deriation 390 functions, etc.) and other functions), there is a lack of standard 391 interface to provision and manage security associations. 393 The keys may be used for message authentication and integrity in 394 order to protect data flows. In addition, keys may be used to secure 395 the protocol and messages in the core routing infrastructure 396 ([RFC4948]) 398 As of now there is not much focus on an abstraction for keying 399 information that describes the interface between protocols, 400 operators, and automated key management. 402 An example of a solution, may provide some insight into why the lack 403 of a mechanism is a problem. If you had an abstract key table 404 maintained by security services, you could use these keys for routing 405 and seurity devices. 407 What does this take? 409 Conceptually, there must be an interface defined for routing/ 410 signaling protocols to make requests for automated key management 411 when it is being used, to notify the protocols when keys become 412 available in the key table. One potential use of such an interface 413 is to manage IPSec security associations on SDN networks. 415 An abstract key service will work under the following conditions: 417 1. I2NSF needs to design the key table abstraction, the interface 418 between key management protocols and routing/other protocols, and 419 possibly security protocols at other layers. 421 2. For each routing/other protocol, I2NSF needs to define the 422 mapping between how the protocol represents key material and the 423 protocol-independent key table abstraction. (If protocols share 424 common mechanisms for authentication (e.g., TCP Authentication 425 Option), then the same mapping may be reused.) 427 3. Automated Key management must support both symmetric keys and 428 group keys via the service provided by items 1 and 2. 430 3.2. Challenges Facing Customers 432 When customers invoke hosted security services, their security 433 policies may be enforced by a collection of security functions hosted 434 in different domains. Customers may not have the security skills to 435 express sufficiently precise requirements or security policies. 436 Usually, these customers express the expectations of their security 437 requirements or the intent of their security policies. These 438 expectations can be considered customer level security expectations. 439 Customers may also desire to express guidelines for security 440 management. Examples of such guidelines include: 442 o Which critical communications are to be preserved during critical 443 events (DOTS), 445 o Which hosts are to continue service even during severe security 446 attacks (DOTS), 448 o Reporting of attacks to CERT (MILE), 450 o Managing network connectivity of systems out of compliance (SACM), 452 3.2.1. NSFs from Heterogeneous Administrative Domains 454 Many medium and large enterprises have deployed various on-premises 455 security functions which they want to continue to deploy. These 456 enterprises want to combine local security functions with remote 457 hosted security functions to achieve more efficient and immediate 458 counter-measures to both Internet-originated attacks and enterprise 459 network-originated attacks. 461 Some enterprises may only need the hosted security services for their 462 remote branch offices where minimal security infrastructures/ 463 capabilities exist. The security solution will consist of deploying 464 NSFs on customer networks and on service provider networks. 466 3.2.2. Today's Control Requests are Vendor Specific 468 Customers may consume NSFs by multiple service providers. Customers 469 need to express their security requirements, guidelines, and 470 expectations to the service providers. In turn, the service 471 providers must translate this customer information into customer 472 security policies and associated configuration tasks for the set of 473 security functions in their network. Without a standard technical 474 standard interface that provides a clear technical characterization, 475 the service provider faces many challenges: 477 No standard technical characterization and/or APIs : Even for the 478 most common security services there is no standard technical 479 characterization or APIs. Most security services are accessible 480 only through disparate, proprietary interfaces (e.g., portals or 481 APIs) in whatever format vendors choose to offer. The service 482 provider must have the customer's input to manage these widely 483 varying interfaces. 485 No standard interface: Without standard interfaces it is complex 486 for customers to update security policies or integrate the 487 security functions in their enterprise with the security services 488 provided by the security service providers. This complexity is 489 induced by the diversity of the configuration models, policy 490 models, and supported management interfaces. Without a standard 491 interface, new innovative security products find a large barrier 492 to entry into the market. 494 Managing by scripts de-jour: The current practices rely upon the 495 use of scripts that generate other scripts which automatically run 496 to upload or download configuration changes, log information and 497 other things. These scripts have to be adjusted each time an 498 implementation from a different vendor technology is enabled on a 499 provider side. 501 Lack of immediate feedback: Customers may also require a mechanism 502 to easily update/modify their security requirements with immediate 503 effect in the underlying involved NSFs. 505 Lack of explicit invocation request: While security agreements are 506 in place, security functions may be solicited without requiring an 507 explicit invocation means. Nevertheless, some explicit invocation 508 means may be required to interact with a service function. 510 To see how standard interfaces could help achieve faster 511 implementation time cycles, let us consider a customer who would like 512 to dynamically allow an encrypted flow with specific port, src/dst 513 addresses or protocol type through the firewall/IPS to enable an 514 encrypted video conferencing call only during the time of the call. 515 With no commonly accepted interface in place, the customer would have 516 to learn about the particular provider's firewall/IPS interface and 517 send the request in the provider's required format. 519 +------------+ 520 | security | 521 | MGT system | 522 +----||------+ 523 || proprietary 524 || or I2NSF standard 525 Picture: || 526 Port 10 +--------+ 527 --------| FW/IPS |------------- 528 Encrypted +--------+ 529 Video Flow 531 Figure 1: Example of non-standard vs. standard interface 533 In contrast, if a firewall/IPS interface standard exists, the 534 customer would be able to send the request, without having to do the 535 extensive preliminary legwork. A standard interface also helps 536 service providers since they could now offer the same firewall/IPS 537 interface to represent firewall/IPS services for utilizing products 538 from many vendors. The result is that the service provider has now 539 abstracted the firewall/IPS services. The standard interface also 540 helps the firewall/IPS vendors to focus on their core security 541 functions or extended features rather than the standard building 542 blocks of a management interface. 544 3.2.3. Difficulty to Monitor the Execution of Desired Policies 546 How a policy is translated into technology-specific actions is hidden 547 from the customers. However, customers still need ways to monitor 548 the delivered security service that results from the execution of 549 their desired security requirements, guidelines and expectations. 551 Today, there is no standard way for customers to get security service 552 assurance of their specified security policies properly enforced by 553 the security functions in the provider domain. The customer also 554 lacks the ability to perform "what-if" scenarios to assess the 555 efficiency of the delivered security service. 557 3.3. Difficulty to Validate Policies across Multiple Domains 559 One key aspect of a hosted security service with security functions 560 located at different premises is the ability to express, monitor and 561 verify security policies that combine several distributed security 562 functions. It is crucial to an effective service to be able to take 563 these actions via a standard interface. This standard interface 564 becomes more crucial to the hosted security service when NSFs are 565 instantiated in Virtual Machines which are sometimes widely 566 distributed in the network and sometimes are combined together in one 567 device to perform a set of tasks for delivering a service. 569 Without standard interfaces and security policy data models, the 570 enforcement of a customer-driven security policy remains challenging 571 because of the inherent complexity created by combining the 572 invocation of several vendor-specific security functions into a 573 multi-vendor, heterogeneous environment. Each vendor-specific 574 function may require specific configuration procedures and 575 operational tasks. 577 Ensuring the consistent enforcement of the policies at various 578 domains is also challenging. Standard data models are likely to 579 contribute to addressing that issue. 581 3.4. Lack of Standard Interface to Inject Feedback to NSF 583 Today, many security functions, such as IPS, IDS, DDoS and Antivirus, 584 depend heavily on the associated profiles. They can perform more 585 effective protection if they have the up-to-date profiles. As more 586 sophisticated threats arise, enterprises, vendors, and service 587 providers have to rely on each other to achieve optimal protection. 588 Cyper Threat Alliance (CA, http://cyberthreatalliance.org/) is one of 589 those initiatives that aim at combining efforts conducted by multiple 590 organizations. 592 Today there is no standard interface to exchange security profiles 593 between organizations. 595 3.5. Lack of Standard Interface for Capability Negotiation 597 There could be situations when the selected NSFs cannot perform the 598 policies requested by the Security Controller, due to resource 599 constraints. The customer and security service provider should 600 negotiate the appropriate resource constraints before the security 601 service begins. However, unexpected events somethings happen and the 602 NSF may exhaust those negotiated resources. At this point, the NSF 603 should inform the security controller that the alloted resources have 604 been exhausted. To support the automatic control in the SDN-era, it 605 is necessary to have a set of messages for proper notification (and a 606 response to that notification) between the Security Controller and 607 the NSFs. 609 4. Use Cases 611 Standard interfaces for monitoring and controlling the behavior of 612 NSFs are essential building blocks for Security Service Providers and 613 enterprises to automate the use of different NSFs from multiple 614 vendors by their security management entities. I2NSF may be invoked 615 by any (authorized) client. Examples of authorized clients are 616 upstream applications (controllers), orchestration systems, and 617 security portals. 619 4.1. Basic Framework 621 Users request security services through specific clients (e.g., a 622 customer application, the NSP BSS/OSS or management platform) and the 623 appropriate NSP network entity will invoke the (v)NSFs according to 624 the user service request. This network entity is denoted as the 625 security controller in this document. The interaction between the 626 entities discussed above (client, security controller, NSF) is shown 627 in Figure 2: 629 +----------+ 630 +-------+ | | +-------+ 631 | | Interface 1 |Security | Interface 2 | NSF(s)| 632 |Client <-------------> <------------------> | 633 | | |Controller| | | 634 +-------+ | | +-------+ 635 +----------+ 637 Figure 2: Interaction between Entities 639 Interface 1 is used for receiving security requirements from client 640 and translating them into commands that NSFs can understand and 641 execute. The security controller also passes back NSF security 642 reports (e.g., statistics) to the client which the control has 643 gathered from NSFs. Interface 2 is used for interacting with NSFs 644 according to commands (e.g. enact policy and distribuge), and 645 collecting status information about NSFs. 647 Client devices or applications can require the security controller to 648 add, delete or update rules in the security service function for 649 their specific traffic. 651 When users want to get the executing status of a security service, 652 they can request NSF status from the client. The security controller 653 will collect NSF information through Interface 2, consolidate them, 654 and give feedback to client through Interface 1. This interface can 655 be used to collect not only individual service information, but also 656 aggregated data suitable for tasks like infrastructure security 657 assessment. 659 Customers may require validating NSF availability, provenance, and 660 correct execution. This validation process, especially relevant for 661 vNSFs, includes at least: 663 Integrity of the NSF: by ensuring that the NSF is not compromised; 665 Isolation: by ensuring the execution of the NSF is self-contained 666 for privacy requirements in multi-tenancy scenarios. 668 Provenance of NSF: Customers may need to be provided with strict 669 guarantees about the origin of the NSF, its status (e.g. 670 available, idle, down, and others), and feedback mechanisms so 671 that a customer may be able to check that a given NSF or set of 672 NSFs properly conform to the the customer's requirements and 673 subsequent configuration tasks. 675 In order to achieve this, the security controller may collect 676 security measurements and share them with an independent and trusted 677 third party (via interface 1) in order to allow for attestation of 678 NSF functions using the third party added information. 680 4.2. Access Networks 682 This scenario describes use cases for users (e.g. enterprise user, 683 network administrator, and residential user) that request and manage 684 security services hosted in the network service provider (NSP) 685 infrastructure. Given that NSP customers are essentially users of 686 their access networks, the scenario is essentially associated with 687 their characteristics, as well as with the use of vNSFs. 689 The Virtual CPE described in [NFVUC] use cases #5 and #7 requires a 690 model of access virtualization that includes mobile and residential 691 access where the operator may offload security services from the 692 customer local environment (e.g., device or terminal) to its own 693 infrastructure. 695 These use cases define the interaction between the operator and the 696 vNSFs through automated interfaces, typically by means of B2B 697 communications. 699 Customer + Access + PoP/Datacenter 700 | | +--------+ 701 | ,-----+--. |Network | 702 | ,' | `-|Operator| 703 +-------------+ | /+----+ | |Mgmt Sys| 704 | Residential |-+------/-+vCPE+----+ +--------+ 705 +-------------+ | / +----+ | \ | : 706 | / | \ | | 707 +----------+ | ; +----+ | +----+ | 708 |Enterprise|---+---+----+ vPE+--+----+ NSF| | 709 +----------+ | : +----+ | +----+ | 710 | : | / | 711 +--------+ | : +----+ | / ; 712 | Mobile |-+-----\--+vEPC+----+ / 713 +--------+ | \ +----+ | ,-' 714 | `--. | _.-' 715 | `----+----'' 716 + + 718 Figure 3: NSF and actors 720 Different access clients may have different service requests: 722 Residential: service requests for parental control, content 723 management, and threat management. 725 Parental control requests may include identity based filters for 726 web content or usage. Content management may include identifying 727 and blocking malicious activities from web contents, mail, or 728 files downloaded. Threat management may include identifying and 729 blocking botnets or malware. 731 Enterprise: service requests for enterprise flow security policies 732 and managed security services 734 Flow security policies include access (or isolation) to data from 735 various internal groups, access (or isolation) from varous web 736 sites or social media applications, and encryption on data 737 transferred between corporates sites (main office, enterprise 738 branch offices, and remote campuses). Managed security services 739 may include detection and mitigation of external and internal 740 threats. External threats can include application or phishing 741 attacks, malware, botnet, DDoS, and others. Internal threats (aka 742 lateral threats) can include detecting programs moving from one 743 enterprise site to another without permission. 745 Service Provider: Service requests for policies that protect 746 service providers networks against various threats (including 747 DDoS, botnets and malware). Such policies are meant to securely 748 and reliably deliver contents (e.g., data, voice, video) to 749 various customers, including residential, mobile and corporate 750 customers. These security policies are also enforced to guarantee 751 isolation between multiple tenants, regardless of the nature of 752 the corresponding connectivity services. 754 Mobile: service requests from interfaces which monitor and ensure 755 user quality of experience, content management, parental controls, 756 and external threat management. 758 Content management for the mobile device includes identifying and 759 blocking malicious activities from web contents, mail, files. 760 Threat management for infrastructure includes detecting and 761 removing malicious programs such as Botnet, DDoS, and Malware. 763 Some access customers may not care about which NSFs are utilized to 764 achieve the services they requested. In this case, provider network 765 orchestration systems can internally select the NSFs (or vNSFs) to 766 enforce the policies requested by the clients. Other access 767 customers, especially some enterprise customers, may want to get 768 their dedicated NSFs (most likely vNSFs) for direct control purposes. 769 In this case, here are the steps to associate vNSFs to specific 770 customers: 772 vNSF Deployment: The deployment process consists in instantiating a 773 NSF on a Virtualization Infrastructure (NFVI), within the NSP 774 administrative domain(s) or with other external domain(s). This 775 is a required step before a customer can subscribe to a security 776 service supported in the vNSF. 778 vNSF Customer Provisioning: Once a vNSF is deployed, any customer 779 can subscribe to it. The provisioning lifecycle includes the 780 following: 782 * Customer enrollment and cancellation of the subscription to a 783 vNSF; 785 * Configuration of the vNSF, based on specific configurations, or 786 derived from common security policies defined by the NSP. 788 * Retrieve and list the vNSF functionalities, extracted from a 789 manifest or a descriptor. The NSP management systems can 790 demand this information to offer detailed information through 791 the commercial channels to the customer. 793 4.3. Cloud Data Center Scenario 795 In a data center, network security mechanisms such as firewalls may 796 need to be dynamically added or removed for a number of reasons. 797 These changes may be explicitly requested by the user, or triggered 798 by a pre-agreed upon Service Level Agreement (SLA) between the user 799 and the provider of the service. For example, the service provider 800 may be required to add more firewall capacity within a set timeframe 801 whenever the bandwidth utilization hits a certain threshold for a 802 specified period. This capacity expansion could result in adding new 803 instances of firewalls on existing machines or provisioning a 804 completely new firewall instance in a different machine. 806 The on-demand, dynamic nature of security service delivery 807 essentially encourages that the network security "devices" be in 808 software or virtual form factors, rather than in a physical appliance 809 form. This requirement is a provider-side concern. Users of the 810 firewall service are agnostic (as they should) as to whether or not 811 the firewall service is run on a VM or any other form factor. 812 Indeed, they may not even be aware that their traffic traverses 813 firewalls. 815 Furthermore, new firewall instances need to be placed in the "right 816 zone" (domain). The issue applies not only to multi-tenant 817 environments where getting the tenant in the right domain is of 818 paramount importance, but also in environments owned and operated by 819 a single organization with its own service segregation policies. For 820 example, an enterprise may mandate that firewalls serving Internet 821 traffic and Business-to-Business (B2B) traffic be separated. Another 822 example is that IPS/IDS services for investment banking and non- 823 banking traffic may be separated for regulatory reasons. 825 4.3.1. On-Demand Virtual Firewall Deployment 827 A service provider-operated cloud data center could serve tens of 828 thousands of clients. Clients' compute servers are typically hosted 829 on virtual machines (VMs), which could be deployed across different 830 server racks located in different parts of the data center. It is 831 often not technically and/or financially feasible to deploy dedicated 832 physical firewalls to suit each client's security policy 833 requirements, which can be numerous. What is needed is the ability 834 to dynamically deploy virtual firewalls for each client's set of 835 servers based on established security policies and underlying network 836 topologies. 838 ---+-----------------------------+----- 839 | | 840 +---+ +-+-+ 841 |vFW| |vFW| 842 +---+ +-+-+ 843 | Client #1 | Client #2 844 ---+-------+--- ---+-------+--- 845 +-+-+ +-+-+ +-+-+ +-+-+ 846 |vM | |vM | |vM | |vM | 847 +---+ +---+ +---+ +---+ 849 Figure 4: NSF in Data Centers 851 4.3.2. Firewall Policy Deployment Automation 853 Firewall rule setting is often a time consuming, complex and error- 854 prone process even within a single organization/enterprise framework. 855 It becomes far more complex in provider-owned cloud networks that 856 serve myriads of customers. 858 Firewall rules today are highly tied with ports and addresses that 859 identify traffic. This makes it very difficult for clients of cloud 860 data centers to construct rules for their own traffic as the clients 861 only see the virtual networks and the virtual addresses. The 862 customer-visible virtual networks and addresses may be different from 863 the actual packets traversing the FWs. 865 Even though most vendors support similar firewall features, the 866 actual rule configuration keywords are different from vendors to 867 vendors, making it difficult for automation. Automation works best 868 when it can leverage a common set of standards that will work across 869 NSFs by multiple vendors. Without automation, it is virtually 870 impossible for clients to dynamically specify their desired rules for 871 their traffic. 873 Another feature that aids automation of firewalls that must be 874 covered in automation is dynamic key management. 876 4.3.3. Client-Specific Security Policy in Cloud VPNs 878 Clients of service provider-operated cloud data centers need not only 879 to secure Virtual Private Networks (VPNs) but also virtual security 880 functions that apply the clients' security policies. The security 881 policies may govern communication within the clients' own virtual 882 networks as well as communication with external networks. For 883 example, VPN service providers may need to provide firewall and other 884 security services to their VPN clients. Today, it is generally not 885 possible for clients to dynamically view (let alone change) what, 886 where and how security policies are implemented on their provider- 887 operated clouds. Indeed, no standards-based framework exists to 888 allow clients to retrieve/manage security policies in a consistent 889 manner across different providers. 891 As described above, the dynamic key mechanisms are critical for the 892 securing the VPN and the distribution of policies. 894 4.3.4. Internal Network Monitoring 896 There are many types of internal traffic monitors that may be managed 897 by a security controller. This includes a new class of services 898 referred to as Data Loss Prevention (DLP), or Reputation Protection 899 Services (RPS). Depending on the class of event, alerts may go to 900 internal administrators, or external services. 902 4.4. I2NSF Preventing Distributed DoS in Overlay Networks 904 In the internet where everything is connected, preventing unwanted 905 traffic that may cause Denial of Service (DoS) attack or distributed 906 DoS (DDoS) has become a challenge. One place where DDoS can be 907 challenging to prevent or mitigate is in overlay networks. Many 908 networks such as Internet of Things (IoT) networks, Information- 909 Centric Networks (ICN), Content Delivery Networks (CDN), and cloud 910 networks use overlay networks within their paths (or links). The 911 underlay networks that support overlay networks can be attacked by 912 DDoS, thereby saturating access links or links within the network. 913 DoS or DDoS attacks on the access links may also cause the overlay 914 nodes' CPUs or links to be saturated by DoS or DDoS traffic which 915 will prevent these links from being used by legitimate overlay 916 traffic. Overlay security solutions do not address underlay security 917 threats so there is a need for a distributed solution to prevent DDoS 918 attacks from spreading throughout overlay and underlay networks. 919 Such solution may for example rely upon the dynamic, highly-reactive, 920 enforcement of security filtering policies network-wise. 922 Similar to traditional networks placing a firewall or Intrusion 923 Prevention System (IPS) on the wire to enforce traffic rules, the 924 interface to network security functions (I2NSF) can be used by 925 overlay networks to request underlay networks enforce certain flow- 926 based security rules. Using this mechanism, the overlay network can 927 coordinate with the underlay network to remove unwanted traffic 928 including DoS and DDoS in the underlay network. 930 +-------------------------------------------+ 931 | Application controlloer | 932 | (e.g video conference service controller | 933 | from centralized control or orchestration | 934 +---+----------------------------+----------+ 935 | consumer facing | 936 | interface (A) | 937 +----+----------------+ +---------------------+ 938 | network operator | | network operator | 939 | security controller +--| | security controller +--| 940 | (underlay network) | | | overlay network | | 941 +----+----------------+ | +------+--------------+ | 942 | vendor facing | | vendor facing | 943 | interface (C) | | interface (C) | 944 | +----+---+ | +-------+-+ 945 | | vendor | | | vendor | 946 | | system | | | system | 947 | +--------+ | +---------+ 948 | | 949 | NSF facing inteface | NSF Facing interface 950 | (capabilty)(B) | (capability) (B) 951 ---+-------------+----- ---+------------+--------- 952 | | | | 953 +--+---+ +-+---+ +---+--+ +--+----+ 954 | NSF |-------| NSF | | NSF |------| NSF | 955 +------+ +-----+ +------+ +-------+ 956 vendor a vendor b vendor B Vendor C 958 Figure 5: I2NSF Preventing DDoS Attacks in Overlay Networks. 960 5. Management Considerations 962 Management of NSFs usually include the following: 964 o Lifecycle managment and resource management of NSFs, 966 o Device configuration, such as address configuration, device 967 internal attributes configuration, etc.; 969 o Signaling, and 971 o Policy rule provisioning. 973 I2NSF will only focus on the policy provisioning part of NSF 974 management. 976 6. IANA Considerations 978 No IANA considerations exist for this document. 980 7. Security Considerations 982 Having a secure access to control and monitor NSFs is crucial for 983 hosted security services. An I2NSF security controller raises new 984 security threats. It needs to be resilient to attacks and quickly 985 recover from attacks. Therefore, proper secure communication 986 channels have to be carefully specified for carrying controlling and 987 monitoring traffic between the NSFs and their management entity (or 988 entities). 990 In addition, the Flow security policies specified by customers can 991 conflict with providers' internal security policies which may allow 992 unauthorized traffic or unauthorized changes to flow polices (e.g. 993 customers changing flow policies that do not belong to them). 994 Therefore, it is crucial to have proper AAA [RFC2904] to authorize 995 access to the network and access to the I2NSF management stream. 997 8. Contributors 999 I2NSF is a group effort. The following people actively contributed 1000 to the initial use case text: Xiaojun Zhuang (China Mobile), Sumandra 1001 Majee (F5), Ed Lopez (Fortinet), and Robert Moskowitz (Huawei). 1003 9. Contributing Authors 1005 I2NSF has had a number of contributing authors. The following are 1006 contributing authors: 1008 o Linda Dunbar (Huawei), 1010 o Antonio Pastur (Telefonica I+D), 1012 o Mohamed Boucadair (France Telecom), 1014 o Michael Georgiades (Prime Tel), 1016 o Minpeng Qi (China Mobile), 1018 o Shaibal Chakrabarty (US Ignite), 1020 o Nic Leymann (Deutsche Telekom), 1022 o Anil Lohiya (Juniper), 1023 o David Qi (Bloomberg), and 1025 o Xiaobo Long. 1027 10. References 1029 10.1. Normative References 1031 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1032 Requirement Levels", BCP 14, RFC 2119, 1033 DOI 10.17487/RFC2119, March 1997, 1034 . 1036 10.2. Informative References 1038 [Gartner-2013] 1039 Messmer, E., "Gartner: Cloud-based security as a service 1040 set to take off", October 2013. 1042 [I-D.hares-i2nsf-gap-analysis] 1043 Hares, S., Zhang, D., Moskowitz, R., and H. Rafiee, 1044 "Analysis of Existing work for I2NSF", draft-hares-i2nsf- 1045 gap-analysis-01 (work in progress), December 2015. 1047 [I-D.ietf-netmod-acl-model] 1048 Bogdanovic, D., Koushik, K., Huang, L., and D. Blair, 1049 "Network Access Control List (ACL) YANG Data Model", 1050 draft-ietf-netmod-acl-model-06 (work in progress), 1051 December 2015. 1053 [I-D.ietf-opsawg-firewalls] 1054 Baker, F. and P. Hoffman, "On Firewalls in Internet 1055 Security", draft-ietf-opsawg-firewalls-01 (work in 1056 progress), October 2012. 1058 [I-D.jeong-i2nsf-sdn-security-services] 1059 Jeong, J., Kim, H., and P. Jung-Soo, "Requirements for 1060 Security Services based on Software-Defined Networking", 1061 draft-jeong-i2nsf-sdn-security-services-01 (work in 1062 progress), March 2015. 1064 [I-D.lopez-i2nsf-packet] 1065 Ed, E., "Packet-Based Paradigm For Interfaces To NSFs", 1066 draft-lopez-i2nsf-packet-00 (work in progress), March 1067 2015. 1069 [I-D.pastor-i2nsf-access-usecases] 1070 Pastor, A. and D. Lopez, "Access Use Cases for an Open OAM 1071 Interface to Virtualized Security Services", draft-pastor- 1072 i2nsf-access-usecases-00 (work in progress), October 2014. 1074 [I-D.pastor-i2nsf-merged-use-cases] 1075 Pastor, A., Lopez, D., Wang, K., Zhuang, X., Qi, M., 1076 Zarny, M., Majee, S., Leymann, N., Dunbar, L., and M. 1077 Georgiades, "Use Cases and Requirements for an Interface 1078 to Network Security Functions", draft-pastor-i2nsf-merged- 1079 use-cases-00 (work in progress), June 2015. 1081 [I-D.qi-i2nsf-access-network-usecase] 1082 Wang, K. and X. Zhuang, "Integrated Security with Access 1083 Network Use Case", draft-qi-i2nsf-access-network- 1084 usecase-02 (work in progress), March 2015. 1086 [I-D.zarny-i2nsf-data-center-use-cases] 1087 Zarny, M., Leymann, N., and L. Dunbar, "I2NSF Data Center 1088 Use Cases", draft-zarny-i2nsf-data-center-use-cases-00 1089 (work in progress), October 2014. 1091 [I-D.zhou-i2nsf-capability-interface-monitoring] 1092 Zhou, C., Xia, L., Boucadair, M., and J. Xiong, "The 1093 Capability Interface for Monitoring Network Security 1094 Functions (NSF) in I2NSF", draft-zhou-i2nsf-capability- 1095 interface-monitoring-00 (work in progress), October 2015. 1097 [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., 1098 Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and 1099 D. Spence, "AAA Authorization Framework", RFC 2904, 1100 DOI 10.17487/RFC2904, August 2000, 1101 . 1103 [RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the 1104 IAB workshop on Unwanted Traffic March 9-10, 2006", 1105 RFC 4948, DOI 10.17487/RFC4948, August 2007, 1106 . 1108 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 1109 RFC 7277, DOI 10.17487/RFC7277, June 2014, 1110 . 1112 Authors' Addresses 1113 Susan Hares 1114 Huawei 1115 7453 Hickory Hill 1116 Saline, MI 48176 1117 USA 1119 Phone: +1-734-604-0332 1120 Email: shares@ndzh.com 1122 Diego R. Lopex 1123 Telefonica I+D 1124 Don Ramon de la Cruz, 82 1125 Madrid 28006 1126 Spain 1128 Email: diego.r.lopez@telefonica.com 1130 Myo Zarny 1131 Goldman Sachs 1132 30 Hudson Street 1133 Jersey City, NJ 07302 1134 USA 1136 Email: myo.zarny@gs.com 1138 Christian Jacquenet 1139 France Telecom 1140 Rennes, 35000 1141 France 1143 Email: Christian.jacquenet@orange.com 1145 Rakesh Kumar 1146 Juniper Networks 1147 1133 Innovation Way 1148 Sunnyvale, CA 94089 1149 USA 1151 Email: rkkumar@juniper.net 1152 Jaehoon Paul Jeong 1153 Department of Software 1154 Sungkyunkwan University 1155 2066 Seobu-Ro, Jangan-Gu 1156 Suwon, Gyeonggi-Do 16419 1157 Republic of Korea 1159 Phone: +82 31 299 4957 1160 Fax: +82 31 290 7996 1161 Email: pauljeong@skku.edu 1162 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php