idnits 2.17.1 draft-kumar-i2nsf-client-facing-interface-im-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.kumar-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 170: '...y-Domain' object SHALL have following ...' RFC 2119 keyword, line 192: '...y-Tenant' object SHALL have following ...' RFC 2119 keyword, line 209: '...icy-Role' object SHALL have following ...' RFC 2119 keyword, line 228: '...icy-User' object SHALL have following ...' RFC 2119 keyword, line 251: '...hentication-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 (April 30, 2017) is 2525 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-i2nsf-terminology' is defined on line 733, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-i2nsf-problem-and-use-cases-15 == Outdated reference: A later version (-08) exists of draft-ietf-i2nsf-terminology-03 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: November 1, 2017 D. Qi 6 Bloomberg 7 N. Bitar 8 S. Palislamovic 9 Nokia 10 L. Xia 11 Huawei 12 April 30, 2017 14 Information model for Client-Facing Interface to Security Controller 15 draft-kumar-i2nsf-client-facing-interface-im-02 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.kumar-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 November 1, 2017. 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. Meta-Data-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 need to express a Security Policy. 98 An objects may have relationship with various other objects to 99 express a complete set of requirement. An information model captures 100 the managed objects and relationship among these. The information 101 model proposed in this draft is in accordance with interface 102 requirements as defined in 103 [I-D.kumar-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-problem-and-use-cases] 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 organization may have multiple tenants or departments 152 such as HR, Finance, Legal, with each tenant having a need to manage 153 its own Security Policies. 155 There are multiple managed objects that constitute multi-tenancy 156 aspects. This section lists these objects and any relationship among 157 these objects. 159 3.1. Policy-Domain 161 This object defines a boundary for the purpose of policy management 162 within a Security Controller. This may vary based on how the 163 Security Controller is deployed and hosted. For example, if an 164 Enterprise host a Security Controller in their network; the domain in 165 this case could just be the one that represents that Enterprise. But 166 if a Cloud Service Provider hosts managed services, then a domain 167 could represent a single customer of that Provider. Multi-tenancy 168 model should be applicable in all such environments. 170 The 'Policy-Domain' object SHALL have following information: 172 Name: Name of the organization or customer representing this 173 domain 175 Address: Address of the organization or customer 177 Contact: Contact information of the organization or customer 179 Date: Date this account was created or last modified 181 Authentication Method: Authentication method to be used for this 182 domain. It should be reference to a 'Policy-Management- 183 Authentication-Method' object 185 3.2. Policy-Tenant 187 This object defines an entity within an organization that wants to 188 manage its own Security Policies. The entity could be a Department 189 or a Division that would like to manages its own Policies due to 190 regulatory, compliance or business reasons. 192 The 'Policy-Tenant' object SHALL have following information: 194 Name: Name of the Department or Division within an organization 196 Date: Date this account was created or last modified 198 Domain: This field identifies the domain to which this tenant 199 belongs. This should be reference to a 'Policy-Domain' 200 object 202 3.3. Policy-Role 204 This object defines a set of permissions assigned to a user in an 205 organization that want to manage its own Security Policies. It 206 provides a convenient way to assign policy users to a job function or 207 set of permissions within the organization. 209 The 'Policy-Role' object SHALL have following information: 211 Name: This field identifies name of the role 213 Date: Date this role was created or last modified 215 Access Profile: This field identifies the access profile for the 216 role. The profile grants or denies access to policy 217 objects. Multiple access profiles can be concatenated 218 together 220 3.4. Policy-User 222 This object represents a unique identity within an organization. The 223 identity authenticates with Security Controller using credentials 224 such as a password or token in order to do policy management. A user 225 may be an individual, system, or application requiring access to 226 Security Controller. 228 The 'Policy-User' object SHALL have following information: 230 Name: Name of user 232 Date: Date this user was created or last modified 233 Password: User password for basic authentication 235 Email: E-mail address of user 237 Scope Type: This field identifies whether a user has domain-wide 238 or tenant-wide privileges 240 Scope Reference: This field should be reference to either a 241 'Policy-Domain' or a 'Policy-Tenant' object 243 Role: This field should be reference to a 'Policy-Role' object 244 that defines the specific permissions 246 3.5. Policy-Management-Authentication-Method 248 This object represents authentication schemes supported by security 249 controller. 251 This 'Policy-Management-Authentication-Method' object' SHALL have 252 following information: 254 Name: This field identifies name of this object 256 Date: Date this object was created or last modified 258 Authentication Method: This field identifies the authentication 259 methods. It could be a password based, token based, 260 certificate based or single sign-on authentication 262 Mutual Authentication: This field indicates whether mutual 263 authentication is mandatory or not 265 Token Server: This field stores the information about server that 266 validates the token submitted as credentials 268 Certificate Server: This field stores the information about 269 server that validates certificates submitted as credentials 271 Single Sign-on Server: This field stores the information about 272 server that validates user credentials 274 4. Information Model for Policy Endpoint Groups 276 The Policy Endpoint Group is very important part of building User- 277 construct based policies. Security Admin would create and use these 278 objects to represent a logical entity in their business environment, 279 where a Security Policy is to be applied. 281 There are multiple managed objects that constitute Policy Endpoint 282 Group. This section lists these objects and relationship among these 283 objects. 285 4.1. Meta-Data-Source 287 This object represents information source for meta-data or tag. The 288 meta-data in a group must be mapped to its corresponding contents to 289 enforce a Security Policy. 291 'Meta-Data-Source' object SHALL have following information: 293 Name: This field identifies name of this object 295 Date: Date this object was created or last modified 297 Tag Type: This field identifies the Endpoint Group type. It can 298 be either a 'User' group or 'App' group or 'Device' group, 299 or 'Location' group 301 Tag Server Information: This field identifies information related 302 to the source of the tag such as IP address and UDP/TCP 303 port information 305 Tag Application Protocol: This filed identifies the protocol e.g. 306 LDAP, Active Directory, or CMDB 308 Tag Server Credentials: This field identifies the credential 309 information needed to access the tag server 311 4.2. User-Group 313 This object represents a user group based on either tag or other 314 information. 316 The 'User-Group' object SHALL have following information: 318 Name: This field identifies the name of this object 320 Date: Date this object was created or last modified 322 Group Type: This field identifies whether the user group is based 323 on 'User-tag', 'User-name', or 'IP-address' 325 Meta-data Server: This field should be reference to a 'Meta-Data- 326 Source' object 328 Group Member: This field is the 'User-tag, or 'User-names', or IP 329 addresses based on the 'Group Type' 331 Risk Level: This field represents the threat level; valid range 332 may be 0 to 9 334 4.3. Device-Group 336 This object represents a device group based on either tag or other 337 information. 339 The 'Device-Group' object SHALL have following information: 341 Name: This field identifies the name of this object 343 Date: Date this object was created or last modified 345 Group Type: This field identifies whether the device group is 346 based on 'Device-tag' or 'Device-name', or IP address 348 Meta-data Server: This field should be reference to a 'Meta-Data- 349 Source' object 351 Group Member: This field is the 'Device-tag, or 'Device-name', or 352 IP address based on the 'Group Type' 354 Risk Level: This field represents the threat level; valid range 355 may be 0 to 9 357 4.4. Application-Group 359 This object represents an application group based on either tag or 360 other information. 362 The 'Application-Group' object SHALL have following information: 364 Name: This field identifies the name of this object 366 Date: Date this object was created or last modified 368 Group Type: This field identifies whether the device group is 369 based on 'App-tag' or 'App-name', or IP address 371 Meta-data Server: This field should be reference to a 'Meta-Data- 372 Source' object 374 Group Member: This field is the 'Device-tag, or 'Device-name', or 375 IP address and port information based on the 'Group Type' 377 Risk Level: This field represents the threat level; valid range 378 may be 0 to 9 380 4.5. Location-Group 382 This object represents an location group based on either tag or other 383 information. 385 The 'Location-Group' object SHALL have following information: 387 Name: This field identifies the name of this object 389 Date: Date this object was created or last modified 391 Group Type: This field identifies whether the location group is 392 based on 'Location-tag' or 'Location-name', or IP address 394 Meta-data Server: This field should be reference to a 'Meta-Data- 395 Source' object 397 Group Member: This field is the 'Location-tag, or 'Location- 398 names', or IP addresses based on the 'Group Type' 400 Risk Level: This field represents the threat level; valid range 401 may be 0 to 9 403 5. Information Model for Threat Prevention 405 The threat prevention plays an important part in the overall security 406 posture by reducing the attack surface. This information could come 407 in the form of threat feeds such as Botnet and GeoIP feeds usually 408 from a third party or external service. 410 There are multiple managed objects that constitute this category. 411 This section lists these objects and relationship among these 412 objects. 414 5.1. Threat-Feed 416 This object represents threat feed such as Botnet servers and GeoIP. 418 The 'Threat-Feed' object SHALL have following information: 420 Name: This field identifies the name of this object 422 Date: Date this object was created or last modified 423 Feed Type: This field identifies whether a feed type is IP 424 address based or URL based. 426 Feed Server: This field identifies the information about the feed 427 provider, it may be an external service or local server 429 Feed Priority: This field represents the feed priority level to 430 resolve conflict if there are multiple feed sources; valid 431 range may be 0 to 9 433 5.2. Custom-List 435 This object represents custom list created for the purpose of 436 defining exception to threat feeds. An organization may want to 437 allow certain exception to threat feeds obtained from a third party 439 The 'Custom-List' object SHALL have following information: 441 Name: This field identifies the name of this object 443 Date: Date this object was created or last modified 445 List Type: This field identifies whether the list type is IP 446 address based or URL based. 448 List Property: This field identifies the attributes of the list 449 property e.g. Blacklist or Whitelist. 451 List Content: This field contains the blacklist or whitelist 452 contents such as IP addresses or URL names. 454 5.3. Malware-Scan-Group 456 This object represents information needed to detect malware. This 457 information could come from a local server or uploaded periodically 458 from a third party. 460 The 'Malware-Scan-Group' object SHALL have following information: 462 Name: This field identifies the name of this object 464 Date: Date this object was created or last modified 466 Signature Server: This field contains information about the 467 server from where signatures can be downloaded periodically 468 as updates become available 470 File Types: This field contains list of file types needed to be 471 scanned for the virus 473 Malware Signatures: This field contains list of malware 474 signatures or hash 476 5.4. Event-Map-Group 478 This object represents an event map containing security events and 479 threat levels used for dynamic policy enforcement. 481 The 'Event-Map-Group' object SHALL have following information: 483 Name: This field identifies the name of this object 485 Date: Date this object was created or last modified 487 Security Events: This contains a list of security events 489 Threat Map: This contains a list of threat levels 491 6. Information Model for Telemetry Data 493 Telemetry provides visibility into the network activities which can 494 be tapped for further security analytics e.g. detecting potential 495 vulnerabilities, malicious activities etc. 497 6.1. Telemetry-Data 499 This object contains information collected for telemetry. 501 The 'Telemetry-Data' object SHALL have following information: 503 Name: This field identifies the name of this object 505 Date: Date this object was created or last modified 507 Logs: This field identifies whether 'Logs' need to be collected 509 Syslogs This field identifies whether 'Syslogs' need to be 510 collected 512 SNMP: This field identifies whether 'SNMP traps' and 'SNMP 513 alarms' need to be collected 515 sFlow: This field identifies whether 'sFlow' data need to be 516 collected 518 NetFlow: This field identifies whether 'NetFlow' data need to be 519 collected 521 Interface Stats: This field identifies whether 'Interface' data 522 such as packet bytes and counts need to be collected 524 6.2. Telemetry-Source 526 This object contains information related to telemetry source. The 527 source would be a NSF element in the network. 529 The 'Telemetry-Source' object SHALL have following information: 531 Name: This field identifies the name of this object 533 Date: Date this object was created or last modified 535 Source Type: This field contains type of the NSF telemetry 536 source: "NETWORK-NSF", "FIREWALL-NSF", "IDS-NSF", "IPS- 537 NSF", "PROXY-NSF", "VPN-NSF", "DNS", "ACTIVE-DIRECTORY","IP 538 Reputation Authority", "Web Reputation Authority", "Anti- 539 Malware Sandbox", "Honey Pot", "DHCP", "Other Third Party", 540 "ENDPOINT" 542 NSF Access Parameters: This field contains information such as IP 543 address and protocol (UDP or TCP) port number of the NSF 544 providing telemetry data 546 NSF Access Credentials: This field contains username and passwod 547 to authenticate with the NSF 549 Collection Interval: This field contains time in milliseconds 550 between each data collection. For example, a value of 5000 551 means data is streamed to collector every 5 seconds. Value 552 of 0 means data streaming is event-based. 554 Collection Method: This field contains method of collection 555 whether it is PUSH-based or PULL-based 557 Heartbeat Interval: This field contains time in seconds the 558 source must send telemetry heartbeat 560 QoS Marking: This field contains DSCP value source MUST mark on 561 its generated telemetry packets 563 6.3. Telemetry-Destination 565 This object contains information related to telemetry destination. 566 The destination is usually a collector which is either a part of 567 Security Controller or external system such as SIEM. 569 The 'Telemetry-Destination' object SHALL have following information: 571 Name: This field identifies the name of this object 573 Date: Date this object was created or last modified 575 Collector State: This field contains the state info regarding the 576 collector 578 Collector Access Parameter: This field contains the information 579 such as IP address and protocol (UDP or TCP) port number 580 for the collector's destination 582 Collector Access Credentials: This field contains the username 583 and passwod for the collector 585 Data Encoding: This field contains the telemetry data encoding, 586 which could in the form of a schema 588 Data Transport: This field contains streaming telemetry data 589 protocols: whether it is gRPC, protocol buffer over UDP, 590 etc. 592 7. Information Model for Policy Instance 594 In order to enforce a security policy, a policy instance must have 595 complete information such as where and when a policy need to be 596 applied. The policy instantiation is done by combining the managed 597 objects described so far and a few others listed below. 599 7.1. Policy-Calendar 601 This object contains information related to scheduling a policy. The 602 policy could be activated based on a time calendar or security event 603 including threat level changes. 605 The 'Policy-Calendar' object SHALL have following information: 607 Name: This field identifies the name of this object 609 Date: Date this object was created or last modified 610 Enforecment Type: This field identifies whether the policy 611 enforcement is 'ADMIN-ENFORCED' or 'TIME-ENFORCED', or 612 'EVENT-ENFORCED' 614 Time Information: This field contains time calendar such as 615 'BEGIN-TIME' and 'END-TIME' for one time enforcement or 616 recurring time calendar for periodic enforcement 618 Event Map: This field contains security events and threat map in 619 order to determine when a policy need to be activated 621 7.2. Policy-Action 623 This object represents actions that a Security Admin want to perform 624 based on certain traffic class. 626 The 'Policy-Action' object SHALL have following information: 628 Name: This field identifies the name of this object 630 Date: Date this object was created or last modified 632 Primary Action: This field identifies the action when a rule is 633 matched by NSF. The action could be one of 'PERMIT', 634 'DENY', 'RATE-LIMIT', 'TRAFFIC-CLASS', 'AUTHENTICATE- 635 SESSION', 'IPS, 'APP-FIREWALL' 637 Secondary Action: Security Admin can also specify additional 638 actions if a rule is matched. This could be one of 'LOG', 639 'SYSLOG', 'SESSION-LOG' 641 7.3. Policy-Rule 643 This object represents rules that a Security Admin want to define in 644 order to express its business objectives in a Security Policy. 646 The 'Policy-Rule' object SHALL have following information: 648 Name: This field identifies the name of this object 650 Date: Date this object was created or last modified 652 Source: This field identifies the source of the traffic. This 653 could be reference to either 'Policy Endpoint Group' or 654 'Threat-Feed' or 'Custom-List' if Security Admin wants to 655 specify the source otherwise the default is to match all 656 traffic 658 Destination: This field identifies the destination of the 659 traffic. This could be reference to either 'Policy 660 Endpoint Group' or 'Threat-Feed' or 'Custom-List' if 661 Security Admin wants to specify the destination otherwise 662 the default is to match all traffic 664 Exception: This field identifies the exception consideration when 665 'Source' and 'Destination' are matched for a given 666 communication. This should be reference to 'Policy 667 Endpoint Group' object 669 Action: This field identifies the action taken when 'Source' and 670 'Destination' are matched for a given communication 672 Precedence: This field identifies the precedence assigned to this 673 rule by Security Admin. This is helpful in conflict 674 resolution when two or more rules match a given traffic 675 class 677 7.4. Policy-Instance 679 This object represents a mechanism to express a Security Policy by 680 Security Admin using Security Controller Client-Facing interface; the 681 policy would be enforced on a NSF. 683 The 'Policy-Instance' object SHALL have following information: 685 Name: This field identifies the name of this object 687 Date: Date this object was created or last modified 689 Rules: This field contains list of rules. If the rule does not 690 have a user defined precedence, then any conflict must be 691 manually resolved 693 Scheduling Type: This field specifies when this policy should be 694 scheduled. The policy could be scheduled based on time 695 calendar or event-map 697 Scheduling Information: This field contains either the 'Calendar' 698 or 'Event-map' based on 'Schedule type' 700 Owner: This field defines the owner of this policy. Only the 701 owner is authorized to modify the contents of the policy 703 8. Security Considerations 705 Information model provides mechanism to protect Client-Facing 706 interface to Security controller. One of the specified mechanism 707 must be used to protect Enterprise network, data and all resources 708 from external attacks. This model mandates that interface must have 709 proper authentication and authorization with Role Based Access 710 Controls to address multi-tenancy requirement. The draft does not 711 mandate that a particular mechanism be used as different organization 712 may have different needs based on their deployment. 714 9. IANA Considerations 716 This document requires no IANA actions. RFC Editor: Please remove 717 this section before publication. 719 10. Acknowledgements 721 The authors would like to thank Kunal Modasiya, Prakash T. Sehsadri 722 and Srinivas Nimmagadda from Juniper Networks for helpful 723 discussions. 725 11. Informative References 727 [I-D.ietf-i2nsf-problem-and-use-cases] 728 Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 729 and J. Jeong, "I2NSF Problem Statement and Use cases", 730 draft-ietf-i2nsf-problem-and-use-cases-15 (work in 731 progress), April 2017. 733 [I-D.ietf-i2nsf-terminology] 734 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 735 Birkholz, "Interface to Network Security Functions (I2NSF) 736 Terminology", draft-ietf-i2nsf-terminology-03 (work in 737 progress), March 2017. 739 [I-D.kumar-i2nsf-client-facing-interface-req] 740 Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic, 741 S., and L. Xia, "Requirements for Client-Facing Interface 742 to Security Controller", draft-kumar-i2nsf-client-facing- 743 interface-req-02 (work in progress), October 2016. 745 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 746 Information Models and Data Models", RFC 3444, 747 DOI 10.17487/RFC3444, January 2003, 748 . 750 Authors' Addresses 752 Rakesh Kumar 753 Juniper Networks 754 1133 Innovation Way 755 Sunnyvale, CA 94089 756 US 758 Email: rkkumar@juniper.net 760 Anil Lohiya 761 Juniper Networks 762 1133 Innovation Way 763 Sunnyvale, CA 94089 764 US 766 Email: alohiya@juniper.net 768 Dave Qi 769 Bloomberg 770 731 Lexington Avenue 771 New York, NY 10022 772 US 774 Email: DQI@bloomberg.net 776 Nabil Bitar 777 Nokia 778 755 Ravendale Drive 779 Mountain View, CA 94043 780 US 782 Email: nabil.bitar@nokia.com 784 Senad Palislamovic 785 Nokia 786 755 Ravendale Drive 787 Mountain View, CA 94043 788 US 790 Email: senad.palislamovic@nokia.com 791 Liang Xia 792 Huawei 793 101 Software Avenue 794 Nanjing, Jiangsu 210012 795 China 797 Email: Frank.Xialiang@huawei.com