idnits 2.17.1 draft-kumar-i2nsf-client-facing-interface-req-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 2, 2016) is 2824 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-i2nsf-problem-and-use-cases-01 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF Working Group R. Kumar 3 Internet-Draft A. Lohiya 4 Intended status: Informational Juniper Networks 5 Expires: February 3, 2017 D. Qi 6 Bloomberg 7 X. Long 8 August 2, 2016 10 Client Interface for Security Controller : A Framework for Security 11 Policy Requirements 12 draft-kumar-i2nsf-client-facing-interface-req-00 14 Abstract 16 This document provides a framework and information model for the 17 definition of northbound interfaces for a security controller. The 18 interfaces are based on user-intent instead of vendor-specific or 19 device-centric approaches that would require deep knowledge of vendor 20 products and their security features. The document identifies the 21 common interfaces needed to enforce the user-intent based policies 22 onto network security functions (NSFs) irrespective of how those 23 functions are realized. The function may be physical or virtual in 24 nature and may be implemented in networking or dedicated appliances. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on February 3, 2017. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Conventions Used in this Document . . . . . . . . . . . . . . 4 62 3. Security Provisioning Framework . . . . . . . . . . . . . . . 4 63 3.1. Client Interface Guiding Principles . . . . . . . . . . . 5 64 3.2. Deployment Models for Implementing Security Policies . . 5 65 3.3. Client Perspective on Security Policy Configuration and 66 Management . . . . . . . . . . . . . . . . . . . . . . . 9 67 4. Functional Requirements for the Client Interface . . . . . . 9 68 4.1. Multi-Tenancy and RBAC for Policy Management . . . . . . 10 69 4.2. Policy Lifecycle Management . . . . . . . . . . . . . . . 11 70 4.3. Policy Endpoint Groups . . . . . . . . . . . . . . . . . 11 71 4.4. Policy Rules . . . . . . . . . . . . . . . . . . . . . . 13 72 4.5. Policy Actions . . . . . . . . . . . . . . . . . . . . . 13 73 4.6. Third-Party Integration . . . . . . . . . . . . . . . . . 14 74 4.7. Telemetry Data . . . . . . . . . . . . . . . . . . . . . 14 75 5. Operational Requirements for the Client Interface . . . . . . 14 76 5.1. API Versioning . . . . . . . . . . . . . . . . . . . . . 14 77 5.2. API Extensiblity . . . . . . . . . . . . . . . . . . . . 15 78 5.3. APIs and Data Model Transport . . . . . . . . . . . . . . 15 79 5.4. Notification . . . . . . . . . . . . . . . . . . . . . . 15 80 5.5. Affinity . . . . . . . . . . . . . . . . . . . . . . . . 15 81 5.6. Test Interface . . . . . . . . . . . . . . . . . . . . . 16 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 83 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 84 8. Normative References . . . . . . . . . . . . . . . . . . . . 16 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 87 1. Introduction 89 Programming security policies in a network is a fairly complex task 90 and requires very deep knowledge of the vendors' devices in order to 91 implement a security policy. This has been the biggest challenge for 92 both Service Providers and Enterprise, henceforth known as end- 93 customers, to keep up-to-date with the security of their networks and 94 assets. The challenge is amplified due to virtualization because 95 security appliances come in both physical and virtual forms and are 96 supplied by a variety of vendors who have their own proprietary 97 interfaces to manage and implement the security policies on their 98 devices. 100 Even if an end-customer deploys a single vendor solution across its 101 entire network, it is difficult to manage security policies due to 102 the complexity of network security features available in the devices. 103 The end-customer may use a vendor-provided management system that 104 gives some abstraction in the form of GUI and helps in provisioning 105 and managing security policies. The single vendor approach is highly 106 restrictive in today's network as explained below: 108 o The end-customer cannot rely on a single vendor because one vendor 109 may not be able keep up to date with its security needs. 111 o The large end-customer may have a presence across different sites 112 and regions and that may mean it is not possible to have a single 113 vendor solution due to technical or business reasons. 115 o If and when the end-customer migrates from one vendor to another, 116 it is not possible to migrate security policies from one 117 management system to another without complex manual work. 119 o Due to virtualization within data centers, end-customers are using 120 physical and virtual forms of security functions with a wide 121 variety of vendors, including open source, to control their costs. 123 o The end-customer might choose various devices in the network (such 124 as routers, switches, firewall devices, and overlay-networks) as 125 enforcement points for security policies for any reason (such as 126 network design simplicity, cost, most-effective place, scale and 127 performance). 129 In order to provide the end-customer with a solution where they can 130 deploy security policies across different vendors and devices whether 131 physical or virtual, the Interface to Network Security Functions 132 (I2NSF) working group in the IETF is defining a set of northbound 133 interfaces. Using these interfaces, a user can write any application 134 e.g. GUI portal, template engine etc. but this is completely out of 135 scope for this working group. 137 This document discusses the requirements for these northbound 138 interfaces and describes a framework that can be easily used by end- 139 customer security administrators without knowledge of specific 140 security devices or features. We refer to this as "user-intent" 141 based interfaces. To further clarify, the "user-intent" here does 142 not mean some natural lanuguage input or an abstract intent such as 143 "I want my traffic secure" or "I don't want DDoS attcks in my 144 network"; rather the user-intent here means that policies are 145 described using client-oriented expressions such as application 146 groups, device groups, user groups etc. instead of using standard 147 n-tuples from the packet header. 149 2. Conventions Used in this Document 151 BSS: Business Support System. 153 CMDB: Configuration Management Database. 155 Controller: Used interchangeably with Service Provider Security 156 Controller or management system throughout this document. 158 CRUD: Create, Retrieve, Update, Delete. 160 FW: Firewall. 162 IDS: Intrusion Detection System. 164 IPS: Intrusion Protection System. 166 LDAP: Lightweight Directory Access Protocol. 168 NSF: Network Security Function, defined by 169 [I-D.ietf-i2nsf-problem-and-use-cases]. 171 OSS: Operation Support System. 173 RBAC: Role Based Access Control. 175 SIEM: Security Information and Event Management. 177 URL: Universal Resource Locator. 179 vNSF: Refers to NSF being instantiated on Virtual Machines. 181 3. Security Provisioning Framework 183 The IETF I2NSF working group has defined a framework for Interfaces 184 to Network Security Functions that defines following terminology: 186 Client: A client could be a GUI system used by a security 187 administrator, an OSS/BSS system used by an end-customer, or a 188 security controller system or application in the end-customer's 189 management system. 191 Client-Facing Interface: A client-facing interface is an interface 192 used to configure and manage security a framework across the 193 entire network independent of device-specific interface so that 194 same interface can be used for any device from any vendor. 196 The "Client Facing Interface" ensures that an end-customer can deploy 197 any device from any vendor and still be able to use same consistent 198 interface. In essence, these interfaces give a framework to manage 199 end-customer's security policies. Henceforth in this document, we 200 "security policy management interface" interchangeably when we refer 201 to these northbound interfaces. 203 3.1. Client Interface Guiding Principles 205 Guiding principles in defining the client interfaces are as follows: 207 o Agnostic of network topology and NSF location in the network. 209 o Declarative/Descriptive model instead of Imperative/Prescriptive 210 model - How a user would like to see security policy instead of 211 how it would be actually implemented. 213 o Agnostic of vendor, implementation and form-factor (physical, 214 virtual). 216 o Agnostic to how NSF is implemented and its hosting environment. 218 o Agnostic to how NSF becomes operational - Network connectivity and 219 other hosting requirements 221 o Agnostic to NSF control plane implementation (if there is one) 222 E.g., cluster of NSF active as one unified service for scale and/ 223 or resilience. 225 o Agnostic to NSF data plane implementation i.e. Encapsulation, 226 Service function chains. 228 3.2. Deployment Models for Implementing Security Policies 230 This document describes a framework for security policy management 231 interfaces. This document does not describe a framework for 232 southbound interface: those may be defined in another draft. 234 Traditionally, medium and larger end-customers deploy management 235 systems to manage their security policies. This approach may not be 236 suitable for modern datacenters that are virtualized and manage their 237 resources using controllers. 239 There are two different deployment models: 241 a. Management without an explicit management system for control of 242 devices and NSFs. In this deployment, the security controller 243 acts as a NSF policy management system that takes information 244 passed over the northbound policy interface and translates into 245 data on the I2NSF southbound interface. The I2NSF interfaces are 246 implemented by security device/function vendors. This would 247 usually be done by having an I2NSF agent embedded in the security 248 device or NSF. This deployment model is shown in Figure 1. 250 RESTful API 251 SUPA or I2NSF Policy Management 252 ^ 253 Northbound | 254 Security Policy Interface | 255 (Independent of individual | 256 NSFs, devices, and vendors) | 257 | 258 ------------------------------ 259 | | 260 | Security Controller | 261 | | 262 ------------------------------ 263 | ^ 264 Southbound Security | I2NSF | 265 Capability Interface | NSF-facing | 266 (Specific to NSFs) | Interface | 267 .............................. 268 | | 269 v | 271 ------------- ------------- 272 | I2NSF Agent | | I2NSF Agent | 273 |-------------| |-------------| 274 | |---| | 275 | NSF | | NSF | 276 NSFs | | | | 277 (virtual -------------\ /------------- 278 and | \ / | 279 physical) | X | 280 | / \ | 281 -------------/ \------------- 282 | I2NSF Agent | | I2NSF Agent | 283 |-------------| |-------------| 284 | |---| | 285 | NSF | | NSF | 286 | | | | 287 ------------- ------------- 289 Figure 1: Deployment without Management System 291 b. Management with an explicit management system for control of 292 devices and NSFs. This model is similar to the model above 293 except that security controller interacts with a dedicated 294 management system which could either proxy I2NSF southbound 295 interfaces or could provide a layer where security devices or 296 NSFs do not support an I2NSF agent to process I2NSF southbound 297 interfaces. This deployment model is shown in Figure 2. 299 RESTful API 300 SUPA or I2NSF Policy Management 301 ^ 302 Northbound | 303 Security Policy Interface | 304 (Independent of individual | 305 NSFs, devices, and vendors) | 306 | 307 ------------------------------ 308 | | 309 | Security Controller | 310 | | 311 ------------------------------ 312 | ^ 313 Southbound Security | I2NSF | 314 Capability Interface | NSF-facing | 315 (Specific to NSFs) | Interface | 316 .............................. 317 | | 318 v | 319 ------------------------------ 320 | | 321 | I2NSF Proxy Agent / | 322 | Management System | 323 | | 324 ------------------------------ 325 | ^ 326 | Proprietary | 327 | Functional | 328 | Interface | 329 .............................. 330 | | 331 v | 333 ------------- ------------- 334 | |---| | 335 | NSF | | NSF | 336 NSFs | | | | 337 (virtual -------------\ /------------- 338 and | \ / | 339 physical) | X | 340 | / \ | 341 -------------/ \------------- 342 | |---| | 343 | NSF | | NSF | 344 | | | | 345 ------------- ------------- 347 Figure 2: Deployment with Management System or I2NSF Proxy Agent 349 Although the deployment models discussed here don't necessarily 350 affect the northbound security policy interface, they do give an 351 overall context for defining a security policy interface based on 352 abstraction. 354 3.3. Client Perspective on Security Policy Configuration and Management 356 In order to provide I2NSF northbound interface for security policies 357 to client that are not specific to any vendor, device or feature 358 implementation, it is important that security policies shall be 359 configured and managed from a client's perspective. We refer to this 360 as the user-intent based model since it is primarily driven by how 361 security administrators view security policies from the deployment 362 perspective. 364 The client perspective ensures that policy management is not only 365 easy to understand for them (the actual users), but is also 366 independent of vendor, device, and specific implementation which is 367 the foremost goal for a northbound interface. 369 4. Functional Requirements for the Client Interface 371 As mentioned earlier, it is important that the northbound interface 372 be primarily driven by user-intent which is what a client understands 373 well. In order to define this interface, we must understand the 374 requirements and framework used by the security administrator. 376 A security policy that is based on user-intent is completely agnostic 377 of how this policy is enforced in the end-customer's network. The 378 security controller may choose to implement such a policy on any 379 device (router, switch, firewall) in a physical or virtual form 380 factor. The security controller's implementation is outside the 381 scope of this document and the I2NSF working group. 383 At a high level, the objects that are required in order to express 384 and build the security policies fall into the following categories: 386 o Multi-tenancy and RBAC for policy management 388 o Policy lifecycle management 389 o Policy endpoint groups 391 o Policy rules 393 o Policy actions 395 o Third party integration 397 o Telemetry data 399 The above categories are by no means a complete list and may not be 400 sufficient for all use-cases and all end-customers, but should be a 401 good start for a wide variety of use-cases in both Service Provider 402 networks and Enterprise networks. 404 The following sections provide further details on the above mentioned 405 security policies categories. 407 4.1. Multi-Tenancy and RBAC for Policy Management 409 An end-customer that uses security policies may have internal tenants 410 and would like to have a framework wherein each tenant manages its 411 own security policies to provide isolation across different tenants. 413 An end-customer may be a cloud service provider with multi-tenant 414 deployments where each tenant is a different organization and must 415 allow complete isolation across different tenants. 417 The RBAC objects and method needed to build such a framework is 418 defined below. 420 Policy-Tenant: An entity that owns and manages the security 421 policies. 423 Policy-User: A user within a Policy-Tenant authorized to manage 424 security policies for that tenant. 426 Policy-Authorization-Role: A role assigned to a Policy-User that 427 determines whether the user has read-write access, read-only 428 access, or no access for certain resources. 430 Authentication and Authorization Scheme: There must be a scheme for 431 a Policy-User to be authenticated and authorized to use the 432 security controller. There are several authentication schemes 433 avialable such as OAuth, XAuth and X.509 certificate based. The 434 authentication scheme between client and controller may also be 435 mutual instead of one-way. Any specific scheme may be determined 436 based on organizational and deployment needs and outside the scope 437 of I2NSF. 439 4.2. Policy Lifecycle Management 441 In order to provide more sophisticated security framework, there 442 should be a mechanism to express that a policy becomes dynamically 443 active/enforced or inactive based on either security administrator 444 intervention or an event. 446 One example of dynamic policy management is when the security 447 administrator pre-configures all the security policies, but the 448 policies get activated/enforced or deactivated based on dynamic 449 threats faced by the end-customer. Basically, a threat event may 450 activate certain inactive policies, and once a new event indicates 451 that the threat has gone away, the policies become inactive again. 453 The northbound interface should support the following mechanisms for 454 policy enforcement: 456 Admin-Enforced: The policy, once configured, remains active/enforced 457 until removed by the security administrator. 459 Time-Enforced: The policy configuration specifies the time profile 460 that determines when policy is activated/enforced. 462 Event-Enforced: The policy configuration specifies the event profile 463 that determines when policy is activated/enforced. 465 4.3. Policy Endpoint Groups 467 Typically, when the security administrator configures a security 468 policy, the intention is to apply this policy to certain subsets of 469 the network. The subsets may be identified based on criteria such as 470 users, devices, and applications. We refer to such a subset of the 471 network as a "Policy Endpoint Group". 473 One of the biggest challenges for a security administrator is how to 474 make sure that security policies remain effective while constant 475 changes are happening to the "Policy Endpoint Group" for various 476 reasons (e.g., organizational changes). If the policy is created 477 based on static information such as user names, application, or 478 network subnets, then every time that this static information changes 479 policies would need to be updated. For example, if a policy is 480 created that allows access to an application only from the group of 481 Human Resource users (the HR-users group), then each time the HR- 482 users group changes, the policy needs to be updated. 484 Changes to policy could be highly taxing to the end-customer for 485 various operational reasons. The policy management framework must 486 allow "Policy Endpoint Group" to be dynamic in nature so that changes 487 to the group (HR-users in our example) automatically result in 488 updates to its content. 490 We call these dynamic Policy Endpoint Groups "Meta-data Driven 491 Groups". The meta-data is a tag associated with endpoint information 492 such as users, applications, and devices. The mapping from meta-data 493 to dynamic content could come either from standards-based or 494 proprietary tools. The security controller could use any available 495 mechanisms to derive this mapping and to make automatic updates to 496 the policy content if the mapping information changes. 498 The northbound policy interface must support endpoint groups for 499 user-intent based policy management. The following meta-data driven 500 groups are typically used for configuring security polices: 502 User-Group: This group identifies a set of users based on a tag or 503 on static information. The tag to user information is dynamically 504 derived from systems such as Active Directory or LDAP. For 505 example, an end-customer may have different user-groups, such as 506 HR-users, Finance-users, Engineering-users, to classify a set of 507 users in each department. 509 Device-Group: This group identifies a set of devices based on a tag 510 or on static information. The tag to device information is 511 dynamically derived from systems such as CMDB. For example, an 512 end-customer may want to classify all machines running one 513 operating system into one group and machines running another 514 operating system into another group. 516 Application-Group: This group identifies a set of applications based 517 on a tag or on static information. The tag to application 518 information is dynamically derived from systems such as CMDB. For 519 example, an end-customer may want to classify all applications 520 running in the Legal department into one group and all 521 applications running under a specific operating system into 522 another group. 524 Location-Group: This group identifies a set of locations based on a 525 tag or on static information. The tag to location information is 526 dynamically derived from systems such as CMDB. For example, an 527 end-customer may want to classify all sites/locations in a 528 geographic region as one group. 530 4.4. Policy Rules 532 The security policy rules can be as simple as specifying a match for 533 the user or application specified through "Policy Endpoint Group" and 534 take one of the "Policy Actions" or more complicated rules that 535 specify how two different "Policy Endpoint Groups" interact with each 536 other. The northbound interface must support mechanisms to allow the 537 following rule matches. 539 Policy Endpoint Groups: The rule must allow a way to match either a 540 single or a member of a list of "Policy Endpoint Groups". 542 There must also be a way to express whether a group is a source or a 543 destination so that the security administrator can apply the rule in 544 only one direction of a communication. 546 There must also be a way to express a match between two "Policy 547 Endpoint Groups" so that a policy can be effective for communication 548 between two groups. 550 Direction: The rule must allow a way to express whether the security 551 administrator wants to match the "Policy Endpoint Group" as the 552 source or destination. The default should be to match both 553 directions if the direction rule is not specified in the policy. 555 Threats: The rule should allow the security administrator to express 556 a match for threats that come either in the form of feeds (such as 557 botnet feeds, GeoIP feeds, URL feeds, or feeds from a SIEM) or 558 speciality security appliances. 560 The threat could be from malware and this requires a way to match for 561 virus signatures or file hashes. 563 4.5. Policy Actions 565 The security administrator must be able to configure a variety of 566 actions within a security policy. Typically, security policy 567 specifies a simple action of "deny" or "permit" if a particular rule 568 is matched. Although this may be enough for most of the simple 569 policies, the I2NSF northbound interface must also provide a more 570 comprehensive set of actions so that the interface can be used 571 effectively across various security functions. 573 Permit: This action means continue processing the next rule or allow 574 the packet to pass if this is the last rule. 576 Deny: This action means stop further rule processing and drop the 577 packet. 579 Drop connection: This action means stop further rule processing, 580 drop the packet, and drop connection (for example, by sending a 581 TCP reset). 583 Log: This action means create a log entry whenever a rule is 584 matched. 586 Authenticate connection: This action means that whenever a new 587 connection is established it should be authenticated. 589 Quarantine/Redirect: This action may be relevant for event driven 590 policy where certain events would activate a configured policy 591 that quarantines or redirects certain packet flows. 593 4.6. Third-Party Integration 595 The security policies in the end-customer's network may require the 596 use of specialty devices such as honeypots, behavioral analytics, or 597 SIEM in the network, and may also involve threat feeds, virus 598 signatures, and malicious file hashes as part of comprehensive 599 security policies. 601 The northbound interface must allow the security administrator to 602 configure these threat sources and any other information to provide 603 integration and fold this into policy management. 605 4.7. Telemetry Data 607 One of the most important aspect of security is to have visibility 608 into the networks. As threats become more sophisticated, the 609 security administrator must be able to gather different types of 610 telemetry data from various devices in the network. The collected 611 data could simply be logged or sent to security analysis engines for 612 behavioral analysis, policy voilations, and for threat detection. 614 The northbound interface must allow the security administrator to 615 collect various kinds of data from NSFs. The data source could be 616 syslog, flow records, policy violation records, and other available 617 data. 619 5. Operational Requirements for the Client Interface 621 5.1. API Versioning 623 The northbound interface must support a version number for each 624 RESTful API. This is very important because the client application 625 and the controller application will most likely come from different 626 vendors. Even if the vendor is same, it is hard to imagine that two 627 different applications would be released in lock step. 629 Without API versioning, it hard to debug and figure out issues if 630 application breaks. Although API versioning does not guarantee that 631 applications will always work, it helps in debugging if the problem 632 is caused by an API mismatch. 634 5.2. API Extensiblity 636 Abstraction and standardization of the northbound interface is of 637 tremendous value to end-customers as it gives them the flexibility of 638 deploying any vendors' NSF. However this might also look like as an 639 obstacle to innovation. 641 If an NSF vendor comes up with new feature or functionality that 642 can't be expressed through the currently defined northbound 643 interface, there must be a way to extend existing APIs or to create a 644 new API that is relevant for that NSF vendor only. 646 5.3. APIs and Data Model Transport 648 The APIs for client interface must be derived from the YANG based 649 data model. The YANG data model for client interface must capture 650 all the requirements as defined in this document to express a 651 security policy. The interface between a client and controller must 652 be reliable to ensure robust policy enforcement. Once such transport 653 mechanism is RESTCONF that uses HTTP operations to provide necessary 654 CRUD operations for YANG data objects, but any other mechanism can be 655 used. 657 5.4. Notification 659 The northbound interface must allow the security administrator to 660 collect various alarams and events from the NSF in the network. The 661 events and alarms may be either related to security policy 662 enforcement or NSF operation. The events and alarms could also be 663 used as a input to the security policy for autonomous handling. 665 5.5. Affinity 667 The northbound interface must allow the security administrator to 668 pass any additional metadata that a user may want to provide for a 669 security policy e.g. certain security policy needs to be applied only 670 on linux machine or windows machine or that a security policy must be 671 applied on the device with Trusted Platform Module chip. 673 5.6. Test Interface 675 The northbound interface must allow the security administrator the 676 ability to test the security policies before the policies are 677 actually applied e.g. a user may want to verify if a policy creates 678 potential conflicts with the existing policies or whether a certain 679 policy can be implemented. The test interface provides such 680 capabilities without actually applying the policies. 682 6. IANA Considerations 684 This document requires no IANA actions. RFC Editor: Please remove 685 this section before publication. 687 7. Acknowledgements 689 The editors would like to thank Adrian Farrel for helpful discussions 690 and advice. 692 8. Normative References 694 [I-D.ietf-i2nsf-problem-and-use-cases] 695 Hares, S., Dunbar, L., Lopez, D., Zarny, M., and C. 696 Jacquenet, "I2NSF Problem Statement and Use cases", draft- 697 ietf-i2nsf-problem-and-use-cases-01 (work in progress), 698 July 2016. 700 Authors' Addresses 702 Rakesh Kumar 703 Juniper Networks 704 1133 Innovation Way 705 Sunnyvale, CA 94089 706 US 708 Email: rkkumar@juniper.net 710 Anil Lohiya 711 Juniper Networks 712 1133 Innovation Way 713 Sunnyvale, CA 94089 714 US 716 Email: alohiya@juniper.net 717 Dave Qi 718 Bloomberg 719 731 Lexington Avenue 720 New York, NY 10022 721 US 723 Email: DQI@bloomberg.net 725 Xiaobo Long 726 4 Cottonwood Lane 727 Warren, NJ 07059 728 US 730 Email: long.xiaobo@gmail.com