idnits 2.17.1 draft-ietf-i2nsf-client-facing-interface-req-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a 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 496: '... Security Admin MUST authenticate to ...' RFC 2119 keyword, line 590: '...cy. Thus, the policy definition SHALL...' RFC 2119 keyword, line 592: '...Facing interface SHALL support the act...' RFC 2119 keyword, line 625: '... changes. The system SHOULD allow for...' RFC 2119 keyword, line 630: '... MAY be used for configuring securit...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 26, 2017) is 2550 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-i2nsf-problem-and-use-cases-15 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF Working Group R. Kumar 3 Internet-Draft A. Lohiya 4 Intended status: Informational Juniper Networks 5 Expires: October 28, 2017 D. Qi 6 Bloomberg 7 N. Bitar 8 S. Palislamovic 9 Nokia 10 L. Xia 11 Huawei 12 April 26, 2017 14 Requirements for Client-Facing Interface to Security Controller 15 draft-ietf-i2nsf-client-facing-interface-req-01 17 Abstract 19 This document captures requirements for Client-Facing interface to 20 Security Controller. The interface is expressed using objects and 21 constructs understood by Security Admin as opposed to vendor or 22 device specific expressions associated with individual product and 23 feature. This document identifies a broad set of requirements needed 24 to express security policies based on User-constructs which are well 25 understood by User Community. This gives ability to decouple policy 26 definition from policy enforcement on a specific element, be it a 27 physical or virtual. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on October 28, 2017. 46 Copyright Notice 48 Copyright (c) 2017 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions Used in this Document . . . . . . . . . . . . . . 4 65 3. Guiding principle for Client-Facing Interface defintion . . . 5 66 3.1. User-construct based modeling . . . . . . . . . . . . . . 5 67 3.2. Basic rules for Client-Facing Interface definition . . . 6 68 3.3. Deployment Models for Implementing Security Policies . . 7 69 4. Functional Requirements for the Client-Facing Interface . . . 10 70 4.1. Requirement for Multi-Tenancy in client interface . . . . 11 71 4.2. Requirement for Authentication and Authorization of 72 client interface . . . . . . . . . . . . . . . . . . . . 12 73 4.3. Requirement for Role-Based Access Control (RBAC) in 74 client interface . . . . . . . . . . . . . . . . . . . . 12 75 4.4. Requirement to protect client interface from attacks . . 12 76 4.5. Requirement to protect client interface from 77 misconfiguration . . . . . . . . . . . . . . . . . . . . 12 78 4.6. Requirement to manage policy lifecycle with diverse needs 13 79 4.7. Requirement to define dynamic policy Endpoint group . . . 14 80 4.8. Requirement to express rich set of policy rules . . . . . 15 81 4.9. Requirement to express rich set of policy actions . . . . 16 82 4.10. Requirement to express policy in a generic model . . . . 18 83 4.11. Requirement to detect and correct policy conflicts . . . 18 84 4.12. Requirement for backward compatibility . . . . . . . . . 18 85 4.13. Requirement for Third-Party integration . . . . . . . . . 18 86 4.14. Requirement to collect telemetry data . . . . . . . . . . 19 87 5. Operational Requirements for the Client-Facing Interface . . 19 88 5.1. API Versioning . . . . . . . . . . . . . . . . . . . . . 19 89 5.2. API Extensiblity . . . . . . . . . . . . . . . . . . . . 19 90 5.3. APIs and Data Model Transport . . . . . . . . . . . . . . 20 91 5.4. Notification . . . . . . . . . . . . . . . . . . . . . . 20 92 5.5. Affinity . . . . . . . . . . . . . . . . . . . . . . . . 20 93 5.6. Test Interface . . . . . . . . . . . . . . . . . . . . . 20 95 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 96 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 97 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 98 9. Normative References . . . . . . . . . . . . . . . . . . . . 21 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 101 1. Introduction 103 Programming security policies in a network has been a fairly complex 104 task that often requires very deep knowledge of vendor specific 105 device and features. This has been the biggest challenge for both 106 Service Provider and Enterprise, henceforth named as Security Admin 107 in this document. This challenge is further amplified due to network 108 virtualization with security functions deployed in physical and 109 virtual form factor, henceforth named as network security function 110 (NSF) in this document, from multiple vendors with proprietary 111 interface. 113 Even if a Security Admin deploys a single vendor solution with one or 114 more security appliances across its entire network, it is still very 115 difficult to manage security policies due to complexity of security 116 features, and mapping of business requirements to vendor specific 117 configuration. The Security Admin may use vendor provided management 118 systems to provision and manage security policies. But, the single 119 vendor approach is highly restrictive in today's network for 120 following reasons: 122 o An organization may not be able to rely on a single vendor because 123 the changing security requirements may not align with vendor's 124 release cycle. 126 o A large organization may have a presence across different sites 127 and regions; which means, it may not be possible to deploy same 128 solution from the same vendor because of regional regulatory and 129 compliance policy. 131 o If and when an organization migrates from one vendor to another, 132 it is almost impossible to migrate security policies from one 133 vendor to another without complex and time consuming manual 134 workflows. 136 o An organization may deploy multiple network security functions in 137 virtual and physical forms to attain the flexibility, elasticity, 138 performance scale, and operational efficiency they require. 139 Practically, that often requires different sources (vendor, open 140 source) to get the best of breed for any such security function. 142 o An organization may choose all or part of their assets such as 143 routers, switches, firewalls, and overlay-networks as policy 144 enforcement points for operational and cost efficiency. It would 145 be highly complex to manage policy enforcement with different tool 146 set for each type of device. 148 In order to facilitate deployment of security policies across 149 different vendor provided NSFs, the Interface to Network Security 150 Functions (I2NSF) working group in the IETF is defining a Client- 151 Facing interface to Security Controller [I-D. ietf-i2nsf-framework] 152 [I-D. ietf-i2nsf-terminology]. Deployment facilitation should be 153 agnostic to the type of device, be it physical or virtual, or type of 154 enforcement point. Using these interfaces, it becomes possible to 155 write different kinds of security management applications (e.g. GUI 156 portal, template engine, etc.) allowing Security Admin to express 157 security policies in an abstract form with choice of wide variety of 158 NSF for policy enforcement. The implementation of security 159 management applications or controller is completely out of the scope 160 of the I2NSF working group, which is only focused on interface 161 definition. 163 This document captures the requirements for Client-Facing interface 164 that can be easily used by Security Admin without a need for 165 expertise in vendor and device specific feature set. We refer to 166 this as "User-construct" based interfaces. To further clarify, in 167 the scope of this document, the "User-construct" here does not mean 168 some free-from natural language input or an abstract intent such as 169 "I want my traffic secure" or "I don't want DDoS attacks in my 170 network"; rather the User-construct here means that policies are 171 described using expressions such as application names, application 172 groups, device groups, user groups etc. with a vocabulary of verbs 173 (e.g., drop, tap, throttle), prepositions, conjunctions, 174 conditionals, adjectives, and nouns instead of using standard 175 n-tuples from the packet header. 177 2. Conventions Used in this Document 179 BSS: Business Support System 181 CLI: Command Line Interface 183 CMDB: Configuration Management Database 185 Controller: Used interchangeably with Security Controller or 186 management system throughout this document 188 CRUD: Create, Retrieve, Update, Delete 189 FW: Firewall 191 GUI: Graphical User Interface 193 IDS: Intrusion Detection System 195 IPS: Intrusion Protection System 197 LDAP: Lightweight Directory Access Protocol 199 NSF: Network Security Function, defined by 200 [I-D.ietf-i2nsf-problem-and-use-cases] 202 OSS: Operation Support System 204 RBAC: Role Based Access Control 206 SIEM: Security Information and Event Management 208 URL: Universal Resource Locator 210 vNSF: Refers to NSF being instantiated on Virtual Machines 212 3. Guiding principle for Client-Facing Interface defintion 214 Client-Facing Interface must ensure that a Security Admin can deploy 215 any NSF from any vendor and should still be able to use the same 216 consistent interface. In essence, this interface must allow a 217 Security Admin to express security policies independent of how NSFs 218 are implemented in their deployment. Henceforth, in this document, 219 we use "security policy management interface" interchangeably when we 220 refer to Client-Facing interface. 222 3.1. User-construct based modeling 224 Traditionally, security policies have been expressed using 225 proprietary interface. The interface is defined by a vendor based on 226 proprietary command line text or a GUI based system with 227 implementation specific constructs such IP address, protocol and 228 L4-L7 information. This requires Security Admin to translate their 229 business objectives into vendor provided constructs in order to 230 express a security policy. But, this alone is not sufficient to 231 render a policy in the network; the admin must also understand 232 network and application design to locate a specific policy 233 enforcement point to make sure policy is effective. This may be 234 highly manual task based on specific network design and may become 235 unmanageable in virtualized networks. 237 The User-construct based framework does not rely on lower level 238 semantics due to problem explained above, but rather uses higher 239 level constructs such as User-group, Application-group, Device-group, 240 Location-group, etcetera. A Security Admin would use these 241 constructs to express a security policy instead of proprietary 242 implementation or feature specific constructs. The policy defined in 243 such a manner is referred to User-construct based policies in this 244 draft. The idea is to enable Security Admin to use constructs they 245 understand best in expressing security policies which simplify their 246 tasks and help avoiding human errors in complex security 247 provisioning. 249 3.2. Basic rules for Client-Facing Interface definition 251 The basic rules in defining the Client-Facing interfaces are as 252 follows: 254 o Not dependent on particular Network topology or the NSF location 255 in the network 257 o Not requiring deep knowledge of proprietary features and 258 capabilities supported in the deployed NSFsa€ 260 o Independent of NSF type that will implement the user security 261 policy be it a stateful firewall,IDP, IDS, Router, Switch 263 o Declarative/Descriptive model instead of Imperative/Prescriptive 264 model - What security policy need to be enforced (declarative) 265 instead of how it is implemented (imperative) 267 o Not dependent on any specific vendor implementation or form-factor 268 (physical, virtual) of the NSF 270 o Not dependent on how a NSF becomes operational - Network 271 connectivity and other hosting requirements. 273 o Not dependent on NSF control plane implementation (if there is 274 one) E.g., cluster of NSFs active as one unified service for scale 275 and/ or resilience. 277 o Not depending on specific data plane implementation of NSF i.e. 278 Encapsulation, Service function chains. 280 Note that the rules stated above only apply to the Client-Facing 281 interface, which a user would use to express a high level policy. 282 These rules do not apply to the lower layers e.g. Security 283 Controller that convert higher level policies into lower level 284 constructs. The lower layers may still need some intelligence such 285 as topology awareness, capability of the NSF and its functions, 286 supported encapsulations etc. to convert and apply the policies 287 accurately on the NSF. 289 3.3. Deployment Models for Implementing Security Policies 291 Traditionally, medium and large Enterprise deploy management systems 292 to manage their statically defined security policies. This approach 293 may not be suitable nor sufficient for modern automated and dynamic 294 data centers that are largely virtualized and rely on various 295 management systems and controllers to dynamically implement security 296 policies over any types of NSF. 298 There are two different deployment models in which the Client-Facing 299 interface referred to in this document could be implemented. These 300 models have no direct impact on the Client-Facing interface, but 301 illustrate the overall security policy and management framework and 302 where various processing functions reside. These models are: 304 a. Policy management without an explicit management system for 305 control of NSFs. In this deployment, Security Controller acts as 306 a NSF management system; it takes information passed over Client- 307 Facing interface and translates into data on I2NSF NSF-facing 308 interface. The NSF-Facing interface is implemented by NSF 309 vendors; this would usually be done by having an I2NSF agent 310 embedded in the NSF. This deployment model is shown in Figure 1. 312 RESTful API 313 SUPA or I2NSF Policy Management 314 ^ 315 | 316 Client-Facing Interface | 317 (Independent of individual | 318 NSFs, devices,and vendors)| 319 | 320 ------------------------------ 321 | | 322 | Security Controller | 323 | | 324 ------------------------------ 325 | ^ 326 | I2NSF | 327 NSF Interface | NSF-facing | 328 (Specific to NSFs) | Interface | 329 .............................. 330 | | 331 v | 333 ------------- ------------- 334 | I2NSF Agent | | I2NSF Agent | 335 |-------------| |-------------| 336 | |---| | 337 | NSF | | NSF | 338 NSFs | | | | 339 (virtual -------------\ /------------- 340 and | \ / | 341 physical) | X | 342 | / \ | 343 -------------/ \------------- 344 | I2NSF Agent | | I2NSF Agent | 345 |-------------| |-------------| 346 | |---| | 347 | NSF | | NSF | 348 | | | | 349 ------------- ------------- 351 Figure 1: Deployment without Management System 353 b. Policy management with an explicit management system for control 354 of NSFs. This model is similar to the model above except that 355 Security Controller interacts with a vendor's dedicated 356 management system that proxy I2NSF NSF-Facing interfaces as NSF 357 may not support NSF-Facing interface. This is a useful model to 358 support legacy NSF. This deployment model is shown in Figure 2. 360 RESTful API 361 SUPA or I2NSF Policy Management 362 ^ 363 | 364 Client-facing Interface | 365 (Independent of individual | 366 NSFs,devices,and vendors) | 367 | 368 ------------------------------ 369 | | 370 | Security Controller | 371 | | 372 ------------------------------ 373 | ^ 374 | I2NSF | 375 NSF Interface | NSF-facing | 376 (Specific to NSFs) | Interface | 377 .............................. 378 | | 379 v | 380 ------------------------------ 381 | | 382 | I2NSF Proxy Agent / | 383 | Management System | 384 | | 385 ------------------------------ 386 | ^ 387 | Proprietary | 388 | Functional | 389 | Interface | 390 .............................. 391 | | 392 v | 394 ------------- ------------- 395 | |---| | 396 | NSF | | NSF | 397 NSFs | | | | 398 (virtual -------------\ /------------- 399 and | \ / | 400 physical) | X | 401 | / \ | 402 -------------/ \------------- 403 | |---| | 404 | NSF | | NSF | 405 | | | | 406 ------------- ------------- 408 Figure 2: Deployment with Management System or I2NSF Proxy Agent 410 Although the deployment models discussed here don't necessarily 411 affect the definition of Client-Facing interface, they do give an 412 overall context for defining a security policy interface based on 413 abstraction. 415 4. Functional Requirements for the Client-Facing Interface 417 As stated in the guiding principle for defining the I2NSF Client- 418 Facing interface, the security policies and the Client-Facing 419 interface shall be defined from user's or client's perspective and 420 abstracted away from type of NSF, NSF specific implementation, 421 controller implementation, network topology, controller NSF-Facing 422 interface. Thus, the security policy definition shall be 423 declarative, expressed using User-construct, and driven by how 424 Security Admin view security policies from definition, communication 425 and deployment perspective. 427 Security Controller's' implementation is outside the scope of this 428 document and the I2NSF working group. 430 In order to express and build security policies, high level 431 requirement for Client-Facing interface is as follows: 433 o Multi-Tenancy 435 o Authentication and Authorization 437 o Role-Based Access Control (RBAC) 439 o Protection from Attacks 441 o Protection from Misconfiguration 443 o Policy Lifecycle Management 445 o Dynamic Policy Endpoint Groups 447 o Policy Rules 449 o Policy Actions 450 o Generic Policy Model 452 o Policy Conflict Resolution 454 o Backward Compatibility 456 o Third-Party Integration 458 o Telemetry Data 460 The above requirements are by no means a complete list and may not be 461 sufficient for all use-cases and all Security Admins, but should be a 462 good starting point for a wide variety of use-cases in Service 463 Provider and Enterprise networks. 465 4.1. Requirement for Multi-Tenancy in client interface 467 A Security Admin may have internal tenants and might want a framework 468 wherein each tenant manages its own security policies with isolation 469 from other tenants. 471 A Security Admin may be a cloud service provider with multi-tenant 472 deployment, where each tenant is a different customer. Each tenant 473 or customer must be allowed to manage its own security policies. 475 It should be noted that tenants may have their own tenants, so a 476 recursive relation may exist. For instance, a tenant in a Cloud 477 Service Provider may have multiple departments or organizations that 478 need to manage their own security rules for compliance. 480 Some key concepts are listed below and used throughout the document 481 hereafter: 483 Policy-Tenant: An entity that owns and manages the security policies 484 applied on its resources. 486 Policy-Administrator: A user authorized to manage the security 487 policies for a Policy-Tenant. 489 Policy-User: A user within a Policy-Tenant who is authorized to 490 access certain resources of that tenant according to the 491 privileges assigned to it. 493 4.2. Requirement for Authentication and Authorization of client 494 interface 496 Security Admin MUST authenticate to and be authorized by Security 497 Controller before they are able to issue control commands and any 498 policy data exchange commands. 500 There must be methods defined for Policy-Administrator to be 501 authenticated and authorized to use Security Controller. There are 502 several authentication methods available such as OAuth, XAuth and 503 X.509 certificate based; the authentication may be mutual or single- 504 sided based on business needs and outside the scope of I2NSF. In 505 addition, there must be a method o authorize the Policy-Administrator 506 to perform certain action. It should be noted that, Policy- 507 Administrator authentication and authorization to perform actions 508 could be part of Security Controller or outside; this document does 509 not mandate any specific implementation but requires that such a 510 scheme must be implemented. 512 4.3. Requirement for Role-Based Access Control (RBAC) in client 513 interface 515 Policy-Authorization-Role represents a role assigned to a Policy-User 516 that determines whether a user has read-write access, read-only 517 access, or no access for certain resources. A User can be mapped to 518 a Policy-Authorization-Role using an internal or external identity 519 provider or mapped statically. 521 4.4. Requirement to protect client interface from attacks 523 The interface must be protections from attacks, malicious or 524 otherwise, from clients or a client impersonator. Potential attacks 525 could come from Botnets, hosts infected with virus or some 526 unauthorized entity. It is recommended that Security Controller use 527 a dedicated IP interface for Client-Facing communications and those 528 communications should be carried over an isolated out-of-band 529 network. In addition, it is recommended that traffic between clients 530 and Security controller be encrypted. Furthermore, some 531 straightforward traffic/session control mechanisms (i.e., Rate-limit, 532 ACL, White/Black list) can be employed on Security Controller to 533 defend against DDoS flooding attacks. 535 4.5. Requirement to protect client interface from misconfiguration 537 There must be protections from mis-configured clients. System and 538 policy validations should be implemented to detect this. Validation 539 may be based on a set of default parameters or custom tuned 540 thresholds such as the number of policy changes submitted, number of 541 objects requested in a given time interval, etc. 543 4.6. Requirement to manage policy lifecycle with diverse needs 545 In order to provide more sophisticated security framework, there 546 should be a mechanism so that a policy becomes dynamically active/ 547 enforced or inactive based on Security Admin's manual intervention or 548 some external event. 550 One example of dynamic policy management is when Security Admin pre- 551 configures all the security policies, but the policies get activated 552 or deactivated based on dynamic threats. Basically, a threat event 553 may activate certain inactive policies, and once a new event 554 indicates that the threat has gone away, the policies become inactive 555 again. 557 There are following ways for dynamically activating policies: 559 o The policy may be dynamically activated by Security Admin or 560 associated management entity 562 o The policy may be dynamically activated by Security Controller upon 563 detecting an external event or an event from I2NSF monitoring 564 interface 566 o The policy can be statically configured but activated or 567 deactivated upon policy attributes, such as timing calendar 569 Client-Facing interface should support the following policy 570 attributes for policy enforcement: 572 Admin-Enforced: A policy, once configured, remains active/enforced 573 until removed by Security Admin. 575 Time-Enforced: A policy configuration specifies the time profile 576 that determines when the policy is to be activated/enforced. 577 Otherwise, it is de-activated. 579 Event-Enforced: A policy configuration specifies the event profile 580 that determines when the policy is to be activated/enforced. It 581 also specifies the duration attribute of that policy once 582 activated based on event. For instance, if the policy is 583 activated upon detecting an application flow, the policy could be 584 de-activated when the corresponding session is closed or the flow 585 becomes inactive for certain time. 587 A policy could be a composite policy, that is composed of many rules, 588 and subject to updates and modification. For the policy maintenance, 589 enforcement, and audit-ability purposes, it becomes important to name 590 and version Security Policy. Thus, the policy definition SHALL 591 support policy naming and versioning. In addition, the i2NSF Client- 592 Facing interface SHALL support the activation, deactivation, 593 programmability, and deletion of policies based on name and version. 594 In addition, it should support reporting operational state of 595 policies by name and version. For instance, a client may probe 596 Security Controller whether a Security Policy is enforced for a 597 tenant and/or a sub-tenant (organization) for audit-ability or 598 verification purposes. 600 4.7. Requirement to define dynamic policy Endpoint group 602 When Security Admin configures a Security Policy, it may have 603 requirement to apply this policy to certain subsets of the network. 604 The subsets may be identified based on criteria such as Users, 605 Devices, and Applications. We refer to such a subset of the network 606 as a "Policy Endpoint Group". 608 One of the biggest challenges for a Security Admin is how to make 609 sure that a Security Policy remain effective while constant changes 610 are happening to the "Policy Endpoint Group" for various reasons 611 (e.g., organizational, network and application changes). If a policy 612 is created based on static information such as user names, 613 application, or network subnets; then every time this static 614 information change, policies need to be updated. For example, if a 615 policy is created that allows access to an application only from the 616 group of Human Resource users (HR-users group), then each time the 617 HR-users group changes, the policy needs to be updated. 619 We call these dynamic Policy Endpoint Groups "Meta-data Driven 620 Groups". The meta-data is a tag associated with endpoint information 621 such as User, Application, or Device. The mapping from meta-data to 622 dynamic content could come from a standards-based or proprietary 623 tools. Security Controller could use any available mechanisms to 624 derive this mapping and to make automatic updates to policy content 625 if the mapping information changes. The system SHOULD allow for 626 multiple, or sets of tags to be applied to a single network object. 628 Client-Facing policy interface must support endpoint groups for 629 expressing a Security Policy. The following meta-data driven groups 630 MAY be used for configuring security polices: 632 User-Group: This group identifies a set of users based on a tag or 633 on static information. The tag to identify user is dynamically 634 derived from systems such as Active Directory or LDAP. For 635 example, an organization may have different User-groups, such as 636 HR-users, Finance-users, Engineering-users, to classify a set of 637 users in each department. 639 Device-Group: This group identifies a set of devices based on a tag 640 or on static information. The tag to identify device is 641 dynamically derived from systems such as configuration management 642 database (CMDB). For example, a Security Admin may want to 643 classify all machines running a particular operating system into 644 one group and machines running a different operating system into 645 another group. 647 Application-Group: This group identifies a set of applications based 648 on a tag or on static information. The tag to identify 649 application is dynamically derived from systems such as CMDB. For 650 example, a Security Admin may want to classify all applications 651 running in the Legal department into one group and all 652 applications running in the HR department into another group. In 653 some cases, the application can semantically associated with a VM 654 or a device. However, in other cases, the application may need to 655 be associated with a set of identifiers (e.g., transport numbers, 656 signature in the application packet payload) that identify the 657 application in the corresponding packets. The mapping of 658 application names/tags to signatures in the associated application 659 packets should be defined and communicated to the NSF. The 660 Client-Facing Interface shall support the communication of this 661 information. 663 Location-Group: This group identifies a set of location tags. Tag 664 may correspond 1:1 to location. The tag to identify location is 665 either statically defined or dynamically derived from systems such 666 as CMDB. For example, a Security Admin may want to classify all 667 sites/locations in a geographic region as one group. 669 4.8. Requirement to express rich set of policy rules 671 The security policy rules can be as simple as specifying a match for 672 the user or application specified through "Policy Endpoint Group" and 673 take one of the "Policy Actions" or more complicated rules that 674 specify how two different "Policy Endpoint Groups" interact with each 675 other. The Client-Facing interface must support mechanisms to allow 676 the following rule matches. 678 Policy Endpoint Groups: The rule must allow a way to match either a 679 single or a member of a list of "Policy Endpoint Groups". 681 There must be a way to express a match between two "Policy Endpoint 682 Groups" so that a policy can be effective for communication between 683 two groups. 685 Direction: The rule must allow a way to express whether Security 686 Admin wants to match the "Policy Endpoint Group" as the source or 687 destination. The default should be to match both directions, if 688 the direction rule is not specified in the policy. 690 Threats: The rule should allow the security administrator to express 691 a match for threats that come either in the form of feeds (such as 692 Botnet feeds, GeoIP feeds, URL feeds, or feeds from a SIEM) or 693 speciality security appliances. Threats could be identified by 694 Tags/names in policy rules. The tag is a label of one or more 695 event types that may be detected by a threat detection system. 697 The threat could be from malware and this requires a way to match for 698 virus signatures or file hashes. 700 4.9. Requirement to express rich set of policy actions 702 Security Admin must be able to configure a variety of actions within 703 a security policy. Typically, security policy specifies a simple 704 action of "deny" or "permit" if a particular condition is matched. 705 Although this may be enough for most of the simple policies, the 706 I2NSF Client-Facing interface must also provide a more comprehensive 707 set of actions so that the interface can be used effectively across 708 various security functions. 710 Policy action MUST be extensible so that additional policy action 711 specifications can easily be added. 713 The following list of actions SHALL be supported: 715 Permit: This action means continue processing the next rule or allow 716 the packet to pass if this is the last rule. This is often a 717 default action. 719 Deny: This action means stop further packet processing and drop the 720 packet. 722 Drop connection: This action means stop further packet processing, 723 drop the packet, and drop connection (for example, by sending a 724 TCP reset). 726 Log: This action means create a log entry whenever a rule is 727 matched. 729 Authenticate connection: This action means that whenever a new 730 connection is established it should be authenticated. 732 Quarantine/Redirect: This action may be relevant for event driven 733 policy where certain events would activate a configured policy 734 that quarantines or redirects certain packets or flows. The 735 redirect action must specify whether the packet is to be tunneled 736 and in that case specify the tunnel or encapsulation method and 737 destination identifier. 739 Netflow: This action creates a Netflow record; Need to define 740 Netflow server or local file and version of Netflow. 742 Count: This action counts the packets that meet the rule condition. 744 Encrypt: This action encrypts the packets on an identified flow. 745 The flow could be over an IPSEC tunnel, or TLS session for 746 instance. 748 Decrypt: This action decrypts the packets on an identified flow. 749 The flow could be over an IPSEC tunnel, or TLS session for 750 instance. 752 Throttle: This action defines shaping a flow or a group of flows 753 that match the rule condition to a designated traffic profile. 755 Mark: This action defines traffic that matches the rule condition by 756 a designated DSCP value and/or VLAN 802.1p Tag value. 758 Instantiate-NSF: This action instantiates an NSF with a predefined 759 profile. An NSF can be any of the FW, LB, IPS, IDS, honeypot, or 760 VPN, etc. 762 WAN-Accelerate: This action optimizes packet delivery using a set of 763 predefined packet optimization methods. 765 Load-Balance: This action load balances connections based on 766 predefined LB schemes or profiles. 768 The policy actions should support combination of terminating actions 769 and non-terminating actions. For example, Syslog and then Permit; 770 Count and then Redirect. 772 Policy actions SHALL support any L2, L3, L4-L7 policy actions. 774 4.10. Requirement to express policy in a generic model 776 Client-Facing interface SHALL provide a generic metadata model that 777 defines once and then be used by appropriate model elements any 778 times, regardless of where they are located in the class hierarchy, 779 as necessary. 781 Client-Facing interface SHALL provide a generic context model that 782 enables the context of an entity, and its surrounding environment, to 783 be measured, calculated, and/or inferred. 785 Client-Facing interface SHALL provide a generic policy model that 786 enables context-aware policy rules to be defined to change the 787 configuration and monitoring of resources and services as context 788 changes. 790 Client-Facing interface SHALL provide the ability to apply policy or 791 multiple sets of policies to any given object. Policy application 792 process SHALL allow for nesting capabilities of given policies or set 793 of policies. For example, an object or any given set of objects 794 could have application team applying certain set of policy rules, 795 while network team would apply different set of their policy rules. 796 Lastly, security team would have an ability to apply its set of 797 policy rules, being the last policy to be evaluated against. 799 4.11. Requirement to detect and correct policy conflicts 801 Client-Facing interface SHALL be able to detect policy "conflicts", 802 and SHALL specify methods on how to resolve these "conflicts" 804 For example: two clients issues conflicting set of security policies 805 to be applied to the same Policy Endpoint Group. 807 4.12. Requirement for backward compatibility 809 It MUST be possible to add new capabilities to Client-Facing 810 interface in a backward compatible fashion. 812 4.13. Requirement for Third-Party integration 814 The security policies in a network may require the use of specialty 815 devices such as honeypots, behavioral analytics, or SIEM in the 816 network, and may also involve threat feeds,virus signatures, and 817 malicious file hashes as part of comprehensive security policies. 819 The Client-Facing interface must allow Security Admin to configure 820 these threat sources and any other information to provide integration 821 and fold this into policy management. 823 4.14. Requirement to collect telemetry data 825 One of the most important aspect of security is to have visibility 826 into the networks. As threats become more sophisticated, Security 827 Admin must be able to gather different types of telemetry data from 828 various devices in the network. The collected data could simply be 829 logged or sent to security analysis engines for behavioral analysis, 830 policy violations, and for threat detection. 832 The Client-Facing interface MUST allow Security Admin to collect 833 various kinds of data from NSFs. The data source could be syslog, 834 flow records, policy violation records, and other available data. 836 Detailed Client-Facing interface telemetry data should be available 837 between clients and Security Controller. Clients should be able to 838 subscribe and receive these telemetry data. 840 client should be able to receive notifications when a policy is 841 dynamically updated. 843 5. Operational Requirements for the Client-Facing Interface 845 5.1. API Versioning 847 Client-Facing interface must support a version number for each 848 RESTful API. This is very important because the client application 849 and the controller application may come from different vendors. Even 850 if the vendor is same, it is hard to imagine that two different 851 applications would be released in lock step. 853 Without API versioning, it is hard to debug and figure out issues if 854 an application breaks. Although API versioning does not guarantee 855 that applications will always work, it helps in debugging if the 856 problem is caused by an API mismatch. 858 5.2. API Extensiblity 860 Abstraction and standardization of Client-Facing interface is of 861 tremendous value to Security Admin as it gives them the flexibility 862 of deploying any vendor's NSF without need to redefine their policies 863 if or when a NSF is changed. 865 If a vendor comes up with new feature or functionality that can't be 866 expressed through the currently defined Client-Facing interface, 867 there must be a way to extend existing APIs or to create a new API 868 that is relevant for that NSF vendor only. 870 5.3. APIs and Data Model Transport 872 The APIs for client interface must be derived from the YANG based 873 data model. The YANG data model for client interface must capture 874 all the requirements as defined in this document to express a 875 security policy. The interface between a client and controller must 876 be reliable to ensure robust policy enforcement. One such transport 877 mechanism is RESTCONF that uses HTTP operations to provide necessary 878 CRUD operations for YANG data objects, but any other mechanism can be 879 used. 881 5.4. Notification 883 Client-Facing interface must allow Security Admin to collect various 884 alarms and events from the NSF in the network. The events and alarms 885 may be either related to security policy itself or related to NSF 886 where the policy is implemented. The events and alarms could also be 887 used as an input to the security policy for autonomous handling as 888 specified in a given security policy. 890 5.5. Affinity 892 Client-Facing interface must allow Security Admin to pass any 893 additional metadata that a user may want to provide for a security 894 policy e.g. certain security policy needs to be implemented only on a 895 very highly secure NSF with Trusted Platform Module (TPM) chip. A 896 user may require Security Controller not to share the NSF with other 897 tenant, this must be expressed through the interface API. 899 5.6. Test Interface 901 Client-Facing interface must allow Security Admin ability to test a 902 security policy before it is enforced e.g. a user may want to verify 903 whether the policy creates any potential conflicts with the existing 904 policies or if there are even resources to enforce the policy. The 905 test policy would provide such a capability without actually applying 906 the policies. 908 6. Security Considerations 910 Client-Facing interface to Security controller must be protected to 911 ensure that entire security posture is not compromised. This draft 912 mandates that interface must have proper authentication and 913 authorization with Role Based Access Controls to address multi- 914 tenancy requirement. The draft does not specify a particular 915 mechanism as different organization may have different needs based on 916 their deployment. This has been discussed extensively in this draft. 918 Authentication and authorization alone may not be sufficient for 919 Client-Facing interface; the interface API must be validated for 920 proper inputs to guard against attacks. The type of checks and 921 verification may be specific to each interface API, but a careful 922 consideration must be made to ensure that Security Controller is not 923 compromised. 925 7. IANA Considerations 927 This document requires no IANA actions. RFC Editor: Please remove 928 this section before publication. 930 8. Acknowledgements 932 The authors would like to thank Adrian Farrel, Linda Dunbar and Diego 933 R.Lopez from IETF I2NSF WG for helpful discussions and advice. 935 The authors would also like to thank Kunal Modasiya, Prakash T. 936 Sehsadri and Srinivas Nimmagadda from Juniper networks for helpful 937 discussions. 939 9. Normative References 941 [I-D.ietf-i2nsf-problem-and-use-cases] 942 Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 943 and J. Jeong, "I2NSF Problem Statement and Use cases", 944 draft-ietf-i2nsf-problem-and-use-cases-15 (work in 945 progress), April 2017. 947 Authors' Addresses 949 Rakesh Kumar 950 Juniper Networks 951 1133 Innovation Way 952 Sunnyvale, CA 94089 953 US 955 Email: rkkumar@juniper.net 957 Anil Lohiya 958 Juniper Networks 959 1133 Innovation Way 960 Sunnyvale, CA 94089 961 US 963 Email: alohiya@juniper.net 964 Dave Qi 965 Bloomberg 966 731 Lexington Avenue 967 New York, NY 10022 968 US 970 Email: DQI@bloomberg.net 972 Nabil Bitar 973 Nokia 974 755 Ravendale Drive 975 Mountain View, CA 94043 976 US 978 Email: nabil.bitar@nokia.com 980 Senad Palislamovic 981 Nokia 982 755 Ravendale Drive 983 Mountain View, CA 94043 984 US 986 Email: senad.palislamovic@nokia.com 988 Liang Xia 989 Huawei 990 101 Software Avenue 991 Nanjing, Jiangsu 210012 992 China 994 Email: Frank.Xialiang@huawei.com