<?xml version="1.0" encoding="iso-8859-1"?>
<!--
     vim: set softtabstop=2 shiftwidth=2 expandtab
     version=20150108
-->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="no" ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>


<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC7491 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7491.xml">
]>

<rfc category="info"
     docName="draft-kumar-i2nsf-client-facing-interface-im-07"
     ipr="trust200902">
  <front>
    <title abbrev="Consumer-Facing Interface Information Model">Information Model for Consumer-Facing Interface to Security Controller</title>

    <author fullname="Rakesh Kumar" initials="R." surname="Kumar">
      <organization>Juniper Networks</organization>

      <address>
        <postal>
          <street>1133 Innovation Way</street>

          <city>Sunnyvale</city>

          <region>CA</region>

          <country>US</country>

          <code>94089</code>
        </postal>

        <email>rakeshkumarcloud@gmail.com</email>
      </address>
    </author>

    <author fullname="Anil Lohiya" initials="A." surname="Lohiya">
      <organization>Juniper Networks</organization>

      <address>
        <postal>
          <street>1133 Innovation Way</street>

          <city>Sunnyvale</city>

          <region>CA</region>

          <country>US</country>

          <code>94089</code>
        </postal>

        <email>alohiya@juniper.net</email>
      </address>
    </author>

    <author fullname="Dave Qi" initials="D." surname="Qi">
      <organization>Bloomberg</organization>

      <address>
        <postal>
          <street>731 Lexington Avenue</street>

          <city>New York</city>

          <region>NY</region>

          <country>US</country>

          <code>10022</code>
        </postal>

        <email>DQI@bloomberg.net</email>
      </address>
    </author>

    <author fullname="Nabil Bitar" initials="N." surname="Bitar">
      <organization>Nokia</organization>

      <address>
        <postal>
          <street>755 Ravendale Drive</street>

          <city>Mountain View</city>

          <region>CA</region>

          <country>US</country>

          <code>94043</code>
        </postal>

        <email>nabil.bitar@nokia.com</email>
      </address>
    </author>

    <author fullname="Senad Palislamovic" initials="S." surname="Palislamovic">
      <organization>Nokia</organization>

      <address>
        <postal>
          <street>755 Ravendale Drive</street>

          <city>Mountain View</city>

          <region>CA</region>

          <country>US</country>

          <code>94043</code>
        </postal>

        <email>senad.palislamovic@nokia.com</email>
      </address>
    </author>

    <author fullname="Liang Xia" initials="L." surname="Xia">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>101 Software Avenue</street>

          <city>Nanjing</city>

          <region>Jiangsu</region>

          <country>China</country>

          <code>210012</code>
        </postal>

        <email>Frank.Xialiang@huawei.com</email>
      </address>
    </author>

    <author initials="J." surname="Jeong" fullname="Jaehoon Paul Jeong">
      <organization abbrev="Sungkyunkwan University">
        Department of Software 
      </organization>

      <address>
        <postal>
          <street>Sungkyunkwan University</street>
          <street>2066 Seobu-Ro, Jangan-Gu</street>
          <city>Suwon</city> <region>Gyeonggi-Do</region>
          <code>16419</code>
          <country>Republic of Korea</country>
        </postal>
        <phone>+82 31 299 4957</phone>
        <facsimile>+82 31 290 7996</facsimile>
        <email>pauljeong@skku.edu</email>
        <uri>http://iotlab.skku.edu/people-jaehoon-jeong.php</uri>
      </address>
    </author>
		
    <date month="July" day="17" year="2018" /> 

    <area>Security</area>

    <workgroup>I2NSF Working Group</workgroup>

    <keyword>I2NSF</keyword>

    <abstract>
      <t>This document defines an information model for Consumer-Facing
      interface to Security Controller based on the requirements identified
      in <xref target="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.
      The information model is organized based on the "Event-Condition-Event" 
      (ECA) policy model defined by a capability information model for 
      Interface to Network Security Functions (I2NSF)
      <xref target="I-D.ietf-i2nsf-capability"/>.
      </t>
    </abstract>
  </front>

  <middle>
    <section anchor="section:introduction" title="Introduction">
      <t>Interface to Network Security Functions (I2NSF) defines a 
      Consumer-Facing Interface to deliver high-level security policies 
      to Security Controller <xref target="RFC8192"/><xref target="RFC8329"/>
      for securiy enforcement in Network Security Functions (NSFs).</t>

      <t>The Consumer-Facing Interface would be 
        built using a set of objects, with each object capturing a unique
        set of information from Security Admin (i.e., I2NSF User
        <xref target="RFC8329"/>) 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 document is in accordance with
        interface requirements as defined in <xref target="I-D.ietf-i2nsf-client-facing-interface-req"/>.</t>
        
        <t>An NSF Capability model is proposed in <xref target="I-D.ietf-i2nsf-capability"/>
        as the basic model for both the NSF-Facing interface and Consumer-Facing Interface 
        security policy model of this document. The information model proposed in this document 
        is structured in accordance with the "Event-Condition-Event" (ECA) policy model.</t>

      <t><xref target="RFC3444"/> explains differences between an 
      information and data model. This document use the guidelines in <xref target="RFC3444"/> to 
      define an information model for Consumer-Facing Interface in this document.
      <xref target="figure:high-level-abstraction" /> shows a high-level abstraction of Consumer-Facing Interface.
      A data model, which represents an implementation of the proposed 
      information model in a specific data representation language, will
      be defined in a separate document.</t>

      <figure anchor="figure:high-level-abstraction" title="Diagram for High-level Abstraction of Consumer-Facing Interface">
      <artwork>
                        +-----------------+       +-----------------+                      
                        |                 |       |                 |                      
                        | Consumer-Facing +------>+ Consumer Facing |
                        |    Interface    |       |    Interface    |       
                        |Information Model|       |    Data Model   |
                        +--------+--------+       +-----------------+
                                 ^
                                 |
                                 |
                   +-------------+-------------+
                   |                           |
                   |       Policy-general      |
                   |                           |
                   +-------------+-------------+
                                 ^                                                                                  
                                 |                                                    
      +------------+-------------+------------+--------------+               
      |            |             |            |              |               
+-----+----+  +----+-----+  +----+----+  +----+----+  +------+-----+       
|          |  |          |  |         |  |         |  |            |       
|  Multi   |  | Endpoint |  |  Policy |  | Threat  |  | Telemetry  |
| tenancy  |  |  groups  |  |         |  |  feed   |  |    data    |       
+----------+  +----------+  +----+----+  +---------+  +------------+                                   
                                 ^
                                 |
                                 |
                          +------+------+
                          |             |
                          |     Rule    |
                          |             |
                          +------+------+
                                 ^
                                 |
                +----------------+----------------+
                |                |                |
         +------+------+  +------+------+  +------+------+ 
         |             |  |             |  |             | 
         |    Event    |  |  Condition  |  |    Action   | 
         |             |  |             |  |             | 
         +-------------+  +-------------+  +-------------+ 
      </artwork>
      </figure>
    </section>

    <section anchor="section:conventions" title="Conventions used in the Document">
      <t><list
          style="hanging" hangIndent="10">
          <t hangText="BSS:">Business Support System</t>

          <t hangText="CLI:">Command Line Interface</t>

          <t hangText="CMDB:">Configuration Management Database</t>

          <t hangText="Controller:">Security Controller or Management System</t>

          <t hangText="CRUD:">Create, Retrieve, Update, Delete</t>

          <t hangText="FW:">Firewall</t>

          <t hangText="GUI:">Graphical User Interface</t>

          <t hangText="IDS:">Intrusion Detection System</t>

          <t hangText="IPS:">Intrusion Prevention System</t>

          <t hangText="LDAP:">Lightweight Directory Access Protocol</t>

          <t hangText="NSF:">Network Security Function, defined by <xref
          target="I-D.ietf-i2nsf-terminology"/></t>

          <t hangText="OSS:">Operations Support System</t>

          <t hangText="RBAC:">Role-Based Access Control</t>

          <t hangText="SIEM:">Security Information and Event Management</t>

          <t hangText="URL:">Universal Resource Locator</t>

          <t hangText="vNSF:">NSF being instantiated on Virtual Machines</t>
        </list></t>
    </section>

    <section anchor="section:Policy" title="Information Model for Policy">
      <t>A Policy object represents a mechanism to express a Security Policy by
      Security Admin (i.e., I2NSF User) using Consumer-Facing Interface toward Security Controller; the policy
      would be enforced on an NSF. The Policy object SHALL have following information:<list
      style="hanging" hangIndent="10">
          
           <t hangText="   Name:">This field identifies the name of this object.</t>
          
           <t hangText="   Date:">Date when this object was created or last modified.</t>
          
           <t hangText="   Multi-Tenancy:">The multi-tenant environment information
           in which the policy is applied. The Rules in the Policy can refer to
           sub-objects (e.g., domain, tenant, role, and user) of it. 
           It can be either a reference to a Multi-Tenancy object defined in another 
           place, or a concrete object. See details in Section 4.</t>

           <t hangText="   End-Group:">This field contains a list of logical entities
           in the business environment where a Security Policy is to be applied. It 
           can be referenced by the Condition objects in a Rule, e.g., Source, Destination, 
           Match, etc. It can be either a reference to an End-Group object defined 
           in other place, or a concrete object. See details in Section 5.</t>

           <t hangText="   Threat-Feed:">This field represents threat feed such as 
            Botnet servers, GeoIP, and Malware signature. This information can be 
            referenced by the Rule Action object directly to execute the threat 
            mitigation. See details in Section 6.</t>

           <t hangText="   Telemetry-Data:">This field represents the telemetry 
           collection related information that the Rule Action object can refer 
           to about how to collect the interested telemetry information, for example, 
           what type of telemetry to collect, where the telemetry source is, where to send 
           the telemetry information. See details in Section 7.</t>

           <t hangText="   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.</t>
          
           <t hangText="   Owner:">This field defines the owner of this policy.
           Only the owner is authorized to modify the contents of the policy.</t>
      </list></t>

      <t>A policy is a container of Rules. In order to express a Rule, a Rule must 
      have complete information such as where and when a policy needs to be applied. 
      This is done by defining a set of managed objects and relationship among them.
      A Policy Rule may be related segmentation, threat mitigation or telemetry data
      collection from an NSF in the network, which will be specified as the sub-model of
      the policy model in the subsequent sections.</t>

      <t>The rule object SHALL have the following information:<list
      style="hanging" hangIndent="10">
          <t hangText="   Name:">This field identifies the name of this object.</t>

          <t hangText="   Date:">This field indicates the date when this object was created or last modified.</t>

          <t hangText="   Event:">This field includes the information to determine 
          whether the Rule Condition can be evaluated or not. See details in 
          Section 3.1.</t>

          <t hangText="   Condition:">This field contains all the checking conditions
          to apply to the objective traffic. See details in Section 3.2.</t>

          <t hangText="   Action:">This field identifies the action taken when a 
          rule is matched. There is always an implicit action to drop traffic if 
          no rule is matched for a traffic type. See details in Section 3.3.</t>

          <t hangText="   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.</t>
        </list></t>

          <section anchor="section:Event-sub-model" title="Event Sub-Model">
            <t>The Event Object contains information related to scheduling a Rule. The
            Rule could be activated based on a time calendar or security event including
            threat level changes.</t>

            <t>Event object SHALL have following information:<list
            style="hanging" hangIndent="10">
                <t hangText="   Name:">This field identifies the name of this object.</t>

                <t hangText="   Date:">This field indicates the date when this object was created or last modified.</t>

                <t hangText="   Event-Type:">This field identifies whether the event of 
                triggering policy enforcement is "ADMIN-ENFORCED", "TIME-ENFORCED" or
                "EVENT-ENFORCED".</t>

                <t hangText="   Time-Information:">This field contains a time calendar such
                as "BEGIN-TIME" and "END-TIME" for one time enforcement or recurring time 
                calendar for periodic enforcement.</t>

                <t hangText="   Event-Map-Group:">This field contains security events or 
                threat map in order to determine when a policy needs to be activated. This
                is a reference to Event-Map-Group defined later.</t>
              </list></t>

              <section anchor="section:Event-Map-Group" title="Event-Map-Group">
                <t>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:<list
                style="hanging" hangIndent="10">

                   <t hangText="   Name:">This field identifies the name of this object.</t>

                   <t hangText="   Date:">This field indicates the date when this object was created or last modified.</t>

                   <t hangText="   Security-Events:">This contains a list of security 
                   events used for purpose for Security Policy definition.</t>

                   <t hangText="   Threat-Map:">This contains a list of threat levels used 
                  for purpose for Security Policy definition.</t>
                </list></t>
              </section>
            </section>
          
          <section anchor="section:Condition-sub-model" title="Condition Sub-Model">
            <t>This object represents Conditions that Security Admin wants to apply the 
            checking on the traffic in order to determine whether the set of actions in 
            the Rule can be executed or not.</t>

            <t>The Condition object SHALL have following information:<list
            style="hanging" hangIndent="10">
                <t hangText="   Source:">This field identifies the source of the traffic.
                This could be a reference to either Policy-Endpoint-Group, Threat-Feed or 
                Custom-List as defined earlier.  This could be a special object "ALL" 
                that matches all traffic.  This could also be Telemetry-Source for telemetry 
                collection policy.</t>

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

                <t hangText="   Match:">This field identifies the match criteria used to
                evaluate whether the specified action needs to be taken or not.
                This could be either a Policy-Endpoint-Group identifying an Application 
                set or a set of traffic rules.</t>

                <t hangText="   Match-Direction:">This field identifies whether the match
                criteria is to be evaluated for both directions or only one direction of the
                traffic with a default of allowing the other direction for stateful match
                conditions. This is optional and by default a rule should apply to both
                directions.</t>

                <t hangText="   Exception:">This field identifies the exception 
                consideration when a rule is evaluated for a given communication.
                This could be a reference to "Policy-Endpoint-Group" object or set 
                of traffic matching criteria.</t>
              </list></t>
              <t>The condition object is made of condition clauses. Each condition clause 
              	consists of three tuples; variable, operator and value.
              </t>
              <t>The variable and value can be source and destination IP address, for
              	example, and they have logical operator in between to check whether they
              	match the condition criteria set by a security admin. For Example:

              	If condition A AND B is true:
              		THEN execute actions
              	ENDIF

              	where A denotes a destination address, and B denotes a blacklisted 
              	IP address. The operator AND is the logical AND operation.
              	
              </t>
              <figure anchor="figure:condition-clause-diagram" title="Condition Clause Diagram">
              <artwork>
                                                  1..n                  
                                                  +----------------+
                                                  |                |
                                    +------------>+  Policy rule   |
                                    |             |                |
                           1..n     |             +----------------+
                           +--------+--------+                    
                           |                 |                       
                           +Condition clause +           
                           |                 |                    
                           +--------+--------+                    
                                ^   ^   ^
                                |   |   |     
                 +--------------+   |   +--------------+                    
        1..n     |         1..n     |          1..n    |           
        +--------+-------+ +--------+--------+ +-------+-------+ 
        |                | |                 | |               | 
        |    Variable    | |    Operator     | |     Value     | 
        |                | |                 | |               | 
        +----------------+ +-----------------+ +---------------+ 
         
         </artwork>
         </figure>
         	<t>The semantics used in a condition clause is also used in the clauses in the
         		Event-submodel and Action sub-model.
            </t>
     </section>
          <section anchor="section:Action-sub-model" title="Action Sub-Model">
            <t>This object represents actions that Security Admin wants to perform
            based on certain traffic class.</t>

            <t>The Action object SHALL have following information:<list
            style="hanging" hangIndent="10">
                <t hangText="   Name:">This field identifies the name of this object.</t>

                <t hangText="   Date:">This field indicates the date when this object was created or last modified.</t>

                <t hangText="   Primary-Action:">This field identifies the action when 
                a rule is matched by an NSF.  The action could be one of "PERMIT", "DENY", 
                "DROP-CONNECTION", "AUTHENTICATE-CONNECTION", "MIRROR", "REDIRECT", "NETFLOW", 
                "COUNT", "ENCRYPT", "DECRYPT", "THROTTLE", "MARK", or "INSTANTIATE-NSF".</t>

                <t hangText="   Secondary-Action:">Security Admin can also specify 
                additional actions if a rule is matched.  This could be one of "LOG",
                "SYSLOG", or "SESSION-LOG".</t>
              
              </list></t>
            </section>
        </section>


    <section anchor="section:multi-tenancy"
             title="Information Model for Multi-Tenancy">
      <t>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 Human Resources (HR), Finance, and Legal, with each tenant having a need to manage
      their own Security Policies. In a Service Provider, a tenant could represent
      a Customer that wants to manage its own Security Policies.</t>

      <t>There are multiple managed objects that constitute multi-tenancy aspects.
      This section lists these objects and any relationship among these objects.
      Below diagram shows an example of multi-tenancy in an Enterprise domain.
  </t>
		<figure anchor="figure:multi-tenancy-diagram" title="Multi-tenancy Diagram">
          <artwork>
                          +-------------------+                          
    (Multi-Tenancy)       |       Domain      |                          
                          |(e.g., Enterprise) |                          
                          +---------+---------+ 
                                    ^
                                    |
               +--------------------+--------------------+                                                                                          
               |                    |                    | 
      +--------+-------+  +---------+--------+  +--------+--------+  
      |  Department 1  |  |   Department 2   |  |  Department n   |  
      +--------+-------+  +---------+--------+  +--------+--------+  
               ^                    ^                    ^            
               |                    |                    |            
      +--------+--------+  +-----------------+  +--------+--------+  
      | Sub-domain 1..n |  | Sub-domain 1..n |  | Sub-domain 1..n |  
      +--------+--------+  +--------+--------+  +--------+--------+  
               ^                    ^                    ^            
               |                    |                    |            
      +--------+--------+  +--------+--------+  +--------+--------+  
      |   Tenant 1..n   |  |   Tenant 1..n   |  |   Tenant 1..n   |  
      +-----------------+  +-----------------+  +-----------------+  

      		</artwork>
      	</figure>             
      <section anchor="section:policy-domain" title="Policy-Domain">
        <t>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 hosts 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.</t>

        <t>The Policy-Domain object SHALL have following information: <list
            style="hanging" hangIndent="10">
            <t hangText="   Name:"> Name of the organization or customer representing
            this domain. </t>

            <t hangText="   Address:"> Address of the organization or customer. </t>

            <t hangText="   Contact:"> Contact information of the organization or
            customer. </t>
            
            <t hangText="   Date:"> Date when this account was created or last modified. </t>

            <t hangText="   Authentication-Method:"> Authentication method to be
            used for this domain. It should be a reference to a
            'Policy-Management-Authentication-Method' object. </t>
          </list></t>
                                                                                                 
      </section>
      <section anchor="section:policy-tenant" title="Policy-Tenant">
        <t>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 manage its own Policies due to regulatory compliance or business
        reasons.</t>

        <t>The Policy-Tenant object SHALL have following information: <list
            style="hanging" hangIndent="10">
            <t hangText="   Name:"> Name of the Department or Division within an
            organization. </t>

            <t hangText="   Date:"> Date when this account was created or last modified. </t>

            <t hangText="   Domain:"> This field identifies the domain to which this
            tenant belongs. This should be a reference to a Policy-Domain object. </t>
          </list></t>
      </section>

      <section anchor="section:policy-role" title="Policy-Role">
        <t>This object defines a set of permissions assigned to a user in an
        organization that wants to manage its own Security Policies. It provides
        a convenient way to assign policy users to a job function or a set of
        permissions within the organization.</t>

        <t>The Policy-Role object SHALL have the following information: <list
            style="hanging" hangIndent="10">
            <t hangText="   Name:"> This field identifies the name of the role. </t>

            <t hangText="   Date:"> Date when this role was created or last modified. </t>

            <t hangText="   Access-Profile:"> This field identifies the access
            profile for the role. The profile grants or denies the permissions to
            access Endpoint Groups for the purpose of policy management or may
            restrict certain operations related to policy managements.</t>
          </list></t>
      </section>

      <section anchor="section:policy-user" title="Policy-User">
        <t>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 perform policy management. A user may
        be an individual, system, or application requiring access to Security
        Controller.</t>

        <t>The Policy-User object SHALL have the following information: <list
            style="hanging" hangIndent="10">
            <t hangText="   Name:"> Name of a user.</t>

            <t hangText="   Date:"> Date when this user was created or last modified. </t>

            <t hangText="   Password:"> User password for basic authentication. </t>

            <t hangText="   Email:"> E-mail address of the user. </t>

            <t hangText="   Scope-Type:"> This field identifies whether the user
            has domain-wide or tenant-wide privileges. </t>

            <t hangText="   Scope-Reference:"> This field should be a reference to either
            a Policy-Domain or a Policy-Tenant object. </t>

            <t hangText="   Role:"> This field should be a reference to a Policy-Role
            object that defines the specific permissions. </t>
          </list></t>
      </section>

      <section anchor="section:policy-management-auth-method"
               title="Policy Management Authentication Method">
        <t>This object represents authentication schemes supported by Security
        Controller.</t>

        <t>This Policy-Management-Authentication-Method object SHALL have
        the following information: <list
            style="hanging" hangIndent="10">
            <t hangText="   Name:"> This field identifies name of this object. </t>
            
            <t hangText="   Date:"> Date when this object was created or last modified. </t>

            <t hangText="   Authentication-Method:"> This field identifies the
            authentication methods. It could be a password-based, token-based,
            certificate-based or single sign-on authentication. </t>
            
            <t hangText="   Mutual-Authentication:"> This field indicates whether mutual
            authentication is mandatory or not. </t>

            <t hangText="   Token-Server:"> This field stores the information about
            server that validates the token submitted as credentials. </t>

            <t hangText="   Certificate-Server:"> This field stores the information
            about server that validates certificates submitted as credentials. </t>

            <t hangText="   Single Sign-on-Server:"> This field stores the information
            about server that validates user credentials. </t>
          </list></t>
      </section>
    </section>

    <section anchor="section:Policy-endpoint-group"
             title="Information Model for Policy Endpoint Groups">
      <t>The Policy Endpoint Group is a 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. </t>

      <t>There are multiple managed objects that constitute a Policy Endpoint
      Group. This section lists these objects and relationship among these
      objects.</t>
      <figure anchor="figure:endpoint-group-diagram" title="Endpoint Group Diagram">
      <artwork>
                       +-------------------+
                       |  Endpoint Group   |
                       +---------+---------+ 
                                 ^
                                 |
            +------------+-------+-----+---------------+
     1..n   |      1..n  |     1..n    |        1..n   |
      +-----+----+  +----+---+  +------+------+  +-----+----+
      |   User   |  | Device |  | Application |  | Location |
      +----------+  +--------+  +-------------+  +----------+
      </artwork>
      </figure>

      <section anchor="section:Tag-source" title="Tag-Source">
        <t>This object represents information source for tag. The
        tag in a group must be mapped to its corresponding contents to
        enforce a Security Policy.</t>

        <t>Tag-Source object SHALL have the following information: <list
            style="hanging" hangIndent="10">
            <t hangText="   Name:"> This field identifies name of this object. </t>
            
            <t hangText="   Date:"> Date when this object was created or last modified. </t>

            <t hangText="   Tag-Type:"> This field identifies the Endpoint Group
            type. It can be a User-Group, App-Group, Device-Group or Location-Group. </t>

            <t hangText="   Tag-Source-Server:"> This field identifies information
            related to the source of the tag such as IP address and UDP/TCP
            port information. </t>

            <t hangText="   Tag-Source-Application:"> This filed identifies the protocol,
            e.g., LDAP, Active Directory, or CMDB used to communicate with a server. </t>
            
            <t hangText="   Tag-Source-Credentials:"> This field identifies the
            credential information needed to access the server. </t>
          </list></t>
      </section>

      <section anchor="section:user-group" title="User-Group">
        <t>This object represents a user group based on either tag or other
        information. </t>

        <t>The User-Group object SHALL have the following information: <list
            style="hanging" hangIndent="10">
            <t hangText="   Name:"> This field identifies the name of this object. </t>
            
            <t hangText="   Date:"> Date when this object was created or last modified. </t>

            <t hangText="   Group-Type:"> This field identifies whether the user
            group is based on User-tag, User-name or IP-address. </t>

            <t hangText="   Metadata-Server:"> This field should be a reference to
            a Metadata-Source object. </t>

            <t hangText="   Group-Member:"> This field is a list of User-tag,
            User-names or IP addresses based on Group-Type. </t>

            <t hangText="   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. </t>
          </list></t>
      </section>

      <section anchor="section:device-group" title="Device-Group">
        <t>This object represents a device group based on either tag or other
        information.</t>

        <t>The Device-Group object SHALL have the following information: <list
            style="hanging" hangIndent="10">
            <t hangText="   Name:"> This field identifies the name of this object. </t>
            
            <t hangText="   Date:"> Date when this object was created or last modified. </t>

            <t hangText="   Group-Type:"> This field identifies whether the device
            group is based on Device-tag or Device-name or IP address. </t>
            
            <t hangText="   Tag-Server:"> This field should be a reference to
            a Tag-Source object. </t>
            
            <t hangText="   Group-Member:"> This field is a list of Device-tag,
            Device-name or IP address based on Group-Type. </t>

            <t hangText="   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. </t>
          </list></t>
      </section>

      <section anchor="section:application-group" title="Application-Group">
        <t>This object represents an application group based on either tag or
        other information.</t>

        <t>The Application-Group object SHALL have the following information: <list
            style="hanging" hangIndent="10">
            <t hangText="   Name:"> This field identifies the name of this object. </t>
            
            <t hangText="   Date:"> Date when this object was created or last modified. </t>

            <t hangText="   Group-Type:"> This field identifies whether the application
            group is based on App-tag or App-name, or IP address. </t>
            
            <t hangText="   Tag-Server:"> This field should be a reference to
            a Tag-Source object. </t>
            
            <t hangText="   Group-Member:"> This field is a list of Application-tag
            Application-name or IP address and port information based on Group-Type. </t>
            
            <t hangText="   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. </t>
          </list></t>
      </section>

      <section anchor="section:location-group-object" title="Location-Group">
        <t>This object represents a location group based on either tag or
        other information.</t>

        <t>The 'Location-Group' object SHALL have the following information: <list
            style="hanging" hangIndent="10">
            <t hangText="   Name:"> This field identifies the name of this object. </t>
            
            <t hangText="   Date:"> Date when this object was created or last modified. </t>

            <t hangText="   Group-Type:"> This field identifies whether the location
            group is based on Location-tag, Location-name or IP address. </t>
            
            <t hangText="   Tag-Server:"> This field should be a reference to
            a Tag-Source object. </t>
            
            <t hangText="   Group-Member:"> This field is a list of Location-tag,
            Location-name or IP addresses based on Group-Type. </t>
            
            <t hangText="   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. </t>
          </list></t>
      </section>
    </section>

    <section anchor="section:threat-prevention" title="Information Model for Threat Prevention">
      <t>The threat prevention plays an important part in the overall security
      posture by reducing the attack surfaces. This information could come in
      the form of threat feeds such as Botnet and GeoIP feeds usually from a third
      party or external service. </t>

      <t>There are multiple managed objects that constitute this category.
      This section lists these objects and relationship among these
      objects.</t>
      <figure anchor="figure:threat-prevention-diagram" title="Threat Prevention Diagram">
      <artwork>
                           +---------------------+                      
                           |  Threat Prevention  |                      
                           +----------+----------+ 
                                      ^
                                      |                               
                +---------------------+----------------------+          
    1..n        |          1..n       |          1..n        |          
     +----------+---------+ +---------+---------+ +----------+---------+
     |     Threat feed    | |    Custom list    | | Malware scan group |
     +--------------------+ +-------------------+ +--------------------+
      </artwork>
  </figure>

      <section anchor="section:threat-feed" title="Threat-Feed">
        <t>This object represents a threat feed such as Botnet servers and
        GeoIP.</t>

        <t>The Threat-Feed object SHALL have the following information: <list
            style="hanging" hangIndent="10">
            <t hangText="   Name:"> This field identifies the name of this object. </t>
            
            <t hangText="   Date:"> Date when this object was created or last modified. </t>

            <t hangText="   Feed-Type:"> This field identifies whether a feed type
            is IP address-based or URL-based. </t>

            <t hangText="   Feed-Server:"> This field identifies the information
            about the feed provider, it may be an external service or local
            server. </t>

            <t hangText="   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. </t>
          </list></t>
      </section>

      <section anchor="section:custom-list" title="Custom-List">
        <t>This object represents a custom list created for the purpose of
        defining exception to threat feeds. An organization may want to
        allow a certain exception to threat feeds obtained from a third party</t>

        <t>The Custom-List object SHALL have the following information: <list
            style="hanging" hangIndent="10">
            <t hangText="   Name:"> This field identifies the name of this object. </t>
            
            <t hangText="   Date:"> Date when this object was created or last modified. </t>

            <t hangText="   List-Type:"> This field identifies whether the list
            type is IP address-based or URL-based. </t>

            <t hangText="   List-Property:"> This field identifies the attributes
            of the list property, e.g., Blacklist or Whitelist. </t>

            <t hangText="   List-Content:"> This field contains contents such as
            IP addresses or URL names. </t>
          </list></t>
      </section>

      <section anchor="section:malware-scan-group" title="Malware-Scan-Group">
        <t>This object represents information needed to detect malware. This
        information could come from a local server or uploaded periodically
        from a third party. </t>

        <t>The Malware-Scan-Group object SHALL have the following information: <list
        style="hanging" hangIndent="10">
            
            <t hangText="   Name:"> This field identifies the name of this object. </t>
            
            <t hangText="   Date:"> Date when this object was created or last modified. </t>
            
            <t hangText="   Signature-Server:"> This field contains information about
            the server from where signatures can be downloaded periodically as
            updates become available. </t>

            <t hangText="   File-Types:"> This field contains a list of file types
            needed to be scanned for the virus. </t>

            <t hangText="   Malware-Signatures:"> This field contains a list of malware
            signatures or hash values. </t>
          </list></t>
      </section>

    </section>

    <section anchor="section:telemetry-collection"
             title="Information Model for Telemetry Data">
      <t>Telemetry provides System Admin with the visibility of the network activities which can be
      tapped for further security analytics, e.g., detecting potential
      vulnerabilities, malicious activities, etc. </t>

      <section anchor="section:telemetry-data" title="Telemetry-Data">
        <t>This object contains information collected for telemetry.</t>

        <t>The Telemetry-Data object SHALL have the following information: <list
            style="hanging" hangIndent="10">
            <t hangText="   Name:"> This field identifies the name of this object. </t>
            
            <t hangText="   Date:"> Date when this object was created or last modified. </t>

            <t hangText="   Log-Data:"> This field identifies whether Log data need to
            be collected. </t>

            <t hangText="   Syslog-Data"> This field  identifies whether Syslog data
            need to be collected. </t>
        
            <t hangText="   SNMP-Data:"> This field  identifies whether SNMP traps and
            alarm data need to be collected. </t>

            <t hangText="   sFlow-Record:"> This field identifies whether sFlow records
            need to be collected. </t>

            <t hangText="   NetFlow-Record:"> This field identifies whether NetFlow
            record need to be collected. </t>

            <t hangText="   NSF-Stats:"> This field identifies whether statistics
            need to be collected from an NSF. </t>
          </list></t>
      </section>

      <section anchor="section:telemetry-source" title="Telemetry-Source">
        <t>This object contains information related to telemetry source. The source
        would be an NSF in the network. </t>

        <t>The Telemetry-Source object SHALL have the following information: <list
            style="hanging" hangIndent="10">
            <t hangText="   Name:"> This field identifies the name of this object. </t>
            
            <t hangText="   Date:"> Date when this object was created or last modified. </t>

            <t hangText="   Source-Type:"> This field contains the type of the NSF telemetry
            source: "NETWORK-NSF", "FIREWALL-NSF", "IDS-NSF", "IPS-NSF",
            "PROXY-NSF or "OTHER-NSF". </t>

            <t hangText="   NSF-Source:"> This field contains information
            such as IP address and protocol (UDP or TCP) port number of the NSF
            providing telemetry data. </t>

            <t hangText="   NSF-Credentials:"> This field contains
            a username and a password used to authenticate the NSF. </t>

            <t hangText="   Collection-Interval:">This field contains time in
            milliseconds between each data collection. For example, a value of
            5,000 means data is streamed to collector every 5 seconds. Value of 0
            means data streaming is event-based. </t>

            <t hangText="   Collection-Method:">This field contains a method of
            collection whether it is PUSH-based or PULL-based. </t>

            <t hangText="   Heartbeat-Interval:">This field contains time in
            seconds when the source must send telemetry heartbeat. </t>

            <t hangText="   QoS-Marking:">This field contains a DSCP value source
            marked on its generated telemetry packets. </t>
          </list></t>
      </section>

      <section anchor="section:telemetry-destination" title="Telemetry-Destination">
        <t>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.</t>

        <t>The Telemetry-Destination object SHALL have the following information: <list
        style="hanging" hangIndent="10">
            <t hangText="   Name:"> This field identifies the name of this object. </t>
            
            <t hangText="   Date:"> Date when this object was created or last modified. </t>

            <t hangText="   Collector-Source:"> This field contains the
            information such as IP address and protocol (UDP or TCP) port number
            for the collector's destination. </t>

            <t hangText="   Collector-Credentials:"> This field contains a 
            username and a password provided by the collector. </t>

            <t hangText="   Data-Encoding:"> This field contains the telemetry data
            encoding, which could in the form of a schema. </t>

            <t hangText="   Data-Transport:"> This field contains streaming
            telemetry data protocols: whether it is gRPC, protocol buffer over
            UDP, etc. </t>
          </list></t>
      </section>
    </section>
    <section anchor="section:role-based-access-control" title="Role-Based Acess Control (RBAC)">
    	<t>Role-Based Access Control (RBAC) provides a powerful and centralized control within
    		a network. It is a policy neutral access control mechanism defined around roles 
    		and privileges. The components of RBAC, such as role-permissions, user-role and 
    		role-role relationships, make it simple to perform user assignments. </t>
     <figure anchor="figure:rbac-diagram" title="RBAC Diagram"> 
     <artwork>
     +--------------+                                                   
     |              |                                                   
     |    User 1    + (has many)                                                  
     |              |\                                                       
     +--------------+ \     +---------------+            +-------------+
             .         \    |               | (has many) |             |
             .          --->+ List of roles +----------->+ Permissions |
     +--------------+  /    |               |            |             |
     |              | /     +---------------+            +-------------+
     |    User n    +/                                                   
     |              | (has many)
     +--------------+                                                   
     </artwork>
 	</figure>
    	<t>As shown in <xref target="figure:rbac-diagram" />, a role represents a collection of permissions (e.g., accessing
    	 a file server or other particular resources). A role may be assigned to one or multiple 
    	 users. Both roles and permissions can be organized in a hirarchy. A role may consists
    	 of other roles and permissions. 
    	</t>
    	<t>Following are the steps required to build RBAC. <list style="hanging" hangIndent="10">
            <t hangText="  1."> Defining roles and permissions. </t>
            
            <t hangText="  2."> Establishing relations among roles and permissions. </t>

            <t hangText="  3."> Defining users. </t>

            <t hangText="  4."> Associating rules with roles and permissions. </t>

            <t hangText="  5."> assigning roles to users. </t>
        </list>
        </t>
    </section>

   
    <section anchor="section:security-considerations" title="Security Considerations">
        <t>An information model provides a mechanism to protect Consumer-Facing Interface between
        System Admin (i.e., I2NSF User) and Security Controller. One of the specified mechanism 
        must be used to protect an Enterprise network, data and all resources from external attacks. 
        This information model mandates that the interface must have proper authentication and authorization
        with Role-Based Access Controls to address the multi-tenancy requirement. The
        document does not mandate that a particular mechanism should be used because a different
        organization may have different needs based on their deployment.</t>
    </section>

    <section anchor="section:iana" title="IANA Considerations">
      <t>This document requires no IANA actions. RFC Editor: Please remove
      this section before publication.</t>
    </section>

    <section anchor="section:acks" title="Acknowledgments">
        <t>
        This work was supported by Institute for Information &amp; communications
        Technology Promotion (IITP) grant funded by the Korea government (MSIT)
        (No. R-20160222-002755, Cloud based Security Intelligence Technology
        Development for the Customized Security Service Provisioning).
        </t>
    </section>

    <section anchor="section:contributors" title="Contributors">
	<t> 
	This document is the work of I2NSF working group, greatly benefiting
        from inputs and suggestions by Kunal Modasiya, Prakash T. Sehsadri and
        Srinivas Nimmagadda from Juniper Networks. The authors sincerely
        appreciate their contributions.
	</t>

	<t> 
	The following are contributing authors of this document, who are
        considered co-authors:
	</t>   

	<t>
        <list style="symbols">
            <t>
            Eunsoo Kim (Sungkyunkwan University)
            </t>
            <t>
            Seungjin Lee (Sungkyunkwan University)
            </t>
            <t>
            Hyoungshick Kim (Sungkyunkwan University)
            </t>
        </list>
        </t>
     </section>
  </middle>

  <back>
    <references title="Informative References">
      <?rfc include="reference.RFC.3444"?>
      
      <?rfc include="reference.I-D.ietf-i2nsf-terminology"?>

      <?rfc include="reference.RFC.8192"?>

      <?rfc include="reference.RFC.8329"?>

      <?rfc include="reference.I-D.ietf-i2nsf-client-facing-interface-req"?>

      <?rfc include="reference.I-D.ietf-i2nsf-capability"?>
    </references>

    <section title="Changes from draft-kumar-i2nsf-client-facing-interface-im-06">
       <t>
       The following changes have been made from draft-kumar-i2nsf-client-facing-interface-im-06:
         <list style="symbols">
           <t>
           In <xref target="section:introduction" />, <xref target="figure:high-level-abstraction" /> is added to show 
           a diagram for a high-level abstraction of Consumer-Facing Interface.
           </t>
        </list>
      </t>
    </section>

  </back>

</rfc>
