idnits 2.17.1 draft-kumar-i2nsf-client-facing-interface-im-04.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 167: '...he Policy object SHALL have following ...' RFC 2119 keyword, line 214: '... The rule object SHALL have the follow...' RFC 2119 keyword, line 245: '... Event object SHALL have following i...' RFC 2119 keyword, line 269: '... Group object SHALL have following i...' RFC 2119 keyword, line 288: '...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 (October 30, 2017) is 2369 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-03 == Outdated reference: A later version (-10) exists of draft-ietf-i2nsf-framework-08 == Outdated reference: A later version (-08) exists of draft-ietf-i2nsf-terminology-04 Summary: 2 errors (**), 0 flaws (~~), 5 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: May 3, 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 October 30, 2017 16 Information Model for Consumer-Facing Interface to Security Controller 17 draft-kumar-i2nsf-client-facing-interface-im-04 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 May 3, 2018. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (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 . . . . . . . . . . . . . . . . . . . 6 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 98 1. Introduction 100 Interface to Network Security Functions (I2NSF) defines a Consumer- 101 Facing Interface to deliver high-level security policies to Security 102 Controller [RFC8192][I-D.ietf-i2nsf-framework] for securiy 103 enforcement in Network Security Functions (NSFs). 105 The Consumer-Facing interface would be built using a set of objects, 106 with each object capturing a unique set of information from Security 107 Admin (i.e., I2NSF User [I-D.ietf-i2nsf-framework]) needed to express 108 a Security Policy. An object may have relationship with various 109 other objects to express a complete set of requirement. An 110 information model captures the managed objects and relationship among 111 these objects. The information model proposed in this document is in 112 accordance with interface requirements as defined in 113 [I-D.ietf-i2nsf-client-facing-interface-req]. 115 An NSF Capability model is proposed in [I-D.ietf-i2nsf-capability] as 116 the basic model for both the NSF-Facing interface and Consumer-Facing 117 interface security policy model of this document. The information 118 model proposed in this document is structured in accordance with the 119 "Event-Condition-Event" (ECA) policy model. 121 [RFC3444] explains differences between an information and data model. 122 This document use the guidelines in [RFC3444] to define an 123 information model for Consumer-Facing interface in this document. A 124 data model, which represents an implementation of the proposed 125 information model in a specific data representation language, will be 126 defined in a separate document. 128 2. Conventions Used in this Document 130 BSS: Business Support System 132 CLI: Command Line Interface 134 CMDB: Configuration Management Database 136 Controller: Security Controller or Management System 138 CRUD: Create, Retrieve, Update, Delete 140 FW: Firewall 142 GUI: Graphical User Interface 143 IDS: Intrusion Detection System 145 IPS: Intrusion Prevention System 147 LDAP: Lightweight Directory Access Protocol 149 NSF: Network Security Function, defined by 150 [I-D.ietf-i2nsf-terminology] 152 OSS: Operations Support System 154 RBAC: Role-Based Access Control 156 SIEM: Security Information and Event Management 158 URL: Universal Resource Locator 160 vNSF: NSF being instantiated on Virtual Machines 162 3. Information Model for Policy 164 A Policy object represents a mechanism to express a Security Policy 165 by Security Admin (i.e., I2NSF User) using Consumer-Facing interface 166 toward Security Controller; the policy would be enforced on an NSF. 167 The Policy object SHALL have following information: 169 Name: This field identifies the name of this object. 171 Date: Date when this object was created or last modified. 173 Multi-Tenancy: The multi-tenant environment information in which 174 the policy is applied. The Rules in the Policy can refer 175 to sub-objects (e.g., domain, tenant, role, and user) of 176 it. It can be either a reference to a Multi-Tenancy object 177 defined in another place, or a concrete object. See 178 details in Section 4. 180 End-Group: This field contains a list of logical entities in the 181 business environment where a Security Policy is to be 182 applied. It can be referenced by the Condition objects in 183 a Rule, e.g., Source, Destination, Match, etc. It can be 184 either a reference to an End-Group object defined in other 185 place, or a concrete object. See details in Section 5. 187 Threat-Feed: This field represents threat feed such as Botnet 188 servers, GeoIP, and Malware signature. This information 189 can be referenced by the Rule Action object directly to 190 execute the threat mitigation. See details in Section 6. 192 Telemetry-Data: This field represents the telemetry collection 193 related information that the Rule Action object can refer 194 to about how to collect the interested telemetry 195 information, for example, what type of telemetry to 196 collect, where the telemetry source is, where to send the 197 telemetry information. See details in Section 7. 199 Rules: This field contains a list of rules. If the rule does not 200 have a user-defined precedence, then any conflict must be 201 manually resolved. 203 Owner: This field defines the owner of this policy. Only the 204 owner is authorized to modify the contents of the policy. 206 A policy is a container of Rules. In order to express a Rule, a Rule 207 must have complete information such as where and when a policy needs 208 to be applied. This is done by defining a set of managed objects and 209 relationship among them. A Policy Rule may be related segmentation, 210 threat mitigation or telemetry data collection from an NSF in the 211 network, which will be specified as the sub-model of the policy model 212 in the subsequent sections. 214 The rule object SHALL have the following information: 216 Name: This field identifies the name of this object. 218 Date: This field indicates the date when this object was created 219 or last modified. 221 Event: This field includes the information to determine whether 222 the Rule Condition can be evaluated or not. See details in 223 Section 3.1. 225 Condition: This field contains all the checking conditions to 226 apply to the objective traffic. See details in 227 Section 3.2. 229 Action: This field identifies the action taken when a rule is 230 matched. There is always an implicit action to drop 231 traffic if no rule is matched for a traffic type. See 232 details in Section 3.3. 234 Precedence: This field identifies the precedence assigned to this 235 rule by Security Admin. This is helpful in conflict 236 resolution when two or more rules match a given traffic 237 class. 239 3.1. Event Sub-Model 241 The Event Object contains information related to scheduling a Rule. 242 The Rule could be activated based on a time calendar or security 243 event including threat level changes. 245 Event object SHALL have following information: 247 Name: This field identifies the name of this object. 249 Date: This field indicates the date when this object was created 250 or last modified. 252 Event-Type: This field identifies whether the event of triggering 253 policy enforcement is "ADMIN-ENFORCED", "TIME-ENFORCED" or 254 "EVENT-ENFORCED". 256 Time-Information: This field contains a time calendar such as 257 "BEGIN-TIME" and "END-TIME" for one time enforcement or 258 recurring time calendar for periodic enforcement. 260 Event-Map-Group: This field contains security events or threat 261 map in order to determine when a policy needs to be 262 activated. This is a reference to Event-Map-Group defined 263 later. 265 3.1.1. Event-Map-Group 267 This object represents an event map containing security events and 268 threat levels used for dynamic policy enforcement. The Event-Map- 269 Group object SHALL have following information: 271 Name: This field identifies the name of this object. 273 Date: This field indicates the date when this object was created 274 or last modified. 276 Security-Events: This contains a list of security events used for 277 purpose for Security Policy definition. 279 Threat-Map: This contains a list of threat levels used for 280 purpose for Security Policy definition. 282 3.2. Condition Sub-Model 284 This object represents Conditions that Security Admin wants to apply 285 the checking on the traffic in order to determine whether the set of 286 actions in the Rule can be executed or not. 288 The Condition object SHALL have following information: 290 Source: This field identifies the source of the traffic. This 291 could be a reference to either Policy-Endpoint-Group, 292 Threat-Feed or Custom-List as defined earlier. This could 293 be a special object "ALL" that matches all traffic. This 294 could also be Telemetry-Source for telemetry collection 295 policy. 297 Destination: This field identifies the destination of the 298 traffic. This could be a reference to either Policy- 299 Endpoint-Group, Threat-Feed or Custom-List as defined 300 earlier. This could be a special object "ALL" that matches 301 all traffic. This could also be Telemetry- Destination for 302 telemetry collection policy. 304 Match: This field identifies the match criteria used to evaluate 305 whether the specified action needs to be taken or not. 306 This could be either a Policy-Endpoint-Group identifying an 307 Application set or a set of traffic rules. 309 Match-Direction: This field identifies the match criteria used to 310 evaluate whether the specified action needs to be taken or 311 not. This could be either a Policy-Endpoint-Group 312 identifying an Application set or a set of traffic rules. 314 Exception: This field identifies the exception consideration when 315 a rule is evaluated for a given communication. This could 316 be a reference to "Policy-Endpoint-Group" object or set of 317 traffic matching criteria. 319 3.3. Action Sub-Model 321 This object represents actions that Security Admin wants to perform 322 based on certain traffic class. 324 The Action object SHALL have following information: 326 Name: This field identifies the name of this object. 328 Date: This field indicates the date when this object was created 329 or last modified. 331 Primary-Action: This field identifies the action when a rule is 332 matched by an NSF. The action could be one of "PERMIT", 333 "DENY", "MIRROR", "REDIRECT", "RATE-LIMIT", "TRAFFIC- 334 CLASS", "AUTHENTICATE-SESSION", "IPS", "APP-FIREWALL", or 335 "COLLECT". 337 Secondary-Action: Security Admin can also specify additional 338 actions if a rule is matched. This could be one of "LOG", 339 "SYSLOG", or "SESSION-LOG". 341 4. Information Model for Multi Tenancy 343 Multi-tenancy is an important aspect of any application that enables 344 multiple administrative domains in order to manage application 345 resources. An Enterprise organization may have multiple tenants or 346 departments such as Human Resources (HR), Finance, and Legal, with 347 each tenant having a need to manage their own Security Policies. In 348 a Service Provider, a tenant could represent a Customer that wants to 349 manage its own Security Policies. 351 There are multiple managed objects that constitute multi-tenancy 352 aspects. This section lists these objects and any relationship among 353 these objects. 355 4.1. Policy-Domain 357 This object defines a boundary for the purpose of policy management 358 within a Security Controller. This may vary based on how the 359 Security Controller is deployed and hosted. For example, if an 360 Enterprise hosts a Security Controller in their network; the domain 361 in this case could just be the one that represents that Enterprise. 362 But if a Cloud Service Provider hosts managed services, then a domain 363 could represent a single customer of that Provider. Multi-tenancy 364 model should be able to work in all such environments. 366 The Policy-Domain object SHALL have following information: 368 Name: Name of the organization or customer representing this 369 domain. 371 Address: Address of the organization or customer. 373 Contact: Contact information of the organization or customer. 375 Date: Date when this account was created or last modified. 377 Authentication-Method: Authentication method to be used for this 378 domain. It should be a reference to a 'Policy-Management- 379 Authentication-Method' object. 381 4.2. Policy-Tenant 383 This object defines an entity within an organization. The entity 384 could be a department or business unit within an Enterprise 385 organization that would like to manage its own Policies due to 386 regulatory compliance or business reasons. 388 The Policy-Tenant object SHALL have following information: 390 Name: Name of the Department or Division within an organization. 392 Date: Date when this account was created or last modified. 394 Domain: This field identifies the domain to which this tenant 395 belongs. This should be a reference to a Policy-Domain 396 object. 398 4.3. Policy-Role 400 This object defines a set of permissions assigned to a user in an 401 organization that wants to manage its own Security Policies. It 402 provides a convenient way to assign policy users to a job function or 403 a set of permissions within the organization. 405 The Policy-Role object SHALL have the following information: 407 Name: This field identifies the name of the role. 409 Date: Date when this role was created or last modified. 411 Access-Profile: This field identifies the access profile for the 412 role. The profile grants or denies the permissions to 413 access Endpoint Groups for the purpose of policy management 414 or may restrict certain operations related to policy 415 managements. 417 4.4. Policy-User 419 This object represents a unique identity within an organization. The 420 identity authenticates with Security Controller using credentials 421 such as a password or token in order to perform policy management. A 422 user may be an individual, system, or application requiring access to 423 Security Controller. 425 The Policy-User object SHALL have the following information: 427 Name: Name of a user. 429 Date: Date when this user was created or last modified. 431 Password: User password for basic authentication. 433 Email: E-mail address of the user. 435 Scope-Type: This field identifies whether the user has domain- 436 wide or tenant-wide privileges. 438 Scope-Reference: This field should be a reference to either a 439 Policy-Domain or a Policy-Tenant object. 441 Role: This field should be a reference to a Policy-Role object 442 that defines the specific permissions. 444 4.5. Policy-Management-Authentication-Method 446 This object represents authentication schemes supported by Security 447 Controller. 449 This Policy-Management-Authentication-Method object SHALL have the 450 following information: 452 Name: This field identifies name of this object. 454 Date: Date when this object was created or last modified. 456 Authentication-Method: This field identifies the authentication 457 methods. It could be a password-based, token-based, 458 certificate-based or single sign-on authentication. 460 Mutual-Authentication: This field indicates whether mutual 461 authentication is mandatory or not. 463 Token-Server: This field stores the information about server that 464 validates the token submitted as credentials. 466 Certificate-Server: This field stores the information about 467 server that validates certificates submitted as 468 credentials. 470 Single Sign-on-Server: This field stores the information about 471 server that validates user credentials. 473 5. Information Model for Policy Endpoint Groups 475 The Policy Endpoint Group is a very important part of building User- 476 construct based policies. Security Admin would create and use these 477 objects to represent a logical entity in their business environment, 478 where a Security Policy is to be applied. 480 There are multiple managed objects that constitute a Policy Endpoint 481 Group. This section lists these objects and relationship among these 482 objects. 484 5.1. Tag-Source 486 This object represents information source for tag. The tag in a 487 group must be mapped to its corresponding contents to enforce a 488 Security Policy. 490 Tag-Source object SHALL have the following information: 492 Name: This field identifies name of this object. 494 Date: Date when this object was created or last modified. 496 Tag-Type: This field identifies the Endpoint Group type. It can 497 be a User-Group, App-Group, Device-Group or Location-Group. 499 Tag-Source-Server: This field identifies information related to 500 the source of the tag such as IP address and UDP/TCP port 501 information. 503 Tag-Source-Application: This filed identifies the protocol, e.g. 504 LDAP, Active Directory, or CMDB used to communicate with a 505 server. 507 Tag-Source-Credentials: This field identifies the credential 508 information needed to access the server. 510 5.2. User-Group 512 This object represents a user group based on either tag or other 513 information. 515 The User-Group object SHALL have the following information: 517 Name: This field identifies the name of this object. 519 Date: Date when this object was created or last modified. 521 Group-Type: This field identifies whether the user group is based 522 on User-tag, User-name or IP-address. 524 Metadata-Server: This field should be a reference to a Metadata- 525 Source object. 527 Group-Member: This field is a list of User-tag, User-names or IP 528 addresses based on Group-Type. 530 Risk-Level: This field represents the risk level or importance of 531 the Endpoint to Security Admin for policy purpose; the 532 valid range may be 0 to 9. 534 5.3. Device-Group 536 This object represents a device group based on either tag or other 537 information. 539 The Device-Group object SHALL have the following information: 541 Name: This field identifies the name of this object. 543 Date: Date when this object was created or last modified. 545 Group-Type: This field identifies whether the device group is 546 based on Device-tag or Device-name or IP address. 548 Tag-Server: This field should be a reference to a Tag-Source 549 object. 551 Group-Member: This field is a list of Device-tag, Device-name or 552 IP address based on Group-Type. 554 Risk-Level: This field represents the risk level or importance of 555 the Endpoint to Security Admin for policy purpose; the 556 valid range may be 0 to 9. 558 5.4. Application-Group 560 This object represents an application group based on either tag or 561 other information. 563 The Application-Group object SHALL have the following information: 565 Name: This field identifies the name of this object. 567 Date: Date when this object was created or last modified. 569 Group-Type: This field identifies whether the application group 570 is based on App-tag or App-name, or IP address. 572 Tag-Server: This field should be a reference to a Tag-Source 573 object. 575 Group-Member: This field is a list of Application-tag 576 Application-name or IP address and port information based 577 on Group-Type. 579 Risk-Level: This field represents the risk level or importance of 580 the Endpoint to Security Admin for policy purpose; the 581 valid range may be 0 to 9. 583 5.5. Location-Group 585 This object represents a location group based on either tag or other 586 information. 588 The 'Location-Group' object SHALL have the following information: 590 Name: This field identifies the name of this object. 592 Date: Date when this object was created or last modified. 594 Group-Type: This field identifies whether the location group is 595 based on Location-tag, Location-name or IP address. 597 Tag-Server: This field should be a reference to a Tag-Source 598 object. 600 Group-Member: This field is a list of Location-tag, Location-name 601 or IP addresses based on Group-Type. 603 Risk Level: This field represents the risk level or importance of 604 the Endpoint to Security Admin for policy purpose; the 605 valid range may be 0 to 9. 607 6. Information Model for Threat Prevention 609 The threat prevention plays an important part in the overall security 610 posture by reducing the attack surfaces. This information could come 611 in the form of threat feeds such as Botnet and GeoIP feeds usually 612 from a third party or external service. 614 There are multiple managed objects that constitute this category. 615 This section lists these objects and relationship among these 616 objects. 618 6.1. Threat-Feed 620 This object represents a threat feed such as Botnet servers and 621 GeoIP. 623 The Threat-Feed object SHALL have the following information: 625 Name: This field identifies the name of this object. 627 Date: Date when this object was created or last modified. 629 Feed-Type: This field identifies whether a feed type is IP 630 address-based or URL-based. 632 Feed-Server: This field identifies the information about the feed 633 provider, it may be an external service or local server. 635 Feed-Priority: This field represents the feed priority level to 636 resolve conflict if there are multiple feed sources; the 637 valid range may be 0 to 9. 639 6.2. Custom-List 641 This object represents a custom list created for the purpose of 642 defining exception to threat feeds. An organization may want to 643 allow a certain exception to threat feeds obtained from a third party 645 The Custom-List object SHALL have the following information: 647 Name: This field identifies the name of this object. 649 Date: Date when this object was created or last modified. 651 List-Type: This field identifies whether the list type is IP 652 address-based or URL-based. 654 List-Property: This field identifies the attributes of the list 655 property, e.g., Blacklist or Whitelist. 657 List-Content: This field contains contents such as IP addresses 658 or URL names. 660 6.3. Malware-Scan-Group 662 This object represents information needed to detect malware. This 663 information could come from a local server or uploaded periodically 664 from a third party. 666 The Malware-Scan-Group object SHALL have the following information: 668 Name: This field identifies the name of this object. 670 Date: Date when this object was created or last modified. 672 Signature-Server: This field contains information about the 673 server from where signatures can be downloaded periodically 674 as updates become available. 676 File-Types: This field contains a list of file types needed to be 677 scanned for the virus. 679 Malware-Signatures: This field contains a list of malware 680 signatures or hash values. 682 7. Information Model for Telemetry Data 684 Telemetry provides System Admin with the visibility of the network 685 activities which can be tapped for further security analytics, e.g., 686 detecting potential vulnerabilities, malicious activities, etc. 688 7.1. Telemetry-Data 690 This object contains information collected for telemetry. 692 The Telemetry-Data object SHALL have the following information: 694 Name: This field identifies the name of this object. 696 Date: Date when this object was created or last modified. 698 Log-Data: This field identifies whether Log data need to be 699 collected. 701 Syslog-Data This field identifies whether Syslog data need to be 702 collected. 704 SNMP-Data: This field identifies whether SNMP traps and alarm 705 data need to be collected. 707 sFlow-Record: This field identifies whether sFlow records need to 708 be collected. 710 NetFlow-Record: This field identifies whether NetFlow record need 711 to be collected. 713 NSF-Stats: This field identifies whether statistics need to be 714 collected from an NSF. 716 7.2. Telemetry-Source 718 This object contains information related to telemetry source. The 719 source would be an NSF in the network. 721 The Telemetry-Source object SHALL have the following information: 723 Name: This field identifies the name of this object. 725 Date: Date when this object was created or last modified. 727 Source-Type: This field contains the type of the NSF telemetry 728 source: "NETWORK-NSF", "FIREWALL-NSF", "IDS-NSF", "IPS- 729 NSF", "PROXY-NSF or "OTHER-NSF". 731 NSF-Source: This field contains information such as IP address 732 and protocol (UDP or TCP) port number of the NSF providing 733 telemetry data. 735 NSF-Credentials: This field contains a username and a password 736 used to authenticate the NSF. 738 Collection-Interval: This field contains time in milliseconds 739 between each data collection. For example, a value of 740 5,000 means data is streamed to collector every 5 seconds. 741 Value of 0 means data streaming is event-based. 743 Collection-Method: This field contains a method of collection 744 whether it is PUSH-based or PULL-based. 746 Heartbeat-Interval: This field contains time in seconds when the 747 source must send telemetry heartbeat. 749 QoS-Marking: This field contains a DSCP value source marked on 750 its generated telemetry packets. 752 7.3. Telemetry-Destination 754 This object contains information related to telemetry destination. 755 The destination is usually a collector which is either a part of 756 Security Controller or external system such as SIEM. 758 The Telemetry-Destination object SHALL have the following 759 information: 761 Name: This field identifies the name of this object. 763 Date: Date when this object was created or last modified. 765 Collector-Source: This field contains the information such as IP 766 address and protocol (UDP or TCP) port number for the 767 collector's destination. 769 Collector-Credentials: This field contains a username and a 770 password provided by the collector. 772 Data-Encoding: This field contains the telemetry data encoding, 773 which could in the form of a schema. 775 Data-Transport: This field contains streaming telemetry data 776 protocols: whether it is gRPC, protocol buffer over UDP, 777 etc. 779 8. Security Considerations 781 An information model provides a mechanism to protect Consumer-Facing 782 interface between System Admin (i.e., I2NSF User) and Security 783 Controller. One of the specified mechanism must be used to protect 784 an Enterprise network, data and all resources from external attacks. 785 This information model mandates that the interface must have proper 786 authentication and authorization with Role-Based Access Controls to 787 address the multi-tenancy requirement. The document does not mandate 788 that a particular mechanism should be used because a different 789 organization may have different needs based on their deployment. 791 9. IANA Considerations 793 This document requires no IANA actions. RFC Editor: Please remove 794 this section before publication. 796 10. Acknowledgments 798 This work was supported by Institute for Information & communications 799 Technology Promotion (IITP) grant funded by the Korea government 800 (MSIT) (No. R-20160222-002755, Cloud based Security Intelligence 801 Technology Development for the Customized Security Service 802 Provisioning). 804 11. Contributors 806 This document is the work of I2NSF working group, greatly benefiting 807 from inputs and suggestions by Kunal Modasiya, Prakash T. Sehsadri 808 and Srinivas Nimmagadda from Juniper Networks. The authors sincerely 809 appreciate their contributions. 811 The following are contributing authors of this document, who are 812 considered co-authors: 814 o Eunsoo Kim (Sungkyunkwan University) 816 12. Informative References 818 [I-D.ietf-i2nsf-capability] 819 Xia, L., Strassner, J., Basile, C., and D. Lopez, 820 "Information Model of NSFs Capabilities", draft-ietf- 821 i2nsf-capability-00 (work in progress), September 2017. 823 [I-D.ietf-i2nsf-client-facing-interface-req] 824 Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic, 825 S., and L. Xia, "Requirements for Client-Facing Interface 826 to Security Controller", draft-ietf-i2nsf-client-facing- 827 interface-req-03 (work in progress), July 2017. 829 [I-D.ietf-i2nsf-framework] 830 Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 831 Kumar, "Framework for Interface to Network Security 832 Functions", draft-ietf-i2nsf-framework-08 (work in 833 progress), October 2017. 835 [I-D.ietf-i2nsf-terminology] 836 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 837 Birkholz, "Interface to Network Security Functions (I2NSF) 838 Terminology", draft-ietf-i2nsf-terminology-04 (work in 839 progress), July 2017. 841 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 842 Information Models and Data Models", RFC 3444, 843 DOI 10.17487/RFC3444, January 2003, 844 . 846 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 847 and J. Jeong, "Interface to Network Security Functions 848 (I2NSF): Problem Statement and Use Cases", RFC 8192, 849 DOI 10.17487/RFC8192, July 2017, 850 . 852 Authors' Addresses 854 Rakesh Kumar 855 Juniper Networks 856 1133 Innovation Way 857 Sunnyvale, CA 94089 858 US 860 Email: rakeshkumarcloud@gmail.com 862 Anil Lohiya 863 Juniper Networks 864 1133 Innovation Way 865 Sunnyvale, CA 94089 866 US 868 Email: alohiya@juniper.net 870 Dave Qi 871 Bloomberg 872 731 Lexington Avenue 873 New York, NY 10022 874 US 876 Email: DQI@bloomberg.net 878 Nabil Bitar 879 Nokia 880 755 Ravendale Drive 881 Mountain View, CA 94043 882 US 884 Email: nabil.bitar@nokia.com 886 Senad Palislamovic 887 Nokia 888 755 Ravendale Drive 889 Mountain View, CA 94043 890 US 892 Email: senad.palislamovic@nokia.com 893 Liang Xia 894 Huawei 895 101 Software Avenue 896 Nanjing, Jiangsu 210012 897 China 899 Email: Frank.Xialiang@huawei.com 901 Jaehoon Paul Jeong 902 Department of Software 903 Sungkyunkwan University 904 2066 Seobu-Ro, Jangan-Gu 905 Suwon, Gyeonggi-Do 16419 906 Republic of Korea 908 Phone: +82 31 299 4957 909 Fax: +82 31 290 7996 910 Email: pauljeong@skku.edu 911 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php