idnits 2.17.1 draft-ietf-i2nsf-problem-and-use-cases-16.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 (May 10, 2017) is 2536 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.zarny-i2nsf-data-center-use-cases' is defined on line 1204, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 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: Informational D. Lopez 5 Expires: November 11, 2017 Telefonica I+D 6 M. Zarny 7 vArmour 8 C. Jacquenet 9 France Telecom 10 R. Kumar 11 Juniper Networks 12 J. Jeong 13 Sungkyunkwan University 14 May 10, 2017 16 I2NSF Problem Statement and Use cases 17 draft-ietf-i2nsf-problem-and-use-cases-16 19 Abstract 21 This document is the problem statement for Interface to Network 22 Security Functions (I2NSF) as well as some companion use cases. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on November 11, 2017. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.1. Challenges Facing Security Service Providers . . . . . . 5 62 3.1.1. Diverse Types of Security Functions . . . . . . . . . 5 63 3.1.2. Diverse Interfaces to Control and Monitor NSFs . . . 6 64 3.1.3. More Distributed NSFs and vNSFs . . . . . . . . . . . 7 65 3.1.4. More Demand to Control NSFs Dynamically . . . . . . . 7 66 3.1.5. Demand for Multi-Tenancy to Control and Monitor NSFs 8 67 3.1.6. Lack of Characterization of NSFs and Capability 68 Exchange . . . . . . . . . . . . . . . . . . . . . . 8 69 3.1.7. Lack of Mechanism for NSFs to Utilize External 70 Profiles . . . . . . . . . . . . . . . . . . . . . . 8 71 3.1.8. Lack of Mechanisms to Accept External Alerts to 72 Trigger Automatic Rule and Configuration Changes . . 9 73 3.1.9. Lack of Mechanism for Dynamic Key Distribution to 74 NSFs . . . . . . . . . . . . . . . . . . . . . . . . 9 75 3.2. Challenges Facing Customers . . . . . . . . . . . . . . . 10 76 3.2.1. NSFs from Heterogeneous Administrative Domains . . . 11 77 3.2.2. Today's Control Requests are Vendor Specific . . . . 11 78 3.2.3. Difficult for Customer to Monitor the Execution of 79 Desired Policies . . . . . . . . . . . . . . . . . . 13 80 3.3. Lack of Standard Interface to Inject Feedback to NSF . . 13 81 3.4. Lack of Standard Interface for Capability Negotiation . . 14 82 3.5. Difficult to Validate Policies across Multiple Domains . 14 83 3.6. Software-Defined Networks . . . . . . . . . . . . . . . . 15 84 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 4.1. Basic Framework . . . . . . . . . . . . . . . . . . . . . 15 86 4.2. Access Networks . . . . . . . . . . . . . . . . . . . . . 17 87 4.3. Cloud Data Center Scenario . . . . . . . . . . . . . . . 20 88 4.3.1. On-Demand Virtual Firewall Deployment . . . . . . . . 20 89 4.3.2. Firewall Policy Deployment Automation . . . . . . . . 21 90 4.3.3. Client-Specific Security Policy in Cloud VPNs . . . . 21 91 4.3.4. Internal Network Monitoring . . . . . . . . . . . . . 22 92 4.4. Preventing Distributed DoS, Malware and Botnet attacks . 22 93 4.5. Regulatory and Compliance Security Policies . . . . . . . 23 94 5. Management Considerations . . . . . . . . . . . . . . . . . . 23 95 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 97 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 98 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . 24 99 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 100 11. Informative References . . . . . . . . . . . . . . . . . . . 25 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 103 1. Introduction 105 This document is the problem statement for Interface to Network 106 Security Functions (I2NSF) as well as some I2NSF use cases. A 107 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.ietf-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. 137 This document also briefly describes the following use cases 138 summarized by [I-D.pastor-i2nsf-merged-use-cases]: 140 o [I-D.pastor-i2nsf-access-usecases] (I2NSF-Access), 142 o [I-D.zarny-i2nsf-data-center-use-cases](I2NSF-DC), and 144 o [I-D.qi-i2nsf-access-network-usecase] (I2NSF-Mobile). 146 2. Terminology 148 AAA: Authentication, Authorization, and Account [RFC2904]. 150 ACL: Access Control List 152 Bespoke security management: Security management which is made to 153 fit a particular customer. 155 DC: Data Center 157 vEPC virtual 3GPP Evolved Packet Core [EPC-3GPP] 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 used to 168 ensure integrity, confidentiality, or availability of network 169 communication, to detect unwanted network activity, or to block or 170 at least mitigate the effects of unwanted activity. 172 Flow-based NSF: An NSF which inspects network flows according to a 173 security policy. Flow-based security also means that packets are 174 inspected in the order they are received, and without altering 175 packets due to the inspection process (e.g., MAC rewrites, TTL 176 decrement action, or NAT inspection or changes). (Note: Some 177 existing firewalls store packets and look at the packets in 178 logical order which is not order these are received in time. This 179 document restricts flow-based NSF to this definition.) 181 Security service provider: A provider of security services to the 182 customers (end-users or enterprises) using NSF equipment purchased 183 from vendors or created by the service provider. 185 SDN: Software Defined Networking. (See [RFC7426]) for 186 architectural and terminology or [RFC7149] for service provider 187 view). 189 Virtual NSF: An NSF which is deployed as a distributed virtual 190 resource. 192 VPN: Virtual Private Networks 194 3. Problem Space 196 The following sub-sections describe the problems and challenges 197 facing customers and security service providers when some or all of 198 the security functions are no longer physically hosted by the 199 customer's administrative domain. 201 Security service providers can be internal or external to the 202 company. For example, an internal IT Security group within a large 203 enterprise could act as a security service provider for the 204 enterprise. In contrast, an enterprise could outsource all security 205 services to an external security service provider. In this document, 206 the security service provider function, whether it is internal or 207 external, will be denoted as "service provider". 209 The "Customer-Provider" relationship may be between any two parties. 210 The parties can be in different organization or different domains of 211 the same organization. Contractual agreements may be required in 212 such contexts to formally document the customer's security 213 requirements and the provider's guarantees to fulfill those 214 requirements. Such agreements may detail protection levels, 215 escalation procedures, alarms reporting, etc. There is currently no 216 standard mechanism to capture those requirements. 218 A service provider may be a customer of another service provider. 220 It is the objective of the I2NSF work to address these problems and 221 challenges. 223 3.1. Challenges Facing Security Service Providers 225 3.1.1. Diverse Types of Security Functions 227 There are many types of NSFs. NSFs by different vendors can have 228 different features and have different interfaces. NSFs can be 229 deployed in multiple locations in a given network, and perhaps have 230 different roles. 232 Below are a few examples of security functions and locations or 233 contexts in which they are often deployed: 235 External Intrusion and Attack Protection: Examples of this function 236 are firewall/ACL authentication, IPS, IDS, and endpoint 237 protection. 239 Security Functions in a Demilitarized Zone (DMZ): Examples of this 240 function are firewall/ACLs, IDS/IPS, one or all of AAA services, 241 NAT, forwarding proxies, and application filtering. These 242 functions may be physically on-premise in a server provider's 243 network at the DMZ spots or located in a "virtual" DMZ. 245 Centralized or Distributed security functions: The security 246 functions could be deployed in a centralized fashion for ease of 247 management and network design or in a distributed fashion for 248 scaled requirement. No matter how a security function is deployed 249 and provisioned, it is desirable to have same interface to 250 provision security policies; otherwise it makes the job of 251 security administration more complex, requiring knowledge of 252 firewall and network design. 254 Internal Security Analysis and Reporting: Examples of this function 255 are security logs, event correlation, and forensic analysis. 257 Internal Data and Content Protection: Examples of this function are 258 encryption, authorization, and public/private key management for 259 internal database. 261 Security gateways and VPN concentrators: Examples of these 262 functions are; IPsec gateways, secure VPN concentrators that 263 handle bridging secure VPNs, and secure VPN controllers for data 264 flows. 266 Given the diversity of security functions, the contexts in which 267 these functions can be deployed, and the constant evolution of these 268 functions, standardizing all aspects of security functions is 269 challenging, and most probably not feasible. Fortunately, it is not 270 necessary to standardize all aspects. For example, from an I2NSF 271 perspective, there is no need to standardize how every firewall's 272 filtering is created or applied. Some features in a specific 273 vendor's filtering may be unique to the vendor's product so it is not 274 necessary to standardize these features. 276 What is needed is a standardized interface to control and monitor the 277 rule sets that NSFs use to treat packets traversing through these 278 NSFs. Thus standardizing interfaces will provide an impetus for 279 standardizing established security functions. 281 I2NSF may specify some filters, but these filters will be linked to 282 specific common functionality developed by I2NSF in information 283 models or data models. 285 3.1.2. Diverse Interfaces to Control and Monitor NSFs 287 To provide effective and competitive solutions and services, security 288 service providers may need to utilize multiple security functions 289 from various vendors to enforce the security policies desired by 290 their customers. 292 Since no widely accepted industry standard security interface to 293 security NSFs exists today, management of NSFs (device and policy 294 provisioning, monitoring, etc.) tends to be custom-made security 295 management offered by product vendors. As a result, automation of 296 such services, if it exists at all, is also custom-made. Thus, even 297 in the traditional way of deploying security features, there is a gap 298 to coordinate among implementations from distinct vendors. This is 299 the main reason why mono-vendor security functions are often deployed 300 and enabled in a particular network segment. 302 A challenge for monitoring prior to mitigation of a security 303 intrusion is that an NSF cannot monitor what it cannot view. For 304 example, enabling a security function to mitigate an intrusion (e.g., 305 firewall [I-D.ietf-opsawg-firewalls]) must include a mechanism to 306 provide monitoring feedback in order to determine the intrusion has 307 been stopped. Therefore, it is necessary to have a mechanism to 308 monitor and provide execution status of NSFs to security and 309 compliance management tools. There exist such mechanisms in vendor- 310 specific network security interfaces for forensics and 311 troubleshooting, but an industry standard interface could provide 312 monitoring across a variety of NSFs. 314 3.1.3. More Distributed NSFs and vNSFs 316 The security functions which are invoked to enforce a security policy 317 can be located in different equipment and network locations. 319 The European Telecommunications Standards Institute (ETSI) Network 320 Functions Virtualization (NFV) initiative [ETSI-NFV] creates new 321 management challenges for security policies to be enforced by 322 distributed virtual network security functions (vNSF). 324 A vNSF has higher risk of changes to the state of network connection, 325 interfaces, or traffic as their hosting Virtual Machines (VMs) are 326 being created, moved, or decommissioned. 328 3.1.4. More Demand to Control NSFs Dynamically 330 In the advent of Software-Defined Networking (SDN)(see 331 [I-D.jeong-i2nsf-sdn-security-services]), more clients, applications 332 or application controllers need to dynamically update their security 333 policies that are enforced by NSFs. The security service providers 334 have to dynamically update their decision-making process (e.g., in 335 terms of NSF resource allocation and invocation) upon receiving 336 security-related requests from their clients. 338 3.1.5. Demand for Multi-Tenancy to Control and Monitor NSFs 340 Service providers may need to deploy several NSF controllers to 341 control and monitor the NSFs, especially when NSFs become distributed 342 and virtualized. 344 3.1.6. Lack of Characterization of NSFs and Capability Exchange 346 To offer effective security services, service providers need to 347 activate various security functions in NSFs or vNSFs manufactured by 348 multiple vendors. Even within one product category (e.g., firewall), 349 security functions provided by different vendors can have different 350 features and capabilities. For example, filters that can be designed 351 and activated by a firewall may or may not support IPv6 depending on 352 the firewall technology. 354 The service provider's management system (or controller) needs a way 355 to retrieve the capabilities of service functions by different 356 vendors so that it could build an effective security solution. These 357 service function capabilities can be documented in a static manner 358 (e.g., a file) or via an interface which accesses a repository of 359 security function capabilities which the NSF vendors dynamically 360 update. 362 A dynamic capability registration is useful for automation because 363 security functions may be subject to software and hardware updates. 364 These updates may have implications on the policies enforced by the 365 NSFs. 367 Today, there is no standard method for vendors to describe the 368 capabilities of their security functions. Without a common technical 369 framework to describe the capabilities of security functions, service 370 providers cannot automate the process of selecting NSFs by different 371 vendors to accommodate customer's security requirements. 373 The I2NSF work will focus on developing a standard method to describe 374 capabilities of security functions. 376 3.1.7. Lack of Mechanism for NSFs to Utilize External Profiles 378 Many security functions depend on signature files or profiles (e.g., 379 IPS/IDS signatures, DDos Open Threat Signaling (DOTS) filters). 380 Different policies might need different signatures or profiles. 381 Today, black list databases can be a beneficial strategy for all 382 parties involved (except the attackers), but in the future there 383 might be open Source-provided signature/profiles distributed as part 384 of IDS systems (e.g., by Snort, Suricata, Bro and Kismet). 386 There is a need to have a standard envelope (i.e., a message format) 387 to allow NSFs to use external profiles. 389 3.1.8. Lack of Mechanisms to Accept External Alerts to Trigger 390 Automatic Rule and Configuration Changes 392 NSF can ask the I2NSF security controller to alter specific rules 393 and/or configurations. For example, a Distributed Denial of Service 394 (DDoS) alert could trigger a change to the routing system to send 395 traffic to a traffic scrubbing service to mitigate the DDoS. 397 The DDoS protection has the following two parts: a) the configuration 398 of signaling of open threats and b) DDoS mitigation. DOTS controller 399 manages the signaling part of DDoS. I2NSF controller(s) would 400 control any changes to affected policies (e.g., forwarding and 401 routing, filtering, etc.). By monitoring the network alerts 402 regarding DDoS attacks (e.g. from DOTS servers or clients), the I2NSF 403 controller(s) can feed an alerts analytics engine that could 404 recognize attacks so the I2NSF can enforce the appropriate policies. 406 DDoS mitigation is enhanced if the provider's network security 407 controller can monitor, analyze, and investigate the abnormal events 408 and provide information to the customer or change the network 409 configuration automatically. 411 [I-D.zhou-i2nsf-capability-interface-monitoring] provides details on 412 how monitoring aspects of the flow-based Network Security Functions 413 (NSFs) can use the I2NSF interfaces to receive traffic reports and 414 enforce appropriate policies. 416 3.1.9. Lack of Mechanism for Dynamic Key Distribution to NSFs 418 There is a need for a controller to create, manage, and distribute 419 various keys to distributed NSFs. While there are many key 420 management methods and cryptographic suites (e.g., encryption 421 algorithms, key derivation functions, etc.) and other functions, 422 there is a lack of a standard interface to provision and manage 423 security associations. 425 The keys may be used for message authentication and integrity in 426 order to protect data flows. In addition, keys may be used to secure 427 the protocols and messages in the core routing infrastructure (see 428 [RFC4948]) 430 As of now there is not much focus on an abstraction for keying 431 information that describes the interface between protocols, 432 operators, and automated key management. 434 An example of a solution may provide some insight into why the lack 435 of a mechanism is a problem. If a device had an abstract key table 436 maintained by security services, it could use these keys for routing 437 and security devices. 439 What does this take? 441 Conceptually, there must be an interface defined for routing/ 442 signaling protocols that can: a) make requests for automated key 443 management when it is being used. and b) notify the protocols when 444 keys become available in the key table. One potential use of such an 445 interface is to manage IPsec security associations on SDN networks. 447 An abstract key service will work under the following conditions: 449 1. I2NSF needs to design the key table abstraction, the interface 450 between key management protocols and routing/other protocols, and 451 possibly security protocols at other layers. 453 2. For each routing/other protocol, I2NSF needs to define the 454 mapping between how the protocol represents key material and the 455 protocol-independent key table abstraction. If several protocols 456 share common mechanisms for authentication (e.g., TCP 457 Authentication Option [RFC5925]), then the same mapping may be 458 used for all usages of that mechanism. 460 3. Automated key management needs to support both pair-wise keys and 461 group keys via the abstract key service provided by items 1 and 462 2. I2NSF controllers within the NSF required to exchange data 463 with NSFs may exchange data with individual NSFs using individual 464 pair-wise keys or with a group of NSFs simultaneously using an IP 465 group address secured by a group security key(s). 467 3.2. Challenges Facing Customers 469 When customers invoke hosted security services, their security 470 policies may be enforced by a collection of security functions hosted 471 in different domains. Customers may not have the security skills to 472 express sufficiently precise requirements or security policies. 473 Usually, these customers express the expectations of their security 474 requirements or the intent of their security policies. These 475 expectations can be considered customer-level security expectations. 476 Customers may also desire to express guidelines for security 477 management. Examples of such guidelines include: 479 o Which critical communications are to be preserved during critical 480 events and which hosts will continue services over the network, 482 o What signaling information is passed to a controller during a 483 Distributed Denial of Service in order to ask for mitigation 484 services (within the scope DOTS working group), 486 o Reporting of attacks to CERT (within the scope of MILE working 487 group), and 489 o Managing network connectivity of systems out of compliance (within 490 the scope of SACM working group). 492 3.2.1. NSFs from Heterogeneous Administrative Domains 494 Many medium and large enterprises have deployed various on-premises 495 security functions which they want to continue to use. These 496 enterprises want to combine local security functions with remote 497 hosted security functions to achieve more efficient and immediate 498 counter-measures to both Internet-originated attacks and enterprise 499 network-originated attacks. 501 Some enterprises may only need the hosted security services for their 502 remote branch offices where minimal security infrastructures/ 503 capabilities exist. The security solution will consist of deploying 504 NSFs on customer networks and on service provider networks. 506 3.2.2. Today's Control Requests are Vendor Specific 508 Customers may utilize NSFs provided by multiple service providers. 509 Customers need to express their security requirements, guidelines, 510 and expectations to the service providers. In turn, the service 511 providers must translate this customer information into customer 512 security policies and associated configuration tasks for the set of 513 security functions in their network. Without a standardized 514 interface that provides a clear technical characterization, the 515 service provider faces many challenges: 517 No standard technical characterization, APIs, or Interface: Even 518 for the most common security services there is no standard 519 technical characterization, APIs, or interface(s). Most security 520 services are accessible only through disparate, proprietary 521 interfaces (e.g., portals or APIs) in whatever format vendors 522 choose to offer. The service provider must process the customer's 523 input with these widely varying interfaces and differing 524 configuration models for security devices and security policy. 525 Without a standard interface, new innovative security products 526 find a large barrier to entry into the market. 528 Lack of immediate feedback: Customers may also require a mechanism 529 to easily update/modify their security requirements with immediate 530 effect in the underlying involved NSFs. 532 Lack of explicit invocation request: While security agreements are 533 in place, security functions may be solicited without requiring an 534 explicit invocation means. Nevertheless, some explicit invocation 535 means may be required to interact with a service function. 537 Managing by scripts de-jour: The current practices rely upon the 538 use of scripts that generate other scripts which automatically run 539 to upload or download configuration changes, log information and 540 other things. These scripts have to be adjusted each time an 541 implementation from a different vendor technology is enabled by a 542 provider. 544 To see how standard interfaces could help achieve faster 545 implementation time cycles, let us consider a customer who would like 546 to dynamically allow an encrypted flow with specific port, src/dst 547 addresses or protocol type through the firewall/IPS to enable an 548 encrypted video conferencing call only during the time of the call. 549 With no commonly accepted interface in place, as shown in figure 1, 550 the customer would have to learn about the particular provider's 551 firewall/IPS interface and send the request in the provider's 552 required format. 554 +------------+ 555 | security | 556 | management | 557 | system | 558 +----||------+ 559 || proprietary 560 || or I2NSF standard 561 Video: || 562 Port 10 +--------+ 563 --------| FW/IPS |------------- 564 Encrypted +--------+ 565 Video Flow 567 Figure 1: Example of non-standard vs. standard interface 569 In contrast, as figure 1 shows, if a firewall/IPS interface standard 570 exists the customer would be able to send the request to a security 571 management system and the security management would send it via a 572 I2NSF standard interface. Service providers could now utilize the 573 same standard interface interface to represent firewall/IPS services 574 implemented using products from many vendors. 576 3.2.3. Difficult for Customer to Monitor the Execution of Desired 577 Policies 579 How a policy is translated into technology-specific actions is hidden 580 from the customers. However, customers still need ways to monitor 581 the delivered security service that results from the execution of 582 their desired security requirements, guidelines and expectations. 583 Customers want to monitor existing policies to determine such things 584 as: which policies are in effect, how many security attacks are being 585 prevented, and how much bandwidth efficiency does security 586 enforcement cost. 588 Today, there is no standard way for customers to get these details 589 from the security service which assure the customer that their 590 specified security policies properly enforced by the security 591 functions in the provider domain. 593 Customers also want this monitoring information from the security 594 system in order to plan for the future using "what-if" scenarios with 595 real data. A tight loop between the data gathered from security 596 systems and the "what-if" scenario planning can reduce the time to 597 design and deploy workable security policies that deal with new 598 threats. 600 It is the objective of the I2NSF work to provide a standard way to 601 get the information that security service assurance systems need to 602 provide customers an evaluation about the current security systems, 603 and to quickly plan for future security policies using "what-if" 604 scenarios based on today's information 606 3.3. Lack of Standard Interface to Inject Feedback to NSF 608 Today, many security functions in the NSF, such as IPS, IDS, DDoS 609 mitigation and antivirus, depend heavily on the associated profiles. 610 NSF devices can perform more effective protection if these NSF 611 devices have the up-to-date profiles for these functions. Today 612 there is no standard interface to provide these security profiles for 613 the NSF. 615 As more sophisticated threats arise, protection will depend on 616 enterprises, vendors, and service providers being able to cooperate 617 to develop optimal profiles such as the [CTA]. The standard 618 interface to provide security profiles to the NSF should interwork 619 with the formats which exchange security profiles between 620 organizations. 622 One objective of the I2NSF work is to provide this type of standard 623 interface to security profiles. 625 3.4. Lack of Standard Interface for Capability Negotiation 627 There could be situations when the selected NSFs cannot perform the 628 policies requested by the Security Controller, due to resource 629 constraints. The customer and security service provider should 630 negotiate the appropriate resource constraints before the security 631 service begins. However, unexpected events may happen causing the 632 NSF to exhaust those negotiated resources. At this point, the NSF 633 should inform the security controller that the alloted resources have 634 been exhausted. To support the automatic control in the SDN-era, it 635 is necessary to have a set of messages for proper notification (and a 636 response to that notification) between the Security Controller and 637 the NSFs. 639 3.5. Difficult to Validate Policies across Multiple Domains 641 As discussed in the previous four sections, both service providers 642 and customers have need to express policies and profiles, monitor 643 systems, verify security policy has been installed in NSFs within a 644 security domain, and establish limits for services NSFs can safely 645 perform. This sub-section and the next sub-section (section 3.6) 646 examine what happens in two specific network scenarios: a) multi- 647 domain control of security devices hosted on virtual and non-virtual 648 NSFs, and b) software defined networking. 650 Hosted security service may instantiate NSFs in virtual machines 651 which are sometimes widely distributed in the network and sometimes 652 are combined together in one device to perform a set of tasks for 653 delivering a service. Hosted security services may be connected 654 within a single service provider or via multiple services provider. 655 Ensuring that the security service purchased by the customer adheres 656 to customer policy requires that the central controller(s) for this 657 service monitor and validate this service across multiple networks on 658 NSFs (some of which may be virtual networks on virtual machines). To 659 set up this cross-domain service, the security controller must be 660 able to communicate with NSFs and/or controllers within its domain 661 and across domains to negotiate for the services needed. 663 Without standard interfaces and security policy data models, the 664 enforcement of a customer-driven security policy remains challenging 665 because of the inherent complexity created by combining the 666 invocation of several vendor-specific security functions into a 667 multi-vendor, heterogeneous environment across multiple domains. 668 Each vendor-specific function may require specific configuration 669 procedures and operational tasks. 671 Ensuring the consistent enforcement of the policies at various 672 domains is also challenging. Standard data models are likely to 673 contribute to solving that issue. 675 3.6. Software-Defined Networks 677 Software-Defined Networks have changed the landscape of data center 678 designs by introducing overlay networks deployed over Top of Rack 679 (ToR) switches that connect to a hypervisor. SDN techniques are 680 meant to improve the flexibility of workload management without 681 affecting applications and how they work. Workload can thus be 682 easily and seamlessly managed across private and public clouds. SDN 683 techniques optimize resource usage and are now being deployed in 684 various networking environments, besides cloud infrastructures. Yet, 685 such SDN conferred agility may raise specific security issues. For 686 example a security administrator must make sure that a security 687 policy can be enforced regardless of the location of the workload, 688 thereby raising concerns about the ability of SDN computation logic 689 to send security policy-provisioning information to the participating 690 NSFs. A second example is workload migration to a public cloud 691 infrastructure which may raise additional security requirements 692 during the migration. 694 4. Use Cases 696 Standard interfaces for monitoring and controlling the behavior of 697 NSFs are essential building blocks for security service providers and 698 enterprises to automate the use of different NSFs from multiple 699 vendors by their security management entities. I2NSF may be invoked 700 by any (authorized) client. Examples of authorized clients are 701 upstream applications (controllers), orchestration systems, and 702 security portals. 704 4.1. Basic Framework 706 Users request security services through specific clients (e.g., a 707 customer application, the Network Service Providers (NSP) Business 708 Support Systems/Operations Support Systems (BSS/OSS) or management 709 platform) and the appropriate NSP network entity will invoke the 710 (v)NSFs according to the user service request. This network entity 711 is denoted as the security controller in this document. The 712 interaction between the entities discussed above (client, security 713 controller, NSF) is shown in Figure 2: 715 +----------+ 716 +-------+ | | +-------+ 717 | | Interface 1 |Security | Interface 2 | NSF(s)| 718 |Client <--------------> <------------------> | 719 | | |Controller| | | 720 +-------+ | | +-------+ 721 +----------+ 723 Figure 2: Interaction between Entities 725 Interface 1 is used for receiving security requirements from a client 726 and translating them into commands that NSFs can understand and 727 execute. The security controller also passes back NSF security 728 reports (e.g., statistics) to the client which the security 729 controller has gathered from NSFs. Interface 2 is used for 730 interacting with NSFs according to commands (e.g., enact/revoke a 731 security policy, or distribute a policy), and collecting status 732 information about NSFs. 734 Client devices or applications can require the security controller to 735 add, delete or update rules in the security service function for 736 their specific traffic. 738 When users want to get the executing status of a security service, 739 they can request NSF status from the client. The security controller 740 will collect NSF information through Interface 2, consolidate it, and 741 give feedback to the client through Interface 1. This interface can 742 be used to collect not only individual service information, but also 743 aggregated data suitable for tasks like infrastructure security 744 assessment. 746 Customers may require validating NSF availability, provenance, and 747 execution. This validation process, especially relevant to vNSFs, 748 includes at least: 750 Integrity of the NSF: Ensuring that the NSF is not compromised; 752 Isolation: Ensuring the execution of the NSF is self-contained for 753 privacy requirements in multi-tenancy scenarios; and 755 Provenance of the NSF: Customers may need to be provided with 756 strict guarantees about the origin of the NSF, its status (e.g., 757 available, idle, down, and others), and feedback mechanisms so 758 that a customer may be able to check that a given NSF or set of 759 NSFs properly conform to the the customer's requirements and 760 subsequent configuration tasks. 762 In order to achieve this, the security controller may collect 763 security measurements and share them with an independent and trusted 764 third party (via Interface 1) in order to allow for attestation of 765 NSF functions using the third party added information. 767 This implies that there may be the following two types of clients 768 using interface 1: the end-user and and the trusted independent third 769 party. The I2NSF work may determine that interface 1 creates two 770 sub-interfaces to support these two types of clients. 772 4.2. Access Networks 774 This scenario describes use cases for users (e.g., residential user, 775 enterprise user, mobile user, and management system) that request and 776 manage security services hosted in the NSP infrastructure. Given 777 that NSP customers are essentially users of their access networks, 778 the scenario is essentially associated with their characteristics as 779 well as with the use of vNSFs. Figure 3 shows how different types of 780 customer connect through virtual access nodes (vCPE, vPE, and vEPC) 781 to an NSF. 783 The virtual customer premise equipment (vCPE) described in use case 784 #7 in [NFVUC] requires a model of access virtualization that includes 785 mobile and residential access networks where the operator may offload 786 security services from the customer local environment (e.g., device 787 or terminal) to its own infrastructure. 789 These use cases define the interaction between the operator and the 790 vNSFs through automated interfaces which support the business 791 communications between customer and provider or between two business 792 entities. 794 Customer + Access + PoP/Datacenter 795 | | +--------+ 796 | ,-----+--. |Network | 797 | ,' | `-|Operator| 798 +-------------+ | /+----+ | |Mgmt Sys| 799 | Residential |-+------/-+vCPE+----+ +--------+ 800 +-------------+ | / +----+ | \ | : 801 | / | \ | | 802 +----------+ | ; +----+ | +----+ | 803 |Enterprise|---+---+----+ vPE+--+----+ NSF| | 804 +----------+ | : +----+ | +----+ | 805 | : | / | 806 +--------+ | : +----+ | / ; 807 | Mobile |-+-----\--+vEPC+----+ / 808 +--------+ | \ +----+ | Service / 809 | `--. | Provider / 810 | `----+---------.. 811 + + ^^ 812 || 813 Service Provider 814 encompasses 815 everything 816 in circle 818 vCPE - virtual customer premise equipment 819 vPE - virtual provider equipment 820 vEPC - virtual evolved packet core 821 (mobile-core network) 823 Figure 3: NSF and actors 825 Different access clients may have different service requests: 827 Residential: service requests for parental control, content 828 management, and threat management. 830 Threat content management may include identifying and blocking 831 malicious activities from web contents, mail, or files downloaded. 832 Threat management may include identifying and blocking botnets or 833 malware. 835 Enterprise: service requests for enterprise flow security policies 836 and managed security services 838 Flow security policies identify and block malicious activities 839 during access to (or isolation from) web sites or social media 840 applications. Managed security services for an enterprise may 841 include detection and mitigation of external and internal threats. 842 External threats can include application or phishing attacks, 843 malware, botnet, DDoS, and others. 845 Service Provider: Service requests for policies that protect 846 service provider networks against various threats (including DDoS, 847 botnets and malware). Such policies are meant to securely and 848 reliably deliver contents (e.g., data, voice, and video) to 849 various customers, including residential, mobile and corporate 850 customers. These security policies are also enforced to guarantee 851 isolation between multiple tenants, regardless of the nature of 852 the corresponding connectivity services. 854 Mobile: service requests from interfaces which monitor and ensure 855 user quality of experience, content management, parental controls, 856 and external threat management. 858 Content management for the mobile device includes identifying and 859 blocking malicious activities from web contents, mail, files 860 uploaded/downloaded. Threat management for infrastructure 861 includes detecting and removing malicious programs such as botnet, 862 malware, and other programs that create distributed DoS attacks). 864 Some access customers may not care about which NSFs are utilized to 865 achieve the services they requested. In this case, provider network 866 orchestration systems can internally select the NSFs (or vNSFs) to 867 enforce the security policies requested by the clients. 869 Other access customers, especially some enterprise customers, may 870 want to contract separately for dedicated NSFs (most likely vNSFs) 871 for direct control purposes. In this case, here are the steps to 872 associate vNSFs to specific customers: 874 vNSF Deployment: The deployment process consists in instantiating 875 an NSF on a Virtualization Infrastructure (NFVI), within the NSP 876 administrative domain(s) or with other external domain(s). This 877 is a required step before a customer can subscribe to a security 878 service supported in the vNSF. 880 vNSF Customer Provisioning: Once a vNSF is deployed, any customer 881 can subscribe to it. The provisioning life cycle includes the 882 following: 884 * Customer enrollment and cancellation of the subscription to a 885 vNSF; 887 * Configuration of the vNSF, based on specific configurations, or 888 derived from common security policies defined by the NSP. 890 * Retrieval of the vNSF functionalities, extracted from a 891 manifest or a descriptor. The NSP management systems can 892 demand this information to offer detailed information through 893 the commercial channels to the customer. 895 4.3. Cloud Data Center Scenario 897 In a data center, network security mechanisms such as firewalls may 898 need to be dynamically added or removed for a number of reasons. 899 These changes may be explicitly requested by the user, or triggered 900 by a pre-agreed upon demand level in the Service Level Agreement 901 (SLA) between the user and the provider of the service. For example, 902 the service provider may be required to add more firewall capacity 903 within a set of time frames whenever the bandwidth utilization hits a 904 certain threshold for a specified period. This capacity expansion 905 could result in adding new instances of firewalls on existing 906 machines or provisioning a completely new firewall instance in a 907 different machine. 909 The on-demand, dynamic nature of security service delivery 910 essentially encourages that the network security "devices" be in 911 software or virtual forms, rather than in a physical appliance form. 912 This requirement is a provider-side concern. Users of the firewall 913 service are agnostic (as they should) as to whether or not the 914 firewall service is run on a VM or any other form factor. Indeed, 915 they may not even be aware that their traffic traverses firewalls. 917 Furthermore, new firewall instances need to be placed in the "right 918 zone" (domain). The issue applies not only to multi-tenant 919 environments where getting the tenant in the right domain is of 920 paramount importance, but also in environments owned and operated by 921 a single organization with its own service segregation policies. For 922 example, an enterprise may mandate that firewalls serving Internet 923 traffic, within organization, and inter-organization traffic be 924 separated. Another example is that IPS/IDS services which splits 925 traffic into investment banking traffic and other data traffic to 926 comply with regulatory restrictions for transfer of investment 927 banking information. 929 4.3.1. On-Demand Virtual Firewall Deployment 931 A service provider-operated cloud data center could serve tens of 932 thousands of clients. Clients' compute servers are typically hosted 933 on VMs, which could be deployed across different server racks located 934 in different parts of the data center. It is often not technically 935 and/or financially feasible to deploy dedicated physical firewalls to 936 suit each client's security policy requirements, which can be 937 numerous. What is needed is the ability to dynamically deploy 938 virtual firewalls for each client's set of servers based on 939 established security policies and underlying network topologies. 940 Figure 4 shows an example topology of virtual firewalls within a data 941 center. 943 ---+-----------------------------+----- 944 | | 945 +---+ +-+-+ 946 |vFW| |vFW| 947 +---+ +-+-+ 948 | Client #1 | Client #2 949 ---+-------+--- ---+-------+--- 950 +-+-+ +-+-+ +-+-+ +-+-+ 951 |vM | |vM | |vM | |vM | 952 +---+ +---+ +---+ +---+ 954 Figure 4: NSF in Data Centers 956 4.3.2. Firewall Policy Deployment Automation 958 Firewall rule setting is often a time consuming, complex and error- 959 prone process even within a single organization/enterprise framework. 960 It becomes far more complex in provider-owned cloud networks that 961 serve myriads of customers. 963 Firewall rules today are highly tied with ports and addresses that 964 identify traffic. This makes it very difficult for clients of cloud 965 data centers to construct rules for their own traffic as the clients 966 only see the virtual networks and the virtual addresses. The 967 customer-visible virtual networks and addresses may be different from 968 the actual packets traversing the firewalls (FWs). 970 Even though most vendors support similar firewall features, the 971 specific rule configuration keywords are different from vendors to 972 vendors, making it difficult for automation. Automation works best 973 when it can leverage a common set of standards that will work across 974 NSFs by multiple vendors and utilize dynamic key management. 976 4.3.3. Client-Specific Security Policy in Cloud VPNs 978 Clients of service provider-operated cloud data centers need to 979 secure Virtual Private Networks (VPNs) and virtual security functions 980 that apply the clients' security policies. The security policies may 981 govern communication within the clients' own virtual networks as well 982 as communication with external networks. For example, VPN service 983 providers may need to provide firewall and other security services to 984 their VPN clients. Today, it is generally not possible for clients 985 to dynamically view (let alone change) what, where and how security 986 policies are implemented on their provider-operated clouds. Indeed, 987 no standards-based framework exists to allow clients to retrieve/ 988 manage security policies in a consistent manner across different 989 providers. 991 As described above, the dynamic key management is critical for the 992 securing the VPN and the distribution of policies. 994 4.3.4. Internal Network Monitoring 996 There are many types of internal traffic monitors that may be managed 997 by a security controller. This includes the class of services 998 referred to as Data Loss Prevention (DLP), or Reputation Protection 999 Services (RPS). Depending on the class of event, alerts may go to 1000 internal administrators, or external services. 1002 4.4. Preventing Distributed DoS, Malware and Botnet attacks 1004 In the Internet where everything is connected, preventing unwanted 1005 traffic that may cause a Denial of Service (DoS) attack or a 1006 distributed DoS (DDoS) attack has become a challenge. Similarly, a 1007 network could be exposed to malware attacks and become an attack 1008 vector to jeopardize the operation of other networks, by means of 1009 remote commands for example. Many networks which carry groups of 1010 information (such as Internet of Things (IoT) networks, Information- 1011 Centric Networks (ICN), Content Delivery Networks (CDN), Voice over 1012 IP packet networks (VoIP), and Voice over LTE (VoLTE)) are also 1013 exposed to such remote attacks. There are many examples of remote 1014 attacks on these networks, but the following examples will illustrate 1015 the issues. A malware attack on an IoT network which carries sensor 1016 readings and instructions may attempt to alter the sensor 1017 instructions in order to disable a key sensor. A malware attack VoIP 1018 or VoLTE networks is software that attempts to place unauthorized 1019 long-distance calls. Botnets may overwhelm nodes in ICN and CDN 1020 networks so that the networks cannot pass critical data. 1022 In order for organizations to better secure their networks against 1023 these kind of attacks, the I2NSF framework should provide a client- 1024 side interface that is use case-independent and technology-agnostic. 1025 Technology-agnostic is to is defined to be generic, technology 1026 independent, and able to support multiple protocols and data models. 1027 For example, such an I2NSF interface could be used to provision 1028 security policy configuration information that looks for specific 1029 malware signatures. Similarly, botnet attacks could be easily 1030 prevented by provisioning security policies using the I2NSF client- 1031 side interface that prevent access to botnet command and control 1032 servers. 1034 4.5. Regulatory and Compliance Security Policies 1036 Organizations must protect their networks against attacks and must 1037 also adhere to various industry regulations: any organization that 1038 falls under a specific regulation like Payment Card Industry (PCI)- 1039 Data Security Standard (DSS) [PCI-DSS] for the payment industry or 1040 Health Insurance Portability and Accountability Act [HIPAA] for the 1041 healthcare industry must be able to isolate various kinds of traffic. 1042 They must also show records of their security policies whenever 1043 audited. 1045 The I2NSF client-side interface could be used to provision regulatory 1046 and compliance-related security policies. The security controller 1047 would keep track of when and where a specific policy is applied and 1048 if there is any policy violation; this information can be provided in 1049 the event of an audit as a proof that traffic is isolated between 1050 specific endpoints, in full compliance with the required regulations. 1052 5. Management Considerations 1054 Management of NSFs usually include the following: 1056 o Life cycle management and resource management of NSFs, 1058 o Device configuration, such as address configuration, device 1059 internal attributes configuration, etc., 1061 o Signaling of events, notifications and changes, and 1063 o Policy rule provisioning. 1065 I2NSF will only focus on the policy provisioning part of NSF 1066 management. 1068 6. IANA Considerations 1070 No IANA considerations exist for this document. 1072 7. Security Considerations 1074 Having secure access to control and monitor NSFs is crucial for 1075 hosted security services. An I2NSF security controller raises new 1076 security threats. It needs to be resilient to attacks and quickly 1077 recover from attacks. Therefore, proper secure communication 1078 channels have to be carefully specified for carrying controlling and 1079 monitoring traffic between the NSFs and their management entity (or 1080 entities). 1082 The traffic flow security policies specified by customers can 1083 conflict with providers' internal traffic flow security policies. 1084 This conflict can be resolved in one of two ways: a) installed 1085 policies can restrict traffic if either the customer traffic flow 1086 security policies or the provider's internal security policies 1087 restrict traffic, or b) can only restrict traffic if both the 1088 customer traffic flow security policies and the provider's internal 1089 traffic flow security policies restrict data. Either choice could 1090 cause potential problems. It is crucial for the management system to 1091 flag these conflicts to the customers and to the service provider. 1093 It is important to proper AAA [RFC2904] to authorize access to the 1094 network and access to the I2NSF management stream. 1096 Enforcing the appropriate privacy is key to all IETF protocols (see 1097 [RFC6973]), and especially important for IETF Security management 1098 protocols since they are deployed to protect the network. In some 1099 circumstances, security management protocols may be utilized to 1100 protect an individual's home, phone, or other personal data. In this 1101 case, any solution should carefully consider whether combining 1102 management streams abides by the recommendations of [RFC6973] for 1103 data minimization, user participation, and security. 1105 8. Contributors 1107 I2NSF is a group effort. The following people actively contributed 1108 to the initial use case text: Xiaojun Zhuang (China Mobile), Sumandra 1109 Majee (F5), Ed Lopez (Curveball Networks), and Robert Moskowitz 1110 (Huawei). 1112 9. Contributing Authors 1114 I2NSF has had a number of contributing authors. The following are 1115 contributing authors: 1117 o Linda Dunbar (Huawei), 1119 o Antonio Pastur (Telefonica I+D), 1121 o Mohamed Boucadair (France Telecom), 1123 o Michael Georgiades (Prime Tel), 1125 o Minpeng Qi (China Mobile), 1127 o Shaibal Chakrabarty (US Ignite), 1129 o Nic Leymann (Deutsche Telekom), 1130 o Anil Lohiya (Juniper), 1132 o David Qi (Bloomberg), 1134 o Hyoungshick Kim (Sungkyunkwan University), 1136 o Jung-Soo Park (ETRI), 1138 o Tae-Jin Ahn (Korea Telecom), and 1140 o Se-Hui Lee (Korea Telecom). 1142 10. Acknowledgments 1144 This document was supported by Institute for Information and 1145 communications Technology Promotion (IITP) funded by the Korea 1146 government (MSIP) [R0166-15-1041, Standard Development of Network 1147 Security based SDN]. 1149 11. Informative References 1151 [CTA] Cyber Threat Alliance, , "Cyber Threat Alliance", October 1152 2016, . 1154 [EPC-3GPP] 1155 Firmin, F., "The Evolved Packet Core", January 2017. 1157 [ETSI-NFV] 1158 ETSI GS NFV 002 V1.1.1, , "Network Functions 1159 Virtualisation (NFV); Architectural Framework", October 1160 2013. 1162 [Gartner-2013] 1163 Messmer, E., "Gartner: Cloud-based security as a service 1164 set to take off", October 2013. 1166 [HIPAA] US Congress, , "HEALTH INSURANCE PORTABILITY AND 1167 ACCOUNTABILITY ACT OF 1996 (Public Law 104-191)", August 1168 1996, . 1170 [I-D.ietf-i2nsf-gap-analysis] 1171 Hares, S., Moskowitz, R., and D. Zhang, "Analysis of 1172 Existing work for I2NSF", draft-ietf-i2nsf-gap-analysis-03 1173 (work in progress), March 2017. 1175 [I-D.ietf-opsawg-firewalls] 1176 Baker, F. and P. Hoffman, "On Firewalls in Internet 1177 Security", draft-ietf-opsawg-firewalls-01 (work in 1178 progress), October 2012. 1180 [I-D.jeong-i2nsf-sdn-security-services] 1181 Jeong, J., Kim, H., Jung-Soo, P., Ahn, T., and s. 1182 sehuilee@kt.com, "Software-Defined Networking Based 1183 Security Services using Interface to Network Security 1184 Functions", draft-jeong-i2nsf-sdn-security-services-05 1185 (work in progress), July 2016. 1187 [I-D.pastor-i2nsf-access-usecases] 1188 Pastor, A. and D. Lopez, "Access Use Cases for an Open OAM 1189 Interface to Virtualized Security Services", draft-pastor- 1190 i2nsf-access-usecases-00 (work in progress), October 2014. 1192 [I-D.pastor-i2nsf-merged-use-cases] 1193 Pastor, A., Lopez, D., Wang, K., Zhuang, X., Qi, M., 1194 Zarny, M., Majee, S., Leymann, N., Dunbar, L., and M. 1195 Georgiades, "Use Cases and Requirements for an Interface 1196 to Network Security Functions", draft-pastor-i2nsf-merged- 1197 use-cases-00 (work in progress), June 2015. 1199 [I-D.qi-i2nsf-access-network-usecase] 1200 Wang, K. and X. Zhuang, "Integrated Security with Access 1201 Network Use Case", draft-qi-i2nsf-access-network- 1202 usecase-02 (work in progress), March 2015. 1204 [I-D.zarny-i2nsf-data-center-use-cases] 1205 Zarny, M., Leymann, N., and L. Dunbar, "I2NSF Data Center 1206 Use Cases", draft-zarny-i2nsf-data-center-use-cases-00 1207 (work in progress), October 2014. 1209 [I-D.zhou-i2nsf-capability-interface-monitoring] 1210 Zhou, C., Xia, L., Boucadair, M., and J. Xiong, "The 1211 Capability Interface for Monitoring Network Security 1212 Functions (NSF) in I2NSF", draft-zhou-i2nsf-capability- 1213 interface-monitoring-00 (work in progress), October 2015. 1215 [NFVUC] ETSI GS NFV 001 V1.1.1, , "ETSI NFV Group Specification, 1216 Network Functions Virtualization (NFV) Use Cases", October 1217 2013. 1219 [PCI-DSS] PCI Security Council, , "Payment Card Industry (PCI) Data 1220 Security Standard Requirements and Security Assessment 1221 Procedures (version 3.2)", April 2016, 1222 . 1224 [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., 1225 Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and 1226 D. Spence, "AAA Authorization Framework", RFC 2904, 1227 DOI 10.17487/RFC2904, August 2000, 1228 . 1230 [RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the 1231 IAB workshop on Unwanted Traffic March 9-10, 2006", 1232 RFC 4948, DOI 10.17487/RFC4948, August 2007, 1233 . 1235 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1236 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1237 June 2010, . 1239 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1240 Morris, J., Hansen, M., and R. Smith, "Privacy 1241 Considerations for Internet Protocols", RFC 6973, 1242 DOI 10.17487/RFC6973, July 2013, 1243 . 1245 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 1246 Networking: A Perspective from within a Service Provider 1247 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 1248 . 1250 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 1251 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 1252 Defined Networking (SDN): Layers and Architecture 1253 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 1254 2015, . 1256 Authors' Addresses 1258 Susan Hares 1259 Huawei 1260 7453 Hickory Hill 1261 Saline, MI 48176 1262 USA 1264 Phone: +1-734-604-0332 1265 Email: shares@ndzh.com 1266 Diego R. Lopez 1267 Telefonica I+D 1268 Don Ramon de la Cruz, 82 1269 Madrid 28006 1270 Spain 1272 Email: diego.r.lopez@telefonica.com 1274 Myo Zarny 1275 vArmour 1276 800 El Camino Real, Suite 3000 1277 Mountain View, CA 94040 1278 USA 1280 Email: myo@varmour.com 1282 Christian Jacquenet 1283 France Telecom 1284 Rennes, 35000 1285 France 1287 Email: Christian.jacquenet@orange.com 1289 Rakesh Kumar 1290 Juniper Networks 1291 1133 Innovation Way 1292 Sunnyvale, CA 94089 1293 USA 1295 Email: rkkumar@juniper.net 1297 Jaehoon Paul Jeong 1298 Department of Software 1299 Sungkyunkwan University 1300 2066 Seobu-Ro, Jangan-Gu 1301 Suwon, Gyeonggi-Do 16419 1302 Republic of Korea 1304 Phone: +82 31 299 4957 1305 Fax: +82 31 290 7996 1306 Email: pauljeong@skku.edu 1307 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php