idnits 2.17.1 draft-ietf-i2nsf-client-facing-interface-req-04.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 abstract seems to contain references ([I-D.ietf-i2nsf-framework]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 494: '... RECOMMENDED category. If an implem...' RFC 2119 keyword, line 524: '... We classify this requirement in MUST...' RFC 2119 keyword, line 546: '... requirement in RECOMMENDED category ...' RFC 2119 keyword, line 562: '...rement is highly RECOMMENDED since it ...' RFC 2119 keyword, line 580: '...der this to be a MUST requirement but ...' (18 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 16, 2018) is 2292 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6749' is mentioned on line 530, but not defined 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 Lilac Cloud 4 Intended status: Informational A. Lohiya 5 Expires: July 20, 2018 Juniper Networks 6 D. Qi 7 Bloomberg 8 N. Bitar 9 S. Palislamovic 10 Nokia 11 L. Xia 12 Huawei 13 January 16, 2018 15 Requirements for Client-Facing Interface to Security Controller 16 draft-ietf-i2nsf-client-facing-interface-req-04 18 Abstract 20 This document captures requirements for Client-Facing interface to 21 the Security Controller as defined by [I-D.ietf-i2nsf-framework]. 22 The interface is expressed using objects and constructs understood by 23 Security Admin as opposed to vendor or device specific expressions 24 associated with individual product and feature. This document 25 identifies a broad set of requirements needed to express Security 26 Policies based on User-constructs which are well understood by the 27 User Community. This gives ability to decouple policy definition 28 from policy enforcement on a specific security functional element, be 29 it a physical or virtual. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on July 20, 2018. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Conventions Used in this Document . . . . . . . . . . . . . . 4 67 3. Guiding principle for Client-Facing Interface definition . . 5 68 3.1. User-construct based modeling . . . . . . . . . . . . . . 5 69 3.2. Basic rules for Client-Facing Interface definition . . . 6 70 3.3. Deployment Models for Implementing Security Policies . . 7 71 4. Functional Requirements for the Client-Facing Interface . . . 10 72 4.1. Requirement for Multi-Tenancy in Client-Facing interface 11 73 4.2. Requirement for Authentication and Authorization of 74 Client-Facing interface . . . . . . . . . . . . . . . . . 12 75 4.3. Requirement for Role-Based Access Control (RBAC) in 76 Client-Facing interface . . . . . . . . . . . . . . . . . 12 77 4.4. Requirement to protect Client-Facing interface from 78 attacks . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 4.5. Requirement to protect Client-Facing interface from 80 misconfiguration . . . . . . . . . . . . . . . . . . . . 13 81 4.6. Requirement to manage policy lifecycle with rich set of 82 controls . . . . . . . . . . . . . . . . . . . . . . . . 13 83 4.7. Requirement to define dynamic Policy Endpoint Group . . . 14 84 4.8. Requirement to express rich set of Policy Rules . . . . . 16 85 4.9. Requirement to express rich set of Policy Actions . . . . 17 86 4.10. Requirement for consistent policy enforcement . . . . . . 19 87 4.11. Requirement to detect and correct policy conflicts . . . 19 88 4.12. Requirement for backward compatibility . . . . . . . . . 19 89 4.13. Requirement for Third-Party integration . . . . . . . . . 20 90 4.14. Requirement to collect telemetry data . . . . . . . . . . 20 91 5. Operational Requirements for the Client-Facing Interface . . 20 92 5.1. API Versioning . . . . . . . . . . . . . . . . . . . . . 20 93 5.2. API Extensibility . . . . . . . . . . . . . . . . . . . . 21 94 5.3. APIs and Data Model Transport . . . . . . . . . . . . . . 21 95 5.4. Notification and Monitoring . . . . . . . . . . . . . . . 21 96 5.5. Affinity . . . . . . . . . . . . . . . . . . . . . . . . 21 97 5.6. Test Interface . . . . . . . . . . . . . . . . . . . . . 21 98 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 99 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 100 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 101 9. Normative References . . . . . . . . . . . . . . . . . . . . 22 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 104 1. Introduction 106 Programming security policies in a network has been a fairly complex 107 task that often requires deep knowledge of vendor specific devices 108 and features. This has been the biggest challenge for both Service 109 Providers and Enterprises, henceforth named as Security Admins in 110 this document. This challenge is further amplified due to network 111 virtualization with security functions deployed in physical and 112 virtual form factors, henceforth named as network security function 113 (NSF) in this document, from multiple vendors with proprietary 114 interfaces. 116 Even if Security Admin deploys a single vendor solution with one or 117 more security appliances across its entire network, it is still very 118 difficult to manage Security Policies that requires mapping of 119 business needs to complex security features with vendor specific 120 configurations. The Security Admin may use vendor provided 121 management systems to provision and manage Security Policies. But, 122 the single vendor approach is highly restrictive in today's network 123 for following reasons: 125 o An organization may not be able to rely on a single vendor because 126 the changing security requirements may not align with vendor's 127 release cycle. 129 o A large organization may have a presence across different sites 130 and regions; which means, it may not be possible to deploy same 131 solution from the same vendor because of regional regulatory and 132 compliance policy. 134 o If and when an organization migrates from one vendor to another, 135 it is almost impossible to migrate Security Policies from one 136 vendor to another without complex and time consuming manual 137 workflows. 139 o An organization may deploy multiple security functions in either 140 virtual or physical form to attain the flexibility, elasticity, 141 performance scale and operational efficiency they require. 142 Practically, that often requires different sources (vendor, open 143 source) to get the best of breed for a given security function. 145 o An organization may choose all or part of their assets such as 146 routers, switches, firewalls, and overlay-networks as policy 147 enforcement points for operational and cost efficiency. It would 148 be highly complex to manage policy enforcement with different tool 149 set for each type of device. 151 In order to facilitate deployment of Security Policies across 152 different vendor provided NSFs, the Interface to Network Security 153 Functions (I2NSF) working group in the IETF is defining a Client- 154 Facing interface to Security Controller [I-D. ietf-i2nsf-framework] 155 [I-D. ietf-i2nsf-terminology]. Deployment facilitation should be 156 agnostic to the type of device, be it physical or virtual, or type of 157 enforcement point. Using these interfaces, it becomes possible to 158 write different kinds of security management applications (e.g. GUI 159 portal, template engine, etc.) allowing Security Admin to express 160 Security Policy in an abstract form with choice of wide variety of 161 NSF as policy enforcement point. The implementation of security 162 management applications or controller is out of scope for I2NSF 163 working group. 165 This document captures the requirements for Client-Facing interface 166 that can be easily used by Security Admin without a need for 167 expertise in vendor and device specific feature set. We refer to 168 this as "User-construct" based interfaces. To further clarify, in 169 the scope of this document, the "User-construct" here does not mean 170 some free-from natural language input or an abstract intent such as 171 "I want my traffic secure" or "I don't want DDoS attacks in my 172 network"; rather the User-construct here means that Security Policies 173 are described using expressions such as application names, 174 application groups, device groups, user groups etc. with a vocabulary 175 of verbs (e.g., drop, tap, throttle), prepositions, conjunctions, 176 conditionals, adjectives, and nouns instead of using standard 177 n-tuples from the packet header. 179 2. Conventions Used in this Document 181 BSS: Business Support System 183 CLI: Command Line Interface 185 CMDB: Configuration Management Database 187 Controller: Used interchangeably with Security Controller or 188 management system throughout this document 190 CRUD: Create, Retrieve, Update, Delete 192 FW: Firewall 193 GUI: Graphical User Interface 195 IDS: Intrusion Detection System 197 IPS: Intrusion Protection System 199 LDAP: Lightweight Directory Access Protocol 201 NSF: Network Security Function, defined by 202 [I-D.ietf-i2nsf-problem-and-use-cases] 204 OSS: Operation Support System 206 RBAC: Role Based Access Control 208 SIEM: Security Information and Event Management 210 URL: Universal Resource Locator 212 vNSF: Refers to NSF being instantiated on Virtual Machines 214 3. Guiding principle for Client-Facing Interface definition 216 Client-Facing Interface must ensure that a Security Admin can deploy 217 a NSF from any vendor and should still be able to use the same 218 consistent interface. In essence, this interface allows a Security 219 Admin to express a Security Policy enforced on the NSF to be 220 independent of vendor and its implementation. Henceforth, in this 221 document, we use "security policy management interface" 222 interchangeably when we refer to Client-Facing interface. 224 3.1. User-construct based modeling 226 Traditionally, Security Policies have been expressed using vendor 227 proprietary interface. The interface is defined by a vendor based on 228 proprietary command line text or a GUI based system with 229 implementation specific constructs such IP address, protocol and 230 L4-L7 information. This requires Security Admin to translate their 231 business objectives into vendor provided constructs in order to 232 express a Security Policy. But, this alone is not sufficient to 233 render a policy in the network; the admin must also understand 234 network and application design to locate a specific policy 235 enforcement point to make sure policy is effective. To further 236 complicate the matters, when changes happen in the network topology, 237 the Security Policy may require modifications accordingly. This may 238 be a highly manual task based on network design and becomes 239 unmanageable in virtualized environment. 241 The User-construct based framework does not rely on lower level 242 semantics due to problem explained above, but rather uses higher 243 level constructs such as User-group, Application-group, Device-group, 244 Location-group, etcetera. A Security Admin would use these 245 constructs to express a security policy instead of proprietary 246 implementation or feature specific constructs. The policy defined in 247 such a manner is referred to User-construct based policies in this 248 draft. The idea is to enable Security Admin to use constructs they 249 understand best in expressing Security Policies which simplify their 250 tasks and help avoiding human errors in complex security 251 provisioning. 253 3.2. Basic rules for Client-Facing Interface definition 255 The basic rules in defining the Client-Facing interfaces are as 256 follows: 258 o Not dependent on a particular network topology or the NSF location 259 in the network 261 o Not forced to express Security Policy with proprietary vendor 262 specific interfaces for a given NSFa€ 264 o Independent of NSF type that will implement a specific Security 265 Policy; e.g., the interface remains same no matter if a specific 266 Security Policy is enforced on a stateful firewall,IDP, IDS, 267 Router or a Switch 269 o Declarative/Descriptive model instead of Imperative/Prescriptive 270 model - What security policy need to be expressed (declarative) 271 instead of how it is implemented (imperative) 273 o Not dependent on vendor's' implementation or form-factor 274 (physical, virtual) of the NSF 276 o Not dependent on how a NSF becomes operational - network 277 connectivity and other hosting requirements. 279 o Not dependent on NSF control plane implementation (if there is 280 one), e.g., cluster of NSFs active as one unified service for 281 scale and/ or resilience. 283 o Not depending on specific data plane implementation of NSF, e.g. 284 encapsulation, service function chains. 286 Note that the rules stated above only apply to the Client-Facing 287 interface, which a Security Admin would use to express a high level 288 policy. These rules do not apply to the lower layers, e.g., Security 289 Controller that convert higher level policies into lower level 290 constructs. The lower layers may still need some intelligence such 291 as topology awareness, capability of the NSF and its functions, 292 supported encapsulations etc., to convert and apply the policies 293 accurately on the NSF. 295 3.3. Deployment Models for Implementing Security Policies 297 Traditionally, medium and large Enterprises deploy vendor provided 298 management systems to create Security Policies and any changes to 299 these Security Policies are made manually over time by Security 300 Admin. This approach may not be suitable and nor sufficient for 301 modern highly automated data centers that are largely virtualized and 302 rely on various management systems and controllers to implement 303 dynamic Security Policies over large number of NSF in the network. 305 There are two distinct deployment models for Security Controller. 306 Although, these have no direct impact on the Client-Facing interface, 307 but illustrate the overall Security Policy management framework in an 308 organization and how the Client-Facing interface remain same which is 309 the main objective of this document. These models are: 311 a. Policy management without an explicit management system for 312 control of NSFs. In this deployment, Security Controller acts as 313 a NSF management system; it takes information passed over Client- 314 Facing interface and translates into data on I2NSF NSF-facing 315 interface. The NSF-Facing interface is implemented by NSF 316 vendors; this would usually be done by having an I2NSF agent 317 embedded in the NSF. This deployment model is shown in Figure 1. 319 RESTful API 320 SUPA or I2NSF Policy Management 321 ^ 322 | 323 Client-Facing Interface | 324 (Independent of individual | 325 NSFs, devices, and vendors) | 326 | 327 ------------------------------ 328 | | 329 | Security Controller | 330 | | 331 ------------------------------ 332 | ^ 333 | I2NSF | 334 NSF Interface | NSF-facing | 335 (Specific to NSFs) | Interface | 336 .............................. 337 | | 338 v | 340 ------------- ------------- 341 | I2NSF Agent | | I2NSF Agent | 342 |-------------| |-------------| 343 | |---| | 344 | NSF | | NSF | 345 NSFs | | | | 346 (virtual -------------\ /------------- 347 and | \ / | 348 physical) | X | 349 | / \ | 350 -------------/ \------------- 351 | I2NSF Agent | | I2NSF Agent | 352 |-------------| |-------------| 353 | |---| | 354 | NSF | | NSF | 355 | | | | 356 ------------- ------------- 358 Figure 1: Deployment without Management System 360 b. Policy management with an explicit management system for control 361 of NSFs. This model is similar to the model above except that 362 Security Controller interacts with a vendor's dedicated 363 management system that proxy I2NSF NSF-Facing interfaces as NSF 364 may not support NSF-Facing interface. This is a useful model to 365 support legacy NSF. This deployment model is shown in Figure 2. 367 RESTful API 368 SUPA or I2NSF Policy Management 369 ^ 370 | 371 Client-facing Interface | 372 (Independent of individual | 373 NSFs, devices, and vendors) | 374 | 375 ------------------------------ 376 | | 377 | Security Controller | 378 | | 379 ------------------------------ 380 | ^ 381 | I2NSF | 382 NSF Interface | NSF-facing | 383 (Specific to NSFs) | Interface | 384 .............................. 385 | | 386 v | 387 ------------------------------ 388 | | 389 | I2NSF Proxy Agent / | 390 | Management System | 391 | | 392 ------------------------------ 393 | ^ 394 | Proprietary | 395 | Functional | 396 | Interface | 397 .............................. 398 | | 399 v | 401 ------------- ------------- 402 | |---| | 403 | NSF | | NSF | 404 NSFs | | | | 405 (virtual -------------\ /------------- 406 and | \ / | 407 physical) | X | 408 | / \ | 409 -------------/ \------------- 410 | |---| | 411 | NSF | | NSF | 412 | | | | 413 ------------- ------------- 415 Figure 2: Deployment with Management System or I2NSF Proxy Agent 417 As mentioned above, these models discussed here don't affect the 418 definition of Client-Facing interface, they do give an overall 419 context for defining a Security Policy interface based on 420 abstraction. This can help in implementing a Security Controller. 422 4. Functional Requirements for the Client-Facing Interface 424 As stated in the guiding principle for defining the I2NSF Client- 425 Facing interface, the Security Policies and the Client-Facing 426 interface shall be defined from Security Admin's perspective and 427 abstracted away from type of NSF, NSF specific implementation, 428 controller implementation, network topology, controller NSF-Facing 429 interface. Thus, the Security Policy definition shall be 430 declarative, expressed using User-construct, and driven by how 431 Security Admin view Security Policies from their business needs and 432 objectives. 434 Security Controller's' implementation is outside the scope of this 435 document and the I2NSF working group. 437 In order to express and build security policies, high level 438 requirement for Client-Facing interface is as follows: 440 o Multi-Tenancy 442 o Authentication and Authorization 444 o Role-Based Access Control (RBAC) 446 o Protection from Attacks 448 o Protection from Misconfiguration 450 o Policy Lifecycle Management 452 o Dynamic Policy Endpoint Groups 454 o Policy Rules 456 o Policy Actions 457 o Generic Policy Model 459 o Policy Conflict Resolution 461 o Backward Compatibility 463 o Third-Party Integration 465 o Telemetry Data 467 The above requirements are by no means a complete list and may not be 468 sufficient or required for all use-cases, but should be a good 469 starting point for a wide variety of use-cases in Service Provider 470 and Enterprise networks. 472 A specific implementation may not support all these requirements but 473 in order to define a base set of requirements which would works for 474 most use-cases, this document will make an attempt to classify these 475 requirements in three categories: 477 MUST: This means, the requirement must be supported by Client-Facing 478 interface. 480 RECOMMENDED: This means, we recommend that Client-Facing interface 481 support this requirement since it might be applicable to large 482 number of use-cases but some vendor may choose to omit if their 483 focus is only certain market segments. 485 MAY: This means, the requirement is not mandatory for Client-Facing 486 interface but may be needed for specific use-cases. 488 4.1. Requirement for Multi-Tenancy in Client-Facing interface 490 An organization may have internal tenants and might want a framework 491 wherein each tenant manages its own Security Policies with isolation 492 from other tenants. This requirement may be applicable to Service 493 Providers and Large Enterprises so we classify this requirement in 494 RECOMMENDED category. If an implement does not support this 495 requirement, it must support a default implicit tenant created by 496 Security Controller that owns all the Security Policies. 498 A Security Admin may be a Cloud Service Provider with multi-tenant 499 deployment, where each tenant is a different customer. Each tenant 500 or customer must be able to manage its own Security Policies without 501 affecting other tenants. 503 It should be noted that tenants may have their own tenants, so a 504 recursive relation may exist. For instance, a tenant in a Cloud 505 Service Provider may have multiple departments or organizations that 506 need to manage their own security rules for compliance. 508 The following objects are needed to fulfill this requirement: 510 Policy-Tenant: An entity that owns and manages Security Policies 511 applied to its own asset and resources. 513 Policy-Administrator: A user authorized to manage the security 514 policies for a Policy-Tenant. 516 Policy-User: A user within a Policy-Tenant who is authorized to 517 access certain resources of that tenant according to the 518 privileges assigned to it. 520 4.2. Requirement for Authentication and Authorization of Client-Facing 521 interface 523 A Security Admin must be authenticated and authorized in order to 524 manage Security Policies. We classify this requirement in MUST 525 category since without proper authentication and authorization, the 526 security posture of entire organization can be easily compromised. 528 There must be methods defined for Policy-Administrator to be 529 authenticated and authorized to use Security Controller. There are 530 several authentication methods available such as OAuth [RFC6749], 531 XAuth and X.509 certificate based; the authentication may be mutual 532 or single-sided based on business needs and outside the scope of 533 I2NSF. In addition, there must be a method o authorize the Policy- 534 Administrator to perform certain action. It should be noted that, 535 Policy-Administrator authentication and authorization to perform 536 actions could be part of Security Controller or outside; this 537 document does not mandate any specific implementation but requires 538 that such a scheme must be implemented. 540 4.3. Requirement for Role-Based Access Control (RBAC) in Client-Facing 541 interface 543 A tenant in organization may have multiple users with each user given 544 certain privileges. Some user such as "Admin" may have all the 545 permission but other may have limited permissions. We classify this 546 requirement in RECOMMENDED category since it aligns with Multi- 547 Tenancy requirement. If this requirement is not supported, a default 548 privilege must be assigned to all the users. 550 The following objects are needed to fulfill this requirement: 552 Policy-Authorization-Role: Defines the permissions assigned to a 553 user such as creating and managing policies on specified 554 resources. A user may not be allowed to change existing policies 555 but only view them. 557 4.4. Requirement to protect Client-Facing interface from attacks 559 The interface must be protections against attacks from malicious 560 clients or a client impersonator. Potential attacks could come from 561 Botnets, hosts infected with virus or some unauthorized entities. 562 This requirement is highly RECOMMENDED since it may not be needed if 563 the entire framework is deployed in very controlled environment. But 564 if needed, we recommend that Security Controller uses a out-of-band 565 communication channel for Client-Facing interface. In addition,it is 566 also recommended that traffic Client-Facing interface communication 567 be encrypted; furthermore, some straightforward traffic/session 568 control mechanisms (i.e., Rate-limit, ACL, White/Black list) can be 569 employed on Security Controller to defend against DDoS flooding 570 attacks. 572 4.5. Requirement to protect Client-Facing interface from 573 misconfiguration 575 There must be protections from mis-configured clients. System and 576 policy parameters validations should be implemented to detect this. 577 Validation may be based on a set of default parameters or custom 578 tuned thresholds such as the number of policy changes submitted, 579 number of objects requested in a given time interval, etc. We 580 consider this to be a MUST requirement but implementation aspects 581 would depend upon each individual API communication. 583 4.6. Requirement to manage policy lifecycle with rich set of controls 585 In order to provide more sophisticated security framework, there 586 should be a mechanism so that a policy becomes dynamically active/ 587 enforced or inactive based on multiple different criteria such as 588 Security Admin's manual intervention or some external event. We 589 consider requirement listed here to be a MUST for wide variety of 590 use-cases. 592 One example of dynamic policy management is when Security Admin pre- 593 configures all the security policies, but the policies get activated 594 or deactivated based on dynamic threat detection. Basically, a 595 threat event may activate certain inactive policies, and once a new 596 event indicates that the threat has gone away, the policies become 597 inactive again. 599 There are following ways for dynamically activating policies: 601 o The policy may be activated by Security Admin manually using a 602 client interface such as GUI or CLI. 604 o The policy may be dynamically activated by Security Controller upon 605 detecting an external event or an event from I2NSF monitoring 606 interface 608 o The policy can be configured but gets activated or deactivated upon 609 specified timing calendar with Security Policy definition. 611 Client-Facing interface should support the following policy 612 attributes for policy enforcement: 614 Admin-Enforced: A policy, once configured, remains active/enforced 615 until removed by Security Admin. 617 Time-Enforced: A policy configuration specifies the time profile 618 that determines when the policy is to be activated/enforced. 619 Otherwise, it is de-activated. 621 Event-Enforced: A policy configuration specifies the event profile 622 that determines when the policy is to be activated/enforced. It 623 also specifies the duration attribute of that policy once 624 activated based on event. For instance, if the policy is 625 activated upon detecting an application flow, the policy could be 626 de-activated when the corresponding session is closed or the flow 627 becomes inactive for certain time. 629 A policy could be a composite policy, that is composed of many rules, 630 and subject to updates and modification. For the policy maintenance, 631 enforcement, and audit-ability purposes, it becomes important to name 632 and version Security Policy. Thus, the policy definition SHALL 633 support policy naming and versioning. In addition, the i2NSF Client- 634 Facing interface SHALL support the activation, deactivation, 635 programmability, and deletion of policies based on name and version. 636 In addition, it should support reporting operational state of 637 policies by name and version. For instance, a Security Admin may 638 probe Security Controller whether a Security Policy is enforced for a 639 tenant and/or a sub-tenant (organization) for audit-ability or 640 verification purposes. 642 4.7. Requirement to define dynamic Policy Endpoint Group 644 When Security Admin configures a Security Policy, it may have 645 requirement to apply this policy to certain subsets of the network. 646 The subsets may be identified based on criteria such as Users, 647 Devices, and Applications. We refer to such a subset of the network 648 as a "Policy Endpoint Group". This requirement is the fundamental 649 building block of Client-Facing interface; so making it a MUST 650 requirement. But object defined here may not support all use-cases 651 and may not be required by everyone so it is left up to vendor 652 whether all or partial set of these object is supported. 654 One of the biggest challenges for a Security Admin is how to make 655 sure that a Security Policy remain effective while constant changes 656 are happening to the "Policy Endpoint Group" for various reasons 657 (e.g., organizational, network and application changes). If a policy 658 is created based on static information such as user names, 659 application, or network subnets; then every time this static 660 information change, policies need to be updated. For example, if a 661 policy is created that allows access to an application only from the 662 group of Human Resource users (HR-users group), then each time the 663 HR-users group changes, the policy needs to be updated. 665 We call these dynamic Policy Endpoint Groups "Metadata Driven 666 Groups". The metadata is a tag associated with endpoint information 667 such as User, Application, or Device. The mapping from metadata to 668 dynamic content could come from a standards-based or proprietary 669 tools. Security Controller could use any available mechanisms to 670 derive this mapping and to make automatic updates to policy content 671 if the mapping information changes. The system SHOULD allow for 672 multiple, or sets of tags to be applied to a single endpoint. 674 Client-Facing interface must support Endpoint Groups as a target for 675 a Security Policy. The following metadata driven groups MAY be used 676 for configuring Security Polices: 678 User-Group: This group identifies a set of users based on a tag or 679 static information such as user-names. The tag identifying users, 680 is dynamically derived from systems such as Active Directory or 681 LDAP. For example, an organization may have different User- 682 groups,such as HR-users, Finance-users, Engineering-users, to 683 classify a set of users in each department. 685 Device-Group: This group identifies a set of devices based on a tag 686 or device information. The tag identifying the devices, is 687 dynamically derived from systems such as configuration management 688 database (CMDB). For example, a Security Admin may want to 689 classify all machines running a particular operating system into 690 one group and machines running a different operating system into 691 another group. 693 Application-Group: This group identifies a set of applications based 694 on a tag or on application names. The tag identifying 695 applications, is dynamically derived from systems such as CMDB. 696 For example, a Security Admin may want to classify all 697 applications running in the Legal department into one group and 698 all applications running in the HR department into another group. 699 In some cases, the application can semantically associated with a 700 VM or a device. However, in other cases, the application may need 701 to be associated with a set of identifiers (e.g., transport 702 numbers, signature in the application packet payload) that 703 identify the application in the corresponding packets. The 704 mapping of application names/tags to signatures in the associated 705 application packets should be defined and communicated to the NSF. 706 The Client-Facing Interface shall support the communication of 707 this information. 709 Location-Group: This group identifies a set of locations. Tag may 710 correspond 1:1 to location. The tag identifying locations is 711 either statically defined or dynamically derived from systems such 712 as CMDB. For example, a Security Admin may want to classify all 713 sites/locations in a geographic region as one group. 715 4.8. Requirement to express rich set of Policy Rules 717 The Policy Rules is a central component of any Security Policy but 718 rule requirements may vary based on use-cases and it is hard to 719 define a complete set that works for everyone. In order to build a 720 rich interface, we are going to take a different approach; we will 721 define the building block of rules and let Security Admin build rules 722 using these construct so that Security Policies meet their 723 requirements: 725 Segmentation policies : This set of policies create rules for 726 communication between two Endpoint Groups. An organization may 727 restrict certain communication between a set of user and 728 applications for example. The segmentation policy may be a micro- 729 segmentation rule between components of complex applications or 730 related to hybrid cloud deployment based on location. 732 Threat policies: This set of policies creates rules to prevent 733 communication with externally or internally identified threats. 734 The threats may be well knows such as threat feeds from external 735 sources or dynamically identified by using specialty devices in 736 the network. 738 Governance and Compliance policies: This set of policies creates 739 rules to implement business requirement such as controlling access 740 to internal or external resources for meeting regulatory 741 compliance or business objectives. 743 In order to build a generic rule engine to satisfy diverse set of 744 Policy Rules, we propose following objects: 746 In order to build a generic rule engine to satisfy diverse set of 747 Policy Rules, we propose following objects: 749 Source Policy Endpoint Group: A source target of the Policy Rule. 750 This may be special object "ALL" if all groups meet this criteria. 752 Destination Policy Endpoint Group: A destination target of the 753 Policy Rule. This may be a special object "ALL", if all groups 754 meet this criteria. 756 Direction: By default rules are applied in either direction but this 757 object can be used to make rule definition uni-directional. 759 Threat Group: An object that represents a set of static or dynamic 760 threats such as Botnet, GeoIP, URL feeds or virus and malware 761 signatures detected dynamically. This object can be used as 762 source or destination target in a rule. 764 Match Condition: An object that represents a set of allowed 765 interactions. It could be as simple as group of application names 766 or L4 ports allowed between two Endpoint Groups. It could very 767 well that all traffic is allowed between two groups. 769 Exceptions: In order to truly build rules which are Security Admin 770 and built with user semantics, we should allow to specify 771 exceptions to the match criteria. This will greatly simplify 772 Security Admin's task. E.g., we could build a rule that allows 773 all traffic between two groups except a particular application or 774 threat source. 776 Actions: Action is what makes rule and Policy work. The Action is 777 defined in details in next section. We RECOMMEND that there be a 778 one-to-one mapping between rule and action otherwise if multiple 779 rules are associated with one action, it may be a difficult to 780 manage Security Policy lifecycle as they evolve. 782 4.9. Requirement to express rich set of Policy Actions 784 Security Admin must be able to configure a variety of actions for a 785 given Policy Rule. Typically, Security Policy specifies a simple 786 action of "deny" or "permit" if a particular condition is matched. 787 Although this may be enough for most use-cases, the I2NSF Client- 788 Facing interface must provide a more comprehensive set of actions so 789 that the interface can be used effectively across various security 790 needs. 792 Policy action MUST be extensible so that additional policy action 793 specifications can easily be added. 795 The following list of actions SHALL be supported: 797 Permit: This action means continue processing the next rule or allow 798 the packet to pass if this is the last rule. This is often a 799 default action. 801 Deny: This action means stop further packet processing and drop the 802 packet. 804 Drop connection: This action means stop further packet processing, 805 drop the packet, and drop connection (for example, by sending a 806 TCP reset). 808 Log: This action means create a log entry whenever a rule is 809 matched. 811 Authenticate connection: This action means that whenever a new 812 connection is established it should be authenticated. 814 Quarantine/Redirect: This action is useful for threat remediation 815 purposes. If a security breach or infection point is detected, a 816 Security Admin would like to isolate for purpose of remediation or 817 controlling attack surface. 819 Netflow: This action creates a Netflow record; Need to define 820 Netflow server or local file and version of Netflow. 822 Count: This action counts the packets that meet the rule condition. 824 Encrypt: This action encrypts the packets on an identified flow. 825 The flow could be over an IPSEC tunnel, or TLS session for 826 instance. 828 Decrypt: This action decrypts the packets on an identified flow. 829 The flow could be over an IPSEC tunnel, or TLS session for 830 instance. 832 Throttle: This action defines shaping a flow or a group of flows 833 that match the rule condition to a designated traffic profile. 835 Mark: This action defines traffic that matches the rule condition by 836 a designated DSCP value and/or VLAN 802.1p Tag value. 838 Instantiate-NSF: This action instantiates an NSF with a predefined 839 profile. An NSF can be any of the FW, IPS, IDS, honeypot, or VPN, 840 etc. 842 The policy actions should support combination of terminating actions 843 and non-terminating actions. For example, Syslog and then Permit; 844 Count and then Redirect. 846 Policy actions SHALL support any L2, L3, L4-L7 policy actions. 848 4.10. Requirement for consistent policy enforcement 850 As proposed in this document that the Client-Facing interface MUST be 851 built using higher-level "User-Constructs" that are independent of 852 network design and implementations. In order to achieve this, it 853 becomes important that Security Controller functionality becomes more 854 complex that keep track of various objects that are used to express 855 Security Policies. The Security Controller MUST evaluate the 856 Security Policies whenever these objects and network topology change 857 to make sure that Security Policy is consistently enforced as 858 expressed. 860 Although this document does not specify how Security Controller 861 achieve this and any implementation challenges. It is assumed that 862 once Security Controller uses Client-Facing interface to accept 863 Security Policies; it would maintain the security posture as per the 864 Security Policies during all changes in network or Endpoints and 865 other building blocks of the framework. 867 An event must be logged by Security Controller when a Security Policy 868 is updated due to changes in it's building blocks such as Endpoint 869 Group contents or the Security Policy is moved from one enforcement 870 point to another because the Endpoint has moved in the network. This 871 may help in debugging and auditing for compliance reasons. The 872 Security Admin may optionally receive notifications if supported and 873 desired. 875 4.11. Requirement to detect and correct policy conflicts 877 Client-Facing interface SHALL be able to detect policy "conflicts", 878 and SHALL specify methods on how to resolve these "conflicts" 880 For example a newly expressed Security Policy could conflict with 881 existing Security Policies applied to a set of Policy Endpoint 882 Groups. This MUST be detected and Security Admin be allowed for 883 manual correction if needed. 885 4.12. Requirement for backward compatibility 887 It MUST be possible to add new capabilities to Client-Facing 888 interface in a backward compatible fashion. 890 4.13. Requirement for Third-Party integration 892 The security framework in a network may require the use of a 893 specialty device such as honeypot, behavioral analytic, or SIEM for 894 threat detection; the device may provide threat information such as 895 threat feeds, virus signatures, and malicious file hashes. 897 The Client-Facing interface must allow Security Admin to include 898 these devices under Security Controller's Client-Facing interface so 899 that a Security Policy could be expressed using information from such 900 devices; basically it allows ability to integrate third part devices 901 into the Security Policy framework. 903 4.14. Requirement to collect telemetry data 905 One of the most important aspect of security is to have visibility 906 into the network. As threats become more sophisticated, Security 907 Admin must be able to gather different types of telemetry data from 908 various NSFs in the network. The collected data could simply be 909 logged or sent to security analysis engines for behavioral analysis, 910 policy violations, and for threat detection. 912 The Client-Facing interface MUST allow Security Admin to collect 913 various kinds of data from NSFs. The data source could be syslog, 914 flow records, policy violation records, and other available data. 916 Client-Facing interface must provide a set of telemetry data 917 available to Security Admin from Security Controller. The Security 918 Admin should be able to subscribe and receive to this data set. 920 5. Operational Requirements for the Client-Facing Interface 922 5.1. API Versioning 924 Client-Facing interface must support a version number for each 925 RESTful API. This is important since Security Controller could be 926 deployed by using multiple componenets and different pieces may come 927 from different vendors; it is difficult to isolate and debug issues 928 without ablility to track each component's operational behavior. 929 Even if the vendor is same for all the components, it is hard to 930 imagine that all pieces would be released in lock step by the vendor. 932 Without API versioning, it is hard to debug and figure out issues 933 when deploying Security Controller and its components built overtime 934 across multiple release cycles. Although API versioning does not 935 guarantee that Security Controller would always work but it helps in 936 debugging if the problem is caused by an API mismatch. 938 5.2. API Extensibility 940 Abstraction and standardization of Client-Facing interface is of 941 tremendous value to Security Admins as it gives them the flexibility 942 of deploying any vendor's NSF without need to redefine their policies 943 if or when a NSF is changed. 945 If a vendor comes up with new feature or functionality that can't be 946 expressed through the currently defined Client-Facing interface, 947 there SHALL be a way to extend existing APIs or to create a new API 948 that addresses specific vendors's new NSF functionality. 950 5.3. APIs and Data Model Transport 952 The APIs for interface SHALL be derived from the YANG based data 953 model. The data model for Client-Facing interface must capture all 954 the requirements as defined in this document to express a Security 955 Policy. The interface between a client and controller must be 956 reliable to ensure robust policy enforcement. One such transport 957 mechanism is RESTCONF that uses HTTP operations to provide necessary 958 CRUD operations for YANG data objects, but any other mechanism can be 959 used. 961 5.4. Notification and Monitoring 963 Client-Facing interface must allow ability to collect various alarms, 964 events, statistics about enforcement and policy violations from NSFs 965 in the network. The events and alarms may be associated with a 966 specific policy or associated with operating conditions of a specific 967 NSF in general. The statistics may be a measure of potential 968 Security Policy violations or general data that reflect operational 969 behavior of a NSF. The events, alarms and statistics may also be 970 used as an input to automate Security Policy lifecycle management. 972 5.5. Affinity 974 Client-Facing interface must allow Security Admin to pass any 975 additional metadata that a user may want to provide with a Security 976 Policy e.g., if the policy needs to be enforced by a very highly 977 secure NSF with Trusted Platform Module (TPM) chip. Another example 978 would be, if a policy can not be enforced by a multi-tenant NSF. 979 This would Security Admin control on operating environment 981 5.6. Test Interface 983 Client-Facing interface must support ability to test a Security 984 Policy before it is enforced e.g., a user may want to verify whether 985 the policy creates any potential conflicts with existing policies or 986 if there are enough resources and capability to enforce this policy. 987 The test interface would provide a mechanism to Security Admin where 988 policies could be tested in the actual environment before 989 enforcement. 991 6. Security Considerations 993 Client-Facing interface to Security controller must be protected to 994 make sure that entire security posture is not compromised. This 995 draft mandates that interface must have proper authentication and 996 authorization control mechanisms to ward off malicious attacks. The 997 draft does not specify a particular mechanism as different 998 organization may have different needs based on their specific 999 deployment environment and moreover new methods may evolve to better 1000 suit contemporary requirements. 1002 Authentication and authorization alone may not be sufficient for 1003 Client-Facing interface; the interface API must be validated for 1004 proper input to guard against attacks. The type of checks and 1005 verification may be specific to each interface API, but a careful 1006 consideration must be made to ensure that Security Controller is not 1007 compromised. 1009 We recommend that all attack surface must be examined with careful 1010 consideration of the operating environment and available industry 1011 best practices must be used such as process and standards to protect 1012 security controller against malicious or inadvertent attacks. 1014 7. IANA Considerations 1016 This document requires no IANA actions. RFC Editor: Please remove 1017 this section before publication. 1019 8. Acknowledgements 1021 The authors would like to thank Adrian Farrel, Linda Dunbar and Diego 1022 R.Lopez from IETF I2NSF WG for helpful discussions and advice. 1024 The authors would also like to thank Kunal Modasiya, Prakash T. 1025 Sehsadri and Srinivas Nimmagadda from Juniper networks for helpful 1026 discussions. 1028 9. Normative References 1030 [I-D.ietf-i2nsf-framework] 1031 Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 1032 Kumar, "Framework for Interface to Network Security 1033 Functions", draft-ietf-i2nsf-framework-10 (work in 1034 progress), November 2017. 1036 [I-D.ietf-i2nsf-problem-and-use-cases] 1037 Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 1038 and J. Jeong, "I2NSF Problem Statement and Use cases", 1039 draft-ietf-i2nsf-problem-and-use-cases-16 (work in 1040 progress), May 2017. 1042 Authors' Addresses 1044 Rakesh Kumar 1045 Lilac Cloud 1046 14435 C Big Basin Way #104 1047 Saratoga, CA 95070 1048 US 1050 Email: rakeshkumarcloud@gmail.com 1052 Anil Lohiya 1053 Juniper Networks 1054 1133 Innovation Way 1055 Sunnyvale, CA 94089 1056 US 1058 Email: alohiya@juniper.net 1060 Dave Qi 1061 Bloomberg 1062 731 Lexington Avenue 1063 New York, NY 10022 1064 US 1066 Email: DQI@bloomberg.net 1068 Nabil Bitar 1069 Nokia 1070 755 Ravendale Drive 1071 Mountain View, CA 94043 1072 US 1074 Email: nabil.bitar@nokia.com 1075 Senad Palislamovic 1076 Nokia 1077 755 Ravendale Drive 1078 Mountain View, CA 94043 1079 US 1081 Email: senad.palislamovic@nokia.com 1083 Liang Xia 1084 Huawei 1085 101 Software Avenue 1086 Nanjing, Jiangsu 210012 1087 China 1089 Email: Frank.Xialiang@huawei.com