idnits 2.17.1 draft-kumar-i2nsf-client-facing-interface-req-02.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 598: '...s, the policy definition SHALL support...' RFC 2119 keyword, line 600: '... interface SHALL support the activat...' RFC 2119 keyword, line 633: '... SHOULD allow for multiple, or sets ...' RFC 2119 keyword, line 638: '... driven groups MAY be used for confi...' (12 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 28, 2016) is 2734 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: May 1, 2017 D. Qi 6 Bloomberg 7 N. Bitar 8 S. Palislamovic 9 Nokia 10 L. Xia 11 Huawei 12 October 28, 2016 14 Requirements for Client-Facing Interface to Security Controller 15 draft-kumar-i2nsf-client-facing-interface-req-02 17 Abstract 19 This document captures the requirements for the client-facing 20 interface to the security controller. The interfaces are based on 21 user constructs understood by a security admin instead of a vendor or 22 a device specific mechanism requiring deep knowledge of individual 23 products and features. This document identifies the requirements 24 needed to enforce the user-construct oriented policies onto network 25 security functions (NSFs) irrespective of how those functions are 26 realized. The function may be physical or virtual in nature and may 27 be 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 May 1, 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-construct based modeling . . . . . . . . . . . . . . 5 67 3.2. Basic rules for client interface definition . . . . . . . 6 68 3.3. Deployment Models for Implementing Security Policies . . 7 69 4. Functional Requirements for the Client-Facing Interface . . . 10 70 4.1. Requirement for Multi-Tenancy in client interface . . . . 11 71 4.2. Requirement for Authentication and Authorization of 72 client interface . . . . . . . . . . . . . . . . . . . . 12 73 4.3. Requirement for Role-Based Access Control (RBAC) in 74 client interface . . . . . . . . . . . . . . . . . . . . 12 75 4.4. Requirement to protect client interface from attacks . . 12 76 4.5. Requirement to protect client interface from 77 misconfiguration . . . . . . . . . . . . . . . . . . . . 13 78 4.6. Requirement to manage policy lifecycle with diverse needs 13 79 4.7. Requirement to define dynamic policy Endpoint group . . . 14 80 4.8. Requirement to express rich set of policy rules . . . . . 15 81 4.9. Requirement to express rich set of policy actions . . . . 16 82 4.10. Requirement to express policy in a generic model . . . . 18 83 4.11. Requirement to detect and correct policy conflicts . . . 18 84 4.12. Requirement for backward compatibility . . . . . . . . . 18 85 4.13. Requirement for Third-Party integration . . . . . . . . . 19 86 4.14. Requirement to collect telemetry data . . . . . . . . . . 19 87 5. Operational Requirements for the Client-Facing Interface . . 19 88 5.1. API Versioning . . . . . . . . . . . . . . . . . . . . . 19 89 5.2. API Extensiblity . . . . . . . . . . . . . . . . . . . . 20 90 5.3. APIs and Data Model Transport . . . . . . . . . . . . . . 20 91 5.4. Notification . . . . . . . . . . . . . . . . . . . . . . 20 92 5.5. Affinity . . . . . . . . . . . . . . . . . . . . . . . . 20 93 5.6. Test Interface . . . . . . . . . . . . . . . . . . . . . 20 95 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 96 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 97 8. Normative References . . . . . . . . . . . . . . . . . . . . 21 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 100 1. Introduction 102 Programming security policies in a network has been a fairly complex 103 task that often requires very deep knowledge of vendor specific 104 devices. This has been the biggest challenge for both service 105 providers and enterprises, henceforth named as security administrator 106 in this document. The challenge is amplified due to virtualization 107 with security appliances in physical and virtual form factor from a 108 wide variety of vendors; each vendor have their own proprietary 109 interfaces to express security policies on their devices. 111 Even if a security administrator deploys a single vendor solution 112 with one or more security appliances across its entire network, it is 113 still difficult to manage security policies due to complexity of 114 security features, and difficulty in mapping business requirement to 115 vendor specific configuration. The security administrator may use 116 either vendor provided CLIs or management system with some 117 abstraction to help provision and manage security policies. But, the 118 single vendor approach is highly restrictive in today's network for 119 the following reasons: 121 o The security administrator cannot rely on a single vendor because 122 one vendor may not be able to keep up with their security 123 requirements or specific deployment model. 125 o A large organization may have a presence across different sites 126 and regions; which means, it may not be possible to deploy same 127 solution from single vendor due to regulatory requirement or 128 organizational policy. 130 o If and when security administrator migrates from one vendor to 131 another, it is almost impossible to migrate security policies from 132 one vendor solution to another without complex manual workflows. 134 o Security administrators deploy various security functions in 135 virtual or physical forms to attain the flexibility, elasticity, 136 performance, and operational efficiency they require. 137 Practically, that often requires different sources (vendor, open 138 source) to get the best of breed for any such security function. 140 o The security administrator might choose various devices or network 141 services (such as routers, switches, firewall devices, and 142 overlay-networks) as enforcement points for security policies. 144 This my be for reason (such as network design simplicity, cost, 145 most-effective place, scale and performance). 147 In order to ease the deployment of security policies across different 148 vendors and devices, the Interface to Network Security Functions 149 (I2NSF) working group in the IETF is defining a client-facing 150 interface from the security controller to clients [I-D. ietf-i2nsf- 151 framework] [I-D. ietf-i2nsf-terminology]. Deployment facilitation 152 should be agnostic to the type of device, be it physical or virtual, 153 or type of the policy, be it dynamic or static. Using these 154 interfaces, it would become possible to write different kinds of 155 application (e.g. GUI portal, template engine, etc.) to control the 156 implementation of security policies on security functional elements, 157 though how these applications are implemente are completely out of 158 the scope of the I2NSF working group, which is only focused on the 159 interfaces. 161 This document captures the requirements for the client-facing 162 interface that can be easily used by security administrators without 163 knowledge of specific security devices or features. We refer to this 164 as "user-construct" based interfaces. To further clarify, in the 165 scope of this document, the "user-construct" here does not mean some 166 free-from natural language input or an abstract intent such as "I 167 want my traffic secure" or "I don't want DDoS attacks in my network"; 168 rather the user-construct here means that policies are described 169 using client-oriented expressions such as application names, 170 application groups, device groups, user groups etc. with a vocabulary 171 of verbs (e.g., drop, tap, throttle), prepositions, conjunctions, 172 conditionals, adjectives, and nouns instead of using standard 173 n-tuples from the packet header. 175 2. Conventions Used in this Document 177 BSS: Business Support System 179 CLI: Command Line Interface 181 CMDB: Configuration Management Database 183 Controller: Used interchangeably with Service Provider Security 184 Controller or management system throughout this document 186 CRUD: Create, Retrieve, Update, Delete 188 FW: Firewall 190 GUI: Graphical User Interface 191 IDS: Intrusion Detection System 193 IPS: Intrusion Protection System 195 LDAP: Lightweight Directory Access Protocol 197 NSF: Network Security Function, defined by 198 [I-D.ietf-i2nsf-problem-and-use-cases] 200 OSS: Operation Support System 202 RBAC: Role Based Access Control 204 SIEM: Security Information and Event Management 206 URL: Universal Resource Locator 208 vNSF: Refers to NSF being instantiated on Virtual Machines 210 3. Guiding principles for definition of Client-Facing Interfaces 212 The "Client-Facing Interface" ensures that a security administrator 213 can deploy any device from any vendor and still be able to use a 214 consistent interface. In essence, this interface gives ability to 215 security admins to express their security policies independent of how 216 security functions are implemented in their deployment. Henceforth, 217 in this document, we use "security policy management interface" 218 interchangeably when we refer to the client-facing interface. 220 3.1. User-construct based modeling 222 Traditionally, security policies have been expressed using 223 proprietary interfaces. These interface are defined by a vendor 224 either based on CLI or a GUI system; but more often these interfaces 225 are built using vendor specific networking construct such IP address, 226 protocol and application constructs with L4-L7 information. This 227 requires security operator to translate their oragnzational business 228 objectives into actionable security policies on the device using 229 vendor specific configuration. But, this alone is not sufficient to 230 render policies in the network as operator also need to identify the 231 device in the network topology where a policy need to be enforced in 232 a complex environment with potenial multiple policy enforcement 233 points. 235 The User-construct based framework defines constructs such as user- 236 group, application-group, device-group and location-group. The 237 security admin would use these constructs to express a security 238 policy instead of proprietary vendor specific constructs. The policy 239 defined in such a manner is referred to user-construct based policies 240 in this draft. The idea is to enable security admin to use 241 constructs they understand best in expressing security policies; 242 which simplify their tasks and help avoiding human errors in complex 243 security provisioning. 245 3.2. Basic rules for client interface definition 247 The basic rules in defining the client-facing interfaces are as 248 follows: 250 o Not depending on particular network topology or the actual NSF 251 location in the network 253 o Not requiring the exact knowledge of the concrete features and 254 capabilities supported in the deployed NSFsa€ 256 o Independent of the nature of the function that will apply the 257 expressed policies be it stateful firewall,IDP, IDS, Router, 258 Switch 260 o Declarative/Descriptive model instead of Imperative/Prescriptive 261 model - What security policies need to be enforced (declarative) 262 instead of how they would be actually implemented (imperative) 264 o Not depending on any specific vendor implementation or form-factor 265 (physical, virtual) of the NSF 267 o Not depending on how a NSF becomes operational - Network 268 connectivity and other hosting requirements. 270 o Not depending on NSF control plane implementation (if there is 271 one) E.g., cluster of NSFs active as one unified service for scale 272 and/ or resilience. 274 o Not depending on specific data plane implementation of NSF i.e. 275 Encapsulation, Service function chains. 277 Note that the rules stated above only apply to the client-facing 278 interface where a user will define a high level policy. These rules 279 do not apply to the lower layers e.g. security controller that 280 convert the higher level policies into lower level constructs. The 281 lower layers may still need some intelligence such as topology 282 awareness, capability of the NSF and its functions, supported 283 encapsulations etc. to convert and apply the policies accurately on 284 the NSF devices. 286 3.3. Deployment Models for Implementing Security Policies 288 Traditionally, medium and larger operators deploy management systems 289 to manage their statically-defined security policies. This approach 290 may not be suitable nor sufficient for modern automated and dynamic 291 data centers that are largely virtualized and rely on various 292 management systems and controllers to dynamically implement security 293 policies over any types of resources. 295 There are two different deployment models in which the client-facing 296 interface referred to in this document could be implemented. These 297 models have no direct impact on the client-facing interface, but 298 illustrate the overall security policy and management framework and 299 where the various processing functions reside. These models are: 301 a. Management without an explicit management system for control of 302 devices and NSFs. In this deployment, the security controller 303 acts as a NSF policy management system that takes information 304 passed over the client security policy interface and translates 305 into data on the I2NSF NSF-facing interface. The I2NSF 306 interfaces are implemented by security device/function vendors. 307 This would usually be done by having an I2NSF agent embedded in 308 the security device or NSF. This deployment model is shown in 309 Figure 1. 311 RESTful API 312 SUPA or I2NSF Policy Management 313 ^ 314 | 315 Client-facing Interface | 316 (Independent of individual | 317 NSFs, devices,and vendors)| 318 | 319 ------------------------------ 320 | | 321 | Security Controller | 322 | | 323 ------------------------------ 324 | ^ 325 | I2NSF | 326 NSF Interface | NSF-facing | 327 (Specific to NSFs) | Interface | 328 .............................. 329 | | 330 v | 332 ------------- ------------- 333 | I2NSF Agent | | I2NSF Agent | 334 |-------------| |-------------| 335 | |---| | 336 | NSF | | NSF | 337 NSFs | | | | 338 (virtual -------------\ /------------- 339 and | \ / | 340 physical) | X | 341 | / \ | 342 -------------/ \------------- 343 | I2NSF Agent | | I2NSF Agent | 344 |-------------| |-------------| 345 | |---| | 346 | NSF | | NSF | 347 | | | | 348 ------------- ------------- 350 Figure 1: Deployment without Management System 352 b. Management with an explicit management system for control of 353 devices and NSFs. This model is similar to the model above 354 except that security controller interacts with a dedicated 355 management system which could either proxy I2NSF NSF-facing 356 interfaces or could provide a layer where security devices or 357 NSFs do not support an I2NSF agent to process I2NSF NSF-facing 358 interfaces. This deployment model is shown in Figure 2. 360 RESTful API 361 SUPA or I2NSF Policy Management 362 ^ 363 | 364 Client-facing Interface | 365 (Independent of individual | 366 NSFs,devices,and vendors) | 367 | 368 ------------------------------ 369 | | 370 | Security Controller | 371 | | 372 ------------------------------ 373 | ^ 374 | I2NSF | 375 NSF Interface | NSF-facing | 376 (Specific to NSFs) | Interface | 377 .............................. 378 | | 379 v | 380 ------------------------------ 381 | | 382 | I2NSF Proxy Agent / | 383 | Management System | 384 | | 385 ------------------------------ 386 | ^ 387 | Proprietary | 388 | Functional | 389 | Interface | 390 .............................. 391 | | 392 v | 394 ------------- ------------- 395 | |---| | 396 | NSF | | NSF | 397 NSFs | | | | 398 (virtual -------------\ /------------- 399 and | \ / | 400 physical) | X | 401 | / \ | 402 -------------/ \------------- 403 | |---| | 404 | NSF | | NSF | 405 | | | | 406 ------------- ------------- 408 Figure 2: Deployment with Management System or I2NSF Proxy Agent 410 Although the deployment models discussed here don't necessarily 411 affect the client security policy interface, they do give an overall 412 context for defining a security policy interface based on 413 abstraction. 415 4. Functional Requirements for the Client-Facing Interface 417 As stated in the guiding principles for defining I2NSF client-facing 418 interface, the security policies and the client-facing interface 419 shall be defined from a user/client perspective and abstracted away 420 from the type of NSF, NSF specific implementation, controller 421 implementation, NSF topology, NSF interfaces, controller NSF-facing 422 interfaces. Thus, the security policy definition shall be 423 declarative, expressing the user construct, and driven by how 424 security administrators view security policies from the definition, 425 communication and deployment perspective. 427 The security controller's implementation is outside the scope of this 428 document and the I2NSF working group. 430 In order to express and build security policies, high level 431 requirements for the client-facing are as follows: 433 o Multi-Tenancy 435 o Authentication and Authorization 437 o Role-Based Access Control (RBAC) 439 o Protection from Attacks 441 o Protection from Misconfiguration 443 o Policy Lifecycle Management 445 o Dynamic Policy Endpoint Groups 447 o Policy Rules 449 o Policy Actions 450 o Generic Policy Model 452 o Policy Conflict Resolution 454 o Backward Compatibility 456 o Third-Party Integration 458 o Telemetry Data 460 The above requirements are by no means a complete list and may not be 461 sufficient for all use-cases and all operators, but should be a good 462 starting point for a wide variety of use-cases in Service Provider 463 and Enterprise networks. 465 4.1. Requirement for Multi-Tenancy in client interface 467 A security administrator that uses security policies may have 468 internal tenants and would like to have a framework wherein each 469 tenant manages its own security policies with isolation from other 470 tenants. 472 An operator may be a cloud service provider with multi-tenant 473 deployments, where each tenant is a different customer. Each tenant 474 or customer must be allowed to manage its own security policies. 476 It should be noted that tenants may have their own tenants, so a 477 recursive relation may exist. For instance, a tenant in a cloud 478 service provider may have multiple departments or organizations that 479 need to manage their own security rules. 481 Some key concepts are listed below and used throughout the document 482 hereafter: 484 Policy-Tenant: An entity that owns and manages the security Policies 485 applied on its resources. 487 Policy-Administrator: A user authorized to manage the security 488 policies for a Policy-Tenant. 490 Policy-User: A user within a Policy-Tenant who is authorized to 491 access certain resources of that tenant according to the 492 privileges assigned to it. 494 4.2. Requirement for Authentication and Authorization of client 495 interface 497 Security administrators MUST authenticate to and be authorized by the 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 the Policy-Administrator to 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) in client 516 interface 518 Policy-Authorization-Role represents a role assigned to a Policy-User 519 that determines whether a user or has read-write access, read-only 520 access, or no access for certain resources. A User can be mapped to 521 a Policy-Authorization-Role using an internal or external identity 522 provider or mapped statically. 524 4.4. Requirement to protect client interface 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 a dedicated 530 IP interface for client-facing communications and those 531 communications should be carried over an isolated out-of-band 532 network. In addition, it is recommended that traffic between clients 533 and security controllers be encrypted. Furthermore, some 534 straightforward traffic/session control mechanisms (i.e., Rate-limit, 535 ACL, White/Black list) can be employed on the security controller to 536 defend against DDoS flooding attacks. 538 4.5. Requirement to protect client interface from misconfiguration 540 There Must be protections from mis-configured clients. System and 541 policy validations should be implemented to detect this. Validation 542 may be based on a set of default parameters or custom tuned 543 thresholds such as the number of policy changes submitted, number of 544 objects requested in a given time interval, etc. 546 4.6. Requirement to manage policy lifecycle with diverse needs 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's 551 manual 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 or deactivated based on dynamic threats. 556 Basically, a threat event may activate certain inactive policies, and 557 once a new event indicates that the threat has gone away, the 558 policies become inactive again. 560 There are following ways for dynamically activating policies: 562 o The policy may be dynamically activated by the I2NSF client or 563 associated management entity, and dynamically communicated over the 564 I2NSF client-facing interface to the controller to program I2NSF 565 functions using the I2NSF NSF-facing interface 567 o The policy may be pulled dynamically by the controller upon 568 detecting an event over the I2NSF monitoring interface 570 o The policy may be statically pushed to the controller and 571 dynamically programmed on the NSFs upon potentially detecting another 572 event 574 o The policy can be programmed in the NSF, and activated or 575 deactivated upon policy attributes, like time or admin enforced. 577 The client-facing interface should support the following policy 578 attributes for policy enforcement: 580 Admin-Enforced: The policy, once configured, remains active/enforced 581 until removed by the security administrator. 583 Time-Enforced: The policy configuration specifies the time profile 584 that determines when policy is activated/enforced. Otherwise, it 585 is de-activated. 587 Event-Enforced: The policy configuration specifies the event profile 588 that determines when policy is activated/enforced. It also 589 specifies the duration attribute of that policy once activated 590 based on event. For instance, if the policy is activated upon 591 detecting an application flow, the policy could be de-activated 592 when the corresponding session is closed or the flow becomes 593 inactive for certain time. 595 A policy could be a composite policy, that is composed of many rules, 596 and subject to updates and modification. For the policy maintenance, 597 enforcement, and auditability purposes, it becomes important to name 598 and version the policies. Thus, the policy definition SHALL support 599 policy naming and versioning. In addition, the i2NSF client-facing 600 interface SHALL support the activation, deactivation, 601 programmability, and deletion of policies based on name and version. 602 In addition, it should support reporting on the state of policies by 603 name and version. For instance, a client may probe the controller 604 about the current policies enforced for a tenant and/or a sub-tenant 605 (organization) for auditability or verification purposes. 607 4.7. Requirement to define dynamic policy Endpoint group 609 When the security administrator configures a security policy, it may 610 have requirement to apply this policy to certain subsets of the 611 network. The subsets may be identified based on criteria such as 612 users, devices, and applications. We refer to such a subset of the 613 network as a "Policy Endpoint Group". 615 One of the biggest challenges for a security administrator is how to 616 make sure that security policies remain effective while constant 617 changes are happening to the "Policy Endpoint Group" for various 618 reasons (e.g., organizational, network and application changes). If 619 a policy is created based on static information such as user names, 620 application, or network subnets; then every time this static 621 information change, policies need to be updated. For example, if a 622 policy is created that allows access to an application only from the 623 group of Human Resource users (the HR-users group), then each time 624 the HR- users group changes, the policy needs to be updated. 626 We call these dynamic Policy Endpoint Groups "Meta-data Driven 627 Groups". The meta-data is a tag associated with endpoint information 628 such as users, applications, and devices. The mapping from meta-data 629 to dynamic content could come either from standards-based or 630 proprietary tools. The security controller could use any available 631 mechanisms to derive this mapping and to make automatic updates to 632 the policy content if the mapping information changes. The system 633 SHOULD allow for multiple, or sets of tags to be applied to a single 634 network object. 636 The client-facing policy interface must support endpoint groups for 637 user-construct based policy management. The following meta-data 638 driven groups MAY be used for configuring security polices: 640 User-Group: This group identifies a set of users based on a tag or 641 on static information. The tag to identify user is dynamically 642 derived from systems such as Active Directory or LDAP. For 643 example, an operator may have different user-groups, such as HR- 644 users, Finance-users, Engineering-users, to classify a set of 645 users in each department. 647 Device-Group: This group identifies a set of devices based on a tag 648 or on static information. The tag to identify device is 649 dynamically derived from systems such as configuration mannagement 650 database (CMDB). For example, a security administrator may want 651 to classify all machines running one operating system into one 652 group and machines running another operating system into another 653 group. 655 Application-Group: This group identifies a set of applications based 656 on a tag or on static information. The tag to identify 657 application is dynamically derived from systems such as CMDB. For 658 example, a security administrator may want to classify all 659 applications running in the Legal department into one group and 660 all applications running under a specific operating system into 661 another group. In some cases, the application can semantically 662 associated with a VM or a device. However, in other cases, the 663 application may need to be associated with a set of identifiers 664 (e.g., transport numbers, signature in the application packet 665 payload) that identify the application in the corresponding 666 packets. The mapping of application names/tags to signatures in 667 the associated application packets should be defined and 668 communicated to the NSF. The client-facing Interface shall 669 support the communication of this information. 671 Location-Group: This group identifies a set of location tags. Tag 672 may correspond 1:1 to location. The tag to identify location is 673 either statically defined or dynamically derived from systems such 674 as CMDB. For example, a security administrator may want to 675 classify all sites/locations in a geographic region as one group. 677 4.8. Requirement to express rich set of policy rules 679 The security policy rules can be as simple as specifying a match for 680 the user or application specified through "Policy Endpoint Group" and 681 take one of the "Policy Actions" or more complicated rules that 682 specify how two different "Policy Endpoint Groups" interact with each 683 other. The client-facing interface must support mechanisms to allow 684 the following rule matches. 686 Policy Endpoint Groups: The rule must allow a way to match either a 687 single or a member of a list of "Policy Endpoint Groups". 689 There must be a way to express a match between two "Policy Endpoint 690 Groups" so that a policy can be effective for communication between 691 two groups. 693 Direction: The rule must allow a way to express whether the security 694 administrator wants to match the "Policy Endpoint Group" as the 695 source or destination. The default should be to match both 696 directions, if the direction rule is not specified in the policy. 698 Threats: The rule should allow the security administrator to express 699 a match for threats that come either in the form of feeds (such as 700 botnet feeds, GeoIP feeds, URL feeds, or feeds from a SIEM) or 701 speciality security appliances. Threats could be identified by 702 Tags/names in policy rules. The tag is a label of one or more 703 event types that may be detected by a threat detection system. 705 The threat could be from malware and this requires a way to match for 706 virus signatures or file hashes. 708 4.9. Requirement to express rich set of policy actions 710 The security administrator must be able to configure a variety of 711 actions within a security policy. Typically, security policy 712 specifies a simple action of "deny" or "permit" if a particular 713 condition is matched. Although this may be enough for most of the 714 simple policies, the I2NSF client-facing interface must also provide 715 a more comprehensive set of actions so that the interface can be used 716 effectively across various security functions. 718 Policy action MUST be extensible so that additional policy action 719 specifications can easily be added. 721 The following list of actions SHALL be supported: 723 Permit: This action means continue processing the next rule or allow 724 the packet to pass if this is the last rule. This is often a 725 default action. 727 Deny: This action means stop further packet processing and drop the 728 packet. 730 Drop connection: This action means stop further packet processing, 731 drop the packet, and drop connection (for example, by sending a 732 TCP reset). 734 Log: This action means create a log entry whenever a rule is 735 matched. 737 Authenticate connection: This action means that whenever a new 738 connection is established it should be authenticated. 740 Quarantine/Redirect: This action may be relevant for event driven 741 policy where certain events would activate a configured policy 742 that quarantines or redirects certain packets or flows. The 743 redirect action must specify whether the packet is to be tunneled 744 and in that case specify the tunnel or encapsulation method and 745 destination identifier. 747 Netflow: This action creates a Netflow record; Need to define 748 Netflow server or local file and version of Netflow. 750 Count: This action counts the packets that meet the rule condition. 752 Encrypt: This action encrypts the packets on an identified flow. 753 The flow could be over an Ipsec tunnel, or TLS session for 754 instance. 756 Decrypt: This action decrypts the packets on an identified flow. 757 The flow could be over an Ipsec tunnel, or TLS session for 758 instance. 760 Throttle: This action defines shaping a flow or a group of flows 761 that match the rule condition to a designated traffic profile. 763 Mark: This action defines traffic that matches the rule condition by 764 a designated DSCP value and/or VLAN 802.1p Tag value. 766 Instantiate-NSF: This action instantiates an NSF with a predefined 767 profile. An NSF can be any of the FW, LB, IPS, IDS, honeypot, or 768 VPN, etc. 770 WAN-Accelerate: This action optimizes packet delivery using a set of 771 predefined packet optimization methods. 773 Load-Balance: This action load balances connections based on 774 predefined LB schemes or profiles. 776 The policy actions should support combination of terminating actions 777 and non-terminating actions. For example, Syslog and then Permit; 778 Count and then Redirect. 780 Policy actions SHALL support any L2, L3, L4-L7 policy actions. 782 4.10. Requirement to express policy in a generic model 784 Client-facing interface SHALL provide a generic metadata model that 785 defines once and then be used by appropriate model elements any 786 times, regardless of where they are located in the class hierarchy, 787 as necessary. 789 Client-facing interface SHALL provide a generic context model that 790 enables the context of an entity, and its surrounding environment, to 791 be measured, calculated, and/or inferred. 793 Client-facing interface SHALL provide a generic policy model that 794 enables context-aware policy rules to be defined to change the 795 configuration and monitoring of resources and services as context 796 changes. 798 Client-facing interface SHALL provide the ability to apply policy or 799 multiple sets of policies to any given object. Policy application 800 process SHALL allow for nesting capabilities of given policies or set 801 of policies. For example, an object or any given set of objects 802 could have application team applying certain set of policy rules, 803 while network team would apply different set of their policy rules. 804 Lastly, security team would have an ability to apply its set of 805 policy rules, being the last policy to be evaluated against. 807 4.11. Requirement to detect and correct policy conflicts 809 Client-facing interface SHALL be able to detect policy "conflicts", 810 and SHALL specify methods on how to resolve these "conflicts" 812 For example: two clients issues conflicting set of security policies 813 to be applied to the same Policy Endpoint Group. 815 4.12. Requirement for backward compatibility 817 It MUST be possible to add new capabilities to client-facing 818 interface in a backward compatible fashion. 820 4.13. Requirement for Third-Party integration 822 The security policies in the security administrator's network may 823 require the use of specialty devices such as honeypots, behavioral 824 analytics, or SIEM in the network, and may also involve threat feeds, 825 virus signatures, and malicious file hashes as part of comprehensive 826 security policies. 828 The client-facing interface must allow the security administrator to 829 configure these threat sources and any other information to provide 830 integration and fold this into policy management. 832 4.14. Requirement to collect telemetry data 834 One of the most important aspect of security is to have visibility 835 into the networks. As threats become more sophisticated, the 836 security administrator must be able to gather different types of 837 telemetry data from various devices in the network. The collected 838 data could simply be logged or sent to security analysis engines for 839 behavioral analysis, policy violations, and for threat detection. 841 The client-facing interface MUST allow the security administrator to 842 collect various kinds of data from NSFs. The data source could be 843 syslog, flow records, policy violation records, and other available 844 data. 846 Detailed client-facing interface telemetry data should be available 847 between clients and security controllers. Clients should be able to 848 subscribe and receive these telemetry data. 850 client should be able to receive notifications when a policy is 851 dynamically updated. 853 5. Operational Requirements for the Client-Facing Interface 855 5.1. API Versioning 857 The client-facing interface must support a version number for each 858 RESTful API. This is very important because the client application 859 and the controller application may most likely come from different 860 vendors. Even if the vendor is same, it is hard to imagine that two 861 different applications would be released in lock step. 863 Without API versioning, it is hard to debug and figure out issues if 864 application breaks. Although API versioning does not guarantee that 865 applications will always work, it helps in debugging if the problem 866 is caused by an API mismatch. 868 5.2. API Extensiblity 870 Abstraction and standardization of the client-facing interface is of 871 tremendous value to security administrators as it gives them the 872 flexibility of deploying any vendor's NSF without needing to redefine 873 their policies or change the client interface. However this might 874 also look like as an obstacle to innovation. 876 If a vendor comes up with new feature or functionality that can't be 877 expressed through the currently defined client-facing interface, 878 there must be a way to extend existing APIs or to create a new API 879 that is relevant for that NSF vendor only. 881 5.3. APIs and Data Model Transport 883 The APIs for client interface must be derived from the YANG based 884 data model. The YANG data model for client interface must capture 885 all the requirements as defined in this document to express a 886 security policy. The interface between a client and controller must 887 be reliable to ensure robust policy enforcement. One such transport 888 mechanism is RESTCONF that uses HTTP operations to provide necessary 889 CRUD operations for YANG data objects, but any other mechanism can be 890 used. 892 5.4. Notification 894 The client-facing interface must allow the security administrator to 895 collect various alarms and events from the NSF in the network. The 896 events and alarms may be either related to security policy 897 enforcement or NSF operation. The events and alarms could also be 898 used as a input to the security policy for autonomous handling. 900 5.5. Affinity 902 The client-facing interface must allow the security administrator to 903 pass any additional metadata that a user may want to provide for a 904 security policy e.g. certain security policy needs to be applied only 905 on linux machine or windows machine or that a security policy must be 906 applied on the device with Trusted Platform Module chip. 908 5.6. Test Interface 910 The client-facing interface must allow the security administrator the 911 ability to test the security policies before the policies are 912 actually applied e.g. a user may want to verify if a policy creates 913 potential conflicts with the existing policies or whether a certain 914 policy can be implemented. The test interface provides such 915 capabilities without actually applying the policies. 917 6. IANA Considerations 919 This document requires no IANA actions. RFC Editor: Please remove 920 this section before publication. 922 7. Acknowledgements 924 The authors would like to thank Adrian Farrel, Linda Dunbar and Diego 925 R.Lopez from IETF I2NSF WG for helpful discussions and advice. 927 The authors would also like to thank Kunal Modasiya, Prakash T. 928 Sehsadri and Srinivas Nimmagadda from Juniper networks for helpful 929 discussions. 931 8. Normative References 933 [I-D.ietf-i2nsf-problem-and-use-cases] 934 Hares, S., Dunbar, L., Lopez, D., Zarny, M., and C. 935 Jacquenet, "I2NSF Problem Statement and Use cases", draft- 936 ietf-i2nsf-problem-and-use-cases-02 (work in progress), 937 October 2016. 939 Authors' Addresses 941 Rakesh Kumar 942 Juniper Networks 943 1133 Innovation Way 944 Sunnyvale, CA 94089 945 US 947 Email: rkkumar@juniper.net 949 Anil Lohiya 950 Juniper Networks 951 1133 Innovation Way 952 Sunnyvale, CA 94089 953 US 955 Email: alohiya@juniper.net 956 Dave Qi 957 Bloomberg 958 731 Lexington Avenue 959 New York, NY 10022 960 US 962 Email: DQI@bloomberg.net 964 Nabil Bitar 965 Nokia 966 755 Ravendale Drive 967 Mountain View, CA 94043 968 US 970 Email: nabil.bitar@nokia.com 972 Senad Palislamovic 973 Nokia 974 755 Ravendale Drive 975 Mountain View, CA 94043 976 US 978 Email: senad.palislamovic@nokia.com 980 Liang Xia 981 Huawei 982 101 Software Avenue 983 Nanjing, Jiangsu 210012 984 China 986 Email: Frank.Xialiang@huawei.com