idnits 2.17.1 draft-kumar-i2nsf-client-facing-interface-im-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 168: '...y-Domain' object SHALL have following ...' RFC 2119 keyword, line 190: '...y-Tenant' object SHALL have the follow...' RFC 2119 keyword, line 207: '...icy-Role' object SHALL have following ...' RFC 2119 keyword, line 226: '...icy-User' object SHALL have following ...' RFC 2119 keyword, line 250: '...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 (October 31, 2016) is 2733 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-i2nsf-terminology' is defined on line 726, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-i2nsf-problem-and-use-cases-02 == Outdated reference: A later version (-08) exists of draft-ietf-i2nsf-terminology-02 Summary: 3 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: May 4, 2017 D. Qi 6 Bloomberg 7 N. Bitar 8 S. Palislamovic 9 Nokia 10 L. Xia 11 Huawei 12 October 31, 2016 14 Information model for Client-Facing Interface to Security Controller 15 draft-kumar-i2nsf-client-facing-interface-im-01 17 Abstract 19 This document defines information model for the client-facing 20 interface to security controller based on the requirements identfied 21 in the [I-D.kumar-i2nsf-client-facing-interface-req]. The 22 information model defines various managed objects and the 23 relationship among these objects needed to build the client 24 interfaces. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 4, 2017. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Conventions Used in this Document . . . . . . . . . . . . . . 3 62 3. Information Model for Multi Tenancy . . . . . . . . . . . . . 4 63 3.1. Policy-Domain . . . . . . . . . . . . . . . . . . . . . . 4 64 3.2. Policy-Tenant . . . . . . . . . . . . . . . . . . . . . . 4 65 3.3. Policy-Role . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.4. Policy-User . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.5. Policy-Management-Authentication-Method . . . . . . . . . 6 68 4. Information Model for Policy Endpoint Groups . . . . . . . . 6 69 4.1. Meta-Data-Source . . . . . . . . . . . . . . . . . . . . 7 70 4.2. User-Group . . . . . . . . . . . . . . . . . . . . . . . 7 71 4.3. Device-Group . . . . . . . . . . . . . . . . . . . . . . 8 72 4.4. Application-Group . . . . . . . . . . . . . . . . . . . . 8 73 4.5. Location-Group . . . . . . . . . . . . . . . . . . . . . 9 74 5. Information Model for Threat Prevention . . . . . . . . . . . 9 75 5.1. Threat-Feed . . . . . . . . . . . . . . . . . . . . . . . 9 76 5.2. Custom-List . . . . . . . . . . . . . . . . . . . . . . . 10 77 5.3. Malware-Scan-Group . . . . . . . . . . . . . . . . . . . 10 78 5.4. Event-Map-Group . . . . . . . . . . . . . . . . . . . . . 11 79 6. Information Model for Telemetry Data . . . . . . . . . . . . 11 80 6.1. Telemetry-Data . . . . . . . . . . . . . . . . . . . . . 11 81 6.2. Telemetry-Source . . . . . . . . . . . . . . . . . . . . 12 82 6.3. Telemetry-Destination . . . . . . . . . . . . . . . . . . 12 83 7. Information Model for Policy Instance . . . . . . . . . . . . 13 84 7.1. Policy-Calendar . . . . . . . . . . . . . . . . . . . . . 13 85 7.2. Policy-Action . . . . . . . . . . . . . . . . . . . . . . 14 86 7.3. Policy-Rule . . . . . . . . . . . . . . . . . . . . . . . 14 87 7.4. Policy-Instance . . . . . . . . . . . . . . . . . . . . . 15 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 89 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 90 10. Informative References . . . . . . . . . . . . . . . . . . . 16 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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. The objects may have relationship 98 with other objects to express complete requirement. An information 99 model captures the managed objects and relationship among these. The 100 information model proposed in this draft is in accordance with the 101 client interface requirements as defined in 102 [I-D.kumar-i2nsf-client-facing-interface-req]. 104 The [RFC3444] explains the difference between information and data 105 model. This draft use those guidlines to define the information 106 model in this draft. A data model, that represents an implementation 107 of this proposed information model in a specific data representation 108 language, will be defined in a separate draft. 110 2. Conventions Used in this Document 112 BSS: Business Support System 114 CLI: Command Line Interface 116 CMDB: Configuration Management Database 118 Controller: Used interchangeably with Service Provider Security 119 Controller or management system throughout this document 121 CRUD: Create, Retrieve, Update, Delete 123 FW: Firewall 125 GUI: Graphical User Interface 127 IDS: Intrusion Detection System 129 IPS: Intrusion Protection System 131 LDAP: Lightweight Directory Access Protocol 133 NSF: Network Security Function, defined by 134 [I-D.ietf-i2nsf-problem-and-use-cases] 136 OSS: Operation Support System 138 RBAC: Role Based Access Control 140 SIEM: Security Information and Event Management 141 URL: Universal Resource Locator 143 vNSF: Refers to NSF being instantiated on Virtual Machines 145 3. Information Model for Multi Tenancy 147 The multi-tenancy is an important aspect of any application that 148 enables multiple administrative domains for managing the application 149 resources. An oganization may have multiple tenants or departments 150 such as HR, Finance, Legal, with each tenant having a need to manage 151 its own security policies. 153 There are multiple managed objects that constitute multi-tenancy 154 aspects. This section lists these objects and any relationship among 155 these objects. 157 3.1. Policy-Domain 159 This object defines an oragnization boundary for the purpose of 160 policy management. This may vary based on how security controller is 161 deployed and hosted. For example, if an Enterprise host a security 162 controller in their network; the domain in this case could just be 163 the one that reperesents that Enterprise. But if a cloud service 164 provider host managed services, then a domain could represent a 165 single customer of the service provider. The multi-tenancy model 166 should be applicable in all such environments. 168 The 'Policy-Domain' object SHALL have following infomation: 170 Name: Name of the organization or customer representing this 171 domain 173 Address: Address of the organization or customer 175 Contact: Contact information of the organization or customer 177 Date: Date this account was created or last modified 179 Authentication Method: Authentication method to be used for this 180 domain. It should be reference to a 'Policy-Management- 181 Authentication-Method' object 183 3.2. Policy-Tenant 185 This object defines an entity within an organization that wants to 186 manage its own security posture. The entity could be a department or 187 a division that manages its own security policies due to regulatory 188 compliance or organizational structure. 190 The 'Policy-Tenant' object SHALL have the following information: 192 Name: Name of the department or division within an organization 194 Date: Date this account was created or last modified 196 Domain: This field identifies the domain to which this tenent 197 belongs. This should be reference to a 'Policy-Domain' 198 object 200 3.3. Policy-Role 202 This object defines a set of permissions assigned to a user in an 203 organization that want to manage its own security posture. It 204 provides a convenient way to assign policy users to a job function or 205 set of permissions within the organization. 207 The 'Policy-Role' object SHALL have following information: 209 Name: This field identifies the name of the role 211 Date: Date this role was created or last modified 213 Access Profile: This field identifies the access profile for the 214 role. The profile grants or denies access to policy 215 objects. Multiple access profiles can be concatenated 216 together 218 3.4. Policy-User 220 This object represents a unique identity within an organization. 221 This identity authenticates with the security controller using 222 credentials such as a password or token in order to do policy 223 management. A user may be an individual, system, or application 224 requiring access to security controller. 226 The 'Policy-User' object SHALL have following information: 228 Name: Name of the user 230 Date: Date this user was created or last modified 232 Password: User password for basic authentication 234 Email: E-mail address of the user 236 Scope Type: This field identifies whether the user has domain- 237 wide or tenent-wide privileges 239 Scope Reference: This field should be reference to either a 240 'policy-domain' or a 'Policy-Tenant' object 242 Role: This field should be reference to a 'Policy-Role' object 243 that defines the specific permissions 245 3.5. Policy-Management-Authentication-Method 247 This object represents authentication schemes supported by security 248 controller. 250 This 'Policy-Management-Authentication-Method' object' SHALL have 251 following information: 253 Name: This field identifies the name of this object 255 Date: Date this object was created or last modified 257 Authentication Method: This field identifies the authentication 258 methods. It could be a password based, token based, 259 certificate based or single sign-on authentication 261 Mutual Authentication: This field indicates whether mutual 262 authentication is mandatory or not 264 Token Server: This field stores the information about server that 265 validates the token submitted as credentials 267 Certificate Server: This field stores the infromation about 268 server that validates certificates submitted as credentials 270 Single Sign-on Server: This field stores the infromation about 271 server that validates user credentials 273 4. Information Model for Policy Endpoint Groups 275 The policy endpoint groups are very important part of building user- 276 construct policy. The security admins could use these objects to 277 represent a logical entity in their business enviroment, where a 278 security policy is to be applied. 280 There are multiple managed objects that constitute policy endpoint 281 groups. This section lists these objects and relationship among 282 these objects. 284 4.1. Meta-Data-Source 286 This object represents information source for the meta-data or tag. 287 The meta-data in a group must be mapped to corresponding contents to 288 enforce a security policy. 290 The 'Meta-Data-Source' object SHALL have following information: 292 Name: This field identifies the name of this object 294 Date: Date this object was created or last modified 296 Tag Type: This field identifies the Endpoint group type. It can 297 be either a 'User' group or 'App' group or 'Device' group, 298 or 'Location' group based policy 300 Tag Server Information: This field identifies the information 301 related to the source of the tag such as IP address and 302 UDP/TCP port information 304 Tag Application Protocol: This filed identifies the protocol e.g. 305 LDAP, Active Directory, or CMDB 307 Tag Server Credentials: This field identifies the credential 308 information needed to access the tag server 310 4.2. User-Group 312 This object represents a user group based on either tag or other 313 information. 315 The 'User-Group' object SHALL have following information: 317 Name: This field identifies the name of this object 319 Date: Date this object was created or last modified 321 Group Type: This field identifies whether the user group is based 322 on 'User-tag', 'User-names', or 'IP-addresses' 324 Meta-data Server: This field should be reference to a 'Meta-Data- 325 Source' object 327 Group Member: This field is the 'User-tag, or 'User-names', or IP 328 addresses based on the 'Group Type' 330 Risk Level: This field represents the threat level; valid range 331 may be 0 to 9 333 4.3. Device-Group 335 This object represents a device group based on either tag or other 336 information. 338 The 'Device-Group' object SHALL have following information: 340 Name: This field identifies the name of this object 342 Date: Date this object was created or last modified 344 Group Type: This field identifies whether the device group is 345 based on 'Device-tag' or 'Device-names', or IP addresses 347 Meta-data Server: This field should be reference to a 'Meta-Data- 348 Source' object 350 Group Member: This field is the 'Device-tag, or 'Device-names', 351 or IP addresses based on the 'Group Type' 353 Risk Level: This field represents the threat level; valid range 354 may be 0 to 9 356 4.4. Application-Group 358 This object represents an application group based on either tag or 359 other information. 361 The 'Application-Group' object SHALL have following information: 363 Name: This field identifies the name of this object 365 Date: Date this object was created or last modified 367 Group Type: This field identifies whether the device group is 368 based on 'App-tag' or 'App-names', or IP addresses 370 Meta-data Server: This field should be reference to a 'Meta-Data- 371 Source' object 373 Group Member: This field is the 'Device-tag, or 'Device-names', 374 or IP addresses and port information based on the 'Group 375 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-names', or IP 393 addresses 395 Meta-data Server: This field should be reference to a 'Meta-Data- 396 Source' object 398 Group Member: This field is the 'Location-tag, or 'Location- 399 names', or IP addresses based on the 'Group Type' 401 Risk Level: This field represents the threat level; valid range 402 may be 0 to 9 404 5. Information Model for Threat Prevention 406 The threat prevention plays an important part in the overall security 407 posture by reducing the attack surface. This information could come 408 in the form of threat feeds such as Botnet, GeoIP usually from a 409 third party or external service. 411 There are multiple managed objects that constitute this category. 412 This section lists these objects and relationship among these 413 objects. 415 5.1. Threat-Feed 417 This object represents threat feed such as Botnet servers and GeoIP. 419 The 'Threat-Feed' object SHALL have following information: 421 Name: This field identifies the name of this object 423 Date: Date this object was created or last modified 425 Feed Type: This field identifies whether a feed type is IP 426 address based or URL based. 428 Feed Server: This field identifies the information about the feed 429 provider, it may be an external service or local server 431 Feed Priority: This field represents the feed priority level to 432 resolve conflict if there are multiple feed sources; valid 433 range may be 0 to 9 435 5.2. Custom-List 437 This object represents custom list created for the purpose of 438 defining exception to threat feeds. An organization may want to 439 allow certain exception to threat feeds obtained from a third party 441 The 'Custom-List' object SHALL have following information: 443 Name: This field identifies the name of this object 445 Date: Date this object was created or last modified 447 List Type: This field identifies whether the list type is IP 448 address based or URL based. 450 List Property: This field identifies the attributes of the list 451 property e.g. Blacklist or Whitelist. 453 List Content: This field contains the blacklist or whitelist 454 contents such as IP addresses or URL names. 456 5.3. Malware-Scan-Group 458 This object represents information needed to detect malware. This 459 information could come from a local server or uploaded periodically 460 from third party. 462 The 'Malware-Scan-Group' object SHALL have following information: 464 Name: This field identifies the name of this object 466 Date: Date this object was created or last modified 468 Signature Server: This field contains information about the 469 server from where signatures can be downloaded periodically 470 as updates become available 472 File Types: This field contains list of file types needed to be 473 scanned for the virus 475 Malware Signatures: This field contains list of malware 476 signatures or hash 478 5.4. Event-Map-Group 480 This object represents an event map containing security events and 481 threat levels used for dyanmic policy enforcement. 483 The 'Event-Map-Group' object SHALL have following information: 485 Name: This field identifies the name of this object 487 Date: Date this object was created or last modified 489 Secuirty Events: This contains a list of security events 491 Threat Map: This contains a list of threat levels 493 6. Information Model for Telemetry Data 495 Telemetry provides visibility into the network activities which can 496 be tapped for further security analytics e.g. detecting potential 497 vulnerabilities, malicious activities etc. 499 6.1. Telemetry-Data 501 This object contains information collected for telemetry. 503 The 'Telemetry-Data' object SHALL have following information: 505 Name: This field identifies the name of this object 507 Date: Date this object was created or last modified 509 Logs: This field identifies whether 'Logs' need to be collected 511 Syslogs This field identifies whether 'Syslogs' need to be 512 collected 514 SNMP: This field identifies whether 'SNMP traps' and 'SNMP 515 alarms' need to be collected 517 sFlow: This field identifies whether 'sFlow' data need to be 518 collected 520 NetFlow: This field identifies whether 'NetFlow' data need to be 521 collected 523 Interface Stats: This field identifies whether 'Interface' data 524 such as packet bytes and counts need to be collected 526 6.2. Telemetry-Source 528 This object contains information related to telemetry source. The 529 source would be a NSF element in the network. 531 The 'Telemetry-Source' object SHALL have following information: 533 Name: This field identifies the name of this object 535 Date: Date this object was created or last modified 537 Source Type: This field contains type of the NSF telemetry 538 source: "NETWORK-NSF", "FIREWALL-NSF", "IDS-NSF", "IPS- 539 NSF", "PROXY-NSF", "VPN-NSF", "DNS", "ACTIVE-DIRECTORY","IP 540 Reputation Authority", "Web Reputation Authority", "Anti- 541 Malware Sandbox", "Honey Pot", "DHCP", "Other Third Party", 542 "ENDPOINT" 544 NSF Access Parameters: This field contains information such as IP 545 address and protocol (UDP or TCP) port number of the NSF 546 providing telemetry data 548 NSF Access Credentials: This field contains username and passwod 549 to authenticate with the NSF 551 Collection Interval: This field contains time in milliseconds 552 between data collections. For example, value of 5000 means 553 data is streamed to collector every 5 seconds. Value of 0 554 means data streaming is event-based. 556 Collection Method: This field contains method of collection 557 whether it is PUSH-based or PULL-based 559 Heartbeat Interval: This field contains time in seconds the 560 source must send telemetry heartbeat 562 QoS Marking: This field contains DSCP value source MUST mark on 563 its generated telemetry packets 565 6.3. Telemetry-Destination 567 This object contains information related to telemetry destination. 568 The destination is usually a collector which is either a part of 569 security controller or external system such as SIEM. 571 The 'Telemetry-Destination' object SHALL have following information: 573 Name: This field identifies the name of this object 575 Date: Date this object was created or last modified 577 Collector State: This field contains the state info regarding the 578 collector 580 Collector Access Parameter: This field contains the infromation 581 such as IP address and protocol (UDP or TCP) port number 582 for the collector's destination 584 Collector Access Credentials: This field contains the username 585 and passwod for the collector 587 Data Encoding: This field contains the telemetry data encoding, 588 which could in the form of a schema 590 Data Transport: This field contains streaming telemetry data 591 protocols: whether it is gRPC, protocol buffer over UDP, 592 etc. 594 7. Information Model for Policy Instance 596 In order to enforce a security policy, a policy instance must have 597 complete information such as where and when a policy need to be 598 applied. The policy instantination is done by combining the managed 599 objects described so far and a few others listed below. 601 7.1. Policy-Calendar 603 This object contains information related to scheduling a policy. The 604 policy could be activated based on a time calendar or security event 605 including threat level changes. 607 The 'Policy-Calendar' object SHALL have following information: 609 Name: This field identifies the name of this object 611 Date: Date this object was created or last modified 613 Enforecment Type: This field identifies whether the policy 614 enforcement is 'ADMIN-ENFORCED' or 'TIME-ENFORCED', or 615 'EVENT-ENFORCED' 617 Time Information: This field contains time calendar such as 618 'BEGIN-TIME' and 'END-TIME' for one time enforcement or 619 recurring time calendar for periodic enforcement 621 Event Map: This field contains security events and threat map 622 when this policy need to be activated 624 7.2. Policy-Action 626 This object represents actions that a security admin want to perform 627 based on certain traffic class. 629 The 'Policy-Action' object SHALL have following information: 631 Name: This field identifies the name of this object 633 Date: Date this object was created or last modified 635 Primary Action: This field identifies the action when a policy 636 rule is matched by NSF. The action could be one of 637 'PERMIT', 'DENY', 'RATE-LIMIT', 'TRAFFIC-CLASS', 638 'AUTHENTICATE-SESSION', 'IPS, 'APP-FIREWALL' 640 Secondary Action: The security admin can also specify additional 641 action if a rule is matched. This could be one of 'LOG', 642 'SYSLOG', 'SESSION-LOG' 644 7.3. Policy-Rule 646 This object represents rules that a security admin want to define in 647 order to express its business objectives through a security policy. 649 The 'Policy-Rule' object SHALL have following information: 651 Name: This field identifies the name of this object 653 Date: Date this object was created or last modified 655 Source: This field identfies the source of the traffic. This 656 could be reference to either 'Policy Endpoint Group' or 657 'Threat-Feed' or 'Custom-List' if security admin wants to 658 specify the source otherwise the default is to match all 659 traffic 661 Destination: This field identfies the destination of the traffic. 662 This could be reference to either 'Policy Endpoint Group' 663 or 'Threat-Feed' or 'Custom-List' if security admin wants 664 to specify the destination otherwise the default is to 665 match all traffic 667 Exception: This field identifies the exception consideration when 668 'Source' and 'Destination' are matched for a given 669 communication. This should be reference to 'Policy 670 Endpoint Group' object 672 Action: This field identifies the action taken when 'Source' and 673 'Destination' are matched for a given communication 675 Precedence: This field identifies the precedence assigned to this 676 rule by security admin. This is helpful in conflict 677 resolution when two or more rules match a given traffic 678 class 680 7.4. Policy-Instance 682 This object represents a security policy expressed by security admin 683 that would be taken by security controller and enforced on NSF as per 684 the instructions specfied in policy instance. 686 The 'Policy-Instance' object SHALL have following information: 688 Name: This field identifies the name of this object 690 Date: Date this object was created or last modified 692 Rules: This field contains list of rules. If the rule does not 693 have a user defined precedence, then any conflict must be 694 manually resolved 696 Scheduling Type: This field specifies when this policy should be 697 scheduled. The policy could be scheduled based on time 698 calendar or event-map 700 Scheduling Information: This field contanins either the 701 'Calendar' or 'Event-map' based on 'Schedule type' 703 Owner: This field defines the owner of this policy. Only the 704 owner is authrozied to modify the the contents of the 705 policy 707 8. IANA Considerations 709 This document requires no IANA actions. RFC Editor: Please remove 710 this section before publication. 712 9. Acknowledgements 714 The authors would like to thank Kunal Modasiya, Prakash T. Sehsadri 715 and Srinivas Nimmagadda from Juniper Networks for helpful 716 discussions. 718 10. Informative References 720 [I-D.ietf-i2nsf-problem-and-use-cases] 721 Hares, S., Dunbar, L., Lopez, D., Zarny, M., and C. 722 Jacquenet, "I2NSF Problem Statement and Use cases", draft- 723 ietf-i2nsf-problem-and-use-cases-02 (work in progress), 724 October 2016. 726 [I-D.ietf-i2nsf-terminology] 727 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 728 Birkholz, "Interface to Network Security Functions (I2NSF) 729 Terminology", draft-ietf-i2nsf-terminology-02 (work in 730 progress), October 2016. 732 [I-D.kumar-i2nsf-client-facing-interface-req] 733 Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic, 734 S., and L. Xia, "Requirements for Client-Facing Interface 735 to Security Controller", draft-kumar-i2nsf-client-facing- 736 interface-req-02 (work in progress), October 2016. 738 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 739 Information Models and Data Models", RFC 3444, 740 DOI 10.17487/RFC3444, January 2003, 741 . 743 Authors' Addresses 745 Rakesh Kumar 746 Juniper Networks 747 1133 Innovation Way 748 Sunnyvale, CA 94089 749 US 751 Email: rkkumar@juniper.net 752 Anil Lohiya 753 Juniper Networks 754 1133 Innovation Way 755 Sunnyvale, CA 94089 756 US 758 Email: alohiya@juniper.net 760 Dave Qi 761 Bloomberg 762 731 Lexington Avenue 763 New York, NY 10022 764 US 766 Email: DQI@bloomberg.net 768 Nabil Bitar 769 Nokia 770 755 Ravendale Drive 771 Mountain View, CA 94043 772 US 774 Email: nabil.bitar@nokia.com 776 Senad Palislamovic 777 Nokia 778 755 Ravendale Drive 779 Mountain View, CA 94043 780 US 782 Email: senad.palislamovic@nokia.com 784 Liang Xia 785 Huawei 786 101 Software Avenue 787 Nanjing, Jiangsu 210012 788 China 790 Email: Frank.Xialiang@huawei.com