idnits 2.17.1 draft-kumar-i2nsf-client-facing-interface-im-03.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-client-facing-interface-req]), 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 172: '...cy-Domain object SHALL have following ...' RFC 2119 keyword, line 194: '...cy-Tenant object SHALL have following ...' RFC 2119 keyword, line 211: '...licy-Role object SHALL have following ...' RFC 2119 keyword, line 230: '...licy-User object SHALL have following ...' RFC 2119 keyword, line 253: '...uthentication-Method object SHALL have...' (17 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 16, 2017) is 2475 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-i2nsf-problem-and-use-cases' is defined on line 753, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-i2nsf-client-facing-interface-req-02 == Outdated reference: A later version (-08) exists of draft-ietf-i2nsf-terminology-04 Summary: 2 errors (**), 0 flaws (~~), 4 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 17, 2018 D. Qi 6 Bloomberg 7 N. Bitar 8 S. Palislamovic 9 Nokia 10 L. Xia 11 Huawei 12 July 16, 2017 14 Information model for Client-Facing Interface to Security Controller 15 draft-kumar-i2nsf-client-facing-interface-im-03 17 Abstract 19 This document defines information model for Client-Facing interface 20 to Security Controller based on the requirements identified in 21 [I-D.ietf-i2nsf-client-facing-interface-req]. The information model 22 defines various managed objects and relationship among these objects 23 needed to build the interface. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 17, 2018. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions Used in this Document . . . . . . . . . . . . . . 3 61 3. Information Model for Multi Tenancy . . . . . . . . . . . . . 4 62 3.1. Policy-Domain . . . . . . . . . . . . . . . . . . . . . . 4 63 3.2. Policy-Tenant . . . . . . . . . . . . . . . . . . . . . . 5 64 3.3. Policy-Role . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.4. Policy-User . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.5. Policy-Management-Authentication-Method . . . . . . . . . 6 67 4. Information Model for Policy Endpoint Groups . . . . . . . . 6 68 4.1. Metadata-Source . . . . . . . . . . . . . . . . . . . . . 7 69 4.2. User-Group . . . . . . . . . . . . . . . . . . . . . . . 7 70 4.3. Device-Group . . . . . . . . . . . . . . . . . . . . . . 8 71 4.4. Application-Group . . . . . . . . . . . . . . . . . . . . 8 72 4.5. Location-Group . . . . . . . . . . . . . . . . . . . . . 9 73 5. Information Model for Threat Prevention . . . . . . . . . . . 9 74 5.1. Threat-Feed . . . . . . . . . . . . . . . . . . . . . . . 9 75 5.2. Custom-List . . . . . . . . . . . . . . . . . . . . . . . 10 76 5.3. Malware-Scan-Group . . . . . . . . . . . . . . . . . . . 10 77 5.4. Event-Map-Group . . . . . . . . . . . . . . . . . . . . . 11 78 6. Information Model for Telemetry Data . . . . . . . . . . . . 11 79 6.1. Telemetry-Data . . . . . . . . . . . . . . . . . . . . . 11 80 6.2. Telemetry-Source . . . . . . . . . . . . . . . . . . . . 12 81 6.3. Telemetry-Destination . . . . . . . . . . . . . . . . . . 13 82 7. Information Model for Policy Instance . . . . . . . . . . . . 13 83 7.1. Policy-Calendar . . . . . . . . . . . . . . . . . . . . . 13 84 7.2. Policy-Action . . . . . . . . . . . . . . . . . . . . . . 14 85 7.3. Policy-Rule . . . . . . . . . . . . . . . . . . . . . . . 14 86 7.4. Policy-Instance . . . . . . . . . . . . . . . . . . . . . 15 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 89 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 90 11. Informative References . . . . . . . . . . . . . . . . . . . 16 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 93 1. Introduction 95 The Security Controller's Client-Facing interfaces would be built 96 using a set of objects, with each object capturing a unique set of 97 information from Security Admin needed to express a Security Policy. 98 An object may have relationship with various other objects to express 99 a complete set of requirement. An information model captures the 100 managed objects and relationship among these objects. The 101 information model proposed in this draft is in accordance with 102 interface requirements as defined in 103 [I-D.ietf-i2nsf-client-facing-interface-req]. 105 The [RFC3444] explains differences between an information and data 106 model. This draft use those guidelines to define information model 107 for Client-Facing interface in this draft. A data model, that 108 represents an implementation of the proposed information model in a 109 specific data representation language, will be defined in a separate 110 draft. 112 2. Conventions Used in this Document 114 BSS: Business Support System 116 CLI: Command Line Interface 118 CMDB: Configuration Management Database 120 Controller: Used interchangeably with Service Provider Security 121 Controller or management system throughout this document 123 CRUD: Create, Retrieve, Update, Delete 125 FW: Firewall 127 GUI: Graphical User Interface 129 IDS: Intrusion Detection System 131 IPS: Intrusion Protection System 133 LDAP: Lightweight Directory Access Protocol 135 NSF: Network Security Function, defined by 136 [I-D.ietf-i2nsf-terminology] 138 OSS: Operation Support System 140 RBAC: Role Based Access Control 141 SIEM: Security Information and Event Management 143 URL: Universal Resource Locator 145 vNSF: Refers to NSF being instantiated on Virtual Machines 147 3. Information Model for Multi Tenancy 149 Multi-tenancy is an important aspect of any application that enables 150 multiple administrative domains in order to manage application 151 resources An Enterprise organization may have multiple tenants or 152 departments such as HR, Finance, Legal, with each tenant having a 153 need to manage their own Security Policies. In a Service Provider, a 154 tenant could represent a Customer that want to manage its own 155 Security Policies. 157 There are multiple managed objects that constitute multi-tenancy 158 aspects. This section lists these objects and any relationship among 159 these objects. 161 3.1. Policy-Domain 163 This object defines a boundary for the purpose of policy management 164 within a Security Controller. This may vary based on how the 165 Security Controller is deployed and hosted. For example, if an 166 Enterprise host a Security Controller in their network; the domain in 167 this case could just be the one that represents that Enterprise. But 168 if a Cloud Service Provider hosts managed services, then a domain 169 could represent a single customer of that Provider. Multi-tenancy 170 model should be able to work in all such environments. 172 The Policy-Domain object SHALL have following information: 174 Name: Name of the organization or customer representing this 175 domain 177 Address: Address of the organization or customer 179 Contact: Contact information of the organization or customer 181 Date: Date this account was created or last modified 183 Authentication-Method: Authentication method to be used for this 184 domain. It should be reference to a 'Policy-Management- 185 Authentication-Method' object 187 3.2. Policy-Tenant 189 This object defines an entity within an organization. The entity 190 could be a department or business unit within an Enterprise 191 organization that would like to manages its own Policies due to 192 regulatory compliance or business reasons. 194 The Policy-Tenant object SHALL have following information: 196 Name: Name of the Department or Division within an organization 198 Date: Date this account was created or last modified 200 Domain: This field identifies the domain to which this tenant 201 belongs. This should be reference to a Policy-Domain 202 object 204 3.3. Policy-Role 206 This object defines a set of permissions assigned to a user in an 207 organization that want to manage its own Security Policies. It 208 provides a convenient way to assign policy users to a job function or 209 set of permissions within the organization. 211 The Policy-Role object SHALL have following information: 213 Name: This field identifies name of the role 215 Date: Date this role was created or last modified 217 Access-Profile: This field identifies the access profile for the 218 role. The profile grants or denies permissions to access 219 Endpoint Groups for the purpose of policy management or may 220 restrict certain operations related to policy managements. 222 3.4. Policy-User 224 This object represents a unique identity within an organization. The 225 identity authenticates with Security Controller using credentials 226 such as a password or token in order to do policy management. A user 227 may be an individual, system, or application requiring access to 228 Security Controller. 230 The Policy-User object SHALL have following information: 232 Name: Name of user 234 Date: Date this user was created or last modified 235 Password: User password for basic authentication 237 Email: E-mail address of user 239 Scope-Type: This field identifies whether a user has domain-wide 240 or tenant-wide privileges 242 Scope-Reference: This field should be reference to either a 243 Policy-Domain or a Policy-Tenant object 245 Role: This field should be reference to a Policy-Role object that 246 defines the specific permissions 248 3.5. Policy-Management-Authentication-Method 250 This object represents authentication schemes supported by Security 251 Controller. 253 This Policy-Management-Authentication-Method object SHALL have 254 following information: 256 Name: This field identifies name of this object 258 Date: Date this object was created or last modified 260 Authentication-Method: This field identifies the authentication 261 methods. It could be a password based, token based, 262 certificate based or single sign-on authentication 264 Mutual-Authentication: This field indicates whether mutual 265 authentication is mandatory or not 267 Token-Server: This field stores the information about server that 268 validates the token submitted as credentials 270 Certificate-Server: This field stores the information about 271 server that validates certificates submitted as credentials 273 Single Sign-on-Server: This field stores the information about 274 server that validates user credentials 276 4. Information Model for Policy Endpoint Groups 278 The Policy Endpoint Group is very important part of building User- 279 construct based policies. Security Admin would create and use these 280 objects to represent a logical entity in their business environment, 281 where a Security Policy is to be applied. 283 There are multiple managed objects that constitute Policy Endpoint 284 Group. This section lists these objects and relationship among these 285 objects. 287 4.1. Metadata-Source 289 This object represents information source for metadata or tag. The 290 metadata in a group must be mapped to its corresponding contents to 291 enforce a Security Policy. 293 Metadata-Source object SHALL have following information: 295 Name: This field identifies name of this object 297 Date: Date this object was created or last modified 299 Tag-Type: This field identifies the Endpoint Group type. It can 300 be a User-Group, App-Group, Device-Group or Location-Group 302 Tag-Source-Server: This field identifies information related to 303 the source of the tag such as IP address and UDP/TCP port 304 information 306 Tag-Source-Application: This filed identifies the protocol e.g. 307 LDAP, Active Directory, or CMDB used to communicated with 308 server 310 Tag-Source-Credentials: This field identifies the credential 311 information needed to access the server 313 4.2. User-Group 315 This object represents a user group based on either tag or other 316 information. 318 The User-Group object SHALL have following information: 320 Name: This field identifies the name of this object 322 Date: Date this object was created or last modified 324 Group-Type: This field identifies whether the user group is based 325 on User-tag, User-name or IP-address 327 Metadata-Server: This field should be reference to a Metadata- 328 Source object 330 Group-Member: This field is a list of User-tag, User-names or IP 331 addresses based on Group-Type 333 Risk-Level: This field represents the risk level or importance of 334 the Endpoint to Security Admin for policy purpose; the 335 valid range may be 0 to 9 337 4.3. Device-Group 339 This object represents a device group based on either tag or other 340 information. 342 The Device-Group object SHALL have following information: 344 Name: This field identifies the name of this object 346 Date: Date this object was created or last modified 348 Group-Type: This field identifies whether the device group is 349 based on Device-tag or Device-name or IP address 351 Metadata-Server: This field should be reference to a Metadata- 352 Source object 354 Group-Member: This field is a list of Device-tag, Device-name or 355 IP address based on Group-Type 357 Risk-Level: This field represents the risk level or importance of 358 the Endpoint to Security Admin for policy purpose; the 359 valid range may be 0 to 9 361 4.4. Application-Group 363 This object represents an application group based on either tag or 364 other information. 366 The Application-Group object SHALL have following information: 368 Name: This field identifies the name of this object 370 Date: Date this object was created or last modified 372 Group-Type: This field identifies whether the application group 373 is based on App-tag or App-name, or IP address 375 Metadata-Server: This field should be reference to a Metadata- 376 Source object 378 Group-Member: This field is a list of Application-tag 379 Application-name or IP address and port information based 380 on Group-Type 382 Risk-Level: This field represents the risk level or importance of 383 the Endpoint to Security Admin for policy purpose; the 384 valid range may be 0 to 9 386 4.5. Location-Group 388 This object represents an location group based on either tag or other 389 information. 391 The 'Location-Group' object SHALL have following information: 393 Name: This field identifies the name of this object 395 Date: Date this object was created or last modified 397 Group-Type: This field identifies whether the location group is 398 based on Location-tag, Location-name or IP address 400 Metadata-Server: This field should be reference to a Metadata- 401 Source object 403 Group-Member: This field is a list of Location-tag, Location-name 404 or IP addresses based on Group-Type 406 Risk Level: This field represents the risk level or importance of 407 the Endpoint to Security Admin for policy purpose; the 408 valid range may be 0 to 9 410 5. Information Model for Threat Prevention 412 The threat prevention plays an important part in the overall security 413 posture by reducing the attack surface. This information could come 414 in the form of threat feeds such as Botnet and GeoIP feeds usually 415 from a third party or external service. 417 There are multiple managed objects that constitute this category. 418 This section lists these objects and relationship among these 419 objects. 421 5.1. Threat-Feed 423 This object represents threat feed such as Botnet servers and GeoIP. 425 The Threat-Feed object SHALL have following information: 427 Name: This field identifies the name of this object 429 Date: Date this object was created or last modified 431 Feed-Type: This field identifies whether a feed type is IP 432 address based or URL based. 434 Feed-Server: This field identifies the information about the feed 435 provider, it may be an external service or local server 437 Feed-Priority: This field represents the feed priority level to 438 resolve conflict if there are multiple feed sources; the 439 valid range may be 0 to 9 441 5.2. Custom-List 443 This object represents custom list created for the purpose of 444 defining exception to threat feeds. An organization may want to 445 allow certain exception to threat feeds obtained from a third party 447 The Custom-List object SHALL have following information: 449 Name: This field identifies the name of this object 451 Date: Date this object was created or last modified 453 List-Type: This field identifies whether the list type is IP 454 address based or URL based. 456 List-Property: This field identifies the attributes of the list 457 property e.g. Blacklist or Whitelist. 459 List-Content: This field contains contents such as IP addresses 460 or URL names. 462 5.3. Malware-Scan-Group 464 This object represents information needed to detect malware. This 465 information could come from a local server or uploaded periodically 466 from a third party. 468 The Malware-Scan-Group object SHALL have following information: 470 Name: This field identifies the name of this object 472 Date: Date this object was created or last modified 473 Signature-Server: This field contains information about the 474 server from where signatures can be downloaded periodically 475 as updates become available 477 File-Types: This field contains list of file types needed to be 478 scanned for the virus 480 Malware-Signatures: This field contains list of malware 481 signatures or hash 483 5.4. Event-Map-Group 485 This object represents an event map containing security events and 486 threat levels used for dynamic policy enforcement. 488 The Event-Map-Group object SHALL have following information: 490 Name: This field identifies the name of this object 492 Date: Date this object was created or last modified 494 Security-Events: This contains a list of security events used for 495 purpose for Security Policy definition 497 Threat-Map: This contains a list of threat levels used for 498 purpose for Security Policy definition 500 6. Information Model for Telemetry Data 502 Telemetry provides visibility into the network activities which can 503 be tapped for further security analytics e.g. detecting potential 504 vulnerabilities, malicious activities etc. 506 6.1. Telemetry-Data 508 This object contains information collected for telemetry. 510 The Telemetry-Data object SHALL have following information: 512 Name: This field identifies the name of this object 514 Date: Date this object was created or last modified 516 Log-Data: This field identifies whether Log data need to be 517 collected 519 Syslog-Data This field identifies whether Syslog data need to be 520 collected 522 SNMP-Data: This field identifies whether SNMP traps and alarm 523 data need to be collected 525 sFlow-Record: This field identifies whether sFlow records need to 526 be collected 528 NetFlow-Record: This field identifies whether NetFlow record need 529 to be collected 531 NSF-Stats: This field identifies whether statistics need to be 532 collected from NSF 534 6.2. Telemetry-Source 536 This object contains information related to telemetry source. The 537 source would be a NSF element in the network. 539 The Telemetry-Source object SHALL have following information: 541 Name: This field identifies the name of this object 543 Date: Date this object was created or last modified 545 Source-Type: This field contains type of the NSF telemetry 546 source: "NETWORK-NSF", "FIREWALL-NSF", "IDS-NSF", "IPS- 547 NSF", "PROXY-NSF or "OTHER-NSF" 549 NSF-Source: This field contains information such as IP address 550 and protocol (UDP or TCP) port number of the NSF providing 551 telemetry data 553 NSF-Credentials: This field contains username and password to 554 authenticate with the NSF 556 Collection-Interval: This field contains time in milliseconds 557 between each data collection. For example, a value of 5000 558 means data is streamed to collector every 5 seconds. Value 559 of 0 means data streaming is event-based. 561 Collection-Method: This field contains method of collection 562 whether it is PUSH-based or PULL-based 564 Heartbeat-Interval: This field contains time in seconds the 565 source must send telemetry heartbeat 567 QoS-Marking: This field contains DSCP value source MUST mark on 568 its generated telemetry packets 570 6.3. Telemetry-Destination 572 This object contains information related to telemetry destination. 573 The destination is usually a collector which is either a part of 574 Security Controller or external system such as SIEM. 576 The Telemetry-Destination object SHALL have following information: 578 Name: This field identifies the name of this object 580 Date: Date this object was created or last modified 582 Collector-Source: This field contains the information such as IP 583 address and protocol (UDP or TCP) port number for the 584 collector's destination 586 Collector-Credentials: This field contains the username and 587 password for the collector 589 Data-Encoding: This field contains the telemetry data encoding, 590 which could in the form of a schema 592 Data-Transport: This field contains streaming telemetry data 593 protocols: whether it is gRPC, protocol buffer over UDP, 594 etc. 596 7. Information Model for Policy Instance 598 In order to express a Security Policy, a policy instance must have 599 complete information such as where and when a policy need to be 600 applied. The is done by defining a set of managed objects and 601 relationship among them. A policy may be related segmentation, 602 threat mitigation or telemetry data collection from NSF in the 603 network. 605 7.1. Policy-Calendar 607 This object contains information related to scheduling a policy. The 608 policy could be activated based on a time calendar or security event 609 including threat level changes. 611 The Policy-Calendar object SHALL have following information: 613 Name: This field identifies the name of this object 615 Date: Date this object was created or last modified 616 Enforecment-Type: This field identifies whether the policy 617 enforcement is "ADMIN-ENFORCED", "TIME-ENFORCED" or "EVENT- 618 ENFORCED" 620 Time-Information: This field contains time calendar such as 621 "BEGIN-TIME" and "END-TIME" for one time enforcement or 622 recurring time calendar for periodic enforcement 624 Event-Map: This field contains security events or threat map in 625 order to determine when a policy need to be activated. 626 This is a reference to Evnet-Map-Group defined earlier 628 7.2. Policy-Action 630 This object represents actions that a Security Admin want to perform 631 based on certain traffic class. 633 The Policy-Action object SHALL have following information: 635 Name: This field identifies the name of this object 637 Date: Date this object was created or last modified 639 Primary-Action: This field identifies the action when a rule is 640 matched by NSF. The action could be one of "PERMIT", 641 "DENY", "REDIRECT", "RATE-LIMIT", "TRAFFIC-CLASS", 642 "AUTHENTICATE-SESSION", "IPS", "APP-FIREWALL", or "COLLECT" 644 Secondary-Action: Security Admin can also specify additional 645 actions if a rule is matched. This could be one of "LOG", 646 "SYSLOG", or "SESSION-LOG" 648 7.3. Policy-Rule 650 This object represents rules that a Security Admin want to define in 651 order to express its business objectives in a Security Policy. 653 The Policy-Rule object SHALL have following information: 655 Name: This field identifies the name of this object 657 Date: Date this object was created or last modified 659 Source: This field identifies the source of the traffic. This 660 could be reference to either Policy-Endpoint-Group, Threat- 661 Feed or Custom-List as defined earlier. This could be a 662 special object "ALL" that match all traffic. This could 663 also be Telemetry-Source for telemetry collection policy. 665 Destination: This field identifies the destination of the 666 traffic. This could be reference to either Policy- 667 Endpoint-Group, Threat-Feed or Custom-List as defined 668 earlier. This could be a special object "ALL" that match 669 all traffic. This could also be Telemetry-Destination for 670 telemetry collection policy. 672 Match-Condition: This field identifies the match criteria used to 673 evaluate whether the specified action need to be taken or 674 not. This could be either a Policy-Endpoint-Group 675 identifying a Application set or a set of traffic rules 677 Match-Direction: This field identifies if the match criteria is 678 to evaluated for both direction of the traffic or only in 679 one direction with default of allowing in the other 680 direction for stateful match conditions. This is optional 681 and by default rule should apply in both directions 683 Exception: This field identifies the exception consideration when 684 a rule is evaluated for a given communication. This could 685 be reference to "Policy-Endpoint-Group" object or set of 686 traffic matching criteria 688 Action: This field identifies the action taken when a rule is 689 matched. There is always a implicit action to drop traffic 690 if no rule is matched for a traffic type 692 Precedence: This field identifies the precedence assigned to this 693 rule by Security Admin. This is helpful in conflict 694 resolution when two or more rules match a given traffic 695 class 697 7.4. Policy-Instance 699 This object represents a mechanism to express a Security Policy by 700 Security Admin using Security Controller Client-Facing interface; the 701 policy would be enforced on a NSF. 703 The Policy-Instance object SHALL have following information: 705 Name: This field identifies the name of this object 707 Date: Date this object was created or last modified 709 Rules: This field contains a list of rules. If the rule does not 710 have a user defined precedence, then any conflict must be 711 manually resolved 713 Scheduling-Type: This field specifies when this policy should be 714 scheduled. The policy could be scheduled based on time 715 calendar or event-map 717 Scheduling-Information: This field contains reference to Policy- 718 Calendar or Event-Map-Group based on Schedule-Type' 720 Owner: This field defines the owner of this policy. Only the 721 owner is authorized to modify the contents of the policy 723 8. Security Considerations 725 Information model provides mechanism to protect Client-Facing 726 interface to Security controller. One of the specified mechanism 727 must be used to protect Enterprise network, data and all resources 728 from external attacks. This model mandates that interface must have 729 proper authentication and authorization with Role Based Access 730 Controls to address multi-tenancy requirement. The draft does not 731 mandate that a particular mechanism be used as different organization 732 may have different needs based on their deployment. 734 9. IANA Considerations 736 This document requires no IANA actions. RFC Editor: Please remove 737 this section before publication. 739 10. Acknowledgements 741 The authors would like to thank Kunal Modasiya, Prakash T. Sehsadri 742 and Srinivas Nimmagadda from Juniper Networks for helpful 743 discussions. 745 11. Informative References 747 [I-D.ietf-i2nsf-client-facing-interface-req] 748 Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic, 749 S., and L. Xia, "Requirements for Client-Facing Interface 750 to Security Controller", draft-ietf-i2nsf-client-facing- 751 interface-req-02 (work in progress), July 2017. 753 [I-D.ietf-i2nsf-problem-and-use-cases] 754 Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 755 and J. Jeong, "I2NSF Problem Statement and Use cases", 756 draft-ietf-i2nsf-problem-and-use-cases-16 (work in 757 progress), May 2017. 759 [I-D.ietf-i2nsf-terminology] 760 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 761 Birkholz, "Interface to Network Security Functions (I2NSF) 762 Terminology", draft-ietf-i2nsf-terminology-04 (work in 763 progress), July 2017. 765 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 766 Information Models and Data Models", RFC 3444, 767 DOI 10.17487/RFC3444, January 2003, 768 . 770 Authors' Addresses 772 Rakesh Kumar 773 Juniper Networks 774 1133 Innovation Way 775 Sunnyvale, CA 94089 776 US 778 Email: rakeshkumarcloud@gmail.com 780 Anil Lohiya 781 Juniper Networks 782 1133 Innovation Way 783 Sunnyvale, CA 94089 784 US 786 Email: alohiya@juniper.net 788 Dave Qi 789 Bloomberg 790 731 Lexington Avenue 791 New York, NY 10022 792 US 794 Email: DQI@bloomberg.net 796 Nabil Bitar 797 Nokia 798 755 Ravendale Drive 799 Mountain View, CA 94043 800 US 802 Email: nabil.bitar@nokia.com 803 Senad Palislamovic 804 Nokia 805 755 Ravendale Drive 806 Mountain View, CA 94043 807 US 809 Email: senad.palislamovic@nokia.com 811 Liang Xia 812 Huawei 813 101 Software Avenue 814 Nanjing, Jiangsu 210012 815 China 817 Email: Frank.Xialiang@huawei.com