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: January 17, 2018                                          D. Qi
                                                               Bloomberg
                                                                N. Bitar
                                                         S. Palislamovic
                                                                   Nokia
                                                                  L. Xia
                                                                  Huawei
                                                           July 16, 2017


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

Abstract

   This document defines information model for Client-Facing interface
   to Security Controller based on the requirements identified in
   [I-D.ietf-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 January 17, 2018.

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 January 17, 2018                [Page 1]


Internet-Draft     Client Interface Information Model          July 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.  Metadata-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 January 17, 2018                [Page 2]


Internet-Draft     Client Interface Information Model          July 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 needed to express a Security Policy.
   An object 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 objects.  The
   information model proposed in this draft is in accordance with
   interface requirements as defined in
   [I-D.ietf-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-terminology]

   OSS:      Operation Support System

   RBAC:     Role Based Access Control



Kumar, et al.           Expires January 17, 2018                [Page 3]


Internet-Draft     Client Interface Information Model          July 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 Enterprise organization may have multiple tenants or
   departments such as HR, Finance, Legal, with each tenant having a
   need to manage their own Security Policies.  In a Service Provider, a
   tenant could represent a Customer that want 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 able to work 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 January 17, 2018                [Page 4]


Internet-Draft     Client Interface Information Model          July 2017


3.2.  Policy-Tenant

   This object defines an entity within an organization.  The entity
   could be a department or business unit within an Enterprise
   organization 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 permissions to access
             Endpoint Groups for the purpose of policy management or may
             restrict certain operations related to policy managements.

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 January 17, 2018                [Page 5]


Internet-Draft     Client Interface Information Model          July 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 January 17, 2018                [Page 6]


Internet-Draft     Client Interface Information Model          July 2017


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

4.1.  Metadata-Source

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

   Metadata-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 a User-Group, App-Group, Device-Group or Location-Group

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

      Tag-Source-Application:  This filed identifies the protocol e.g.
             LDAP, Active Directory, or CMDB used to communicated with
             server

      Tag-Source-Credentials:  This field identifies the credential
             information needed to access the 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

      Metadata-Server:  This field should be reference to a Metadata-
             Source object





Kumar, et al.           Expires January 17, 2018                [Page 7]


Internet-Draft     Client Interface Information Model          July 2017


      Group-Member:  This field is a list of User-tag, User-names or IP
             addresses based on Group-Type

      Risk-Level:  This field represents the risk level or importance of
             the Endpoint to Security Admin for policy purpose; the
             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

      Metadata-Server:  This field should be reference to a Metadata-
             Source object

      Group-Member:  This field is a list of Device-tag, Device-name or
             IP address based on Group-Type

      Risk-Level:  This field represents the risk level or importance of
             the Endpoint to Security Admin for policy purpose; the
             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 application group
             is based on App-tag or App-name, or IP address

      Metadata-Server:  This field should be reference to a Metadata-
             Source object




Kumar, et al.           Expires January 17, 2018                [Page 8]


Internet-Draft     Client Interface Information Model          July 2017


      Group-Member:  This field is a list of Application-tag
             Application-name or IP address and port information based
             on Group-Type

      Risk-Level:  This field represents the risk level or importance of
             the Endpoint to Security Admin for policy purpose; the
             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, Location-name or IP address

      Metadata-Server:  This field should be reference to a Metadata-
             Source object

      Group-Member:  This field is a list of Location-tag, Location-name
             or IP addresses based on Group-Type

      Risk Level:  This field represents the risk level or importance of
             the Endpoint to Security Admin for policy purpose; the
             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:



Kumar, et al.           Expires January 17, 2018                [Page 9]


Internet-Draft     Client Interface Information Model          July 2017


      Name:  This field identifies the name of this object

      Date:  Date this object was created or last modified

      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; the
             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 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





Kumar, et al.           Expires January 17, 2018               [Page 10]


Internet-Draft     Client Interface Information Model          July 2017


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

      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 used for
             purpose for Security Policy definition

      Threat-Map:  This contains a list of threat levels used for
             purpose for Security Policy definition

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

      Log-Data:  This field identifies whether Log data need to be
             collected

      Syslog-Data  This field identifies whether Syslog data need to be
             collected



Kumar, et al.           Expires January 17, 2018               [Page 11]


Internet-Draft     Client Interface Information Model          July 2017


      SNMP-Data:  This field identifies whether SNMP traps and alarm
             data need to be collected

      sFlow-Record:  This field identifies whether sFlow records need to
             be collected

      NetFlow-Record:  This field identifies whether NetFlow record need
             to be collected

      NSF-Stats:  This field identifies whether statistics need to be
             collected from NSF

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 or "OTHER-NSF"

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

      NSF-Credentials:  This field contains username and password 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 January 17, 2018               [Page 12]


Internet-Draft     Client Interface Information Model          July 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-Source:  This field contains the information such as IP
             address and protocol (UDP or TCP) port number for the
             collector's destination

      Collector-Credentials:  This field contains the username and
             password 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 express a Security Policy, a policy instance must have
   complete information such as where and when a policy need to be
   applied.  The is done by defining a set of managed objects and
   relationship among them.  A policy may be related segmentation,
   threat mitigation or telemetry data collection from NSF in the
   network.

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 January 17, 2018               [Page 13]


Internet-Draft     Client Interface Information Model          July 2017


      Enforecment-Type:  This field identifies whether the policy
             enforcement is "ADMIN-ENFORCED", "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 or threat map in
             order to determine when a policy need to be activated.
             This is a reference to Evnet-Map-Group defined earlier

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", "REDIRECT", "RATE-LIMIT", "TRAFFIC-CLASS",
             "AUTHENTICATE-SESSION", "IPS", "APP-FIREWALL", or "COLLECT"

      Secondary-Action:  Security Admin can also specify additional
             actions if a rule is matched.  This could be one of "LOG",
             "SYSLOG", or "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, Threat-
             Feed or Custom-List as defined earlier.  This could be a
             special object "ALL" that match all traffic.  This could
             also be Telemetry-Source for telemetry collection policy.



Kumar, et al.           Expires January 17, 2018               [Page 14]


Internet-Draft     Client Interface Information Model          July 2017


      Destination:  This field identifies the destination of the
             traffic.  This could be reference to either Policy-
             Endpoint-Group, Threat-Feed or Custom-List as defined
             earlier.  This could be a special object "ALL" that match
             all traffic.  This could also be Telemetry-Destination for
             telemetry collection policy.

      Match-Condition:  This field identifies the match criteria used to
             evaluate whether the specified action need to be taken or
             not.  This could be either a Policy-Endpoint-Group
             identifying a Application set or a set of traffic rules

      Match-Direction:  This field identifies if the match criteria is
             to evaluated for both direction of the traffic or only in
             one direction with default of allowing in the other
             direction for stateful match conditions.  This is optional
             and by default rule should apply in both directions

      Exception:  This field identifies the exception consideration when
             a rule is evaluated for a given communication.  This could
             be reference to "Policy-Endpoint-Group" object or set of
             traffic matching criteria

      Action:  This field identifies the action taken when a rule is
             matched.  There is always a implicit action to drop traffic
             if no rule is matched for a traffic type

      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 a list of rules.  If the rule does not
             have a user defined precedence, then any conflict must be
             manually resolved




Kumar, et al.           Expires January 17, 2018               [Page 15]


Internet-Draft     Client Interface Information Model          July 2017


      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 reference to Policy-
             Calendar or Event-Map-Group 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

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-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-ietf-i2nsf-client-facing-
              interface-req-02 (work in progress), July 2017.

   [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-16 (work in
              progress), May 2017.






Kumar, et al.           Expires January 17, 2018               [Page 16]


Internet-Draft     Client Interface Information Model          July 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-04 (work in
              progress), July 2017.

   [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>.

Authors' Addresses

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

   Email: rakeshkumarcloud@gmail.com


   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




Kumar, et al.           Expires January 17, 2018               [Page 17]


Internet-Draft     Client Interface Information Model          July 2017


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

   Email: senad.palislamovic@nokia.com


   Liang Xia
   Huawei
   101 Software Avenue
   Nanjing, Jiangsu  210012
   China

   Email: Frank.Xialiang@huawei.com



































Kumar, et al.           Expires January 17, 2018               [Page 18]