idnits 2.17.1 draft-ietf-i2nsf-problem-and-use-cases-05.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 (December 5, 2016) is 2692 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 723, but not defined == Unused Reference: 'RFC2119' is defined on line 1064, but no explicit reference was found in the text == Unused Reference: 'AVANT-GUARD' is defined on line 1071, but no explicit reference was found in the text == Unused Reference: 'ETSI-NFV' is defined on line 1076, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2nsf-framework' is defined on line 1090, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netmod-acl-model' is defined on line 1096, but no explicit reference was found in the text == Unused Reference: 'I-D.lopez-i2nsf-packet' is defined on line 1114, but no explicit reference was found in the text == Unused Reference: 'I-D.zarny-i2nsf-data-center-use-cases' is defined on line 1136, but no explicit reference was found in the text == Unused Reference: 'ITU-T.Y.3300' is defined on line 1147, but no explicit reference was found in the text == Unused Reference: 'ONF-OpenFlow' is defined on line 1151, but no explicit reference was found in the text == Unused Reference: 'ONF-SDN-Architecture' is defined on line 1155, but no explicit reference was found in the text == Unused Reference: 'RFC4566' is defined on line 1164, but no explicit reference was found in the text == Unused Reference: 'RFC7149' is defined on line 1173, but no explicit reference was found in the text == Unused Reference: 'RFC7277' is defined on line 1178, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-i2nsf-framework-04 == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-06 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 7277 (Obsoleted by RFC 8344) Summary: 0 errors (**), 0 flaws (~~), 17 warnings (==), 3 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: June 8, 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 December 5, 2016 16 I2NSF Problem Statement and Use cases 17 draft-ietf-i2nsf-problem-and-use-cases-05 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 June 8, 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 . . . . 11 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. Software-Defined Networks . . . . . . . . . . . . . . . . 13 83 3.5. Lack of Standard Interface to Inject Feedback to NSF . . 13 84 3.6. Lack of Standard Interface for Capability Negotiation . . 14 85 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 4.1. Basic Framework . . . . . . . . . . . . . . . . . . . . . 14 87 4.2. Access Networks . . . . . . . . . . . . . . . . . . . . . 16 88 4.3. Cloud Data Center Scenario . . . . . . . . . . . . . . . 18 89 4.3.1. On-Demand Virtual Firewall Deployment . . . . . . . . 19 90 4.3.2. Firewall Policy Deployment Automation . . . . . . . . 19 91 4.3.3. Client-Specific Security Policy in Cloud VPNs . . . . 20 92 4.3.4. Internal Network Monitoring . . . . . . . . . . . . . 20 93 4.4. Preventing Distributed DoS, Malware and Botnet attacks . 20 94 4.5. Regulatory and compliance secuirty policies . . . . . . . 21 95 5. Management Considerations . . . . . . . . . . . . . . . . . . 21 96 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 97 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 98 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 99 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . 22 100 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 101 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 102 11.1. Normative References . . . . . . . . . . . . . . . . . . 23 103 11.2. Informative References . . . . . . . . . . . . . . . . . 23 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 106 1. Introduction 108 This document describes the problem statement for Interface to 109 Network Security Functions (I2NSF) as well as some I2NSF use cases. 110 A summary of the state of the art in the industry and IETF which is 111 relevant to I2NSF work is documented in 112 [I-D.hares-i2nsf-gap-analysis]. 114 The growing challenges and complexity in maintaining a secure 115 infrastructure, complying with regulatory requirements, and 116 controlling costs are enticing enterprises into consuming network 117 security functions hosted by service providers. The hosted security 118 service is especially attractive to small and medium size enterprises 119 who suffer from a lack of security experts to continuously monitor 120 networks, acquire new skills and propose immediate mitigations to 121 ever increasing sets of security attacks. 123 According to [Gartner-2013], the demand for hosted (or cloud-based) 124 security services is growing. Small and medium-sized businesses 125 (SMBs) are increasingly adopting cloud-based security services to 126 replace on-premises security tools, while larger enterprises are 127 deploying a mix of traditional and cloud-based security services. 129 To meet the demand, more and more service providers are providing 130 hosted security solutions to deliver cost-effective managed security 131 services to enterprise customers. The hosted security services are 132 primarily targeted at enterprises (especially small/medium ones), but 133 could also be provided to any kind of mass-market customer. As a 134 result, the Network Security Functions (NSFs) are provided and 135 consumed in a large variety of environments. Users of NSFs may 136 consume network security services hosted by one or more providers, 137 which may be their own enterprise, service providers, or a 138 combination of both. This document also briefly describes the 139 following use cases summarized by 140 [I-D.pastor-i2nsf-merged-use-cases]: 142 o [I-D.pastor-i2nsf-access-usecases] (I2NSF-Access), 144 o [I-D.zarny-i2nsf-data-center-use-cases](I2NSF-DC), and 145 o [I-D.qi-i2nsf-access-network-usecase] (I2NSF-Mobile). 147 2. Terminology 149 ACL: Access Control List 151 B2B: Business-to-Business 153 Bespoke: Something made to fit a particular person, client or 154 company. 156 Bespoke security management: Security management which is made to 157 fit a particular customer. 159 DC: Data Center 161 FW: Firewall 163 IDS: Intrusion Detection System 165 IPS: Intrusion Protection System 167 I2NSF: interface to Network Security Functions. 169 NSF: Network Security Function. An NSF is a function that detects 170 abnormal activity and blocks/mitigates the effect of such abnormal 171 activity in order to preserve the availability of a network or a 172 service. In addition, the NSF can help in supporting 173 communication stream integrity and confidentiality. 175 Flow-based NSF: An NSF which inspects network flows according to a 176 security policy. Flow-based security also means that packets are 177 inspected in the order they are received, and without altering 178 packets due to the inspection process (e.g., MAC rewrites, TTL 179 decrement action, or NAT inspection or changes). 181 Virtual NSF: An NSF which is deployed as a distributed virtual 182 resource. 184 VNFPool: Pool of Virtual Network Functions. 186 3. Problem Space 188 The following sub-section describes the problems and challenges 189 facing customers and security service providers when some or all of 190 the security functions are no longer physically hosted by the 191 customer's adminstrative domain. 193 Security service providers can be internal or external to the 194 company. For example, an internal IT Security group within a large 195 enterprise could act as a security service provider for the 196 enterprise. In contrast, an enterprise could outsource all security 197 services to an external security service provider. In this document, 198 the security service provider function whether it is internal or 199 external, will be denoted as "service provider". 201 The "Customer-Provider" relationship may be between any two parties. 202 The parties can be in different firms or different domains of the 203 same firm. Contractual agreements may be required in such contexts 204 to formally document the customer's security requirements and the 205 provider's guarantees to fulfill those requirements. Such agreements 206 may detail protection levels, escalation procedures, alarms 207 reporting, etc. There is currently no standard mechanism to capture 208 those requirements. 210 A service provider may be a customer of another service provider. 212 3.1. Challenges Facing Security Service Providers 214 3.1.1. Diverse Types of Security Functions 216 There are many types of NSFs. NSFs by different vendors can have 217 different features and have different interfaces. NSFs can be 218 deployed in multiple locations in a given network, and perhaps have 219 different roles. 221 Below are a few examples of security functions and locations or 222 contexts in which they are often deployed: 224 External Intrusion and Attack Protection: Examples of this function 225 are firewall/ACL authentication, IPS, IDS, and endpoint 226 protection. 228 Security Functions in a DMZ: Examples of this function are 229 firewall/ACLs, IDS/IPS, one or all of AAA services NAT, forwarding 230 proxies, and application filtering. These functions may be 231 physically on-premise in a server provider's network at the DMZ 232 spots or located in a "virtual" DMZ. 234 Centralized or Distributed security functions: The security 235 functions could be deployed in a centalized manner for handling 236 large traffic with ease of management or in a distrubuted manner 237 if a specifc function does not scale or may be for simplified 238 network deployment. No matter, how a security function is 239 deployed and provisioned, there should be a consistent mechanism 240 to provision security policies otherwise it make the job of 241 security admin lot more complex. 243 Internal Security Analysis and Reporting: Examples of this function 244 are security logs, event correlation, and forensic analysis. 246 Internal Data and Content Protection: Examples of this function are 247 encryption, authorization, and public/private key management for 248 internal database. 250 Security gateways and VPN concentrators: Examples of these 251 functions are; IP-sec gateways, Secure VPN concentrators that 252 handle bridging secure VPNs, and Secure VPN controllers for data 253 flows. 255 Given the diversity of security functions, the contexts in which 256 these functions can be deployed, and the constant evolution of these 257 functions, standardizing all aspects of security functions is 258 challenging, and most probably not feasible. Fortunately, it is not 259 necessary to standardize all aspects. For example, from an I2NSF 260 perspective, there is no need to standardize how every firewall's 261 filtering is created or applied. Some features in a specific 262 vendor's filtering may be unique to the vendor's product so it is not 263 necessary to standardize these features. 265 What is needed is a standardized interface to control and monitor the 266 rule sets that NSFs use to treat packets traversing through. And 267 standardizing interfaces will provide an impetuous for standardizing 268 established security functions. 270 I2NSF may specify some filters, but these filters will be linked to 271 specific common functionality developed by I2NSF in informational 272 models or data models. 274 3.1.2. Diverse Interfaces to Control and Monitor NSFs 276 To provide effective and competitive solutions and services, Security 277 Service Providers may need to utilize multiple security functions 278 from various vendors to enforce the security policies desired by 279 their customers. 281 Since no widely accepted industry standard security interface exists 282 today, management of NSFs (device and policy provisioning, 283 monitoring, etc.) tends to be bespoke security management offered by 284 product vendors. As a result, automation of such services, if it 285 exists at all, is also bespoke. Thus, even in the traditional way of 286 deploying security features, there is a gap to coordinate among 287 implementations from distinct vendors. This is the main reason why 288 mono-vendor security functions are often deployed and enabled in a 289 particular network segment. 291 A challenge for monitoring is that an NSF cannot monitor what it 292 cannot view. Therefore, enabling a security function (e.g., firewall 293 [I-D.ietf-opsawg-firewalls]) does not mean that a network is 294 protected. As such, it is necessary to have a mechanism to monitor 295 and provide execution status of NSFs to security and compliance 296 management tools. There exist various network security monitoring 297 vendor-specific interfaces for forensics and troubleshooting. 299 3.1.3. More Distributed NSFs and vNSFs 301 The security functions which are invoked to enforce a security policy 302 can be located in different equipment and network locations. 304 The European Telecommunications Standards Institute (ETSI) Network 305 Function Virtualization (NFV) initiative creates new management 306 challenges for security policies to be enforced by distributed, 307 virtual, and network security functions (vNSF). 309 A vNSF has higher risk of failure, migrating, and state changes as 310 their hosting VMs are being created, moved, or decommissioned. 312 3.1.4. More Demand to Control NSFs Dynamically 314 In the advent of Software-Defined Networking (see 315 [I-D.jeong-i2nsf-sdn-security-services]), more clients, applications 316 or application controllers need to dynamically update their security 317 policies that are enforced by NSFs. The Security Service Providers 318 have to dynamically update their decision-making process (e.g., in 319 terms of NSF resource allocation and invocation) upon receiving 320 requests from their clients. 322 3.1.5. Demand for Multi-Tenancy to Control and Monitor NSFs 324 Service providers may need several operational units to control and 325 monitor the NSFs, especially when NSFs become distributed and 326 virtualized. 328 3.1.6. Lack of Characterization of NSFs and Capability Exchange 330 To offer effective security services, service providers need to 331 activate various security functions in NSFs or vNSFs manufactured by 332 multiple vendors. Even within one product category (e.g., firewall), 333 security functions provided by different vendors can have different 334 features and capabilities. For example, filters that can be designed 335 and activated by a firewall may or may not support IPv6 depending on 336 the firewall technology. 338 The service provider's management system (or controller) needs a way 339 to retrieve the capabilities of service functions by different 340 vendors so that it could build an effective security solution. These 341 service function capabilities can be documented in a static manner 342 (e.g., a file) or via an interface which accesses a repository of 343 security function capabilities which the NSF vendors dynamically 344 update. 346 A dynamic capability registration is useful for automation because 347 security functions may be subject to software and hardware updates. 348 These updates may have implications on the policies enforced by the 349 NSFs. 351 Today, there is no standard method for vendors to describe the 352 capabilities of their security functions. Without a common technical 353 framework to describe the capabilities of security functions, service 354 providers cannot automate the process of selecting NSFs by different 355 vendors to accommodate customer's requirements. 357 3.1.7. Lack of Mechanism for NSFs to Utilize External Profiles 359 Many security functions depend on signature files or profiles to 360 perform (e.g., IPS/IDS signatures, DOTS filters). Different policies 361 might need different signatures or profiles. Today, the construction 362 and use of black list databases can be a win-win strategy for all 363 parties involved. There might be Open Source-provided signature/ 364 profiles (e.g., by Snort or others) in the future. 366 There is a need to have a standard envelop (i.e., the format) to 367 allow NSFs to use external profiles. 369 3.1.8. Lack of Mechanisms to Accept External Alerts to Trigger 370 Automatic Rule and Configuration Changes 372 NSF can ask the I2NSF security controller to alter a specific rules 373 and/or configurations. For example, a DDoS alert could trigger a 374 change to the routing system to send traffic to a traffic scrubbing 375 service to mitigate the DDoS. 377 The DDoS protection has the following two parts: a) the configuration 378 of signaling of open threats and b) DDoS mitigation. DOTS controller 379 manages the signaling part of DDoS. I2NSF controller(s) would manage 380 the changing to the affected policies (e.g., forwarding and routing, 381 filtering, etc.). By monitoring the network alerts from DDoS, I2NSF 382 can feed an alerts analytics engine that could recognize attacks and 383 the I2NSF can thus enforce the appropriate policies. 385 DDoS mitigation is enhanced if the provider's network security 386 controller can monitor, analyze, and investigate the abnormal events 387 and provide information to the client or change the network 388 configuration automatically. 390 [I-D.zhou-i2nsf-capability-interface-monitoring] provides details on 391 how monitoring aspects of the flow-based Network Security Functions 392 (NSFs) can use the I2NSF interfaces to receive traffic reports and 393 enforce policy. 395 3.1.9. Lack of Mechanism for Dynamic Key Distribution to NSFs 397 There is a need for a controller to distribute various keys to 398 distributed NSFs. To distribute various keys, the keys must be 399 created and managed. While there are many key management methods and 400 cryptographic uites (e.g. encryptoni algorithms, key deriation 401 functions, etc.) and other functions), there is a lack of standard 402 interface to provision and manage security associations. 404 The keys may be used for message authentication and integrity in 405 order to protect data flows. In addition, keys may be used to secure 406 the protocol and messages in the core routing infrastructure 407 ([RFC4948]) 409 As of now there is not much focus on an abstraction for keying 410 information that describes the interface between protocols, 411 operators, and automated key management. 413 An example of a solution, may provide some insight into why the lack 414 of a mechanism is a problem. If you had an abstract key table 415 maintained by security services, you could use these keys for routing 416 and seurity devices. 418 What does this take? 420 Conceptually, there must be an interface defined for routing/ 421 signaling protocols to make requests for automated key management 422 when it is being used, to notify the protocols when keys become 423 available in the key table. One potential use of such an interface 424 is to manage IPSec security associations on SDN networks. 426 An abstract key service will work under the following conditions: 428 1. I2NSF needs to design the key table abstraction, the interface 429 between key management protocols and routing/other protocols, and 430 possibly security protocols at other layers. 432 2. For each routing/other protocol, I2NSF needs to define the 433 mapping between how the protocol represents key material and the 434 protocol-independent key table abstraction. (If protocols share 435 common mechanisms for authentication (e.g., TCP Authentication 436 Option), then the same mapping may be reused.) 438 3. Automated Key management must support both symmetric keys and 439 group keys via the service provided by items 1 and 2. 441 3.2. Challenges Facing Customers 443 When customers invoke hosted security services, their security 444 policies may be enforced by a collection of security functions hosted 445 in different domains. Customers may not have the security skills to 446 express sufficiently precise requirements or security policies. 447 Usually, these customers express the expectations of their security 448 requirements or the intent of their security policies. These 449 expectations can be considered customer level security expectations. 450 Customers may also desire to express guidelines for security 451 management. Examples of such guidelines include: 453 o Which critical communications are to be preserved during critical 454 events (DOTS), 456 o Which hosts are to continue service even during severe security 457 attacks (DOTS), 459 o Reporting of attacks to CERT (MILE), 461 o Managing network connectivity of systems out of compliance (SACM), 463 3.2.1. NSFs from Heterogeneous Administrative Domains 465 Many medium and large enterprises have deployed various on-premises 466 security functions which they want to continue to deploy. These 467 enterprises want to combine local security functions with remote 468 hosted security functions to achieve more efficient and immediate 469 counter-measures to both Internet-originated attacks and enterprise 470 network-originated attacks. 472 Some enterprises may only need the hosted security services for their 473 remote branch offices where minimal security infrastructures/ 474 capabilities exist. The security solution will consist of deploying 475 NSFs on customer networks and on service provider networks. 477 3.2.2. Today's Control Requests are Vendor Specific 479 Customers may consume NSFs by multiple service providers. Customers 480 need to express their security requirements, guidelines, and 481 expectations to the service providers. In turn, the service 482 providers must translate this customer information into customer 483 security policies and associated configuration tasks for the set of 484 security functions in their network. Without a standard technical 485 standard interface that provides a clear technical characterization, 486 the service provider faces many challenges: 488 No standard technical characterization and/or APIs : Even for the 489 most common security services there is no standard technical 490 characterization or APIs. Most security services are accessible 491 only through disparate, proprietary interfaces (e.g., portals or 492 APIs) in whatever format vendors choose to offer. The service 493 provider must have the customer's input to manage these widely 494 varying interfaces. 496 No standard interface: Without standard interfaces it is complex 497 for customers to update security policies or integrate the 498 security functions in their enterprise with the security services 499 provided by the security service providers. This complexity is 500 induced by the diversity of the configuration models, policy 501 models, and supported management interfaces. Without a standard 502 interface, new innovative security products find a large barrier 503 to entry into the market. 505 Managing by scripts de-jour: The current practices rely upon the 506 use of scripts that generate other scripts which automatically run 507 to upload or download configuration changes, log information and 508 other things. These scripts have to be adjusted each time an 509 implementation from a different vendor technology is enabled on a 510 provider side. 512 Lack of immediate feedback: Customers may also require a mechanism 513 to easily update/modify their security requirements with immediate 514 effect in the underlying involved NSFs. 516 Lack of explicit invocation request: While security agreements are 517 in place, security functions may be solicited without requiring an 518 explicit invocation means. Nevertheless, some explicit invocation 519 means may be required to interact with a service function. 521 To see how standard interfaces could help achieve faster 522 implementation time cycles, let us consider a customer who would like 523 to dynamically allow an encrypted flow with specific port, src/dst 524 addresses or protocol type through the firewall/IPS to enable an 525 encrypted video conferencing call only during the time of the call. 526 With no commonly accepted interface in place, the customer would have 527 to learn about the particular provider's firewall/IPS interface and 528 send the request in the provider's required format. 530 +------------+ 531 | security | 532 | MGT system | 533 +----||------+ 534 || proprietary 535 || or I2NSF standard 536 Picture: || 537 Port 10 +--------+ 538 --------| FW/IPS |------------- 539 Encrypted +--------+ 540 Video Flow 542 Figure 1: Example of non-standard vs. standard interface 544 In contrast, if a firewall/IPS interface standard exists, the 545 customer would be able to send the request, without having to do the 546 extensive preliminary legwork. A standard interface also helps 547 service providers since they could now offer the same firewall/IPS 548 interface to represent firewall/IPS services for utilizing products 549 from many vendors. The result is that the service provider has now 550 abstracted the firewall/IPS services. The standard interface also 551 helps the firewall/IPS vendors to focus on their core security 552 functions or extended features rather than the standard building 553 blocks of a management interface. 555 3.2.3. Difficulty to Monitor the Execution of Desired Policies 557 How a policy is translated into technology-specific actions is hidden 558 from the customers. However, customers still need ways to monitor 559 the delivered security service that results from the execution of 560 their desired security requirements, guidelines and expectations. 562 Today, there is no standard way for customers to get security service 563 assurance of their specified security policies properly enforced by 564 the security functions in the provider domain. The customer also 565 lacks the ability to perform "what-if" scenarios to assess the 566 efficiency of the delivered security service. 568 3.3. Difficulty to Validate Policies across Multiple Domains 570 One key aspect of a hosted security service with security functions 571 located at different premises is the ability to express, monitor and 572 verify security policies that combine several distributed security 573 functions. It is crucial to an effective service to be able to take 574 these actions via a standard interface. This standard interface 575 becomes more crucial to the hosted security service when NSFs are 576 instantiated in Virtual Machines which are sometimes widely 577 distributed in the network and sometimes are combined together in one 578 device to perform a set of tasks for delivering a service. 580 Without standard interfaces and security policy data models, the 581 enforcement of a customer-driven security policy remains challenging 582 because of the inherent complexity created by combining the 583 invocation of several vendor-specific security functions into a 584 multi-vendor, heterogeneous environment. Each vendor-specific 585 function may require specific configuration procedures and 586 operational tasks. 588 Ensuring the consistent enforcement of the policies at various 589 domains is also challenging. Standard data models are likely to 590 contribute to addressing that issue. 592 3.4. Software-Defined Networks 594 The Software-Defined Networks (SDN) has changed the landascpe of the 595 data ceter design with overlay networks usually in the server 596 hyprvisor or ToR switches allowing complete flexibility of placing 597 the workload anywhere and even across the data-centers without 598 affecting the application architecture. The workload can be easily 599 and semalessly migrate not only across private clouds but also over 600 to public cloud. The SDN network, due to their agility and better 601 resource utilization, are becoming a must have in all segments of 602 network across all use-cases. 604 Although this flexibility is great from the application orchestartion 605 perspecive where any available resources from anywhere can be utlized 606 but it creates a nigtmare scenario for maintaining the desired 607 security posture. The secuirty admin must make sure the any security 608 policy associated with a given workload must follow whereever 609 application is hosted or moved otherwise it may create a hole in the 610 security posture. Moreover, security admin may like to impose 611 additional security policies if the workload moves to public cloud. 612 This is one of the biggest challenge in the SDN networks. 614 3.5. Lack of Standard Interface to Inject Feedback to NSF 616 Today, many security functions, such as IPS, IDS, DDoS and Antivirus, 617 depend heavily on the associated profiles. They can perform more 618 effective protection if they have the up-to-date profiles. As more 619 sophisticated threats arise, enterprises, vendors, and service 620 providers have to rely on each other to achieve optimal protection. 622 Cyper Threat Alliance (CA, http://cyberthreatalliance.org/) is one of 623 those initiatives that aim at combining efforts conducted by multiple 624 organizations. 626 Today there is no standard interface to exchange security profiles 627 between organizations. 629 3.6. Lack of Standard Interface for Capability Negotiation 631 There could be situations when the selected NSFs cannot perform the 632 policies requested by the Security Controller, due to resource 633 constraints. The customer and security service provider should 634 negotiate the appropriate resource constraints before the security 635 service begins. However, unexpected events somethings happen and the 636 NSF may exhaust those negotiated resources. At this point, the NSF 637 should inform the security controller that the alloted resources have 638 been exhausted. To support the automatic control in the SDN-era, it 639 is necessary to have a set of messages for proper notification (and a 640 response to that notification) between the Security Controller and 641 the NSFs. 643 4. Use Cases 645 Standard interfaces for monitoring and controlling the behavior of 646 NSFs are essential building blocks for Security Service Providers and 647 enterprises to automate the use of different NSFs from multiple 648 vendors by their security management entities. I2NSF may be invoked 649 by any (authorized) client. Examples of authorized clients are 650 upstream applications (controllers), orchestration systems, and 651 security portals. 653 4.1. Basic Framework 655 Users request security services through specific clients (e.g., a 656 customer application, the NSP BSS/OSS or management platform) and the 657 appropriate NSP network entity will invoke the (v)NSFs according to 658 the user service request. This network entity is denoted as the 659 security controller in this document. The interaction between the 660 entities discussed above (client, security controller, NSF) is shown 661 in Figure 2: 663 +----------+ 664 +-------+ | | +-------+ 665 | | Interface 1 |Security | Interface 2 | NSF(s)| 666 |Client <-------------> <------------------> | 667 | | |Controller| | | 668 +-------+ | | +-------+ 669 +----------+ 671 Figure 2: Interaction between Entities 673 Interface 1 is used for receiving security requirements from client 674 and translating them into commands that NSFs can understand and 675 execute. The security controller also passes back NSF security 676 reports (e.g., statistics) to the client which the control has 677 gathered from NSFs. Interface 2 is used for interacting with NSFs 678 according to commands (e.g. enact policy and distribuge), and 679 collecting status information about NSFs. 681 Client devices or applications can require the security controller to 682 add, delete or update rules in the security service function for 683 their specific traffic. 685 When users want to get the executing status of a security service, 686 they can request NSF status from the client. The security controller 687 will collect NSF information through Interface 2, consolidate them, 688 and give feedback to client through Interface 1. This interface can 689 be used to collect not only individual service information, but also 690 aggregated data suitable for tasks like infrastructure security 691 assessment. 693 Customers may require validating NSF availability, provenance, and 694 correct execution. This validation process, especially relevant for 695 vNSFs, includes at least: 697 Integrity of the NSF: by ensuring that the NSF is not compromised; 699 Isolation: by ensuring the execution of the NSF is self-contained 700 for privacy requirements in multi-tenancy scenarios. 702 Provenance of NSF: Customers may need to be provided with strict 703 guarantees about the origin of the NSF, its status (e.g. 704 available, idle, down, and others), and feedback mechanisms so 705 that a customer may be able to check that a given NSF or set of 706 NSFs properly conform to the the customer's requirements and 707 subsequent configuration tasks. 709 In order to achieve this, the security controller may collect 710 security measurements and share them with an independent and trusted 711 third party (via interface 1) in order to allow for attestation of 712 NSF functions using the third party added information. 714 4.2. Access Networks 716 This scenario describes use cases for users (e.g. enterprise user, 717 network administrator, and residential user) that request and manage 718 security services hosted in the network service provider (NSP) 719 infrastructure. Given that NSP customers are essentially users of 720 their access networks, the scenario is essentially associated with 721 their characteristics, as well as with the use of vNSFs. 723 The Virtual CPE described in [NFVUC] use cases #5 and #7 requires a 724 model of access virtualization that includes mobile and residential 725 access where the operator may offload security services from the 726 customer local environment (e.g., device or terminal) to its own 727 infrastructure. 729 These use cases define the interaction between the operator and the 730 vNSFs through automated interfaces, typically by means of B2B 731 communications. 733 Customer + Access + PoP/Datacenter 734 | | +--------+ 735 | ,-----+--. |Network | 736 | ,' | `-|Operator| 737 +-------------+ | /+----+ | |Mgmt Sys| 738 | Residential |-+------/-+vCPE+----+ +--------+ 739 +-------------+ | / +----+ | \ | : 740 | / | \ | | 741 +----------+ | ; +----+ | +----+ | 742 |Enterprise|---+---+----+ vPE+--+----+ NSF| | 743 +----------+ | : +----+ | +----+ | 744 | : | / | 745 +--------+ | : +----+ | / ; 746 | Mobile |-+-----\--+vEPC+----+ / 747 +--------+ | \ +----+ | ,-' 748 | `--. | _.-' 749 | `----+----'' 750 + + 752 Figure 3: NSF and actors 754 Different access clients may have different service requests: 756 Residential: service requests for parental control, content 757 management, and threat management. 759 Parental control requests may include identity based filters for 760 web content or usage. Content management may include identifying 761 and blocking malicious activities from web contents, mail, or 762 files downloaded. Threat management may include identifying and 763 blocking botnets or malware. 765 Enterprise: service requests for enterprise flow security policies 766 and managed security services 768 Flow security policies include access (or isolation) to data from 769 various internal groups, access (or isolation) from varous web 770 sites or social media applications, and encryption on data 771 transferred between corporates sites (main office, enterprise 772 branch offices, and remote campuses). Managed security services 773 may include detection and mitigation of external and internal 774 threats. External threats can include application or phishing 775 attacks, malware, botnet, DDoS, and others. Internal threats (aka 776 lateral threats) can include detecting programs moving from one 777 enterprise site to another without permission. 779 Service Provider: Service requests for policies that protect 780 service providers networks against various threats (including 781 DDoS, botnets and malware). Such policies are meant to securely 782 and reliably deliver contents (e.g., data, voice, video) to 783 various customers, including residential, mobile and corporate 784 customers. These security policies are also enforced to guarantee 785 isolation between multiple tenants, regardless of the nature of 786 the corresponding connectivity services. 788 Mobile: service requests from interfaces which monitor and ensure 789 user quality of experience, content management, parental controls, 790 and external threat management. 792 Content management for the mobile device includes identifying and 793 blocking malicious activities from web contents, mail, files. 794 Threat management for infrastructure includes detecting and 795 removing malicious programs such as Botnet, DDoS, and Malware. 797 Some access customers may not care about which NSFs are utilized to 798 achieve the services they requested. In this case, provider network 799 orchestration systems can internally select the NSFs (or vNSFs) to 800 enforce the policies requested by the clients. Other access 801 customers, especially some enterprise customers, may want to get 802 their dedicated NSFs (most likely vNSFs) for direct control purposes. 804 In this case, here are the steps to associate vNSFs to specific 805 customers: 807 vNSF Deployment: The deployment process consists in instantiating a 808 NSF on a Virtualization Infrastructure (NFVI), within the NSP 809 administrative domain(s) or with other external domain(s). This 810 is a required step before a customer can subscribe to a security 811 service supported in the vNSF. 813 vNSF Customer Provisioning: Once a vNSF is deployed, any customer 814 can subscribe to it. The provisioning lifecycle includes the 815 following: 817 * Customer enrollment and cancellation of the subscription to a 818 vNSF; 820 * Configuration of the vNSF, based on specific configurations, or 821 derived from common security policies defined by the NSP. 823 * Retrieve and list the vNSF functionalities, extracted from a 824 manifest or a descriptor. The NSP management systems can 825 demand this information to offer detailed information through 826 the commercial channels to the customer. 828 4.3. Cloud Data Center Scenario 830 In a data center, network security mechanisms such as firewalls may 831 need to be dynamically added or removed for a number of reasons. 832 These changes may be explicitly requested by the user, or triggered 833 by a pre-agreed upon Service Level Agreement (SLA) between the user 834 and the provider of the service. For example, the service provider 835 may be required to add more firewall capacity within a set timeframe 836 whenever the bandwidth utilization hits a certain threshold for a 837 specified period. This capacity expansion could result in adding new 838 instances of firewalls on existing machines or provisioning a 839 completely new firewall instance in a different machine. 841 The on-demand, dynamic nature of security service delivery 842 essentially encourages that the network security "devices" be in 843 software or virtual form factors, rather than in a physical appliance 844 form. This requirement is a provider-side concern. Users of the 845 firewall service are agnostic (as they should) as to whether or not 846 the firewall service is run on a VM or any other form factor. 847 Indeed, they may not even be aware that their traffic traverses 848 firewalls. 850 Furthermore, new firewall instances need to be placed in the "right 851 zone" (domain). The issue applies not only to multi-tenant 852 environments where getting the tenant in the right domain is of 853 paramount importance, but also in environments owned and operated by 854 a single organization with its own service segregation policies. For 855 example, an enterprise may mandate that firewalls serving Internet 856 traffic and Business-to-Business (B2B) traffic be separated. Another 857 example is that IPS/IDS services for investment banking and non- 858 banking traffic may be separated for regulatory reasons. 860 4.3.1. On-Demand Virtual Firewall Deployment 862 A service provider-operated cloud data center could serve tens of 863 thousands of clients. Clients' compute servers are typically hosted 864 on virtual machines (VMs), which could be deployed across different 865 server racks located in different parts of the data center. It is 866 often not technically and/or financially feasible to deploy dedicated 867 physical firewalls to suit each client's security policy 868 requirements, which can be numerous. What is needed is the ability 869 to dynamically deploy virtual firewalls for each client's set of 870 servers based on established security policies and underlying network 871 topologies. 873 ---+-----------------------------+----- 874 | | 875 +---+ +-+-+ 876 |vFW| |vFW| 877 +---+ +-+-+ 878 | Client #1 | Client #2 879 ---+-------+--- ---+-------+--- 880 +-+-+ +-+-+ +-+-+ +-+-+ 881 |vM | |vM | |vM | |vM | 882 +---+ +---+ +---+ +---+ 884 Figure 4: NSF in Data Centers 886 4.3.2. Firewall Policy Deployment Automation 888 Firewall rule setting is often a time consuming, complex and error- 889 prone process even within a single organization/enterprise framework. 890 It becomes far more complex in provider-owned cloud networks that 891 serve myriads of customers. 893 Firewall rules today are highly tied with ports and addresses that 894 identify traffic. This makes it very difficult for clients of cloud 895 data centers to construct rules for their own traffic as the clients 896 only see the virtual networks and the virtual addresses. The 897 customer-visible virtual networks and addresses may be different from 898 the actual packets traversing the FWs. 900 Even though most vendors support similar firewall features, the 901 actual rule configuration keywords are different from vendors to 902 vendors, making it difficult for automation. Automation works best 903 when it can leverage a common set of standards that will work across 904 NSFs by multiple vendors. Without automation, it is virtually 905 impossible for clients to dynamically specify their desired rules for 906 their traffic. 908 Another feature that aids automation of firewalls that must be 909 covered in automation is dynamic key management. 911 4.3.3. Client-Specific Security Policy in Cloud VPNs 913 Clients of service provider-operated cloud data centers need not only 914 to secure Virtual Private Networks (VPNs) but also virtual security 915 functions that apply the clients' security policies. The security 916 policies may govern communication within the clients' own virtual 917 networks as well as communication with external networks. For 918 example, VPN service providers may need to provide firewall and other 919 security services to their VPN clients. Today, it is generally not 920 possible for clients to dynamically view (let alone change) what, 921 where and how security policies are implemented on their provider- 922 operated clouds. Indeed, no standards-based framework exists to 923 allow clients to retrieve/manage security policies in a consistent 924 manner across different providers. 926 As described above, the dynamic key mechanisms are critical for the 927 securing the VPN and the distribution of policies. 929 4.3.4. Internal Network Monitoring 931 There are many types of internal traffic monitors that may be managed 932 by a security controller. This includes a new class of services 933 referred to as Data Loss Prevention (DLP), or Reputation Protection 934 Services (RPS). Depending on the class of event, alerts may go to 935 internal administrators, or external services. 937 4.4. Preventing Distributed DoS, Malware and Botnet attacks 939 In the internet where everything is connected, preventing unwanted 940 traffic that may cause Denial of Service (DoS) attack or distributed 941 DoS (DDoS) has become a challenge. Similarly, a network could be 942 subjected to Malware attacks and making the victim networks as Botnet 943 army to attack other networks by a remote command and control server. 944 Many networks such as Internet of Things (IoT) networks, Information- 945 Centric Networks (ICN), Content Delivery Networks (CDN), Voice over 946 packet networks (VoIP/VoLTE) are constantly subjected such attacks, 947 it is imperative that for successful operation of any organization, 948 such attacks be recognized and mitigated . 950 In order for organization to secure their networks against such 951 attacks, I2NSF would provide client-side interface that are 952 indepedent of use-case and implementation details. For example, in 953 order to prevent malware attacks, I2NSF interface could be used to 954 program security policy that look for specfic malware signatures. 955 Similarly, Botnet attacks could be easily prevented by provisioing 956 security policies using I2NSF client-side interface that prevent 957 access to Botnet Command and Control servers. 959 4.5. Regulatory and compliance secuirty policies 961 The organizations are not only supposed to protect their networks 962 against unwanted traffic, but also comply with various industry 963 specific regulations. Any organization under a specific regulation 964 such as PCI-DSS for payment industry or HIPPA for healthcare must 965 isolate different traffic and data as per the specifc regulation. 966 They also must show a proof if audited abouth their comliance so it 967 not just necessary to provision policies but also keep a record of 968 all such policies. 970 The I2NSF client-side interface could be used to provision regulatory 971 and compliance related security policies. The security controller 972 would keep track of when and where a specific policy is applied and 973 if there is any policy violations. This information can be used in 974 the event of an audit to show the traffic and data isolation amog 975 desired end-points as per the required regulation for that 976 organization. 978 5. Management Considerations 980 Management of NSFs usually include the following: 982 o Lifecycle managment and resource management of NSFs, 984 o Device configuration, such as address configuration, device 985 internal attributes configuration, etc.; 987 o Signaling, and 989 o Policy rule provisioning. 991 I2NSF will only focus on the policy provisioning part of NSF 992 management. 994 6. IANA Considerations 996 No IANA considerations exist for this document. 998 7. Security Considerations 1000 Having a secure access to control and monitor NSFs is crucial for 1001 hosted security services. An I2NSF security controller raises new 1002 security threats. It needs to be resilient to attacks and quickly 1003 recover from attacks. Therefore, proper secure communication 1004 channels have to be carefully specified for carrying controlling and 1005 monitoring traffic between the NSFs and their management entity (or 1006 entities). 1008 In addition, the Flow security policies specified by customers can 1009 conflict with providers' internal security policies which may allow 1010 unauthorized traffic or unauthorized changes to flow polices (e.g. 1011 customers changing flow policies that do not belong to them). 1012 Therefore, it is crucial to have proper AAA [RFC2904] to authorize 1013 access to the network and access to the I2NSF management stream. 1015 8. Contributors 1017 I2NSF is a group effort. The following people actively contributed 1018 to the initial use case text: Xiaojun Zhuang (China Mobile), Sumandra 1019 Majee (F5), Ed Lopez (Fortinet), and Robert Moskowitz (Huawei). 1021 9. Contributing Authors 1023 I2NSF has had a number of contributing authors. The following are 1024 contributing authors: 1026 o Linda Dunbar (Huawei), 1028 o Antonio Pastur (Telefonica I+D), 1030 o Mohamed Boucadair (France Telecom), 1032 o Michael Georgiades (Prime Tel), 1034 o Minpeng Qi (China Mobile), 1036 o Shaibal Chakrabarty (US Ignite), 1038 o Nic Leymann (Deutsche Telekom), 1040 o Anil Lohiya (Juniper), 1041 o David Qi (Bloomberg), 1043 o Xiaobo Long, 1045 o Hyoungshick Kim (Sungkyunkwan University), 1047 o Jung-Soo Park (ETRI), 1049 o Tae-Jin Ahn (Korea Telecom), and 1051 o Se-Hui Lee (Korea Telecom). 1053 10. Acknowledgements 1055 This document was supported by Institute for Information and 1056 communications Technology Promotion (IITP) funded by the Korea 1057 government (MSIP) [R0166-15-1041, Standard Development of Network 1058 Security based SDN]. 1060 11. References 1062 11.1. Normative References 1064 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1065 Requirement Levels", BCP 14, RFC 2119, 1066 DOI 10.17487/RFC2119, March 1997, 1067 . 1069 11.2. Informative References 1071 [AVANT-GUARD] 1072 Shin, S., Yegneswaran, V., Porras, P., and G. Gu, "AVANT- 1073 GUARD: Scalable and Vigilant Switch Flow Management in 1074 Software-Defined Networks", ACM CCS, November 2013. 1076 [ETSI-NFV] 1077 ETSI GS NFV 002 V1.1.1, , "Network Functions 1078 Virtualisation (NFV); Architectural Framework", October 1079 2013. 1081 [Gartner-2013] 1082 Messmer, E., "Gartner: Cloud-based security as a service 1083 set to take off", October 2013. 1085 [I-D.hares-i2nsf-gap-analysis] 1086 Hares, S., Zhang, D., Moskowitz, R., and H. Rafiee, 1087 "Analysis of Existing work for I2NSF", draft-hares-i2nsf- 1088 gap-analysis-01 (work in progress), December 2015. 1090 [I-D.ietf-i2nsf-framework] 1091 Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 1092 Kumar, "Framework for Interface to Network Security 1093 Functions", draft-ietf-i2nsf-framework-04 (work in 1094 progress), October 2016. 1096 [I-D.ietf-netmod-acl-model] 1097 Bogdanovic, D., Koushik, K., Huang, L., and D. Blair, 1098 "Network Access Control List (ACL) YANG Data Model", 1099 draft-ietf-netmod-acl-model-06 (work in progress), 1100 December 2015. 1102 [I-D.ietf-opsawg-firewalls] 1103 Baker, F. and P. Hoffman, "On Firewalls in Internet 1104 Security", draft-ietf-opsawg-firewalls-01 (work in 1105 progress), October 2012. 1107 [I-D.jeong-i2nsf-sdn-security-services] 1108 Jeong, J., Kim, H., Jung-Soo, P., Ahn, T., and s. 1109 sehuilee@kt.com, "Software-Defined Networking Based 1110 Security Services using Interface to Network Security 1111 Functions", draft-jeong-i2nsf-sdn-security-services-05 1112 (work in progress), July 2016. 1114 [I-D.lopez-i2nsf-packet] 1115 Ed, E., "Packet-Based Paradigm For Interfaces To NSFs", 1116 draft-lopez-i2nsf-packet-00 (work in progress), March 1117 2015. 1119 [I-D.pastor-i2nsf-access-usecases] 1120 Pastor, A. and D. Lopez, "Access Use Cases for an Open OAM 1121 Interface to Virtualized Security Services", draft-pastor- 1122 i2nsf-access-usecases-00 (work in progress), October 2014. 1124 [I-D.pastor-i2nsf-merged-use-cases] 1125 Pastor, A., Lopez, D., Wang, K., Zhuang, X., Qi, M., 1126 Zarny, M., Majee, S., Leymann, N., Dunbar, L., and M. 1127 Georgiades, "Use Cases and Requirements for an Interface 1128 to Network Security Functions", draft-pastor-i2nsf-merged- 1129 use-cases-00 (work in progress), June 2015. 1131 [I-D.qi-i2nsf-access-network-usecase] 1132 Wang, K. and X. Zhuang, "Integrated Security with Access 1133 Network Use Case", draft-qi-i2nsf-access-network- 1134 usecase-02 (work in progress), March 2015. 1136 [I-D.zarny-i2nsf-data-center-use-cases] 1137 Zarny, M., Leymann, N., and L. Dunbar, "I2NSF Data Center 1138 Use Cases", draft-zarny-i2nsf-data-center-use-cases-00 1139 (work in progress), October 2014. 1141 [I-D.zhou-i2nsf-capability-interface-monitoring] 1142 Zhou, C., Xia, L., Boucadair, M., and J. Xiong, "The 1143 Capability Interface for Monitoring Network Security 1144 Functions (NSF) in I2NSF", draft-zhou-i2nsf-capability- 1145 interface-monitoring-00 (work in progress), October 2015. 1147 [ITU-T.Y.3300] 1148 Recommendation ITU-T Y.3300, , "Framework of Software- 1149 Defined Networking", June 2014. 1151 [ONF-OpenFlow] 1152 ONF, , "OpenFlow Switch Specification (Version 1.4.0)", 1153 October 2013. 1155 [ONF-SDN-Architecture] 1156 ONF, , "SDN Architecture", June 2014. 1158 [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., 1159 Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and 1160 D. Spence, "AAA Authorization Framework", RFC 2904, 1161 DOI 10.17487/RFC2904, August 2000, 1162 . 1164 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1165 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1166 July 2006, . 1168 [RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the 1169 IAB workshop on Unwanted Traffic March 9-10, 2006", 1170 RFC 4948, DOI 10.17487/RFC4948, August 2007, 1171 . 1173 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 1174 Networking: A Perspective from within a Service Provider 1175 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 1176 . 1178 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 1179 RFC 7277, DOI 10.17487/RFC7277, June 2014, 1180 . 1182 Authors' Addresses 1184 Susan Hares 1185 Huawei 1186 7453 Hickory Hill 1187 Saline, MI 48176 1188 USA 1190 Phone: +1-734-604-0332 1191 Email: shares@ndzh.com 1193 Diego R. Lopex 1194 Telefonica I+D 1195 Don Ramon de la Cruz, 82 1196 Madrid 28006 1197 Spain 1199 Email: diego.r.lopez@telefonica.com 1201 Myo Zarny 1202 vArmour 1203 800 El Camino Real, Suite 3000 1204 Mountain View, CA 94040 1205 USA 1207 Email: myo@varmour.com 1209 Christian Jacquenet 1210 France Telecom 1211 Rennes, 35000 1212 France 1214 Email: Christian.jacquenet@orange.com 1216 Rakesh Kumar 1217 Juniper Networks 1218 1133 Innovation Way 1219 Sunnyvale, CA 94089 1220 USA 1222 Email: rkkumar@juniper.net 1223 Jaehoon Paul Jeong 1224 Department of Software 1225 Sungkyunkwan University 1226 2066 Seobu-Ro, Jangan-Gu 1227 Suwon, Gyeonggi-Do 16419 1228 Republic of Korea 1230 Phone: +82 31 299 4957 1231 Fax: +82 31 290 7996 1232 Email: pauljeong@skku.edu 1233 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php