idnits 2.17.1 draft-kumar-i2nsf-client-facing-interface-im-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-i2nsf-capability], [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 169: '...he Policy object SHALL have following ...' RFC 2119 keyword, line 216: '... The rule object SHALL have the follow...' RFC 2119 keyword, line 247: '... Event object SHALL have following i...' RFC 2119 keyword, line 271: '... Group object SHALL have following i...' RFC 2119 keyword, line 290: '...Condition object SHALL have following ...' (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 (March 5, 2018) is 2244 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-ietf-i2nsf-capability-00 == Outdated reference: A later version (-05) exists of draft-ietf-i2nsf-client-facing-interface-req-04 == Outdated reference: A later version (-08) exists of draft-ietf-i2nsf-terminology-05 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: September 6, 2018 D. Qi 6 Bloomberg 7 N. Bitar 8 S. Palislamovic 9 Nokia 10 L. Xia 11 Huawei 12 J. Jeong 13 Sungkyunkwan University 14 March 5, 2018 16 Information Model for Consumer-Facing Interface to Security Controller 17 draft-kumar-i2nsf-client-facing-interface-im-05 19 Abstract 21 This document defines an information model for Consumer-Facing 22 interface to Security Controller based on the requirements identified 23 in [I-D.ietf-i2nsf-client-facing-interface-req]. The information 24 model defines various managed objects and relationship among these 25 objects needed to build the interface. The information model is 26 organized based on the "Event-Condition-Event" (ECA) policy model 27 defined by a capability information model for Interface to Network 28 Security Functions (I2NSF) [I-D.ietf-i2nsf-capability]. 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 https://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 September 6, 2018. 47 Copyright Notice 49 Copyright (c) 2018 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 (https://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 . . . . . . . . . . . . . . 3 66 3. Information Model for Policy . . . . . . . . . . . . . . . . 4 67 3.1. Event Sub-Model . . . . . . . . . . . . . . . . . . . . . 6 68 3.1.1. Event-Map-Group . . . . . . . . . . . . . . . . . . . 6 69 3.2. Condition Sub-Model . . . . . . . . . . . . . . . . . . . 7 70 3.3. Action Sub-Model . . . . . . . . . . . . . . . . . . . . 7 71 4. Information Model for Multi Tenancy . . . . . . . . . . . . . 8 72 4.1. Policy-Domain . . . . . . . . . . . . . . . . . . . . . . 8 73 4.2. Policy-Tenant . . . . . . . . . . . . . . . . . . . . . . 9 74 4.3. Policy-Role . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.4. Policy-User . . . . . . . . . . . . . . . . . . . . . . . 9 76 4.5. Policy-Management-Authentication-Method . . . . . . . . . 10 77 5. Information Model for Policy Endpoint Groups . . . . . . . . 11 78 5.1. Tag-Source . . . . . . . . . . . . . . . . . . . . . . . 11 79 5.2. User-Group . . . . . . . . . . . . . . . . . . . . . . . 11 80 5.3. Device-Group . . . . . . . . . . . . . . . . . . . . . . 12 81 5.4. Application-Group . . . . . . . . . . . . . . . . . . . . 12 82 5.5. Location-Group . . . . . . . . . . . . . . . . . . . . . 13 83 6. Information Model for Threat Prevention . . . . . . . . . . . 13 84 6.1. Threat-Feed . . . . . . . . . . . . . . . . . . . . . . . 14 85 6.2. Custom-List . . . . . . . . . . . . . . . . . . . . . . . 14 86 6.3. Malware-Scan-Group . . . . . . . . . . . . . . . . . . . 14 87 7. Information Model for Telemetry Data . . . . . . . . . . . . 15 88 7.1. Telemetry-Data . . . . . . . . . . . . . . . . . . . . . 15 89 7.2. Telemetry-Source . . . . . . . . . . . . . . . . . . . . 16 90 7.3. Telemetry-Destination . . . . . . . . . . . . . . . . . . 16 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 92 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 93 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 94 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 95 12. Informative References . . . . . . . . . . . . . . . . . . . 18 96 Appendix A. Changes from draft-kumar-i2nsf-client-facing- 97 interface-im-04 . . . . . . . . . . . . . . . . . . 19 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 100 1. Introduction 102 Interface to Network Security Functions (I2NSF) defines a Consumer- 103 Facing Interface to deliver high-level security policies to Security 104 Controller [RFC8192][RFC8329] for securiy enforcement in Network 105 Security Functions (NSFs). 107 The Consumer-Facing interface would be built using a set of objects, 108 with each object capturing a unique set of information from Security 109 Admin (i.e., I2NSF User [RFC8329]) needed to express a Security 110 Policy. An object may have relationship with various other objects 111 to express a complete set of requirement. An information model 112 captures the managed objects and relationship among these objects. 113 The information model proposed in this document is in accordance with 114 interface requirements as defined in 115 [I-D.ietf-i2nsf-client-facing-interface-req]. 117 An NSF Capability model is proposed in [I-D.ietf-i2nsf-capability] as 118 the basic model for both the NSF-Facing interface and Consumer-Facing 119 interface security policy model of this document. The information 120 model proposed in this document is structured in accordance with the 121 "Event-Condition-Event" (ECA) policy model. 123 [RFC3444] explains differences between an information and data model. 124 This document use the guidelines in [RFC3444] to define an 125 information model for Consumer-Facing interface in this document. A 126 data model, which represents an implementation of the proposed 127 information model in a specific data representation language, will be 128 defined in a separate document. 130 2. Conventions Used in this Document 132 BSS: Business Support System 134 CLI: Command Line Interface 136 CMDB: Configuration Management Database 138 Controller: Security Controller or Management System 140 CRUD: Create, Retrieve, Update, Delete 142 FW: Firewall 143 GUI: Graphical User Interface 145 IDS: Intrusion Detection System 147 IPS: Intrusion Prevention System 149 LDAP: Lightweight Directory Access Protocol 151 NSF: Network Security Function, defined by 152 [I-D.ietf-i2nsf-terminology] 154 OSS: Operations Support System 156 RBAC: Role-Based Access Control 158 SIEM: Security Information and Event Management 160 URL: Universal Resource Locator 162 vNSF: NSF being instantiated on Virtual Machines 164 3. Information Model for Policy 166 A Policy object represents a mechanism to express a Security Policy 167 by Security Admin (i.e., I2NSF User) using Consumer-Facing interface 168 toward Security Controller; the policy would be enforced on an NSF. 169 The Policy object SHALL have following information: 171 Name: This field identifies the name of this object. 173 Date: Date when this object was created or last modified. 175 Multi-Tenancy: The multi-tenant environment information in which 176 the policy is applied. The Rules in the Policy can refer 177 to sub-objects (e.g., domain, tenant, role, and user) of 178 it. It can be either a reference to a Multi-Tenancy object 179 defined in another place, or a concrete object. See 180 details in Section 4. 182 End-Group: This field contains a list of logical entities in the 183 business environment where a Security Policy is to be 184 applied. It can be referenced by the Condition objects in 185 a Rule, e.g., Source, Destination, Match, etc. It can be 186 either a reference to an End-Group object defined in other 187 place, or a concrete object. See details in Section 5. 189 Threat-Feed: This field represents threat feed such as Botnet 190 servers, GeoIP, and Malware signature. This information 191 can be referenced by the Rule Action object directly to 192 execute the threat mitigation. See details in Section 6. 194 Telemetry-Data: This field represents the telemetry collection 195 related information that the Rule Action object can refer 196 to about how to collect the interested telemetry 197 information, for example, what type of telemetry to 198 collect, where the telemetry source is, where to send the 199 telemetry information. See details in Section 7. 201 Rules: This field contains a list of rules. If the rule does not 202 have a user-defined precedence, then any conflict must be 203 manually resolved. 205 Owner: This field defines the owner of this policy. Only the 206 owner is authorized to modify the contents of the policy. 208 A policy is a container of Rules. In order to express a Rule, a Rule 209 must have complete information such as where and when a policy needs 210 to be applied. This is done by defining a set of managed objects and 211 relationship among them. A Policy Rule may be related segmentation, 212 threat mitigation or telemetry data collection from an NSF in the 213 network, which will be specified as the sub-model of the policy model 214 in the subsequent sections. 216 The rule object SHALL have the following information: 218 Name: This field identifies the name of this object. 220 Date: This field indicates the date when this object was created 221 or last modified. 223 Event: This field includes the information to determine whether 224 the Rule Condition can be evaluated or not. See details in 225 Section 3.1. 227 Condition: This field contains all the checking conditions to 228 apply to the objective traffic. See details in 229 Section 3.2. 231 Action: This field identifies the action taken when a rule is 232 matched. There is always an implicit action to drop 233 traffic if no rule is matched for a traffic type. See 234 details in Section 3.3. 236 Precedence: This field identifies the precedence assigned to this 237 rule by Security Admin. This is helpful in conflict 238 resolution when two or more rules match a given traffic 239 class. 241 3.1. Event Sub-Model 243 The Event Object contains information related to scheduling a Rule. 244 The Rule could be activated based on a time calendar or security 245 event including threat level changes. 247 Event object SHALL have following information: 249 Name: This field identifies the name of this object. 251 Date: This field indicates the date when this object was created 252 or last modified. 254 Event-Type: This field identifies whether the event of triggering 255 policy enforcement is "ADMIN-ENFORCED", "TIME-ENFORCED" or 256 "EVENT-ENFORCED". 258 Time-Information: This field contains a time calendar such as 259 "BEGIN-TIME" and "END-TIME" for one time enforcement or 260 recurring time calendar for periodic enforcement. 262 Event-Map-Group: This field contains security events or threat 263 map in order to determine when a policy needs to be 264 activated. This is a reference to Event-Map-Group defined 265 later. 267 3.1.1. Event-Map-Group 269 This object represents an event map containing security events and 270 threat levels used for dynamic policy enforcement. The Event-Map- 271 Group object SHALL have following information: 273 Name: This field identifies the name of this object. 275 Date: This field indicates the date when this object was created 276 or last modified. 278 Security-Events: This contains a list of security events used for 279 purpose for Security Policy definition. 281 Threat-Map: This contains a list of threat levels used for 282 purpose for Security Policy definition. 284 3.2. Condition Sub-Model 286 This object represents Conditions that Security Admin wants to apply 287 the checking on the traffic in order to determine whether the set of 288 actions in the Rule can be executed or not. 290 The Condition object SHALL have following information: 292 Source: This field identifies the source of the traffic. This 293 could be a reference to either Policy-Endpoint-Group, 294 Threat-Feed or Custom-List as defined earlier. This could 295 be a special object "ALL" that matches all traffic. This 296 could also be Telemetry-Source for telemetry collection 297 policy. 299 Destination: This field identifies the destination of the 300 traffic. This could be a reference to either Policy- 301 Endpoint-Group, Threat-Feed or Custom-List as defined 302 earlier. This could be a special object "ALL" that matches 303 all traffic. This could also be Telemetry- Destination for 304 telemetry collection policy. 306 Match: This field identifies the match criteria used to evaluate 307 whether the specified action needs to be taken or not. 308 This could be either a Policy-Endpoint-Group identifying an 309 Application set or a set of traffic rules. 311 Match-Direction: This field identifies whether the match criteria 312 is to be evaluated for both directions or only one 313 direction of the traffic with a default of allowing the 314 other direction for stateful match conditions. This is 315 optional and by default a rule should apply to both 316 directions. 318 Exception: This field identifies the exception consideration when 319 a rule is evaluated for a given communication. This could 320 be a reference to "Policy-Endpoint-Group" object or set of 321 traffic matching criteria. 323 3.3. Action Sub-Model 325 This object represents actions that Security Admin wants to perform 326 based on certain traffic class. 328 The Action object SHALL have following information: 330 Name: This field identifies the name of this object. 332 Date: This field indicates the date when this object was created 333 or last modified. 335 Primary-Action: This field identifies the action when a rule is 336 matched by an NSF. The action could be one of "PERMIT", 337 "DENY", "MIRROR", "REDIRECT", "RATE-LIMIT", "TRAFFIC- 338 CLASS", "AUTHENTICATE-SESSION", "IPS", "APP-FIREWALL", or 339 "COLLECT". 341 Secondary-Action: Security Admin can also specify additional 342 actions if a rule is matched. This could be one of "LOG", 343 "SYSLOG", or "SESSION-LOG". 345 4. Information Model for Multi Tenancy 347 Multi-tenancy is an important aspect of any application that enables 348 multiple administrative domains in order to manage application 349 resources. An Enterprise organization may have multiple tenants or 350 departments such as Human Resources (HR), Finance, and Legal, with 351 each tenant having a need to manage their own Security Policies. In 352 a Service Provider, a tenant could represent a Customer that wants to 353 manage its own Security Policies. 355 There are multiple managed objects that constitute multi-tenancy 356 aspects. This section lists these objects and any relationship among 357 these objects. 359 4.1. Policy-Domain 361 This object defines a boundary for the purpose of policy management 362 within a Security Controller. This may vary based on how the 363 Security Controller is deployed and hosted. For example, if an 364 Enterprise hosts a Security Controller in their network; the domain 365 in this case could just be the one that represents that Enterprise. 366 But if a Cloud Service Provider hosts managed services, then a domain 367 could represent a single customer of that Provider. Multi-tenancy 368 model should be able to work in all such environments. 370 The Policy-Domain object SHALL have following information: 372 Name: Name of the organization or customer representing this 373 domain. 375 Address: Address of the organization or customer. 377 Contact: Contact information of the organization or customer. 379 Date: Date when this account was created or last modified. 381 Authentication-Method: Authentication method to be used for this 382 domain. It should be a reference to a 'Policy-Management- 383 Authentication-Method' object. 385 4.2. Policy-Tenant 387 This object defines an entity within an organization. The entity 388 could be a department or business unit within an Enterprise 389 organization that would like to manage its own Policies due to 390 regulatory compliance or business reasons. 392 The Policy-Tenant object SHALL have following information: 394 Name: Name of the Department or Division within an organization. 396 Date: Date when this account was created or last modified. 398 Domain: This field identifies the domain to which this tenant 399 belongs. This should be a reference to a Policy-Domain 400 object. 402 4.3. Policy-Role 404 This object defines a set of permissions assigned to a user in an 405 organization that wants to manage its own Security Policies. It 406 provides a convenient way to assign policy users to a job function or 407 a set of permissions within the organization. 409 The Policy-Role object SHALL have the following information: 411 Name: This field identifies the name of the role. 413 Date: Date when this role was created or last modified. 415 Access-Profile: This field identifies the access profile for the 416 role. The profile grants or denies the permissions to 417 access Endpoint Groups for the purpose of policy management 418 or may restrict certain operations related to policy 419 managements. 421 4.4. Policy-User 423 This object represents a unique identity within an organization. The 424 identity authenticates with Security Controller using credentials 425 such as a password or token in order to perform policy management. A 426 user may be an individual, system, or application requiring access to 427 Security Controller. 429 The Policy-User object SHALL have the following information: 431 Name: Name of a user. 433 Date: Date when this user was created or last modified. 435 Password: User password for basic authentication. 437 Email: E-mail address of the user. 439 Scope-Type: This field identifies whether the user has domain- 440 wide or tenant-wide privileges. 442 Scope-Reference: This field should be a reference to either a 443 Policy-Domain or a Policy-Tenant object. 445 Role: This field should be a reference to a Policy-Role object 446 that defines the specific permissions. 448 4.5. Policy-Management-Authentication-Method 450 This object represents authentication schemes supported by Security 451 Controller. 453 This Policy-Management-Authentication-Method object SHALL have the 454 following information: 456 Name: This field identifies name of this object. 458 Date: Date when this object was created or last modified. 460 Authentication-Method: This field identifies the authentication 461 methods. It could be a password-based, token-based, 462 certificate-based or single sign-on authentication. 464 Mutual-Authentication: This field indicates whether mutual 465 authentication is mandatory or not. 467 Token-Server: This field stores the information about server that 468 validates the token submitted as credentials. 470 Certificate-Server: This field stores the information about 471 server that validates certificates submitted as 472 credentials. 474 Single Sign-on-Server: This field stores the information about 475 server that validates user credentials. 477 5. Information Model for Policy Endpoint Groups 479 The Policy Endpoint Group is a very important part of building User- 480 construct based policies. Security Admin would create and use these 481 objects to represent a logical entity in their business environment, 482 where a Security Policy is to be applied. 484 There are multiple managed objects that constitute a Policy Endpoint 485 Group. This section lists these objects and relationship among these 486 objects. 488 5.1. Tag-Source 490 This object represents information source for tag. The tag in a 491 group must be mapped to its corresponding contents to enforce a 492 Security Policy. 494 Tag-Source object SHALL have the following information: 496 Name: This field identifies name of this object. 498 Date: Date when this object was created or last modified. 500 Tag-Type: This field identifies the Endpoint Group type. It can 501 be a User-Group, App-Group, Device-Group or Location-Group. 503 Tag-Source-Server: This field identifies information related to 504 the source of the tag such as IP address and UDP/TCP port 505 information. 507 Tag-Source-Application: This filed identifies the protocol, e.g., 508 LDAP, Active Directory, or CMDB used to communicate with a 509 server. 511 Tag-Source-Credentials: This field identifies the credential 512 information needed to access the server. 514 5.2. User-Group 516 This object represents a user group based on either tag or other 517 information. 519 The User-Group object SHALL have the following information: 521 Name: This field identifies the name of this object. 523 Date: Date when this object was created or last modified. 525 Group-Type: This field identifies whether the user group is based 526 on User-tag, User-name or IP-address. 528 Metadata-Server: This field should be a reference to a Metadata- 529 Source object. 531 Group-Member: This field is a list of User-tag, User-names or IP 532 addresses based on Group-Type. 534 Risk-Level: This field represents the risk level or importance of 535 the Endpoint to Security Admin for policy purpose; the 536 valid range may be 0 to 9. 538 5.3. Device-Group 540 This object represents a device group based on either tag or other 541 information. 543 The Device-Group object SHALL have the following information: 545 Name: This field identifies the name of this object. 547 Date: Date when this object was created or last modified. 549 Group-Type: This field identifies whether the device group is 550 based on Device-tag or Device-name or IP address. 552 Tag-Server: This field should be a reference to a Tag-Source 553 object. 555 Group-Member: This field is a list of Device-tag, Device-name or 556 IP address based on Group-Type. 558 Risk-Level: This field represents the risk level or importance of 559 the Endpoint to Security Admin for policy purpose; the 560 valid range may be 0 to 9. 562 5.4. Application-Group 564 This object represents an application group based on either tag or 565 other information. 567 The Application-Group object SHALL have the following information: 569 Name: This field identifies the name of this object. 571 Date: Date when this object was created or last modified. 573 Group-Type: This field identifies whether the application group 574 is based on App-tag or App-name, or IP address. 576 Tag-Server: This field should be a reference to a Tag-Source 577 object. 579 Group-Member: This field is a list of Application-tag 580 Application-name or IP address and port information based 581 on Group-Type. 583 Risk-Level: This field represents the risk level or importance of 584 the Endpoint to Security Admin for policy purpose; the 585 valid range may be 0 to 9. 587 5.5. Location-Group 589 This object represents a location group based on either tag or other 590 information. 592 The 'Location-Group' object SHALL have the following information: 594 Name: This field identifies the name of this object. 596 Date: Date when this object was created or last modified. 598 Group-Type: This field identifies whether the location group is 599 based on Location-tag, Location-name or IP address. 601 Tag-Server: This field should be a reference to a Tag-Source 602 object. 604 Group-Member: This field is a list of Location-tag, Location-name 605 or IP addresses based on Group-Type. 607 Risk Level: This field represents the risk level or importance of 608 the Endpoint to Security Admin for policy purpose; the 609 valid range may be 0 to 9. 611 6. Information Model for Threat Prevention 613 The threat prevention plays an important part in the overall security 614 posture by reducing the attack surfaces. This information could come 615 in the form of threat feeds such as Botnet and GeoIP feeds usually 616 from a third party or external service. 618 There are multiple managed objects that constitute this category. 619 This section lists these objects and relationship among these 620 objects. 622 6.1. Threat-Feed 624 This object represents a threat feed such as Botnet servers and 625 GeoIP. 627 The Threat-Feed object SHALL have the following information: 629 Name: This field identifies the name of this object. 631 Date: Date when this object was created or last modified. 633 Feed-Type: This field identifies whether a feed type is IP 634 address-based or URL-based. 636 Feed-Server: This field identifies the information about the feed 637 provider, it may be an external service or local server. 639 Feed-Priority: This field represents the feed priority level to 640 resolve conflict if there are multiple feed sources; the 641 valid range may be 0 to 9. 643 6.2. Custom-List 645 This object represents a custom list created for the purpose of 646 defining exception to threat feeds. An organization may want to 647 allow a certain exception to threat feeds obtained from a third party 649 The Custom-List object SHALL have the following information: 651 Name: This field identifies the name of this object. 653 Date: Date when this object was created or last modified. 655 List-Type: This field identifies whether the list type is IP 656 address-based or URL-based. 658 List-Property: This field identifies the attributes of the list 659 property, e.g., Blacklist or Whitelist. 661 List-Content: This field contains contents such as IP addresses 662 or URL names. 664 6.3. Malware-Scan-Group 666 This object represents information needed to detect malware. This 667 information could come from a local server or uploaded periodically 668 from a third party. 670 The Malware-Scan-Group object SHALL have the following information: 672 Name: This field identifies the name of this object. 674 Date: Date when this object was created or last modified. 676 Signature-Server: This field contains information about the 677 server from where signatures can be downloaded periodically 678 as updates become available. 680 File-Types: This field contains a list of file types needed to be 681 scanned for the virus. 683 Malware-Signatures: This field contains a list of malware 684 signatures or hash values. 686 7. Information Model for Telemetry Data 688 Telemetry provides System Admin with the visibility of the network 689 activities which can be tapped for further security analytics, e.g., 690 detecting potential vulnerabilities, malicious activities, etc. 692 7.1. Telemetry-Data 694 This object contains information collected for telemetry. 696 The Telemetry-Data object SHALL have the following information: 698 Name: This field identifies the name of this object. 700 Date: Date when this object was created or last modified. 702 Log-Data: This field identifies whether Log data need to be 703 collected. 705 Syslog-Data This field identifies whether Syslog data need to be 706 collected. 708 SNMP-Data: This field identifies whether SNMP traps and alarm 709 data need to be collected. 711 sFlow-Record: This field identifies whether sFlow records need to 712 be collected. 714 NetFlow-Record: This field identifies whether NetFlow record need 715 to be collected. 717 NSF-Stats: This field identifies whether statistics need to be 718 collected from an NSF. 720 7.2. Telemetry-Source 722 This object contains information related to telemetry source. The 723 source would be an NSF in the network. 725 The Telemetry-Source object SHALL have the following information: 727 Name: This field identifies the name of this object. 729 Date: Date when this object was created or last modified. 731 Source-Type: This field contains the type of the NSF telemetry 732 source: "NETWORK-NSF", "FIREWALL-NSF", "IDS-NSF", "IPS- 733 NSF", "PROXY-NSF or "OTHER-NSF". 735 NSF-Source: This field contains information such as IP address 736 and protocol (UDP or TCP) port number of the NSF providing 737 telemetry data. 739 NSF-Credentials: This field contains a username and a password 740 used to authenticate the NSF. 742 Collection-Interval: This field contains time in milliseconds 743 between each data collection. For example, a value of 744 5,000 means data is streamed to collector every 5 seconds. 745 Value of 0 means data streaming is event-based. 747 Collection-Method: This field contains a method of collection 748 whether it is PUSH-based or PULL-based. 750 Heartbeat-Interval: This field contains time in seconds when the 751 source must send telemetry heartbeat. 753 QoS-Marking: This field contains a DSCP value source marked on 754 its generated telemetry packets. 756 7.3. Telemetry-Destination 758 This object contains information related to telemetry destination. 759 The destination is usually a collector which is either a part of 760 Security Controller or external system such as SIEM. 762 The Telemetry-Destination object SHALL have the following 763 information: 765 Name: This field identifies the name of this object. 767 Date: Date when this object was created or last modified. 769 Collector-Source: This field contains the information such as IP 770 address and protocol (UDP or TCP) port number for the 771 collector's destination. 773 Collector-Credentials: This field contains a username and a 774 password provided by the collector. 776 Data-Encoding: This field contains the telemetry data encoding, 777 which could in the form of a schema. 779 Data-Transport: This field contains streaming telemetry data 780 protocols: whether it is gRPC, protocol buffer over UDP, 781 etc. 783 8. Security Considerations 785 An information model provides a mechanism to protect Consumer-Facing 786 interface between System Admin (i.e., I2NSF User) and Security 787 Controller. One of the specified mechanism must be used to protect 788 an Enterprise network, data and all resources from external attacks. 789 This information model mandates that the interface must have proper 790 authentication and authorization with Role-Based Access Controls to 791 address the multi-tenancy requirement. The document does not mandate 792 that a particular mechanism should be used because a different 793 organization may have different needs based on their deployment. 795 9. IANA Considerations 797 This document requires no IANA actions. RFC Editor: Please remove 798 this section before publication. 800 10. Acknowledgments 802 This work was supported by Institute for Information & communications 803 Technology Promotion (IITP) grant funded by the Korea government 804 (MSIT) (No. R-20160222-002755, Cloud based Security Intelligence 805 Technology Development for the Customized Security Service 806 Provisioning). 808 11. Contributors 810 This document is the work of I2NSF working group, greatly benefiting 811 from inputs and suggestions by Kunal Modasiya, Prakash T. Sehsadri 812 and Srinivas Nimmagadda from Juniper Networks. The authors sincerely 813 appreciate their contributions. 815 The following are contributing authors of this document, who are 816 considered co-authors: 818 o Eunsoo Kim (Sungkyunkwan University) 820 12. Informative References 822 [I-D.ietf-i2nsf-capability] 823 Xia, L., Strassner, J., Basile, C., and D. Lopez, 824 "Information Model of NSFs Capabilities", draft-ietf- 825 i2nsf-capability-00 (work in progress), September 2017. 827 [I-D.ietf-i2nsf-client-facing-interface-req] 828 Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic, 829 S., and L. Xia, "Requirements for Client-Facing Interface 830 to Security Controller", draft-ietf-i2nsf-client-facing- 831 interface-req-04 (work in progress), January 2018. 833 [I-D.ietf-i2nsf-terminology] 834 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 835 Birkholz, "Interface to Network Security Functions (I2NSF) 836 Terminology", draft-ietf-i2nsf-terminology-05 (work in 837 progress), January 2018. 839 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 840 Information Models and Data Models", RFC 3444, 841 DOI 10.17487/RFC3444, January 2003, 842 . 844 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 845 and J. Jeong, "Interface to Network Security Functions 846 (I2NSF): Problem Statement and Use Cases", RFC 8192, 847 DOI 10.17487/RFC8192, July 2017, 848 . 850 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 851 Kumar, "Framework for Interface to Network Security 852 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 853 . 855 Appendix A. Changes from draft-kumar-i2nsf-client-facing-interface- 856 im-04 858 The following changes have been made from draft-kumar-i2nsf-client- 859 facing-interface-im-04: 861 o In Section 3.2, the description of Match-Direction was corrected. 863 o References are updated. 865 Authors' Addresses 867 Rakesh Kumar 868 Juniper Networks 869 1133 Innovation Way 870 Sunnyvale, CA 94089 871 US 873 Email: rakeshkumarcloud@gmail.com 875 Anil Lohiya 876 Juniper Networks 877 1133 Innovation Way 878 Sunnyvale, CA 94089 879 US 881 Email: alohiya@juniper.net 883 Dave Qi 884 Bloomberg 885 731 Lexington Avenue 886 New York, NY 10022 887 US 889 Email: DQI@bloomberg.net 891 Nabil Bitar 892 Nokia 893 755 Ravendale Drive 894 Mountain View, CA 94043 895 US 897 Email: nabil.bitar@nokia.com 898 Senad Palislamovic 899 Nokia 900 755 Ravendale Drive 901 Mountain View, CA 94043 902 US 904 Email: senad.palislamovic@nokia.com 906 Liang Xia 907 Huawei 908 101 Software Avenue 909 Nanjing, Jiangsu 210012 910 China 912 Email: Frank.Xialiang@huawei.com 914 Jaehoon Paul Jeong 915 Department of Software 916 Sungkyunkwan University 917 2066 Seobu-Ro, Jangan-Gu 918 Suwon, Gyeonggi-Do 16419 919 Republic of Korea 921 Phone: +82 31 299 4957 922 Fax: +82 31 290 7996 923 Email: pauljeong@skku.edu 924 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php