Information Model for Consumer-Facing Interface to Security Controller
draft-kumar-i2nsf-client-facing-interface-im-04

Versions: 00 01 02 03 04                                                
I2NSF Working Group                                             R. Kumar
Internet-Draft                                                 A. Lohiya
Intended status: Informational                          Juniper Networks
Expires: November 1, 2017                                          D. Qi
                                                               Bloomberg
                                                                N. Bitar
                                                         S. Palislamovic
                                                                   Nokia
                                                                  L. Xia
                                                                  Huawei
                                                          April 30, 2017


  Information model for Client-Facing Interface to Security Controller
            draft-kumar-i2nsf-client-facing-interface-im-02

Abstract

   This document defines information model for Client-Facing interface
   to Security Controller based on the requirements identified in
   [I-D.kumar-i2nsf-client-facing-interface-req].  The information model
   defines various managed objects and relationship among these objects
   needed to build the interface.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 1, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



Kumar, et al.           Expires November 1, 2017                [Page 1]


Internet-Draft     Client Interface Information Model         April 2017


   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions Used in this Document . . . . . . . . . . . . . .   3
   3.  Information Model for Multi Tenancy . . . . . . . . . . . . .   4
     3.1.  Policy-Domain . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Policy-Tenant . . . . . . . . . . . . . . . . . . . . . .   5
     3.3.  Policy-Role . . . . . . . . . . . . . . . . . . . . . . .   5
     3.4.  Policy-User . . . . . . . . . . . . . . . . . . . . . . .   5
     3.5.  Policy-Management-Authentication-Method . . . . . . . . .   6
   4.  Information Model for Policy Endpoint Groups  . . . . . . . .   6
     4.1.  Meta-Data-Source  . . . . . . . . . . . . . . . . . . . .   7
     4.2.  User-Group  . . . . . . . . . . . . . . . . . . . . . . .   7
     4.3.  Device-Group  . . . . . . . . . . . . . . . . . . . . . .   8
     4.4.  Application-Group . . . . . . . . . . . . . . . . . . . .   8
     4.5.  Location-Group  . . . . . . . . . . . . . . . . . . . . .   9
   5.  Information Model for Threat Prevention . . . . . . . . . . .   9
     5.1.  Threat-Feed . . . . . . . . . . . . . . . . . . . . . . .   9
     5.2.  Custom-List . . . . . . . . . . . . . . . . . . . . . . .  10
     5.3.  Malware-Scan-Group  . . . . . . . . . . . . . . . . . . .  10
     5.4.  Event-Map-Group . . . . . . . . . . . . . . . . . . . . .  11
   6.  Information Model for Telemetry Data  . . . . . . . . . . . .  11
     6.1.  Telemetry-Data  . . . . . . . . . . . . . . . . . . . . .  11
     6.2.  Telemetry-Source  . . . . . . . . . . . . . . . . . . . .  12
     6.3.  Telemetry-Destination . . . . . . . . . . . . . . . . . .  13
   7.  Information Model for Policy Instance . . . . . . . . . . . .  13
     7.1.  Policy-Calendar . . . . . . . . . . . . . . . . . . . . .  13
     7.2.  Policy-Action . . . . . . . . . . . . . . . . . . . . . .  14
     7.3.  Policy-Rule . . . . . . . . . . . . . . . . . . . . . . .  14
     7.4.  Policy-Instance . . . . . . . . . . . . . . . . . . . . .  15
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  16
   11. Informative References  . . . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17








Kumar, et al.           Expires November 1, 2017                [Page 2]


Internet-Draft     Client Interface Information Model         April 2017


1.  Introduction

   The Security Controller's Client-Facing interfaces would be built
   using a set of objects, with each object capturing a unique set of
   information from Security Admin need to express a Security Policy.
   An objects may have relationship with various other objects to
   express a complete set of requirement.  An information model captures
   the managed objects and relationship among these.  The information
   model proposed in this draft is in accordance with interface
   requirements as defined in
   [I-D.kumar-i2nsf-client-facing-interface-req].

   The [RFC3444] explains differences between an information and data
   model.  This draft use those guidelines to define information model
   for Client-Facing interface in this draft.  A data model, that
   represents an implementation of the proposed information model in a
   specific data representation language, will be defined in a separate
   draft.

2.  Conventions Used in this Document

   BSS:      Business Support System

   CLI:      Command Line Interface

   CMDB:     Configuration Management Database

   Controller:  Used interchangeably with Service Provider Security
             Controller or management system throughout this document

   CRUD:     Create, Retrieve, Update, Delete

   FW:       Firewall

   GUI:      Graphical User Interface

   IDS:      Intrusion Detection System

   IPS:      Intrusion Protection System

   LDAP:     Lightweight Directory Access Protocol

   NSF:      Network Security Function, defined by
             [I-D.ietf-i2nsf-problem-and-use-cases]

   OSS:      Operation Support System

   RBAC:     Role Based Access Control



Kumar, et al.           Expires November 1, 2017                [Page 3]


Internet-Draft     Client Interface Information Model         April 2017


   SIEM:     Security Information and Event Management

   URL:      Universal Resource Locator

   vNSF:     Refers to NSF being instantiated on Virtual Machines

3.  Information Model for Multi Tenancy

   Multi-tenancy is an important aspect of any application that enables
   multiple administrative domains in order to manage application
   resources.  An organization may have multiple tenants or departments
   such as HR, Finance, Legal, with each tenant having a need to manage
   its own Security Policies.

   There are multiple managed objects that constitute multi-tenancy
   aspects.  This section lists these objects and any relationship among
   these objects.

3.1.  Policy-Domain

   This object defines a boundary for the purpose of policy management
   within a Security Controller.  This may vary based on how the
   Security Controller is deployed and hosted.  For example, if an
   Enterprise host a Security Controller in their network; the domain in
   this case could just be the one that represents that Enterprise.  But
   if a Cloud Service Provider hosts managed services, then a domain
   could represent a single customer of that Provider.  Multi-tenancy
   model should be applicable in all such environments.

   The 'Policy-Domain' object SHALL have following information:

      Name:  Name of the organization or customer representing this
             domain

      Address:  Address of the organization or customer

      Contact:  Contact information of the organization or customer

      Date:  Date this account was created or last modified

      Authentication Method:  Authentication method to be used for this
             domain.  It should be reference to a 'Policy-Management-
             Authentication-Method' object








Kumar, et al.           Expires November 1, 2017                [Page 4]


Internet-Draft     Client Interface Information Model         April 2017


3.2.  Policy-Tenant

   This object defines an entity within an organization that wants to
   manage its own Security Policies.  The entity could be a Department
   or a Division that would like to manages its own Policies due to
   regulatory, compliance or business reasons.

   The 'Policy-Tenant' object SHALL have following information:

      Name:  Name of the Department or Division within an organization

      Date:  Date this account was created or last modified

      Domain:  This field identifies the domain to which this tenant
             belongs.  This should be reference to a 'Policy-Domain'
             object

3.3.  Policy-Role

   This object defines a set of permissions assigned to a user in an
   organization that want to manage its own Security Policies.  It
   provides a convenient way to assign policy users to a job function or
   set of permissions within the organization.

   The 'Policy-Role' object SHALL have following information:

      Name:  This field identifies name of the role

      Date:  Date this role was created or last modified

      Access Profile:  This field identifies the access profile for the
             role.  The profile grants or denies access to policy
             objects.  Multiple access profiles can be concatenated
             together

3.4.  Policy-User

   This object represents a unique identity within an organization.  The
   identity authenticates with Security Controller using credentials
   such as a password or token in order to do policy management.  A user
   may be an individual, system, or application requiring access to
   Security Controller.

   The 'Policy-User' object SHALL have following information:

      Name:  Name of user

      Date:  Date this user was created or last modified



Kumar, et al.           Expires November 1, 2017                [Page 5]


Internet-Draft     Client Interface Information Model         April 2017


      Password:  User password for basic authentication

      Email: E-mail address of user

      Scope Type:  This field identifies whether a user has domain-wide
             or tenant-wide privileges

      Scope Reference:  This field should be reference to either a
             'Policy-Domain' or a 'Policy-Tenant' object

      Role:  This field should be reference to a 'Policy-Role' object
             that defines the specific permissions

3.5.  Policy-Management-Authentication-Method

   This object represents authentication schemes supported by security
   controller.

   This 'Policy-Management-Authentication-Method' object' SHALL have
   following information:

      Name:  This field identifies name of this object

      Date:  Date this object was created or last modified

      Authentication Method:  This field identifies the authentication
             methods.  It could be a password based, token based,
             certificate based or single sign-on authentication

      Mutual Authentication:  This field indicates whether mutual
             authentication is mandatory or not

      Token Server:  This field stores the information about server that
             validates the token submitted as credentials

      Certificate Server:  This field stores the information about
             server that validates certificates submitted as credentials

      Single Sign-on Server:  This field stores the information about
             server that validates user credentials

4.  Information Model for Policy Endpoint Groups

   The Policy Endpoint Group is very important part of building User-
   construct based policies.  Security Admin would create and use these
   objects to represent a logical entity in their business environment,
   where a Security Policy is to be applied.




Kumar, et al.           Expires November 1, 2017                [Page 6]


Internet-Draft     Client Interface Information Model         April 2017


   There are multiple managed objects that constitute Policy Endpoint
   Group.  This section lists these objects and relationship among these
   objects.

4.1.  Meta-Data-Source

   This object represents information source for meta-data or tag.  The
   meta-data in a group must be mapped to its corresponding contents to
   enforce a Security Policy.

   'Meta-Data-Source' object SHALL have following information:

      Name:  This field identifies name of this object

      Date:  Date this object was created or last modified

      Tag Type:  This field identifies the Endpoint Group type.  It can
             be either a 'User' group or 'App' group or 'Device' group,
             or 'Location' group

      Tag Server Information:  This field identifies information related
             to the source of the tag such as IP address and UDP/TCP
             port information

      Tag Application Protocol:  This filed identifies the protocol e.g.
             LDAP, Active Directory, or CMDB

      Tag Server Credentials:  This field identifies the credential
             information needed to access the tag server

4.2.  User-Group

   This object represents a user group based on either tag or other
   information.

   The 'User-Group' object SHALL have following information:

      Name:  This field identifies the name of this object

      Date:  Date this object was created or last modified

      Group Type:  This field identifies whether the user group is based
             on 'User-tag', 'User-name', or 'IP-address'

      Meta-data Server:  This field should be reference to a 'Meta-Data-
             Source' object





Kumar, et al.           Expires November 1, 2017                [Page 7]


Internet-Draft     Client Interface Information Model         April 2017


      Group Member:  This field is the 'User-tag, or 'User-names', or IP
             addresses based on the 'Group Type'

      Risk Level:  This field represents the threat level; valid range
             may be 0 to 9

4.3.  Device-Group

   This object represents a device group based on either tag or other
   information.

   The 'Device-Group' object SHALL have following information:

      Name:  This field identifies the name of this object

      Date:  Date this object was created or last modified

      Group Type:  This field identifies whether the device group is
             based on 'Device-tag' or 'Device-name', or IP address

      Meta-data Server:  This field should be reference to a 'Meta-Data-
             Source' object

      Group Member:  This field is the 'Device-tag, or 'Device-name', or
             IP address based on the 'Group Type'

      Risk Level:  This field represents the threat level; valid range
             may be 0 to 9

4.4.  Application-Group

   This object represents an application group based on either tag or
   other information.

   The 'Application-Group' object SHALL have following information:

      Name:  This field identifies the name of this object

      Date:  Date this object was created or last modified

      Group Type:  This field identifies whether the device group is
             based on 'App-tag' or 'App-name', or IP address

      Meta-data Server:  This field should be reference to a 'Meta-Data-
             Source' object

      Group Member:  This field is the 'Device-tag, or 'Device-name', or
             IP address and port information based on the 'Group Type'



Kumar, et al.           Expires November 1, 2017                [Page 8]


Internet-Draft     Client Interface Information Model         April 2017


      Risk Level:  This field represents the threat level; valid range
             may be 0 to 9

4.5.  Location-Group

   This object represents an location group based on either tag or other
   information.

   The 'Location-Group' object SHALL have following information:

      Name:  This field identifies the name of this object

      Date:  Date this object was created or last modified

      Group Type:  This field identifies whether the location group is
             based on 'Location-tag' or 'Location-name', or IP address

      Meta-data Server:  This field should be reference to a 'Meta-Data-
             Source' object

      Group Member:  This field is the 'Location-tag, or 'Location-
             names', or IP addresses based on the 'Group Type'

      Risk Level:  This field represents the threat level; valid range
             may be 0 to 9

5.  Information Model for Threat Prevention

   The threat prevention plays an important part in the overall security
   posture by reducing the attack surface.  This information could come
   in the form of threat feeds such as Botnet and GeoIP feeds usually
   from a third party or external service.

   There are multiple managed objects that constitute this category.
   This section lists these objects and relationship among these
   objects.

5.1.  Threat-Feed

   This object represents threat feed such as Botnet servers and GeoIP.

   The 'Threat-Feed' object SHALL have following information:

      Name:  This field identifies the name of this object

      Date:  Date this object was created or last modified





Kumar, et al.           Expires November 1, 2017                [Page 9]


Internet-Draft     Client Interface Information Model         April 2017


      Feed Type:  This field identifies whether a feed type is IP
             address based or URL based.

      Feed Server:  This field identifies the information about the feed
             provider, it may be an external service or local server

      Feed Priority:  This field represents the feed priority level to
             resolve conflict if there are multiple feed sources; valid
             range may be 0 to 9

5.2.  Custom-List

   This object represents custom list created for the purpose of
   defining exception to threat feeds.  An organization may want to
   allow certain exception to threat feeds obtained from a third party

   The 'Custom-List' object SHALL have following information:

      Name:  This field identifies the name of this object

      Date:  Date this object was created or last modified

      List Type:  This field identifies whether the list type is IP
             address based or URL based.

      List Property:  This field identifies the attributes of the list
             property e.g.  Blacklist or Whitelist.

      List Content:  This field contains the blacklist or whitelist
             contents such as IP addresses or URL names.

5.3.  Malware-Scan-Group

   This object represents information needed to detect malware.  This
   information could come from a local server or uploaded periodically
   from a third party.

   The 'Malware-Scan-Group' object SHALL have following information:

      Name:  This field identifies the name of this object

      Date:  Date this object was created or last modified

      Signature Server:  This field contains information about the
             server from where signatures can be downloaded periodically
             as updates become available





Kumar, et al.           Expires November 1, 2017               [Page 10]


Internet-Draft     Client Interface Information Model         April 2017


      File Types:  This field contains list of file types needed to be
             scanned for the virus

      Malware Signatures:  This field contains list of malware
             signatures or hash

5.4.  Event-Map-Group

   This object represents an event map containing security events and
   threat levels used for dynamic policy enforcement.

   The 'Event-Map-Group' object SHALL have following information:

      Name:  This field identifies the name of this object

      Date:  Date this object was created or last modified

      Security Events:  This contains a list of security events

      Threat Map:  This contains a list of threat levels

6.  Information Model for Telemetry Data

   Telemetry provides visibility into the network activities which can
   be tapped for further security analytics e.g. detecting potential
   vulnerabilities, malicious activities etc.

6.1.  Telemetry-Data

   This object contains information collected for telemetry.

   The 'Telemetry-Data' object SHALL have following information:

      Name:  This field identifies the name of this object

      Date:  Date this object was created or last modified

      Logs:  This field identifies whether 'Logs' need to be collected

      Syslogs  This field identifies whether 'Syslogs' need to be
             collected

      SNMP:  This field identifies whether 'SNMP traps' and 'SNMP
             alarms' need to be collected

      sFlow: This field identifies whether 'sFlow' data need to be
             collected




Kumar, et al.           Expires November 1, 2017               [Page 11]


Internet-Draft     Client Interface Information Model         April 2017


      NetFlow:  This field identifies whether 'NetFlow' data need to be
             collected

      Interface Stats:  This field identifies whether 'Interface' data
             such as packet bytes and counts need to be collected

6.2.  Telemetry-Source

   This object contains information related to telemetry source.  The
   source would be a NSF element in the network.

   The 'Telemetry-Source' object SHALL have following information:

      Name:  This field identifies the name of this object

      Date:  Date this object was created or last modified

      Source Type:  This field contains type of the NSF telemetry
             source: "NETWORK-NSF", "FIREWALL-NSF", "IDS-NSF", "IPS-
             NSF", "PROXY-NSF", "VPN-NSF", "DNS", "ACTIVE-DIRECTORY","IP
             Reputation Authority", "Web Reputation Authority", "Anti-
             Malware Sandbox", "Honey Pot", "DHCP", "Other Third Party",
             "ENDPOINT"

      NSF Access Parameters:  This field contains information such as IP
             address and protocol (UDP or TCP) port number of the NSF
             providing telemetry data

      NSF Access Credentials:  This field contains username and passwod
             to authenticate with the NSF

      Collection Interval:  This field contains time in milliseconds
             between each data collection.  For example, a value of 5000
             means data is streamed to collector every 5 seconds.  Value
             of 0 means data streaming is event-based.

      Collection Method:  This field contains method of collection
             whether it is PUSH-based or PULL-based

      Heartbeat Interval:  This field contains time in seconds the
             source must send telemetry heartbeat

      QoS Marking:  This field contains DSCP value source MUST mark on
             its generated telemetry packets







Kumar, et al.           Expires November 1, 2017               [Page 12]


Internet-Draft     Client Interface Information Model         April 2017


6.3.  Telemetry-Destination

   This object contains information related to telemetry destination.
   The destination is usually a collector which is either a part of
   Security Controller or external system such as SIEM.

   The 'Telemetry-Destination' object SHALL have following information:

      Name:  This field identifies the name of this object

      Date:  Date this object was created or last modified

      Collector State:  This field contains the state info regarding the
             collector

      Collector Access Parameter:  This field contains the information
             such as IP address and protocol (UDP or TCP) port number
             for the collector's destination

      Collector Access Credentials:  This field contains the username
             and passwod for the collector

      Data Encoding:  This field contains the telemetry data encoding,
             which could in the form of a schema

      Data Transport:  This field contains streaming telemetry data
             protocols: whether it is gRPC, protocol buffer over UDP,
             etc.

7.  Information Model for Policy Instance

   In order to enforce a security policy, a policy instance must have
   complete information such as where and when a policy need to be
   applied.  The policy instantiation is done by combining the managed
   objects described so far and a few others listed below.

7.1.  Policy-Calendar

   This object contains information related to scheduling a policy.  The
   policy could be activated based on a time calendar or security event
   including threat level changes.

   The 'Policy-Calendar' object SHALL have following information:

      Name:  This field identifies the name of this object

      Date:  Date this object was created or last modified




Kumar, et al.           Expires November 1, 2017               [Page 13]


Internet-Draft     Client Interface Information Model         April 2017


      Enforecment Type:  This field identifies whether the policy
             enforcement is 'ADMIN-ENFORCED' or 'TIME-ENFORCED', or
             'EVENT-ENFORCED'

      Time Information:  This field contains time calendar such as
             'BEGIN-TIME' and 'END-TIME' for one time enforcement or
             recurring time calendar for periodic enforcement

      Event Map:  This field contains security events and threat map in
             order to determine when a policy need to be activated

7.2.  Policy-Action

   This object represents actions that a Security Admin want to perform
   based on certain traffic class.

   The 'Policy-Action' object SHALL have following information:

      Name:  This field identifies the name of this object

      Date:  Date this object was created or last modified

      Primary Action:  This field identifies the action when a rule is
             matched by NSF.  The action could be one of 'PERMIT',
             'DENY', 'RATE-LIMIT', 'TRAFFIC-CLASS', 'AUTHENTICATE-
             SESSION', 'IPS, 'APP-FIREWALL'

      Secondary Action:  Security Admin can also specify additional
             actions if a rule is matched.  This could be one of 'LOG',
             'SYSLOG', 'SESSION-LOG'

7.3.  Policy-Rule

   This object represents rules that a Security Admin want to define in
   order to express its business objectives in a Security Policy.

   The 'Policy-Rule' object SHALL have following information:

      Name:  This field identifies the name of this object

      Date:  Date this object was created or last modified

      Source:  This field identifies the source of the traffic.  This
             could be reference to either 'Policy Endpoint Group' or
             'Threat-Feed' or 'Custom-List' if Security Admin wants to
             specify the source otherwise the default is to match all
             traffic




Kumar, et al.           Expires November 1, 2017               [Page 14]


Internet-Draft     Client Interface Information Model         April 2017


      Destination:  This field identifies the destination of the
             traffic.  This could be reference to either 'Policy
             Endpoint Group' or 'Threat-Feed' or 'Custom-List' if
             Security Admin wants to specify the destination otherwise
             the default is to match all traffic

      Exception:  This field identifies the exception consideration when
             'Source' and 'Destination' are matched for a given
             communication.  This should be reference to 'Policy
             Endpoint Group' object

      Action:  This field identifies the action taken when 'Source' and
             'Destination' are matched for a given communication

      Precedence:  This field identifies the precedence assigned to this
             rule by Security Admin.  This is helpful in conflict
             resolution when two or more rules match a given traffic
             class

7.4.  Policy-Instance

   This object represents a mechanism to express a Security Policy by
   Security Admin using Security Controller Client-Facing interface; the
   policy would be enforced on a NSF.

   The 'Policy-Instance' object SHALL have following information:

      Name:  This field identifies the name of this object

      Date:  Date this object was created or last modified

      Rules: This field contains list of rules.  If the rule does not
             have a user defined precedence, then any conflict must be
             manually resolved

      Scheduling Type:  This field specifies when this policy should be
             scheduled.  The policy could be scheduled based on time
             calendar or event-map

      Scheduling Information:  This field contains either the 'Calendar'
             or 'Event-map' based on 'Schedule type'

      Owner: This field defines the owner of this policy.  Only the
             owner is authorized to modify the contents of the policy







Kumar, et al.           Expires November 1, 2017               [Page 15]


Internet-Draft     Client Interface Information Model         April 2017


8.  Security Considerations

   Information model provides mechanism to protect Client-Facing
   interface to Security controller.  One of the specified mechanism
   must be used to protect Enterprise network, data and all resources
   from external attacks.  This model mandates that interface must have
   proper authentication and authorization with Role Based Access
   Controls to address multi-tenancy requirement.  The draft does not
   mandate that a particular mechanism be used as different organization
   may have different needs based on their deployment.

9.  IANA Considerations

   This document requires no IANA actions.  RFC Editor: Please remove
   this section before publication.

10.  Acknowledgements

   The authors would like to thank Kunal Modasiya, Prakash T.  Sehsadri
   and Srinivas Nimmagadda from Juniper Networks for helpful
   discussions.

11.  Informative References

   [I-D.ietf-i2nsf-problem-and-use-cases]
              Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R.,
              and J. Jeong, "I2NSF Problem Statement and Use cases",
              draft-ietf-i2nsf-problem-and-use-cases-15 (work in
              progress), April 2017.

   [I-D.ietf-i2nsf-terminology]
              Hares, S., Strassner, J., Lopez, D., Xia, L., and H.
              Birkholz, "Interface to Network Security Functions (I2NSF)
              Terminology", draft-ietf-i2nsf-terminology-03 (work in
              progress), March 2017.

   [I-D.kumar-i2nsf-client-facing-interface-req]
              Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic,
              S., and L. Xia, "Requirements for Client-Facing Interface
              to Security Controller", draft-kumar-i2nsf-client-facing-
              interface-req-02 (work in progress), October 2016.

   [RFC3444]  Pras, A. and J. Schoenwaelder, "On the Difference between
              Information Models and Data Models", RFC 3444,
              DOI 10.17487/RFC3444, January 2003,
              <http://www.rfc-editor.org/info/rfc3444>.





Kumar, et al.           Expires November 1, 2017               [Page 16]


Internet-Draft     Client Interface Information Model         April 2017


Authors' Addresses

   Rakesh Kumar
   Juniper Networks
   1133 Innovation Way
   Sunnyvale, CA  94089
   US

   Email: rkkumar@juniper.net


   Anil Lohiya
   Juniper Networks
   1133 Innovation Way
   Sunnyvale, CA  94089
   US

   Email: alohiya@juniper.net


   Dave Qi
   Bloomberg
   731 Lexington Avenue
   New York, NY  10022
   US

   Email: DQI@bloomberg.net


   Nabil Bitar
   Nokia
   755 Ravendale Drive
   Mountain View, CA  94043
   US

   Email: nabil.bitar@nokia.com


   Senad Palislamovic
   Nokia
   755 Ravendale Drive
   Mountain View, CA  94043
   US

   Email: senad.palislamovic@nokia.com






Kumar, et al.           Expires November 1, 2017               [Page 17]


Internet-Draft     Client Interface Information Model         April 2017


   Liang Xia
   Huawei
   101 Software Avenue
   Nanjing, Jiangsu  210012
   China

   Email: Frank.Xialiang@huawei.com












































Kumar, et al.           Expires November 1, 2017               [Page 18]