idnits 2.17.1 draft-kumar-i2nsf-client-facing-interface-req-01.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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 497: '...y administrators MUST authenticate to ...' RFC 2119 keyword, line 599: '...s, the policy definition SHALL support...' RFC 2119 keyword, line 601: '... interface SHALL support the activat...' RFC 2119 keyword, line 640: '... SHOULD allow for multiple, or sets ...' RFC 2119 keyword, line 645: '... groups MAY be used for configuring ...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 9, 2016) is 2754 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-02 Summary: 2 errors (**), 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: April 12, 2017 D. Qi 6 Bloomberg 7 N. Bitar 8 S. Palislamovic 9 Nokia 10 L. Xia 11 Huawei 12 October 9, 2016 14 Requirements for Client-Facing Interface to Security Controller 15 draft-kumar-i2nsf-client-facing-interface-req-01 17 Abstract 19 This document captures the requirements for the client-facing 20 interface to security controller. The interfaces are based on user- 21 intent instead of developer-specific or device-centric approaches 22 that would require deep knowledge of specific products and their 23 security features. The document identifies the requirements needed 24 to enforce the user-intent based policies onto network security 25 functions (NSFs) irrespective of how those functions are realized. 26 The function may be physical or virtual in nature and may be 27 implemented in networking or dedicated appliances. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 12, 2017. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions Used in this Document . . . . . . . . . . . . . . 4 65 3. Guiding principles for definition of Client-Facing Interfaces 5 66 3.1. User-intent based modeling . . . . . . . . . . . . . . . 5 67 3.2. Basic rules for interface definition . . . . . . . . . . 6 68 3.3. Independent of deployment models . . . . . . . . . . . . 6 69 4. Functional Requirements for the Client-Facing Interface . . . 10 70 4.1. Requirement for Multi-Tenancy . . . . . . . . . . . . . . 11 71 4.2. Requirement for Authentication and Authorization . . . . 12 72 4.3. Requirement for Role-Based Access Control (RBAC) . . . . 12 73 4.4. Requirement for Protection from Attacks . . . . . . . . . 12 74 4.5. Requirement for Protection from Misconfiguration . . . . 13 75 4.6. Requirement for Policy Lifecycle Management . . . . . . . 13 76 4.7. Requirement for Dynamic Policy Endpoint Groups . . . . . 14 77 4.8. Requirement for Policy Rules . . . . . . . . . . . . . . 16 78 4.9. Requirement for Policy Actions . . . . . . . . . . . . . 16 79 4.10. Requirement for Generic Policy Models . . . . . . . . . . 18 80 4.11. Requirement for Policy Conflict Resolution . . . . . . . 18 81 4.12. Requirement for Backward Compatibility . . . . . . . . . 18 82 4.13. Requirement for Third-Party Integration . . . . . . . . . 18 83 4.14. Requirement for Telemetry Data . . . . . . . . . . . . . 19 84 5. Operational Requirements for the Client-Facing Interface . . 19 85 5.1. API Versioning . . . . . . . . . . . . . . . . . . . . . 19 86 5.2. API Extensiblity . . . . . . . . . . . . . . . . . . . . 19 87 5.3. APIs and Data Model Transport . . . . . . . . . . . . . . 20 88 5.4. Notification . . . . . . . . . . . . . . . . . . . . . . 20 89 5.5. Affinity . . . . . . . . . . . . . . . . . . . . . . . . 20 90 5.6. Test Interface . . . . . . . . . . . . . . . . . . . . . 20 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 92 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 93 8. Normative References . . . . . . . . . . . . . . . . . . . . 21 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 96 1. Introduction 98 Programming security policies in a network has been a fairly complex 99 task that often requires very deep knowledge of developers' specific 100 devices. This has been the biggest challenge for both service 101 providers and enterprises, henceforth named as security administrator 102 in this document. The challenge is amplified due to virtualization 103 because security appliances come in both physical and virtual forms 104 and are supplied by a variety of developers who have their own 105 proprietary interfaces to manage and implement the security policies 106 on their devices. 108 Even if a security administrator deploys a single developer solution 109 with a set of one or more security functions across its entire 110 network, it is difficult to manage security policies due to the 111 complexity of network security features available in the developer 112 devices, and the difficulty in mapping the user intent to developer- 113 specific configurations. The security administrator may use asset of 114 developer-specific APIs or a developer-provided management system 115 that gives some abstraction in the form of GUI to help provision and 116 manage security policies. However, the single developer approach is 117 highly restrictive in today's network for the following reasons: 119 o The security administrator cannot rely on a single developer 120 because one developer may not be able keep up to date with the 121 customer security needs or specific deployment models. 123 o A large organization may have a presence across different sites 124 and regions; which means, it is not possible to have a complete 125 solution from a single developer due to technical, regulatory or 126 business reasons. 128 o If and when the security administrator migrates from one developer 129 to another, it is almost impossible to migrate security policies 130 from one management system to another without complex manual work. 132 o Security administrators are implementing various security 133 functions in virtual forms or physical forms to attain the 134 flexibility, elasticity, performance, and operational efficiency 135 they require. Practically, that often requires different sources 136 (developers and open source) that provide the best of breed for 137 any such security function. 139 o The security administrator might choose various devices or network 140 services (such as routers, switches, firewall devices, and 141 overlay-networks) as enforcement points for security policies for 142 any reason (such as network design simplicity, cost, most- 143 effective place, scale and performance). 145 In order to ease the deployment of security policies across different 146 developers and devices, the Interface to Network Security Functions 147 (I2NSF) working group in the IETF is defining a client-facing 148 interface from the security controller to clients [I-D. ietf-i2nsf- 149 framework] [I-D. ietf-i2nsf-terminology]. The easiness of deployment 150 should be agnostic to type of device, be it physical or virtual, or 151 type of the policy, be it dynamic or static. Using these interfaces, 152 a user can write any application (e.g. GUI portal, template engine, 153 etc.) to control the implementation of security policies on security 154 functional elements, but this is completely out of scope for the 155 I2NSF working group. 157 This document captures the requirements for the client-facing 158 interface that can be easily used by security administrators without 159 knowledge of specific security devices or features. We refer to this 160 as "user-intent" based interfaces. To further clarify, in the scope 161 of this document, the "user-intent" here does not mean some free-from 162 natural language input or an abstract intent such as "I want my 163 traffic secure" or "I don't want DDoS attacks in my network"; rather 164 the user-intent here means that policies are described using client- 165 oriented expressions such as application names, application groups, 166 device groups, user groups etc. with a vocabulary of verbs (e.g., 167 drop, tap, throttle), prepositions, conjunctions, conditionals, 168 adjectives, and nouns instead of using standard n-tuples from the 169 packet header. 171 2. Conventions Used in this Document 173 BSS: Business Support System 175 CLI: Command Line Interface 177 CMDB: Configuration Management Database 179 Controller: Used interchangeably with Service Provider Security 180 Controller or management system throughout this document 182 CRUD: Create, Retrieve, Update, Delete 184 FW: Firewall 186 GUI: Graphical User Interface 188 IDS: Intrusion Detection System 189 IPS: Intrusion Protection System 191 LDAP: Lightweight Directory Access Protocol 193 NSF: Network Security Function, defined by 194 [I-D.ietf-i2nsf-problem-and-use-cases] 196 OSS: Operation Support System 198 RBAC: Role Based Access Control 200 SIEM: Security Information and Event Management 202 URL: Universal Resource Locator 204 vNSF: Refers to NSF being instantiated on Virtual Machines 206 3. Guiding principles for definition of Client-Facing Interfaces 208 The "Client-Facing Interface" ensures that a security administrator 209 can deploy any device from any developer and still be able to use 210 same consistent interface. In essence, these interfaces provide a 211 management framework to manage security administrator's security 212 policies. Henceforth in this document, we use "security policy 213 management interface" interchangeably when we refer to the client- 214 facing interface. 216 3.1. User-intent based modeling 218 Traditionally, security policies have been expressed using 219 proprietary interfaces. These interfaces are defined by a developer 220 either based on CLI or a GUI system; but more often these interfaces 221 are built using developer specific networking construct such IP 222 address, protocol and application constructs with L4-L7 information. 223 This requires security operators to translate their oragnzational 224 business objectives into actionable security policies on security 225 device using developers policy constructs. But, this alone is not 226 sufficient to render policies in the network as operator also need to 227 identify the device where the policy need to be applied in a complex 228 network environment with multiple policy enforcement points. 230 The User-intent based framework defines constructs such as user- 231 group, application-group, device-group and location group. The 232 security operator would use these constructs to express a security 233 policy instead of proprietary constructs. The policy defined in such 234 a manner is referred to user-intent based policies in this draft. 235 The idea is to enable security operator to use constructs they knows 236 best in expressing security policies; which simplify their tasks and 237 help in avoiding human errors in complex security provisioing. 239 3.2. Basic rules for interface definition 241 The basic rules in defining the client-facing interfaces are as 242 following: 244 o Agnostic of network topology and NSF location in the network. 246 o Agnostic to the features and capabilities supported in NSFs. 248 o Agnostic to the resources available in NSFs or resources available 249 for various features/capabilities. 251 o Agnostic to the network function type, be it stateful firewall, 252 IDP, IDS, Router, Switch. 254 o Declarative/Descriptive model instead of Imperative/Prescriptive 255 model - What security policies need to enforce (declarative) 256 instead of how they would be actually implemented (imperative). 258 o Agnostic of developer, implementation and form-factor (physical, 259 virtual). 261 o Agnostic to how NSF is implemented and its hosting environment. 263 o Agnostic to how NSF becomes operational - Network connectivity and 264 other hosting requirements 266 o Agnostic to NSF control plane implementation (if there is one) 267 E.g., cluster of NSF active as one unified service for scale and/ 268 or resilience. 270 o Agnostic to NSF data plane implementation i.e. Encapsulation, 271 Service function chains. 273 3.3. Independent of deployment models 275 This document does not describe requirements for NSF-facing 276 interface; they are expected to be defined in a separate draft. This 277 draft does not mandate a specific deployment model but rather shows 278 how client interfaces remain the same and interact with the overall 279 security framework from security administrator's perspective. 281 Traditionally, medium and larger operators deploy management systems 282 to manage their statically-defined security policies. This approach 283 may not be suitable nor sufficient for modern automated and dynamic 284 data centers that are largely virtualized and rely on various 285 management systems and controllers to dynamically implement security 286 policies over any types of resources. 288 There are two different deployment models in which the client-facing 289 interface referred to in this document could be implemented. These 290 models have no direct impact on the client-facing interface, but 291 illustrate the overall security policy and management framework and 292 where the various processing functions reside. These models are: 294 a. Management without an explicit management system for control of 295 devices and NSFs. In this deployment, the security controller 296 acts as a NSF policy management system that takes information 297 passed over the client security policy interface and translates 298 into data on the I2NSF southbound interface. The I2NSF 299 interfaces are implemented by security device/function 300 developers. This would usually be done by having an I2NSF agent 301 embedded in the security device or NSF. This deployment model is 302 shown in Figure 1. 304 RESTful API 305 SUPA or I2NSF Policy Management 306 ^ 307 Client-facing | 308 Security Policy Interface | 309 (Independent of individual | 310 NSFs, devices,and developers)| 311 | 312 ------------------------------ 313 | | 314 | Security Controller | 315 | | 316 ------------------------------ 317 | ^ 318 Southbound Security | I2NSF | 319 Capability Interface | NSF-facing | 320 (Specific to NSFs) | Interface | 321 .............................. 322 | | 323 v | 325 ------------- ------------- 326 | I2NSF Agent | | I2NSF Agent | 327 |-------------| |-------------| 328 | |---| | 329 | NSF | | NSF | 330 NSFs | | | | 331 (virtual -------------\ /------------- 332 and | \ / | 333 physical) | X | 334 | / \ | 335 -------------/ \------------- 336 | I2NSF Agent | | I2NSF Agent | 337 |-------------| |-------------| 338 | |---| | 339 | NSF | | NSF | 340 | | | | 341 ------------- ------------- 343 Figure 1: Deployment without Management System 345 b. Management with an explicit management system for control of 346 devices and NSFs. This model is similar to the model above 347 except that security controller interacts with a dedicated 348 management system which could either proxy I2NSF southbound 349 interfaces or could provide a layer where security devices or 350 NSFs do not support an I2NSF agent to process I2NSF southbound 351 interfaces. This deployment model is shown in Figure 2. 353 RESTful API 354 SUPA or I2NSF Policy Management 355 ^ 356 Client-facing | 357 Security Policy Interface | 358 (Independent of individual | 359 NSFs,devices,and developers) | 360 | 361 ------------------------------ 362 | | 363 | Security Controller | 364 | | 365 ------------------------------ 366 | ^ 367 Southbound Security | I2NSF | 368 Capability Interface | NSF-facing | 369 (Specific to NSFs) | Interface | 370 .............................. 371 | | 372 v | 373 ------------------------------ 374 | | 375 | I2NSF Proxy Agent / | 376 | Management System | 377 | | 378 ------------------------------ 379 | ^ 380 | Proprietary | 381 | Functional | 382 | Interface | 383 .............................. 384 | | 385 v | 387 ------------- ------------- 388 | |---| | 389 | NSF | | NSF | 390 NSFs | | | | 391 (virtual -------------\ /------------- 392 and | \ / | 393 physical) | X | 394 | / \ | 395 -------------/ \------------- 396 | |---| | 397 | NSF | | NSF | 398 | | | | 399 ------------- ------------- 401 Figure 2: Deployment with Management System or I2NSF Proxy Agent 403 Although the deployment models discussed here don't necessarily 404 affect the client security policy interface, they do give an overall 405 context for defining a security policy interface based on 406 abstraction. 408 4. Functional Requirements for the Client-Facing Interface 410 As stated in the guiding principles for defining I2NSF client-facing 411 interface, the security policies and the client-facing interface 412 shall be defined from a user/client perspective and abstracted away 413 from the type of NSF, NSF specific implementation, controller 414 implementation, NSF topology, NSF interfaces, controller southbound 415 interfaces. Thus, the security policy definition shall be 416 declarative, expressing the user/client intent, and driven by how 417 security administrators view security policies from the definition, 418 communication and deployment perspective. 420 The security controller's implementation is outside the scope of this 421 document and the I2NSF working group. 423 At a high level, the requirements for the client-facing interface in 424 order to express and build security policies are as follows: 426 o Multi-Tenancy 428 o Authentication and Authorization 430 o Role-Based Access Control (RBAC) 432 o Protection from Attacks 434 o Protection from Misconfiguration 436 o Policy Lifecycle Management 438 o Dynamic Policy Endpoint Groups 440 o Policy Rules 442 o Policy Actions 443 o Generic Policy Model 445 o Policy Conflict Resolution 447 o Backward Compatibility 449 o Third-Party Integration 451 o Telemetry Data 453 The above constructs are by no means a complete list and may not be 454 sufficient for all use-cases and all operators, but should be a good 455 start for a wide variety of use-cases in both Service Provider 456 networks and Enterprise networks. 458 4.1. Requirement for Multi-Tenancy 460 A security administrator that uses security policies may have 461 internal tenants and would like to have a framework wherein each 462 tenant manages its own security policies to provide isolation across 463 different tenants. 465 An operator may be a cloud service provider with multi-tenant 466 deployments where each tenant is a different organization and must 467 allow complete isolation across different tenants. 469 It should be noted that tenants in turn can have their own tenants, 470 so a recursive relation exists. For instance, a tenant in a cloud 471 service provider may have multiple departments or organizations that 472 need to manage their own security rules. 474 Some key concepts are listed below and used throughout the document 475 hereafter: 477 Policy-Tenant: An entity that owns and manages the security Policies 478 applied on itself. 480 Policy-Administrator: A user authorized to manage the security 481 policies for a Policy-Tenant. 483 Policy-User: A user within a Policy-Tenant who is authorized to 484 access certain resources of that tenant according to the security 485 policies of the Policy-Tenant. 487 Policy-User-Group: A collection of Policy-Users. This group 488 identifies a set of users based on a policy tag or on static 489 information. The tag to identify the user is dynamically derived 490 from systems such as Active Directory or LDAP. For example, an 491 operator may have different user-groups, such as HR-users, 492 Finance-users, Engineering-users, to classify a set of users in 493 each department. 495 4.2. Requirement for Authentication and Authorization 497 Security administrators MUST authenticate to and be authorized by 498 security controller before they are able to issue control commands 499 and any policy data exchange commences. 501 There must be methods defined for Policy-Administrator be 502 authenticated and authorized to use the security controller. There 503 are several authentication methods available such as OAuth, XAuth and 504 X.509 certificate based. The authentication scheme between Policy- 505 Administrator and security controller may also be mutual instead of 506 one-way. Any specific method may be determined based on 507 organizational and deployment needs and outside the scope of I2NSF. 508 In addition, there must be a method to authorize the Policy- 509 Administrator for performing certain action. It should be noted 510 that, depending on the deployment model, Policy-Administrator 511 authentication and authorization to perform actions communicated to 512 the controller could be performed as part of a portal or another 513 system prior to communication the action to the controller. 515 4.3. Requirement for Role-Based Access Control (RBAC) 517 Policy-Authorization-Role represents a role assigned to a Policy-User 518 or Policy-User Group that determines whether the user or the user- 519 group has read-write access, read-only access, or no access for 520 certain resources. A User or a User-Group can be mapped to a Policy- 521 Authorization- Role using an internal or external identity provider 522 or mapped statically. 524 4.4. Requirement for Protection from Attacks 526 There Must be protections from attacks, malicious or otherwise, from 527 clients or a client impersonator. Potential attacks could come from 528 a botnet or a host or hosts infected with virus or some unauthorized 529 entity. It is recommended that security controller use adedicated IP 530 interface for client-facing communications and those communications 531 should be carried over an isolated out-of-band network. In addition, 532 it is recommended that traffic between clients and security 533 controllers be encrypted. Furthermore, some straightforward traffic/ 534 session control mechanisms (i.e., Rate-limit, ACL, White/Black list) 535 can be employed on the security controller to defend against DDoS 536 flooding attacks. 538 4.5. Requirement for Protection from Misconfiguration 540 There Must be protections from mis-configured clients, unintentional 541 or otherwise. System and policy validations should be implemented. 542 Validation may be based on a set of default parameters or custom 543 tuned thresholds such as # of policy changes submitted; # of objects 544 requested in given time interval, etc. 546 4.6. Requirement for Policy Lifecycle Management 548 In order to provide more sophisticated security framework, there 549 should be a mechanism to express that a policy becomes dynamically 550 active/enforced or inactive based on either security administrator 551 intervention or an event. 553 One example of dynamic policy management is when the security 554 administrator pre-configures all the security policies, but the 555 policies get activated/enforced or deactivated based on dynamic 556 threats faced by the security administrator. Basically, a threat 557 event may activate certain inactive policies, and once a new event 558 indicates that the threat has gone away, the policies become inactive 559 again. 561 There are four models for dynamically activating policies: 563 o The policy may be dynamically activated by the I2NSF client or 564 associated management entity, and dynamically communicated over the 565 I2NSF client-facing interface to the controller to program I2NSF 566 functions using the I2NSF NSF-facing interface 568 o The policy may be pulled dynamically by the controller upon 569 detecting an event over the I2NSF monitoring interface 571 o The policy may be statically pushed to the controller and 572 dynamically programmed on the NSFs upon potentially detecting another 573 event 575 o The policy can be programmed in the N2SFs functions, and activated/ 576 deactivated upon policy attributes, like time or admin enforced. 578 The client-facing interface should support the following policy 579 attributes for policy enforcement: 581 Admin-Enforced: The policy, once configured, remains active/enforced 582 until removed by the security administrator. 584 Time-Enforced: The policy configuration specifies the time profile 585 that determines when policy is activated/enforced. Otherwise, it 586 is de-activated. 588 Event-Enforced: The policy configuration specifies the event profile 589 that determines when policy is activated/enforced. It also 590 specifies the duration attribute of that policy once activated 591 based on event. For instance, if the policy is activated upon 592 detecting an application flow, the policy could be de-activated 593 when the corresponding session is closed or the flow becomes 594 inactive for certain time. 596 A policy could be a composite policy, that is composed of many rules, 597 and subject to updates and modification. For policy maintenance 598 purposes, enforcement, and auditability, it becomes important to name 599 and version the policies. Thus, the policy definition SHALL support 600 policy naming and versioning. In addition, the i2NSF client-facing 601 interface SHALL support the activation, deactivation, 602 programmability, and deletion of policies based on name and version. 603 In addition, it Should support reporting on the state of policies by 604 name and version. For instance, a client may probe the controller 605 about the current policies enforced for a tenant and/or a sub-tenant 606 (organization) for auditability or verification purposes. 608 4.7. Requirement for Dynamic Policy Endpoint Groups 610 When the security administrator configures a security policy, the 611 intention is to apply this policy to certain subsets of the network. 612 The subsets may be identified based on criteria such as users, 613 devices, and applications. We refer to such a subset of the network 614 as a "Policy Endpoint Group". 616 One of the biggest challenges for a security administrator is how to 617 make sure that security policies remain effective while constant 618 changes are happening to the "Policy Endpoint Group" for various 619 reasons (e.g., organizational changes). If the policy is created 620 based on static information such as user names, application, or 621 network subnets, then every time that this static information changes 622 policies would need to be updated. For example, if a policy is 623 created that allows access to an application only from the group of 624 Human Resource users (the HR-users group), then each time the HR- 625 users group changes, the policy needs to be updated. 627 Changes to policy could be highly taxing to the security 628 administrator for various operational reasons. The policy management 629 framework must allow "Policy Endpoint Group" to be dynamic in nature 630 so that changes to the group (HR-users in our example) automatically 631 result in updates to its content. 633 We call these dynamic Policy Endpoint Groups "Meta-data Driven 634 Groups". The meta-data is a tag associated with endpoint information 635 such as users, applications, and devices. The mapping from meta-data 636 to dynamic content could come either from standards-based or 637 proprietary tools. The security controller could use any available 638 mechanisms to derive this mapping and to make automatic updates to 639 the policy content if the mapping information changes. The system 640 SHOULD allow for multiple, or sets of tags to be applied to a single 641 network object. 643 The client-facing policy interface must support endpoint groups for 644 user-intent based policy management. The following meta-data driven 645 groups MAY be used for configuring security polices: 647 User-Group: This group identifies a set of users based on a tag or 648 on static information. The tag to identify user is dynamically 649 derived from systems such as Active Directory or LDAP. For 650 example, an operator may have different user-groups, such as HR- 651 users, Finance-users, Engineering-users, to classify a set of 652 users in each department. 654 Device-Group: This group identifies a set of devices based on a tag 655 or on static information. The tag to identify device is 656 dynamically derived from systems such as configuration mannagement 657 database (CMDB). For example, a security administrator may want 658 to classify all machines running one operating system into one 659 group and machines running another operating system into another 660 group. 662 Application-Group: This group identifies a set of applications based 663 on a tag or on static information. The tag to identify 664 application is dynamically derived from systems such as CMDB. For 665 example, a security administrator may want to classify all 666 applications running in the Legal department into one group and 667 all applications running under a specific operating system into 668 another group. In some cases, the application can semantically 669 associated with a VM or a device. However, in other cases, the 670 application may need to be associated with a set of identifiers 671 (e.g., transport numbers, signature in the application packet 672 payload) that identify the application in the corresponding 673 packets. The mapping of application names/tags to signatures in 674 the associated application packets should be defined and 675 communicated to the NSF. The client-facing Interface shall 676 support the communication of this information. 678 Location-Group: This group identifies a set of location tags. Tag 679 may correspond 1:1 to location. The tag to identify location is 680 either statically defined or dynamically derived from systems such 681 as CMDB. For example, a security administrator may want to 682 classify all sites/locations in a geographic region as one group. 684 4.8. Requirement for Policy Rules 686 The security policy rules can be as simple as specifying a match for 687 the user or application specified through "Policy Endpoint Group" and 688 take one of the "Policy Actions" or more complicated rules that 689 specify how two different "Policy Endpoint Groups" interact with each 690 other. The client-facing interface must support mechanisms to allow 691 the following rule matches. 693 Policy Endpoint Groups: The rule must allow a way to match either a 694 single or a member of a list of "Policy Endpoint Groups". 696 There must be a way to express a match between two "Policy Endpoint 697 Groups" so that a policy can be effective for communication between 698 two groups. 700 Direction: The rule must allow a way to express whether the security 701 administrator wants to match the "Policy Endpoint Group" as the 702 source or destination. The default should be to match both 703 directions if the direction rule is not specified in the policy. 705 Threats: The rule should allow the security administrator to express 706 a match for threats that come either in the form of feeds (such as 707 botnet feeds, GeoIP feeds, URL feeds, or feeds from a SIEM) or 708 speciality security appliances. Threats could be identified by 709 Tags/names in policy rules. The tag is a label of one or more 710 event types that may be detected by a threat detection system. 712 The threat could be from malware and this requires a way to match for 713 virus signatures or file hashes. 715 4.9. Requirement for Policy Actions 717 The security administrator must be able to configure a variety of 718 actions within a security policy. Typically, security policy 719 specifies a simple action of "deny" or "permit" if a particular 720 condition is matched. Although this may be enough for most of the 721 simple policies, the I2NSF client-facing interface must also provide 722 a more comprehensive set of actions so that the interface can be used 723 effectively across various security functions. 725 Policy action MUST be extensible so that additional policy action 726 specifications can easily be added. 728 The following list of actions SHALL be supported: 730 Permit: This action means continue processing the next rule or allow 731 the packet to pass if this is the last rule. This is often a 732 default action. 734 Deny: This action means stop further packet processing and drop the 735 packet. 737 Drop connection: This action means stop further packet processing, 738 drop the packet, and drop connection (for example, by sending a 739 TCP reset). 741 Log: This action means create a log entry whenever a rule is 742 matched. 744 Authenticate connection: This action means that whenever a new 745 connection is established it should be authenticated. 747 Quarantine/Redirect: This action may be relevant for event driven 748 policy where certain events would activate a configured policy 749 that quarantines or redirects certain packets or flows. The 750 redirect action must specify whether the packet is to be tunneled 751 and in that case specify the tunnel or encapsulation method and 752 destination identifier. 754 Netflow: This action creates a Netflow record; Need to define 755 Netflow server or local file and version of Netflow. 757 Count: This action counts the packets that meet the rule condition. 759 Encrypt: This action encrypts the packets on an identified flow. 760 The flow could be over an Ipsec tunnel, or TLS session for 761 instance. 763 Decrypt: This action decrypts the packets on an identified flow. 764 The flow could be over an Ipsec tunnel, or TLS session for 765 instance. 767 Throttle: This action defines shaping a flow or a group of flows 768 that match the rule condition to a designated traffic profile. 770 Mark: This action defines traffic that matches the rule condition by 771 a designated DSCP value and/or VLAN 802.1p Tag value. 773 Instantiate-NSF: Instantiate a NSF with predefined profile. A NSF 774 can be any of FW, LB, IPS, IDS, honeypot, or VPN, etc. 776 WAN-Accelerate: This action optimize packet delivery using a set of 777 predefined packet optimization methods. 779 Load-Balance: This action load balance connections based on 780 predefined LB schemes or profiles. 782 The policy actions should support combination of terminating actions 783 and non-terminating actions. For example, Syslog and then Permit; 784 Count and then Redirect. 786 Policy actions SHALL support any L2, L3, L4-L7 policy actions. 788 4.10. Requirement for Generic Policy Models 790 Client-facing interface SHALL provide a generic metadata model that 791 defines once and then be used by appropriate model elements any 792 times, regardless of where they are located in the class hierarchy, 793 as necessary. 795 Client-facing interface SHALL provide a generic context model that 796 enables the context of an entity, and its surrounding environment, to 797 be measured, calculated, and/or inferred. 799 Client-facing interface SHALL provide a generic policy model that 800 enables context-aware policy rules to be defined to change the 801 configuration and monitoring of resources and services as context 802 changes. 804 4.11. Requirement for Policy Conflict Resolution 806 Client-facing interface SHALL be able to detect policy "conflicts", 807 and SHALL specify methods on how to resolve these "conflicts" 809 For example: two clients issues conflicting set of security policies 810 to be applied to the same Policy Endpoint Group. 812 4.12. Requirement for Backward Compatibility 814 It MUST be possible to add new capabilities to client-facing 815 interface in a backward compatible fashion. 817 4.13. Requirement for Third-Party Integration 819 The security policies in the security administrator's network may 820 require the use of specialty devices such as honeypots, behavioral 821 analytics, or SIEM in the network, and may also involve threat feeds, 822 virus signatures, and malicious file hashes as part of comprehensive 823 security policies. 825 The client-facing interface must allow the security administrator to 826 configure these threat sources and any other information to provide 827 integration and fold this into policy management. 829 4.14. Requirement for Telemetry Data 831 One of the most important aspect of security is to have visibility 832 into the networks. As threats become more sophisticated, the 833 security administrator must be able to gather different types of 834 telemetry data from various devices in the network. The collected 835 data could simply be logged or sent to security analysis engines for 836 behavioral analysis, policy violations, and for threat detection. 838 The client-facing interface MUST allow the security administrator to 839 collect various kinds of data from NSFs. The data source could be 840 syslog, flow records, policy violation records, and other available 841 data. 843 Detailed client-facing interface telemetry data should be available 844 between clients and security controllers. Clients should be able to 845 subscribe and receive these telemetry data. 847 client should be able to receive notifications when a policy is 848 dynamically updated. 850 5. Operational Requirements for the Client-Facing Interface 852 5.1. API Versioning 854 The client-facing interface must support a version number for each 855 RESTful API. This is very important because the client application 856 and the controller application will most likely come from different 857 developers. Even if the developer is same, it is hard to imagine 858 that two different applications would be released in lock step. 860 Without API versioning, it is hard to debug and figure out issues if 861 application breaks. Although API versioning does not guarantee that 862 applications will always work, it helps in debugging if the problem 863 is caused by an API mismatch. 865 5.2. API Extensiblity 867 Abstraction and standardization of the client-facing interface is of 868 tremendous value to security administrators as it gives them the 869 flexibility of deploying any developers' NSF without needing to 870 redefine their policies or change the client interface. However this 871 might also look like as an obstacle to innovation. 873 If an NSF developer comes up with new feature or functionality that 874 can't be expressed through the currently defined client-facing 875 interface, there must be a way to extend existing APIs or to create a 876 new API that is relevant for that NSF developer only. 878 5.3. APIs and Data Model Transport 880 The APIs for client interface must be derived from the YANG based 881 data model. The YANG data model for client interface must capture 882 all the requirements as defined in this document to express a 883 security policy. The interface between a client and controller must 884 be reliable to ensure robust policy enforcement. One such transport 885 mechanism is RESTCONF that uses HTTP operations to provide necessary 886 CRUD operations for YANG data objects, but any other mechanism can be 887 used. 889 5.4. Notification 891 The client-facing interface must allow the security administrator to 892 collect various alarms and events from the NSF in the network. The 893 events and alarms may be either related to security policy 894 enforcement or NSF operation. The events and alarms could also be 895 used as a input to the security policy for autonomous handling. 897 5.5. Affinity 899 The client-facing interface must allow the security administrator to 900 pass any additional metadata that a user may want to provide for a 901 security policy e.g. certain security policy needs to be applied only 902 on linux machine or windows machine or that a security policy must be 903 applied on the device with Trusted Platform Module chip. 905 5.6. Test Interface 907 The client-facing interface must allow the security administrator the 908 ability to test the security policies before the policies are 909 actually applied e.g. a user may want to verify if a policy creates 910 potential conflicts with the existing policies or whether a certain 911 policy can be implemented. The test interface provides such 912 capabilities without actually applying the policies. 914 6. IANA Considerations 916 This document requires no IANA actions. RFC Editor: Please remove 917 this section before publication. 919 7. Acknowledgements 921 The editors would like to thank Adrian Farrel for helpful discussions 922 and advice. 924 8. Normative References 926 [I-D.ietf-i2nsf-problem-and-use-cases] 927 Hares, S., Dunbar, L., Lopez, D., Zarny, M., and C. 928 Jacquenet, "I2NSF Problem Statement and Use cases", draft- 929 ietf-i2nsf-problem-and-use-cases-02 (work in progress), 930 October 2016. 932 Authors' Addresses 934 Rakesh Kumar 935 Juniper Networks 936 1133 Innovation Way 937 Sunnyvale, CA 94089 938 US 940 Email: rkkumar@juniper.net 942 Anil Lohiya 943 Juniper Networks 944 1133 Innovation Way 945 Sunnyvale, CA 94089 946 US 948 Email: alohiya@juniper.net 950 Dave Qi 951 Bloomberg 952 731 Lexington Avenue 953 New York, NY 10022 954 US 956 Email: DQI@bloomberg.net 957 Nabil Bitar 958 Nokia 959 755 Ravendale Drive 960 Mountain View, CA 94043 961 US 963 Email: nabil.bitar@nokia.com 965 Senad Palislamovic 966 Nokia 967 755 Ravendale Drive 968 Mountain View, CA 94043 969 US 971 Email: senad.palislamovic@nokia.com 973 Liang Xia 974 Huawei 975 101 Software Avenue 976 Nanjing, Jiangsu 210012 977 China 979 Email: Frank.Xialiang@huawei.com