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