idnits 2.17.00 (12 Aug 2021) /tmp/idnits4304/draft-ietf-i2nsf-client-facing-interface-req-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8327]), 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 512: '...ify this requirement in MUST category....' RFC 2119 keyword, line 520: '... RECOMMENDED category. If an implem...' RFC 2119 keyword, line 550: '... We classify this requirement in MUST...' RFC 2119 keyword, line 572: '... requirement in RECOMMENDED category ...' RFC 2119 keyword, line 588: '...rement is highly RECOMMENDED since it ...' (19 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 27, 2018) is 1448 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6749' is mentioned on line 556, 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: November 28, 2018 Juniper Networks 6 D. Qi 7 Bloomberg 8 N. Bitar 9 S. Palislamovic 10 Nokia 11 L. Xia 12 Huawei 13 May 27, 2018 15 Requirements for Client-Facing Interface to Security Controller 16 draft-ietf-i2nsf-client-facing-interface-req-05 18 Abstract 20 This document captures requirements for Client-Facing interface to 21 the Security Controller as defined by [RFC8327]. The interface is 22 expressed using objects and constructs understood by Security Admin 23 as opposed to vendor or device specific expressions associated with 24 individual product and feature. This document identifies a broad set 25 of requirements needed to express Security Policies based on User- 26 constructs which are well understood by the User Community. This 27 gives ability to decouple policy definition from policy enforcement 28 on a specific security functional element, be it a physical or 29 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 November 28, 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 Unified Model for Various Network Types . 11 73 4.2. Requirement for Multi-Tenancy in Client-Facing Interface 12 74 4.3. Requirement for Authentication and Authorization of 75 Client-Facing Interface . . . . . . . . . . . . . . . . . 12 76 4.4. Requirement for Role-Based Access Control (RBAC) in 77 Client-Facing Interface . . . . . . . . . . . . . . . . . 13 78 4.5. Requirement to Protect Client-Facing Interface from 79 Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 4.6. Requirement to protect Client-Facing Interface from 81 Misconfiguration . . . . . . . . . . . . . . . . . . . . 13 82 4.7. Requirement to Manage Policy Lifecycle with Rich Set of 83 Controls . . . . . . . . . . . . . . . . . . . . . . . . 14 84 4.8. Requirement to Define Dynamic Policy Endpoint Group . . . 15 85 4.9. Requirement to Express Rich Set of Policy Rules . . . . . 17 86 4.10. Requirement to Express Rich Set of Policy Actions . . . . 18 87 4.11. Requirement for Consistent Policy Enforcement . . . . . . 19 88 4.12. Requirement to Detect and Correct Policy Conflicts . . . 20 89 4.13. Requirement for Backward Compatibility . . . . . . . . . 20 90 4.14. Requirement for Third-Party Integration . . . . . . . . . 20 91 4.15. Requirement to Collect Telemetry Data . . . . . . . . . . 20 92 5. Operational Requirements for the Client-Facing Interface . . 21 93 5.1. API Versioning . . . . . . . . . . . . . . . . . . . . . 21 94 5.2. API Extensibility . . . . . . . . . . . . . . . . . . . . 21 95 5.3. APIs and Data Model Transport . . . . . . . . . . . . . . 21 96 5.4. Notification and Monitoring . . . . . . . . . . . . . . . 22 97 5.5. Affinity . . . . . . . . . . . . . . . . . . . . . . . . 22 98 5.6. Test Interface . . . . . . . . . . . . . . . . . . . . . 22 99 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 100 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 101 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 102 9. Normative References . . . . . . . . . . . . . . . . . . . . 23 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 105 1. Introduction 107 Programming security policies in a network has been a fairly complex 108 task that often requires deep knowledge of vendor specific devices 109 and features. This has been the biggest challenge for both Service 110 Providers and Enterprises, henceforth named as Security Admins in 111 this document. This challenge is further amplified due to network 112 virtualization with security functions deployed in physical and 113 virtual form factors, henceforth named as network security function 114 (NSF) in this document, from multiple vendors with proprietary 115 interfaces. 117 Even if Security Admin deploys a single vendor solution with one or 118 more security appliances across its entire network, it is still very 119 difficult to manage Security Policies that requires mapping of 120 business needs to complex security features with vendor specific 121 configurations. The Security Admin may use vendor provided 122 management systems to provision and manage Security Policies. But, 123 the single vendor approach is highly restrictive in today's network 124 for following reasons: 126 o An organization may not be able to rely on a single vendor because 127 the changing security requirements may not align with vendor's 128 release cycle. 130 o A large organization may have a presence across different sites 131 and regions; which means, it may not be possible to deploy same 132 solution from the same vendor because of regional regulatory and 133 compliance policy. 135 o If and when an organization migrates from one vendor to another, 136 it is almost impossible to migrate Security Policies from one 137 vendor to another without complex and time consuming manual 138 workflows. 140 o An organization may deploy multiple security functions in either 141 virtual or physical form to attain the flexibility, elasticity, 142 performance scale and operational efficiency they require. 144 Practically, that often requires different sources (vendor, open 145 source) to get the best of breed for a given security function. 147 o An organization may choose all or part of their assets such as 148 routers, switches, firewalls, and overlay-networks as policy 149 enforcement points for operational and cost efficiency. It would 150 be highly complex to manage policy enforcement with different tool 151 set for each type of device. 153 In order to facilitate deployment of Security Policies across 154 different vendor provided NSFs, the Interface to Network Security 155 Functions (I2NSF) working group in the IETF is defining a Client- 156 Facing interface to Security Controller [RFC8327] [I-D.ietf-i2nsf- 157 terminology]. Deployment facilitation should be agnostic to the type 158 of device, be it physical or virtual, or type of enforcement point. 159 Using these interfaces, it becomes possible to write different kinds 160 of security management applications (e.g. GUI portal, template 161 engine, etc.) allowing Security Admin to express Security Policy in 162 an abstract form with choice of wide variety of NSF as policy 163 enforcement point. The implementation of security management 164 applications or controller is out of scope for I2NSF working group. 166 This document captures the requirements for Client-Facing interface 167 that can be easily used by Security Admin without a need for 168 expertise in vendor and device specific feature set. We refer to 169 this as "User-construct" based interfaces. To further clarify, in 170 the scope of this document, the "User-construct" here does not mean 171 some free-from natural language input or an abstract intent such as 172 "I want my traffic secure" or "I don't want DDoS attacks in my 173 network"; rather the User-construct here means that Security Policies 174 are described using expressions such as application names, 175 application groups, device groups, user groups etc. with a vocabulary 176 of verbs (e.g., drop, tap, throttle), prepositions, conjunctions, 177 conditionals, adjectives, and nouns instead of using standard 178 n-tuples from the packet header. 180 2. Conventions Used in This Document 182 BSS: Business Support System 184 CLI: Command Line Interface 186 CMDB: Configuration Management Database 188 Controller: Used interchangeably with Security Controller or 189 management system throughout this document 191 CRUD: Create, Retrieve, Update, Delete 192 FW: Firewall 194 GUI: Graphical User Interface 196 IDS: Intrusion Detection System 198 IPS: Intrusion Protection System 200 LDAP: Lightweight Directory Access Protocol 202 NSF: Network Security Function, defined by [RFC8192] 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 VPN: Virtual Private Network 216 3. Guiding Principle for Client-Facing Interface Definition 218 Client-Facing Interface must ensure that a Security Admin can deploy 219 a NSF from any vendor and should still be able to use the same 220 consistent interface. In essence, this interface allows a Security 221 Admin to express a Security Policy enforced on the NSFs to be 222 independent of vendor and its implementation. Henceforth, in this 223 document, we use "security policy management interface" 224 interchangeably when we refer to Client-Facing interface. 226 3.1. User-construct Based Modeling 228 Traditionally, Security Policies have been expressed using vendor 229 proprietary interface. The interface is defined by a vendor based on 230 proprietary command line text or a GUI based system with 231 implementation specific constructs such IP address, protocol and 232 L4-L7 information. This requires Security Admin to translate their 233 business objectives into vendor provided constructs in order to 234 express a Security Policy. But, this alone is not sufficient to 235 render a policy in the network; the admin must also understand 236 network and application design to locate a specific policy 237 enforcement point to make sure policy is effective. To further 238 complicate the matters, when changes happen in the network topology, 239 the Security Policy may require modifications accordingly. This may 240 be a highly manual task based on network design and becomes 241 unmanageable in virtualized environment. 243 The User-construct based framework does not rely on lower level 244 semantics due to problem explained above, but rather uses higher 245 level constructs such as User-group, Application-group, Device-group, 246 Location-group, etcetera. A Security Admin would use these 247 constructs to express a security policy instead of proprietary 248 implementation or feature specific constructs. The policy defined in 249 such a manner is referred to User-construct based policies in this 250 draft. The idea is to enable Security Admin to use constructs they 251 understand best in expressing Security Policies which simplify their 252 tasks and help avoiding human errors in complex security 253 provisioning. 255 3.2. Basic Rules for Client-Facing Interface Definition 257 The basic rules in defining the Client-Facing interfaces are as 258 follows: 260 o Not dependent on a particular network topology or the NSF location 261 in the network 263 o Not forced to express Security Policy with proprietary vendor 264 specific interfaces for a given NSF 266 o Independent of NSF type that will implement a specific Security 267 Policy; e.g., the interface remains same no matter if a specific 268 Security Policy is enforced on a stateful firewall, IDP, IDS, 269 Router or a Switch 271 o Declarative/Descriptive model instead of Imperative/Prescriptive 272 model - What security policy need to be expressed (declarative) 273 instead of how it is implemented (imperative) 275 o Not dependent on vendors' implementation or form-factor (physical, 276 virtual) of the NSF 278 o Not dependent on how a NSF becomes operational - network 279 connectivity and other hosting requirements. 281 o Not dependent on NSF control plane implementation (if there is 282 one), e.g., cluster of NSFs active as one unified service for 283 scale and/ or resilience. 285 o Not depending on specific data plane implementation of NSF, e.g. 286 encapsulation, service function chains. 288 Note that the rules stated above only apply to the Client-Facing 289 interface, which a Security Admin would use to express a high level 290 policy. These rules do not apply to the lower layers, e.g., Security 291 Controller that convert higher level policies into lower level 292 constructs. The lower layers may still need some intelligence such 293 as topology awareness, capability of the NSF and its functions, 294 supported encapsulations etc., to convert and apply the policies 295 accurately on the NSF. 297 3.3. Deployment Models for Implementing Security Policies 299 Traditionally, medium and large Enterprises deploy vendor provided 300 management systems to create Security Policies and any changes to 301 these Security Policies are made manually over time by Security 302 Admin. This approach may not be suitable and nor sufficient for 303 modern highly automated campus network, and data centers that are 304 largely virtualized and rely on various management systems and 305 controllers to implement dynamic Security Policies over large number 306 of NSF in the network. 308 There are two distinct deployment models for Security Controller. 309 Although, these have no direct impact on the Client-Facing interface, 310 but illustrate the overall Security Policy management framework in an 311 organization and how the Client-Facing interface remain same which is 312 the main objective of this document. These models are: 314 a. Policy management without an explicit management system for 315 control of NSFs. In this deployment, Security Controller acts as 316 a NSF management system; it takes information passed over Client- 317 Facing interface and translates into data on I2NSF NSF-Facing 318 interface. The NSF-Facing interface is implemented by NSF 319 vendors; this would usually be done by having an I2NSF agent 320 embedded in the NSF. This deployment model is shown in Figure 1. 322 RESTful API 323 SUPA or I2NSF Policy Management 324 ^ 325 | 326 Client-Facing Interface | 327 (Independent of individual | 328 NSFs, devices, and vendors) | 329 | 330 ------------------------------ 331 | | 332 | Security Controller | 333 | | 334 ------------------------------ 335 | ^ 336 | I2NSF | 337 NSF Interface | NSF-Facing | 338 (Specific to NSFs) | Interface | 339 .............................. 340 | | 341 v | 343 ------------- ------------- 344 | I2NSF Agent | | I2NSF Agent | 345 |-------------| |-------------| 346 | |---| | 347 | NSF | | NSF | 348 NSFs | | | | 349 (virtual -------------\ /------------- 350 and | \ / | 351 physical) | X | 352 | / \ | 353 -------------/ \------------- 354 | I2NSF Agent | | I2NSF Agent | 355 |-------------| |-------------| 356 | |---| | 357 | NSF | | NSF | 358 | | | | 359 ------------- ------------- 361 Figure 1: Deployment without Management System 363 b. Policy management with an explicit management system for control 364 of NSFs. This model is similar to the model above except that 365 Security Controller interacts with a vendor's dedicated 366 management system that proxy I2NSF NSF-Facing interfaces as NSF 367 may not support NSF-Facing interface. This is a useful model to 368 support legacy NSF. This deployment model is shown in Figure 2. 370 RESTful API 371 SUPA or I2NSF Policy Management 372 ^ 373 | 374 Client-Facing Interface | 375 (Independent of individual | 376 NSFs, devices, and vendors) | 377 | 378 ------------------------------ 379 | | 380 | Security Controller | 381 | | 382 ------------------------------ 383 | ^ 384 | I2NSF | 385 NSF Interface | NSF-Facing | 386 (Specific to NSFs) | Interface | 387 .............................. 388 | | 389 v | 390 ------------------------------ 391 | | 392 | I2NSF Proxy Agent / | 393 | Management System | 394 | | 395 ------------------------------ 396 | ^ 397 | Proprietary | 398 | Functional | 399 | Interface | 400 .............................. 401 | | 402 v | 404 ------------- ------------- 405 | |---| | 406 | NSF | | NSF | 407 NSFs | | | | 408 (virtual -------------\ /------------- 409 and | \ / | 410 physical) | X | 411 | / \ | 412 -------------/ \------------- 413 | |---| | 414 | NSF | | NSF | 415 | | | | 416 ------------- ------------- 418 Figure 2: Deployment with Management System or I2NSF Proxy Agent 420 As mentioned above, these models discussed here don't affect the 421 definition of Client-Facing interface, they do give an overall 422 context for defining a Security Policy interface based on 423 abstraction. This can help in implementing a Security Controller. 425 4. Functional Requirements for the Client-Facing Interface 427 As stated in the guiding principle for defining the I2NSF Client- 428 Facing interface, the Security Policies and the Client-Facing 429 interface shall be defined from Security Admin's perspective and 430 abstracted away from type of NSF, NSF specific implementation, 431 controller implementation, network topology, controller NSF-Facing 432 interface. Thus, the Security Policy definition shall be 433 declarative, expressed using User-construct, and driven by how 434 Security Admin view Security Policies from their business needs and 435 objectives. 437 Security Controller's' implementation is outside the scope of this 438 document and the I2NSF working group. 440 In order to express and build security policies, high level 441 requirement for Client-Facing interface is as follows: 443 o Unified model for various network types (i.e., campus network, 444 date center, operator core/metro network, etc) 446 o Multi-Tenancy 448 o Authentication and Authorization 450 o Role-Based Access Control (RBAC) 452 o Protection from Attacks 454 o Protection from Misconfiguration 456 o Policy Lifecycle Management 458 o Dynamic Policy Endpoint Groups 460 o Policy Rules 461 o Policy Actions 463 o Generic Policy Model 465 o Policy Conflict Resolution 467 o Backward Compatibility 469 o Third-Party Integration 471 o Telemetry Data 473 The above requirements are by no means a complete list and may not be 474 sufficient or required for all use-cases, but should be a good 475 starting point for a wide variety of use-cases in Service Provider 476 and Enterprise networks. 478 A specific implementation may not support all these requirements but 479 in order to define a base set of requirements which would works for 480 most use-cases, this document will make an attempt to classify these 481 requirements in three categories: 483 MUST: This means, the requirement must be supported by Client-Facing 484 interface. 486 RECOMMENDED: This means, we recommend that Client-Facing interface 487 support this requirement since it might be applicable to large 488 number of use-cases but some vendor may choose to omit if their 489 focus is only certain market segments. 491 MAY: This means, the requirement is not mandatory for Client-Facing 492 interface but may be needed for specific use-cases. 494 4.1. Requirement for Unified Model for Various Network Types 496 In terms of security management/control, different network types have 497 different focus and requirements. In general, campus network focuses 498 more on user and device management, as well as the access control 499 among them. But for data center, more focus are putted on the east- 500 west traffic control for various application, or workload isolation 501 with micro-segmentation. 503 Comparing to campus network and DC network, the other network types, 504 such as: operator core/metro network, VPN network, are relatively 505 simple in terms of security policies but still have their own 506 considerations. Despite their different focus on security policy, 507 one unified model is still necessary with the benefits of simplicity, 508 wide applicability and extensibility. More specifically, the unified 509 model here means all the policy objects are constructed with the same 510 structured method in the security policies for all the network types. 512 We classify this requirement in MUST category. 514 4.2. Requirement for Multi-Tenancy in Client-Facing Interface 516 An organization may have internal tenants and might want a framework 517 wherein each tenant manages its own Security Policies with isolation 518 from other tenants. This requirement may be applicable to Service 519 Providers and Large Enterprises so we classify this requirement in 520 RECOMMENDED category. If an implement does not support this 521 requirement, it must support a default implicit tenant created by 522 Security Controller that owns all the Security Policies. 524 A Security Admin may be a Cloud Service Provider with multi-tenant 525 deployment, where each tenant is a different customer. Each tenant 526 or customer must be able to manage its own Security Policies without 527 affecting other tenants. 529 It should be noted that tenants may have their own tenants, so a 530 recursive relation may exist. For instance, a tenant in a Cloud 531 Service Provider may have multiple departments or organizations that 532 need to manage their own security rules for compliance. 534 The following objects are needed to fulfill this requirement: 536 Policy-Tenant: An entity that owns and manages Security Policies 537 applied to its own asset and resources. 539 Policy-Administrator: A user authorized to manage the security 540 policies for a Policy-Tenant. 542 Policy-User: A user within a Policy-Tenant who is authorized to 543 access certain resources of that tenant according to the 544 privileges assigned to it. 546 4.3. Requirement for Authentication and Authorization of Client-Facing 547 Interface 549 A Security Admin must be authenticated and authorized in order to 550 manage Security Policies. We classify this requirement in MUST 551 category since without proper authentication and authorization, the 552 security posture of entire organization can be easily compromised. 554 There must be methods defined for Policy-Administrator to be 555 authenticated and authorized to use Security Controller. There are 556 several authentication methods available such as OAuth [RFC6749], 557 XAuth and X.509 certificate based; the authentication may be mutual 558 or single-sided based on business needs and outside the scope of 559 I2NSF. In addition, there must be a method o authorize the Policy- 560 Administrator to perform certain action. It should be noted that, 561 Policy-Administrator authentication and authorization to perform 562 actions could be part of Security Controller or outside; this 563 document does not mandate any specific implementation but requires 564 that such a scheme must be implemented. 566 4.4. Requirement for Role-Based Access Control (RBAC) in Client-Facing 567 Interface 569 A tenant in organization may have multiple users with each user given 570 certain privileges. Some user such as "Admin" may have all the 571 permission but other may have limited permissions. We classify this 572 requirement in RECOMMENDED category since it aligns with Multi- 573 Tenancy requirement. If this requirement is not supported, a default 574 privilege must be assigned to all the users. 576 The following objects are needed to fulfill this requirement: 578 Policy-Authorization-Role: Defines the permissions assigned to a 579 user such as creating and managing policies on specified 580 resources. A user may not be allowed to change existing policies 581 but only view them. 583 4.5. Requirement to Protect Client-Facing Interface from Attacks 585 The interface must be protected against attacks from malicious 586 clients or a client impersonator. Potential attacks could come from 587 Botnets, hosts infected with virus or some unauthorized entities. 588 This requirement is highly RECOMMENDED since it may not be needed if 589 the entire framework is deployed in very controlled environment. But 590 if needed, we recommend that Security Controller uses an out-of-band 591 communication channel for Client-Facing interface. In addition, it 592 is also recommended that traffic of Client-Facing interface 593 communication are encrypted; Furthermore, some straightforward 594 traffic/session control mechanisms (i.e., Rate-limit, ACL, White/ 595 Black list) can be employed on Security Controller to protect against 596 DDoS flooding attacks. 598 4.6. Requirement to protect Client-Facing Interface from 599 Misconfiguration 601 There must be measures to protect from mis-configured clients. 602 System and policy parameters validations should be implemented to 603 detect this. Validation may be based on a set of default parameters 604 or custom tuned thresholds such as the number of policy changes 605 submitted, number of objects requested in a given time interval, etc. 606 We consider this to be a MUST requirement but implementation aspects 607 would depend upon each individual API communication. 609 4.7. Requirement to Manage Policy Lifecycle with Rich Set of Controls 611 In order to provide more sophisticated and flexible security 612 framework, there should be a mechanism so that a policy becomes 613 dynamically active/enforced or inactive based on multiple different 614 criteria such as Security Admin's manual intervention or some 615 external event. We consider requirement listed here to be a MUST for 616 wide variety of use-cases. 618 One example of dynamic policy management is when Security Admin pre- 619 configures all the security policies, but the policies get activated 620 or deactivated based on dynamic threat detection. Basically, a 621 threat event may activate certain inactive policies, and once a new 622 event indicates that the threat has gone away, the policies become 623 inactive again. 625 There are following ways for dynamically activating policies: 627 o The policy may be activated by Security Admin manually using a 628 client interface such as GUI or CLI. 630 o The policy may be dynamically activated by Security Controller upon 631 detecting an external event or an event from I2NSF monitoring 632 interface 634 o The policy can be configured but gets activated or deactivated upon 635 specified timing calendar with Security Policy definition. 637 Client-Facing interface should support the following policy 638 attributes for policy enforcement: 640 Admin-Enforced: A policy, once configured, remains active/enforced 641 until removed by Security Admin. 643 Time-Enforced: A policy configuration specifies the time profile 644 that determines when the policy is to be activated/enforced. 645 Otherwise, it is de-activated. 647 Event-Enforced: A policy configuration specifies the event profile 648 that determines when the policy is to be activated/enforced. It 649 also specifies the duration attribute of that policy once 650 activated based on event. For instance, if the policy is 651 activated upon detecting an application flow, the policy could be 652 de-activated when the corresponding session is closed or the flow 653 becomes inactive for certain time. 655 A policy could be a composite policy, which is composed of many 656 rules, and subject to updates and modification. For the policy 657 maintenance, enforcement, and audit-ability purposes, it becomes 658 important to name and version Security Policy. Thus, the policy 659 definition SHALL support policy naming and versioning. In addition, 660 the I2NSF Client-Facing interface SHALL support the activation, 661 deactivation, programmability, and deletion of policies based on name 662 and version. In addition, it should support reporting operational 663 state of policies by name and version. For instance, a Security 664 Admin may probe Security Controller whether a Security Policy is 665 enforced for a tenant and/or a sub-tenant (organization) for audit- 666 ability or verification purposes. 668 4.8. Requirement to Define Dynamic Policy Endpoint Group 670 When Security Admin configures a Security Policy, it may have 671 requirement to apply this policy to certain subsets of the network. 672 The subsets may be identified based on criteria such as Users, 673 Devices, and Applications, or combination of them. We refer to such 674 a subset of the network as a "Policy Endpoint Group". This 675 requirement is the fundamental building block of Client-Facing 676 interface; so making it a MUST requirement. But object defined here 677 may not support all use-cases and may not be required by everyone so 678 it is left up to vendor whether all or partial set of these object is 679 supported. 681 One of the biggest challenges for a Security Admin is how to make 682 sure that a Security Policy remain effective while constant changes 683 are happening to the "Policy Endpoint Group" for various reasons 684 (e.g., organizational, network and application changes). If a policy 685 is created based on static information such as user names, 686 application, or network subnets; then every time this static 687 information change, policies need to be updated. For example, if a 688 policy is created that allows access to an application only from the 689 group of Human Resource users (HR-users group), then each time the 690 HR-users group changes, the policy needs to be updated. 692 We call these dynamic Policy Endpoint Groups "Metadata Driven 693 Groups". The metadata is a tag associated with endpoint information 694 such as User, Application, or Device. The mapping from metadata to 695 dynamic content could come from a standards-based or proprietary 696 tools. Security Controller could use any available mechanisms to 697 derive this mapping and to make automatic updates to policy content 698 if the mapping information changes. The system SHOULD allow for 699 multiple, or sets of tags to be applied to a single endpoint. 701 Client-Facing interface must support Policy Endpoint Groups as a 702 target for a Security Policy. The following metadata driven groups 703 MAY be used for configuring Security Polices: 705 User-Group: This group identifies a set of users based on a tag or 706 static information such as user-names. The tag identifying users, 707 is dynamically derived from systems such as Active Directory or 708 LDAP. For example, an organization may have different User- 709 groups,such as HR-users, Finance-users, Engineering-users, to 710 classify a set of users in each department. 712 Device-Group: This group identifies a set of devices based on a tag 713 or device information. The tag identifying the devices, is 714 dynamically derived from systems such as configuration management 715 database (CMDB). For example, a Security Admin may want to 716 classify all machines running a particular operating system into 717 one group and machines running a different operating system into 718 another group. 720 Application-Group: This group identifies a set of applications based 721 on a tag or on application names. The tag identifying 722 applications, is dynamically derived from systems such as CMDB. 723 For example, a Security Admin may want to classify all 724 applications running in the Legal department into one group and 725 all applications running in the HR department into another group. 726 In some cases, the application can semantically associated with a 727 VM or a device. However, in other cases, the application may need 728 to be associated with a set of identifiers (e.g., transport 729 numbers, signature in the application packet payload) that 730 identify the application in the corresponding packets. The 731 mapping of application names/tags to signatures in the associated 732 application packets should be defined and communicated to the NSF. 733 The Client-Facing Interface shall support the communication of 734 this information. 736 Location-Group: This group identifies a set of locations. Tag may 737 correspond 1:1 to location. The tag identifying locations is 738 either statically defined or dynamically derived from systems such 739 as CMDB. For example, a Security Admin may want to classify all 740 sites/locations in a geographic region as one group. Note that 741 the location can be both the geographic and abstract concept. 742 Some typical examples for the latter case are: branches and 743 headquarter for a large enterprise; different data center sites; 744 private cloud and public cloud. 746 4.9. Requirement to Express Rich Set of Policy Rules 748 The Policy Rules is a central component of any Security Policy but 749 rule requirements may vary based on use-cases and it is hard to 750 define a complete set that works for everyone. In order to build a 751 rich interface, we are going to take a different approach; we will 752 define the building block of rules and let Security Admin build rules 753 using these construct so that Security Policies meet their 754 requirements divided into the following major categories: 756 Segmentation policies : This set of policies create rules for 757 communication between two Endpoint Groups. An organization may 758 restrict certain communication between a set of user and 759 applications for example. The segmentation policy may be a micro- 760 segmentation rule between components of complex applications or 761 related to hybrid cloud deployment based on location. 763 Threat policies: This set of policies creates rules to prevent 764 communication with externally or internally identified threats. 765 The threats may be well knows such as threat feeds from external 766 sources or dynamically identified by using specialty devices in 767 the network. 769 Governance and Compliance policies: This set of policies creates 770 rules to implement business requirement such as controlling access 771 to internal or external resources for meeting regulatory 772 compliance or business objectives. 774 In order to build a generic rule engine to satisfy diverse set of 775 Policy Rules, we propose following objects: 777 Source Policy Endpoint Group: A source target of the Policy Rule. 778 This may be special object "ALL" if all groups meet this criteria. 780 Destination Policy Endpoint Group: A destination target of the 781 Policy Rule. This may be a special object "ALL", if all groups 782 meet this criteria. 784 Direction: By default rules are applied in both directions but this 785 object can be used to make rule definition uni-directional. 787 Threat Group: An object that represents a set of static or dynamic 788 threats such as Botnet, GeoIP, URL feeds or virus and malware 789 signatures detected dynamically. This object can be used as 790 source or destination target in a rule. 792 Match Condition: An object that represents a set of allowed 793 interactions. It could be as simple as group of application names 794 or L4 ports allowed between two Endpoint Groups. 796 Exceptions: In order to greatly simplify Security Admin's task, we 797 should allow to specify exceptions to the match criteria. E.g., 798 we could build a rule that allows all traffic between two groups 799 except a particular application or threat source. 801 Actions: Action is what makes rule and Policy work. The Action is 802 defined in details in next section. We RECOMMEND that there be a 803 one-to-one mapping between rule and action otherwise if multiple 804 rules are associated with one action, it may be a difficult to 805 manage Security Policy lifecycle as they evolve. 807 4.10. Requirement to Express Rich Set of Policy Actions 809 Security Admin must be able to configure a variety of actions for a 810 given Policy Rule. Typically, Security Policy specifies a simple 811 action of "deny" or "permit" if a particular condition is matched. 812 Although this may be enough for most use-cases, the I2NSF Client- 813 Facing interface must provide a more comprehensive set of actions so 814 that the interface can be used effectively across various security 815 needs. 817 Policy action MUST be extensible so that additional policy action 818 specifications can easily be added. 820 The following list of actions SHALL be supported: 822 Permit: This action means continue processing the next rule or allow 823 the packet to pass if this is the last rule. 825 Deny: This action means stop further packet processing and drop the 826 packet. 828 Drop connection: This action means stop further packet processing, 829 drop the packet, and drop connection (for example, by sending a 830 TCP reset). 832 Log: This action means create a log entry whenever a rule is 833 matched. 835 Authenticate connection: This action means that whenever a new 836 connection is established it should be authenticated. 838 Quarantine/Redirect: This action is useful for threat remediation 839 purposes. If a security breach or infection point is detected, a 840 Security Admin would like to isolate for purpose of remediation or 841 controlling attack surface. 843 Netflow: This action creates a Netflow record; Need to define 844 Netflow server or local file and version of Netflow. 846 Count: This action counts the packets that meet the rule condition. 848 Encrypt: This action encrypts the packets on an identified flow. 849 The flow could be over an IPSEC tunnel, or TLS session for 850 instance. 852 Decrypt: This action decrypts the packets on an identified flow. 853 The flow could be over an IPSEC tunnel, or TLS session for 854 instance. 856 Throttle: This action defines shaping a flow or a group of flows 857 that match the rule condition to a designated traffic profile. 859 Mark: This action defines traffic that matches the rule condition by 860 a designated DSCP value and/or VLAN 802.1p Tag value. 862 Instantiate-NSF: This action instantiates an NSF with a predefined 863 profile. An NSF can be any of the FW, IPS, IDS, honeypot, or VPN, 864 etc. 866 The policy actions should support combination of terminating actions 867 and non-terminating actions. For example, Syslog and then Permit; 868 Count and then Redirect. 870 Policy actions SHALL support any L2, L3, L4-L7 policy actions. 872 4.11. Requirement for Consistent Policy Enforcement 874 As proposed in this document, the Client-Facing interface MUST be 875 built using higher-level "User-Constructs" that are independent of 876 network design and implementations. In order to achieve this goal, 877 it becomes important that Security Controller functionality becomes 878 more complex that keep track of various objects that are used to 879 express Security Policies. The Security Controller MUST evaluate the 880 Security Policies whenever these objects and network topology change 881 to make sure that Security Policy is consistently enforced as 882 expressed. 884 Although this document does not specify how Security Controller 885 achieve this and any implementation challenges. It is assumed that 886 once Security Controller uses Client-Facing interface to accept 887 Security Policies; it would maintain the security posture as per the 888 Security Policies during all changes in network or Endpoints and 889 other building blocks of the framework. 891 An event must be logged by Security Controller when a Security Policy 892 is updated due to changes in it's building blocks such as Endpoint 893 Group contents or the Security Policy is moved from one enforcement 894 point to another because the Endpoint has moved in the network. This 895 may help in debugging and auditing for compliance reasons. The 896 Security Admin may optionally receive notifications if supported and 897 desired. 899 4.12. Requirement to Detect and Correct Policy Conflicts 901 Client-Facing interface SHALL be able to detect policy "conflicts", 902 and SHALL specify methods on how to resolve these "conflicts" 904 For example a newly submitted Security Policy could conflict with 905 existing Security Policies applied to a set of Policy Endpoint 906 Groups. This MUST be detected and Security Admin be allowed for 907 manual correction if needed. 909 4.13. Requirement for Backward Compatibility 911 It MUST be possible to add new capabilities to Client-Facing 912 interface in a backward compatible fashion. 914 4.14. Requirement for Third-Party Integration 916 The security framework in a network may require the use of some 917 special devices such as honeypot, behavioral analytic, or SIEM for 918 threat detection; the device may provide threat information such as 919 threat feeds, virus signatures, and malicious file hashes. 921 The Client-Facing interface must allow Security Admin to include 922 these devices under Security Controller's Client-Facing interface so 923 that a Security Policy could be expressed using information from such 924 devices; basically it allows ability to integrate third part devices 925 into the Security Policy framework. 927 4.15. Requirement to Collect Telemetry Data 929 One of the most important aspect of security is to have visibility 930 into the network. As threats become more sophisticated, Security 931 Admin must be able to gather different types of telemetry data from 932 various NSFs in the network. The collected data could simply be 933 logged or sent to security analysis engines for application 934 identification, flow context and behavioral analysis, policy 935 violations, and for threat detection. Based on the analysis result, 936 the security controller can enforce the policy lifecycle management 937 and automatic optimization. 939 The Client-Facing interface MUST allow Security Admin to collect 940 various kinds of data from NSFs. The data source could be syslog, 941 flow records, policy violation records, and other available data. 943 Client-Facing interface must provide a set of telemetry data 944 available to Security Admin from Security Controller. The Security 945 Admin should be able to subscribe and receive to this data set. 947 5. Operational Requirements for the Client-Facing Interface 949 5.1. API Versioning 951 Client-Facing interface must support a version number for each 952 RESTful API. This is important since Security Controller could be 953 deployed by using multiple componenets and different pieces may come 954 from different vendors; it is difficult to isolate and debug issues 955 without ability to track each component's operational behavior. Even 956 if the vendor is same for all the components, it is hard to imagine 957 that all pieces would be released in lock step by the vendor. 959 Without API versioning, it is hard to debug and figure out issues 960 when deploying Security Controller and its components built overtime 961 across multiple release cycles. Although API versioning does not 962 guarantee that Security Controller would always work but it helps in 963 debugging if the problem is caused by an API mismatch. 965 5.2. API Extensibility 967 Abstraction and standardization of Client-Facing interface is of 968 tremendous value to Security Admins as it gives them the flexibility 969 of deploying any vendor's NSF without need to redefine their policies 970 if or when a NSF is changed. 972 If a vendor comes up with new feature or functionality that can't be 973 expressed through the currently defined Client-Facing interface, 974 there SHALL be a way to extend existing APIs or to create a new API 975 that addresses specific vendors's new NSF functionality. 977 5.3. APIs and Data Model Transport 979 The APIs for interface SHALL be derived from the YANG based data 980 model. The data model for Client-Facing interface must capture all 981 the requirements as defined in this document to express a Security 982 Policy. The interface between a client and controller must be 983 reliable to ensure robust policy enforcement. One such transport 984 mechanism is RESTCONF that uses HTTP operations to provide necessary 985 CRUD operations for YANG data objects, but any other mechanism can be 986 used. 988 5.4. Notification and Monitoring 990 Client-Facing interface must allow ability to collect various alarms, 991 events, statistics about enforcement and policy violations from NSFs 992 in the network. The events and alarms may be associated with a 993 specific policy or associated with operating conditions of a specific 994 NSF in general. The statistics may be a measure of potential 995 Security Policy violations or general data that reflect operational 996 behavior of a NSF. The events, alarms and statistics may also be 997 used as an input to automate Security Policy lifecycle management. 999 5.5. Affinity 1001 Client-Facing interface must allow Security Admin to pass any 1002 additional metadata that a user may want to provide with a Security 1003 Policy e.g., whether the policy needs to be enforced by a very highly 1004 secure NSF with Trusted Platform Module (TPM) chip. Another example 1005 would be, whether or not a policy can be enforced by a multi-tenant 1006 NSF. This would Security Admin control on operating environment 1008 5.6. Test Interface 1010 Client-Facing interface must support ability to test a Security 1011 Policy before it is enforced e.g., a user may want to verify whether 1012 the policy creates any potential conflicts with existing policies or 1013 if there are enough resources and capability to enforce this policy. 1014 The test interface would provide a mechanism to Security Admin where 1015 policies could be tested in the actual environment before 1016 enforcement. 1018 6. Security Considerations 1020 Client-Facing interface to Security controller must be protected to 1021 make sure that entire security posture is not compromised. This 1022 draft mandates that interface must have proper authentication and 1023 authorization control mechanisms to ward off malicious attacks. The 1024 draft does not specify a particular mechanism as different 1025 organization may have different needs based on their specific 1026 deployment environment and moreover new methods may evolve to better 1027 suit contemporary requirements. 1029 Authentication and authorization alone may not be sufficient for 1030 Client-Facing interface; the interface API must be validated for 1031 proper input to guard against attacks. The type of checks and 1032 verification may be specific to each interface API, but a careful 1033 consideration must be made to ensure that Security Controller is not 1034 compromised. 1036 We recommend that all attack surface must be examined with careful 1037 consideration of the operating environment and available industry 1038 best practices must be used such as process and standards to protect 1039 security controller against malicious or inadvertent attacks. 1041 7. IANA Considerations 1043 This document requires no IANA actions. RFC Editor: Please remove 1044 this section before publication. 1046 8. Acknowledgements 1048 The authors would like to thank Adrian Farrel, Linda Dunbar and Diego 1049 R.Lopez from IETF I2NSF WG for helpful discussions and advice. 1051 The authors would also like to thank Kunal Modasiya, Prakash T. 1052 Sehsadri and Srinivas Nimmagadda from Juniper networks for helpful 1053 discussions. 1055 9. Normative References 1057 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 1058 and J. Jeong, "Interface to Network Security Functions 1059 (I2NSF): Problem Statement and Use Cases", RFC 8192, 1060 DOI 10.17487/RFC8192, July 2017, 1061 . 1063 [RFC8327] Hargrave, W., Griswold, M., Snijders, J., and N. Hilliard, 1064 "Mitigating the Negative Impact of Maintenance through BGP 1065 Session Culling", BCP 214, RFC 8327, DOI 10.17487/RFC8327, 1066 March 2018, . 1068 Authors' Addresses 1070 Rakesh Kumar 1071 Lilac Cloud 1072 14435 C Big Basin Way #104 1073 Saratoga, CA 95070 1074 US 1076 Email: rakeshkumarcloud@gmail.com 1077 Anil Lohiya 1078 Juniper Networks 1079 1133 Innovation Way 1080 Sunnyvale, CA 94089 1081 US 1083 Email: alohiya@juniper.net 1085 Dave Qi 1086 Bloomberg 1087 731 Lexington Avenue 1088 New York, NY 10022 1089 US 1091 Email: DQI@bloomberg.net 1093 Nabil Bitar 1094 Nokia 1095 755 Ravendale Drive 1096 Mountain View, CA 94043 1097 US 1099 Email: nabil.bitar@nokia.com 1101 Senad Palislamovic 1102 Nokia 1103 755 Ravendale Drive 1104 Mountain View, CA 94043 1105 US 1107 Email: senad.palislamovic@nokia.com 1109 Liang Xia 1110 Huawei 1111 101 Software Avenue 1112 Nanjing, Jiangsu 210012 1113 China 1115 Email: Frank.Xialiang@huawei.com