[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Interface to Network Security Functions (I2NSF)                   L. Xia
Internet-Draft                                                    Q. Lin
Intended status: Standards Track                                  Huawei
Expires: January 3, 2018                                    July 2, 2017


   Policy Object for Interface to Network Security Functions (I2NSF)
               draft-xia-i2nsf-security-policy-object-01

Abstract

   This document describes policy object used in the Interface to
   Network Security Functions (I2NSF) policy rules to provide re-
   usability and defines essential attributes for each policy object.

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 3, 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
   (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.





Xia & Lin                Expires January 3, 2018                [Page 1]


Internet-Draft           Policy Object for I2NSF               July 2017


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   4
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Policy Object . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Address Object  . . . . . . . . . . . . . . . . . . . . .   5
       4.1.1.  The addressName Attribute . . . . . . . . . . . . . .   5
       4.1.2.  The addressRange Attribute  . . . . . . . . . . . . .   5
     4.2.  Address Group Object  . . . . . . . . . . . . . . . . . .   6
       4.2.1.  The addressGroupName Attribute  . . . . . . . . . . .   6
       4.2.2.  The addressReference Attribute  . . . . . . . . . . .   6
       4.2.3.  The addressRange Attribute  . . . . . . . . . . . . .   6
     4.3.  Service Object  . . . . . . . . . . . . . . . . . . . . .   7
       4.3.1.  The serviceName Attribute . . . . . . . . . . . . . .   7
       4.3.2.  The serviceList Attribute . . . . . . . . . . . . . .   7
         4.3.2.1.  The serviceProtocol Attribute . . . . . . . . . .   7
         4.3.2.2.  The serviceProtocolNumber Attribute . . . . . . .   8
         4.3.2.3.  The serviceICMPType Attribute . . . . . . . . . .   8
         4.3.2.4.  The serviceICMPCode Attribute . . . . . . . . . .   8
         4.3.2.5.  The serviceSourcePort Attribute . . . . . . . . .   8
         4.3.2.6.  The serviceDestinationPort Attribute  . . . . . .   8
     4.4.  Service Group Object  . . . . . . . . . . . . . . . . . .   8
       4.4.1.  The serviceGroupName Attribute  . . . . . . . . . . .   9
       4.4.2.  The serviceReference Attribute  . . . . . . . . . . .   9
     4.5.  Application Object  . . . . . . . . . . . . . . . . . . .   9
       4.5.1.  The applicationName Attribute . . . . . . . . . . . .   9
       4.5.2.  The applicationCategory Attribute . . . . . . . . . .   9
       4.5.3.  The applicationSubCategory Attribute  . . . . . . . .   9
       4.5.4.  The applicationTransmissionModel Attribute  . . . . .  10
       4.5.5.  The applicationVulnerability Attribute  . . . . . . .  10
       4.5.6.  The applicationRiskLevel Attribute  . . . . . . . . .  10
     4.6.  Application Group Object  . . . . . . . . . . . . . . . .  10
       4.6.1.  The applicationGroupName Attribute  . . . . . . . . .  10
       4.6.2.  The applicationReference Attribute  . . . . . . . . .  10
     4.7.  Schedule Object . . . . . . . . . . . . . . . . . . . . .  10
       4.7.1.  The scheduleName Attribute  . . . . . . . . . . . . .  11
       4.7.2.  The scheduleList Attribute  . . . . . . . . . . . . .  11
         4.7.2.1.  The scheduleType Attribute  . . . . . . . . . . .  11
         4.7.2.2.  The scheduleStartTime Attribute . . . . . . . . .  11
         4.7.2.3.  The scheduleEndTime Attribute . . . . . . . . . .  11
         4.7.2.4.  The scheduleWeekDay Attribute . . . . . . . . . .  11
     4.8.  User Object . . . . . . . . . . . . . . . . . . . . . . .  11
       4.8.1.  The userName Attribute  . . . . . . . . . . . . . . .  12
       4.8.2.  The userParentGroup Attribute . . . . . . . . . . . .  12
       4.8.3.  The userSecurityGroup Attribute . . . . . . . . . . .  12
       4.8.4.  The userDomain Attribute  . . . . . . . . . . . . . .  12
       4.8.5.  The userPassword Attribute  . . . . . . . . . . . . .  13



Xia & Lin                Expires January 3, 2018                [Page 2]


Internet-Draft           Policy Object for I2NSF               July 2017


       4.8.6.  The userExpirationTime Attribute  . . . . . . . . . .  13
     4.9.  User Group Object . . . . . . . . . . . . . . . . . . . .  13
       4.9.1.  The userGroupName Attribute . . . . . . . . . . . . .  13
       4.9.2.  The userGroupParentGroup Attribute  . . . . . . . . .  13
       4.9.3.  The userGroupDomain Attribute . . . . . . . . . . . .  13
       4.9.4.  The userGroupReference Attribute  . . . . . . . . . .  13
     4.10. Security Group Object . . . . . . . . . . . . . . . . . .  13
       4.10.1.  The securityGroupName Attribute  . . . . . . . . . .  14
       4.10.2.  The securityGroupParentGroup Attribute . . . . . . .  14
       4.10.3.  The securityGroupDomain Attribute  . . . . . . . . .  14
       4.10.4.  The securityGroupType Attribute  . . . . . . . . . .  14
       4.10.5.  The securityGroupReference Attribute . . . . . . . .  14
       4.10.6.  The securityGroupFilters Attribute . . . . . . . . .  14
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  15
   Appendix A.  Application Attributes . . . . . . . . . . . . . . .  15
     A.1.  Category and Subcategory  . . . . . . . . . . . . . . . .  15
     A.2.  Data Transmission Model . . . . . . . . . . . . . . . . .  16
     A.3.  Vulnerability . . . . . . . . . . . . . . . . . . . . . .  17
   Appendix B.  Example of Application Scenario for Policy Object  .  17
     B.1.  Security Policy Control for Marketing Departments . . . .  20
     B.2.  Security Policy Control for R&D Departments . . . . . . .  20
     B.3.  Security Policy Control for Server Access of Internet
           Users . . . . . . . . . . . . . . . . . . . . . . . . . .  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21

1.  Introduction

   I2NSF policy consists of policy rules that are used to provision NSF
   instances.  The I2NSF policy rule is defined by using "Event-
   Condition-Action" (ECA) model described in I2NSF framework draft
   [I-D.ietf-i2nsf-framework].  In the ECA model, a condition is used to
   determine whether or not the predefined actions should be executed.
   A condition usually consists of several attributes.  Information
   Model of NSFs Capabilities [I-D.ietf-i2nsf-capability] describes
   attributes of different condition subclasses.  When configuring
   policy rules by attributes, it is common to see that the same
   attribute or the same set of several attributes are configured for
   several times or more.  And modifications of the policy rules are
   also very tedious and time-consuming.

   To facilitate the provisioning of NSF instances, this document
   describes a set of policy objects which are reusable and can be
   referenced by variable I2NSF policy rules.  A policy object consists



Xia & Lin                Expires January 3, 2018                [Page 3]


Internet-Draft           Policy Object for I2NSF               July 2017


   of a name attribute that identifies itself and one or several
   attributes that are typically used together to represent a certain
   condition.  For example, protocol type and port number are usually
   used together to represent a certain service.  Each policy object is
   predefined and named in order to be used in I2NSF policy rules.  By
   defining policy objects, the creation and maintenance of policy rules
   are greatly simplified.

   o  A policy object can be referenced in different policy rules as
      required to provide re-usability.  And a policy rule can reference
      several policy objects.

   o  The modification of a policy object will be propagated to the
      I2NSF policy rules that reference this object.  No modification
      should be made to the related policy rules.

   In this document, a set of policy objects are described, and for each
   policy object, several essential attributes are defined.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

3.  Terminology

   This document uses the terminology described in Interface to Network
   Security Functions (I2NSF) Terminology [I-D.ietf-i2nsf-terminology].

4.  Policy Object

   IP addresses, port numbers, protocol types, services, applications,
   user accounts are commonly used attributes to determine whether a
   certain condition occurs.  In real-world deployment, these attributes
   are often configured for many times.  The definition of policy
   objects could help to minimize the configuration effort and provide
   simplicity.

   Figure 1 shows the policy objects defined in this document and their
   relationships.










Xia & Lin                Expires January 3, 2018                [Page 4]


Internet-Draft           Policy Object for I2NSF               July 2017


    +-----------------------------------------------------------------+
    |                       Policy Object                             |
    +-----------------------------------------------------------------+
        |          |            |           |         |           |
        |          |            |           |         |           |
    +-------+  +-------+  +-----------+  +-----+  +--------+      |
    |Address|  |Service|  |Application|  |User |  |Security|      |
    |Group  |  |Group  |  |Group      |  |Group|  |Group   |      |
    +-------+  +-------+  +-----------+  +-----+  +--------+      |
        |          |            |           |         |           |
        |          |            |           +---------+           |
        |          |            |                |                |
    +-------+  +-------+  +-----------+      +------+        +--------+
    |Address|  |Service|  |Application|      |User  |        |Schedule|
    |Object |  |Object |  |Object     |      |Object|        |Object  |
    +-------+  +-------+  +-----------+      +------+        +--------+

                   Figure 1: The Policy Objects Overview

4.1.  Address Object

   A of IPv4/IPv6 addresses or MAC addresses can be defined as an
   address object, which may belongs to an address group object.  An
   address object consists of the following attributes:

4.1.1.  The addressName Attribute

   This attribute defines a unique name for the address object.

4.1.2.  The addressRange Attribute

   This attribute defines a set of IPv4/IPv6 addresses or MAC addresses,
   or a range of contiguous IPv4/IPv6 addresses.

   An IPv4 address range can be defined by one of the following
   representations:

   o  IPv4 address with wildcard mask, e.g., 10.10.1.2\0.0.0.255.

   o  IPv4 address with subnet mask (subnet mask address or length of
      the subnet mask), e.g., 10.10.1.2/255.255.255.0 or 10.10.1.2/32.

   o  Start address and end address of the IPv4 address range, e.g.,
      10.10.1.2-10.10.1.254.

   An IPv6 address range can be defined by one of the following
   representations:




Xia & Lin                Expires January 3, 2018                [Page 5]


Internet-Draft           Policy Object for I2NSF               July 2017


   o  IPv6 address with length of the prefix, e.g., a234::120/120.

   o  Start address and end address of the IPv6 address range, e.g.,
      a231::a237-b231::b237.

4.2.  Address Group Object

   An address group object is comprised of several address items that
   require the same policy enforcement.  An address item can be an IPv4/
   IPv6 address, or a MAC address, or a range of contiguous IPv4/IPv6
   addresses, or existing address object, or existing address group
   object.  An address group object consists of the following
   attributes:

4.2.1.  The addressGroupName Attribute

   This attribute defines a unique name for the address group object.

4.2.2.  The addressReference Attribute

   This attribute refers to the existing address objects or existing
   address group objects identified by their unique names.

4.2.3.  The addressRange Attribute

   This attribute is the same as the addressRange attribute of address
   object.  It can define a set of IPv4/IPv6 addresses or MAC addresses,
   or a range of contiguous IPv4/IPv6 addresses.

   An IPv4 address range can be defined by one of the following
   representations:

   o  IPv4 address with wildcard mask, e.g., 10.10.1.2\0.0.0.255.

   o  IPv4 address with subnet mask (subnet mask address or length of
      the subnet mask), e.g., 10.10.1.2/255.255.255.0 or 10.10.1.2/32.

   o  Start address and end address of the IPv4 address range, e.g.,
      10.10.1.2-10.10.1.254.

   An IPv6 address range can be defined by one of the following
   representations:

   o  IPv6 address with length of the prefix, e.g., a234::120/120.

   o  Start address and end address of the IPv6 address range, e.g.,
      a231::a237-b231::b237.




Xia & Lin                Expires January 3, 2018                [Page 6]


Internet-Draft           Policy Object for I2NSF               July 2017


4.3.  Service Object

   A service object can be a single service based on IP, or ICMP, or
   UDP, or TCP, or SCTP and it can also contain a set of services.  To
   identify services based on different protocols, different attributes
   should be specified (see Section 4.3.2 The serviceList Attribute).

   o  IP based service is recognized by the value of the protocol field
      in IP packet header.

   o  ICMP or ICMPv6 based service is recognized by two header fields in
      the ICMP or ICMPv6 packets: type field and code field.

   o  UDP, TCP, or SCTP based service is recognized by port number.  The
      source port number and destination port number are used to
      identify the sending and receiving service respectively.

   A set of well-known services should be predefined by NSFs as service
   objects to support direct reference.  A service object consists of
   the following attributes:

4.3.1.  The serviceName Attribute

   This attribute defines a unique name for the service object.

4.3.2.  The serviceList Attribute

   This attribute defined a set of services.  Each service can be
   defined by a subset of the following sub-attributes, according to the
   protocol on which the service is based.

   o  For IP based service, the serviceProtocolNumber attribute should
      be specified.

   o  For ICMP or ICMPv6 based service, the serviceICMPType attribute
      and serviceICMPCode attribute should be specified.

   o  For UDP, TCP, or SCTP based service, the serviceSourcePort
      attribute and serviceDestinationPort attribute should be
      specified.

4.3.2.1.  The serviceProtocol Attribute

   This attribute defines the protocol type on which the service is
   based, IP, ICMP, ICMPv6, TCP, UDP, or SCTP.






Xia & Lin                Expires January 3, 2018                [Page 7]


Internet-Draft           Policy Object for I2NSF               July 2017


4.3.2.2.  The serviceProtocolNumber Attribute

   This attribute defines the protocol number for IP based service.  The
   protocol number is the value of protocol field in IP packet header
   which identifies the corresponding upper layer protocol.  For
   example, to define a service object for IPsec Encapsulating Security
   Payload, this attribute should be set to 50.

4.3.2.3.  The serviceICMPType Attribute

   This attribute defines the ICMP/ICMPv6 type number for ICMP/ICMPv6
   based service.  This attribute shall be used together with
   serviceICMPCode attribute.  For example, to define a service object
   for IPv4 ping request, this attribute should be set to 8 and
   serviceICMPCode attribute should be set to 0.

4.3.2.4.  The serviceICMPCode Attribute

   This attribute defines the ICMP/ICMPv6 message code for ICMP/ICMPv6
   based service.  This attribute shall be used together with
   serviceICMPType attribute.  For example, to define a service object
   for IPv6 ping request, this attribute should be set to 0 and
   serviceICMPCode should be set to 128.

4.3.2.5.  The serviceSourcePort Attribute

   This attribute defines the source port number for service based on
   TCP, UDP or SCTP.  The value could be a single port number which
   identifies a single service, or a range of port numbers which
   identify a family of services or several services in consecutive port
   numbers.  For example, to define a service object using port number
   greater or equal to 1024 and enforce security policy on the traffic
   that this object sends out, this attribute should be set as a port
   range, 1024-65535.

4.3.2.6.  The serviceDestinationPort Attribute

   This attribute defines the destination port number for service based
   on TCP, UDP or SCTP.  The value could be a single port number or a
   range of port numbers.  For example, to define a service object for
   HTTP and enforce security policy on the traffic that communicates
   with this service object, this attribute should be set to 80.

4.4.  Service Group Object

   A service group object is a collection of service objects that
   require the same policy enforcement.  It consists of the following
   attributes:



Xia & Lin                Expires January 3, 2018                [Page 8]


Internet-Draft           Policy Object for I2NSF               July 2017


4.4.1.  The serviceGroupName Attribute

   This attribute defines a unique name for the service group object.

4.4.2.  The serviceReference Attribute

   This attribute refers to the existing service objects or service
   group objects identified by their unique names.

4.5.  Application Object

   Due to the diversity and large amount of applications, it is not able
   to identify a certain application based on protocol type and port
   number.  For example, there are many web applications with different
   risk levels run on ports 80 and 443 using HTTP and HTTPS, such as web
   gaming application and web chat application.  Protocol type and port
   number could not distinguish applications using the same application
   protocol.  In this document, category, subcategory, data transmission
   model, vulnerability, and risk level are used to describe an
   application.  A set of well-known application objects should be
   predefined in NSFs to support direct reference.  For a newly created
   application object, the rules for NSFs to identify this application
   in the traffic should be configured.  In this document, the
   configuration of these rules is out of scope.  An application object
   consists of the following attributes:

4.5.1.  The applicationName Attribute

   This attribute defines a unique name for the application object.

4.5.2.  The applicationCategory Attribute

   This attribute defines the category for the application.  The value
   of this attribute is selected from a predefined set of categories,
   e.g., general category, network category.  Values of this attribute
   are defined in Appendix A.1.  Each category is broken down into
   several subcategories.

4.5.3.  The applicationSubCategory Attribute

   This attribute defines the subcategory for the application.  The
   value of this attribute is selected from the predefined subcategories
   of a category.  For example, the entertainment category has seven
   subcategories, and Facebook application belongs to social networking
   subcategory.  (See Appendix A.1 for details about subcategory and
   examples of applications belong to each subcategory.)





Xia & Lin                Expires January 3, 2018                [Page 9]


Internet-Draft           Policy Object for I2NSF               July 2017


4.5.4.  The applicationTransmissionModel Attribute

   This attribute defines the data transmission model of the
   application.  Four types of data transmission model are defined in
   this document: client/server, browser-based, network protocol, peer-
   to-peer.  (See Appendix A.2 for more details.)

4.5.5.  The applicationVulnerability Attribute

   This attribute describes a set of possible threats for the
   application.  The values of this attribute are selected from a
   predefined set of vulnerabilities, e.g., exploitable, bandwidth
   consuming.  (See Appendix A.3 for more details.)

4.5.6.  The applicationRiskLevel Attribute

   This attribute defines a risk level for the application.  The value
   of this attribute is selected from a predefined number of risk
   levels, e.g., 5 risk levels.  The risk level is determined by the
   vulnerabilities of this application object.

4.6.  Application Group Object

   An application group object is a collection of application objects
   that will be processed according to the same security policy.  It
   consists of the following attributes:

4.6.1.  The applicationGroupName Attribute

   This attribute defines a unique name for the application group
   object.

4.6.2.  The applicationReference Attribute

   This attribute refers to the existing application objects or
   application group objects identified by their unique names.

4.7.  Schedule Object

   A schedule object is a set of time ranges.  There are two kinds of
   time ranges: periodic time range and absolute time range.  A periodic
   time range occurs every week.  An absolute time range occurs only
   once.  A schedule object consists of the following attributes:








Xia & Lin                Expires January 3, 2018               [Page 10]


Internet-Draft           Policy Object for I2NSF               July 2017


4.7.1.  The scheduleName Attribute

   This attribute defines a unique name for the schedule object.

4.7.2.  The scheduleList Attribute

   This attribute defines a set of time ranges.  A time range can be
   defined by the following sub-attributes.

   o  For a periodic time range, the start and end time in a day, and
      the days in a week that it takes effect, should be specified.

   o  For an absolute time range, the start time and date, and the end
      time and date, should be specified.

4.7.2.1.  The scheduleType Attribute

   This attribute defines the type of a time range, periodic, absolute.

4.7.2.2.  The scheduleStartTime Attribute

   For a periodic time range, this attribute defines the start time in a
   week day, such as 9:00 am.  For an absolute time range, this
   attribute defines the start time and start date, such as 00:00 am
   2017-07-03.

4.7.2.3.  The scheduleEndTime Attribute

   For a periodic time range, this attribute defines the end time in a
   week day, such as 18:00 pm.  For an absolute time range, this
   attribute defines the end time and end date, such as 23:59 pm
   2017-07-03.

4.7.2.4.  The scheduleWeekDay Attribute

   This attribute defines the days in a week that the periodic time
   range takes effect.  For example, to define working hours in a week,
   the scheduleStartTime can be set to 9:00 am, the scheduleEndTime can
   be set to 18:00 pm, and this attribute should contain fives days,
   from Monday to Friday.

4.8.  User Object

   A user object identifies a person who may access network resources.
   It is the basis of implementing user-based policy control.  The user
   objects may be created locally on the NSFs, or be imported from third
   parties, such as authentication servers.  User objects that require
   the same policy enforcement are grouped as user group objects or



Xia & Lin                Expires January 3, 2018               [Page 11]


Internet-Draft           Policy Object for I2NSF               July 2017


   security group objects.  The user group objects are organized as a
   hierarchical structure, See Figure 2.  A security group object
   consists of user objects from different user group objects that
   require the same policy enforcement.

                       +---------------------------+
                       |        UserGroup_3        |
                       +---------------------------+
                         |                       |
                         |                       |
                 +--------------+         +--------------+
                 | UserGroup_1  |         | UserGroup_2  |
                 +--------------+         +--------------+
                   |          |             |          |
                   |          |             |          |
              +--------+  +--------+   +--------+  +--------+
              | User_1 |  | User_2 |   | User_a |  | User_b |
              +--------+  +--------+   +--------+  +--------+

              Figure 2: Hierarchical Structure of User Group

   A user object consists of the following attributes:

4.8.1.  The userName Attribute

   This attribute refers to the user name that used for user
   authentication.

4.8.2.  The userParentGroup Attribute

   This attribute refers to the existing parent user group object to
   which this user object belongs.  The parent user group object is
   identified by its unique name.  A user object can only belong to one
   user group object.

4.8.3.  The userSecurityGroup Attribute

   This attribute refers to the existing security group object to which
   this user object belongs.  The security user group object is
   identified by its unique name.  A user object can belong to several
   security group objects.

4.8.4.  The userDomain Attribute

   This attribute refers to the authentication domain to which this user
   object belongs.





Xia & Lin                Expires January 3, 2018               [Page 12]


Internet-Draft           Policy Object for I2NSF               July 2017


4.8.5.  The userPassword Attribute

   If user is authenticated locally on the NSF, this attribute is
   mandatory.  It defines the password corresponding to the user name.

4.8.6.  The userExpirationTime Attribute

   This attribute defines when will this user object expire.

4.9.  User Group Object

   A user object group is a collection of user objects that require the
   same policy enforcement and it usually corresponds to a physical
   entity such as a department.  The user group objects are organized as
   a hierarchical structure.  A user group object may belong to another
   user group object.  The user group objects may be created locally on
   the NSFs, or be imported from third parties, such as authentication
   servers.  It consists of the following attributes:

4.9.1.  The userGroupName Attribute

   This attribute defines a unique name for the user group object.

4.9.2.  The userGroupParentGroup Attribute

   This attribute refers to the existing parent user group object to
   which this user group object belongs.  The parent user group object
   is identified by its unique name.  A user group object can only
   belong to one parent user group object.

4.9.3.  The userGroupDomain Attribute

   This attribute refers to the authentication domain to which this user
   group object belongs.

4.9.4.  The userGroupReference Attribute

   This attribute refers to the existing user objects or user group
   objects which belong to this user group object.

4.10.  Security Group Object

   A security group object consists of user objects from different user
   group objects that require the same policy enforcement.  The security
   group objects may be created locally on the NSFs, or be imported from
   third parties, such as authentication servers.  This attribute
   consists of the following attributes:




Xia & Lin                Expires January 3, 2018               [Page 13]


Internet-Draft           Policy Object for I2NSF               July 2017


4.10.1.  The securityGroupName Attribute

   This attribute defines a unique name for the security group object.

4.10.2.  The securityGroupParentGroup Attribute

   This attribute refers to the existing parent security group objects
   to which this security group object belongs.  The parent security
   group objects are identified by their unique names.

4.10.3.  The securityGroupDomain Attribute

   This attribute refers to the authentication domain to which this
   security group object belongs.

4.10.4.  The securityGroupType Attribute

   This attribute defines the type of the security group object.  There
   are two types: static and dynamic.  For static security group, the
   member objects are fixed and added as required.  For dynamic security
   group, the member objects are dynamically generated by setting
   filtering rules.

4.10.5.  The securityGroupReference Attribute

   This attribute defines the member objects for static security group
   object.  It refers to the existing user objects or security group
   objects which belong to this security group object.

4.10.6.  The securityGroupFilters Attribute

   This attribute defines the filtering rules for dynamic security group
   object.

5.  Acknowledgements

6.  IANA Considerations

   This document requires no IANA actions.

7.  Security Considerations

   When the policy objects are transmitted, the integrity of these
   policy objects should be guaranteed.  NSFs should verify that the
   modifications of policy objects come from the authenticated security
   controller.  And NSF should protect the stored policy objects from
   being tampered.




Xia & Lin                Expires January 3, 2018               [Page 14]


Internet-Draft           Policy Object for I2NSF               July 2017


8.  References

8.1.  Normative References

   [I-D.ietf-i2nsf-capability]
              Xia, L., Strassner, J., Basile, C., and D. Lopez,
              "Information Model of NSFs Capabilities", 2017,
              <https://tools.ietf.org/pdf/draft-xibassnez-i2nsf-
              capability-01.pdf>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

8.2.  Informative References

   [I-D.ietf-i2nsf-framework]
              Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
              Kumar, "Framework for Interface to Network Security
              Functions", 2017, <https://tools.ietf.org/pdf/draft-ietf-
              i2nsf-framework-05.pdf>.

   [I-D.ietf-i2nsf-terminology]
              Hares, S., Strassner, J., Lopez, D., Xia, L., and H.
              Birkholz, "Interface to Network Security Functions (I2NSF)
              Terminology", 2017, <https://tools.ietf.org/pdf/draft-
              ietf-i2nsf-terminology-03.pdf>.

Appendix A.  Application Attributes

   An application object is described by five items, category,
   subcategory, data transmission model, vulnerability and risk level.
   This appendix illustrates the possible values of applicationCategory
   attribute, applicationSubCategory attribute,
   applicationTransmissionModel attribute and applicationVulnerability
   attribute.

A.1.  Category and Subcategory

   This section lists the possible values for applicationCategory
   attribute and applicationSubCategory attribute.









Xia & Lin                Expires January 3, 2018               [Page 15]


Internet-Draft           Policy Object for I2NSF               July 2017


 +-------------------+------------------------+------------------------+
 | Category          | Subcategory            | Example                |
 +-------------------+------------------------+------------------------+
 | General           | General_TCP            | TCP-based applications |
 |                   | General_UDP            | UDP-based applications |
 |                   | Other                  | Error_Packets          |
 +-------------------+------------------------+------------------------+
 | Network           | IP_Protocol            | ICMP, IGMP, OSPF       |
 |                   | Encrypted_Tunnel       | GRE, L2TP, IKEv2       |
 |                   | Infrastructure         | FTP, HTTP, DNS         |
 |                   | Proxy                  | HTTP_Proxy             |
 |                   | Network_Admin          | Syslog                 |
 +-------------------+------------------------+------------------------+
 | General_Internet  | Search_Engine          | www.google.com         |
 |                   | Web_Content_Aggregate  | FeedReader             |
 |                   | Utility                | Google Earth           |
 |                   | Web_Desktop            | Zimbra Desktop         |
 |                   | Browser_Plugin         | Adobe                  |
 |                   | File_Sharing           | XDCC                   |
 |                   | FileShare_P2P          | BT, Thunder            |
 |                   | Network_Storage        | DBank                  |
 |                   | App_Download           | AndroidMarket          |
 |                   | Software_Update        | WindowsUpdate          |
 |                   | Web_Browsing           | OperaMobile            |
 +-------------------+------------------------+------------------------+
 | Entertainment     | Social_Networking      | Facebook, Twitter      |
 |                   | Instant_Messaging      | QQ, MSN                |
 |                   | Media_Sharing          | RayV                   |
 |                   | Peer_Casting           | QQLive                 |
 |                   | Web_Video              | YouKu, YouTube         |
 |                   | Game                   | QQGame                 |
 |                   | VoIP                   | Skype                  |
 +-------------------+------------------------+------------------------+
 | Business_Systems  | Electronic_Business    | Taobao                 |
 |                   | Remote_Access          | Radmin                 |
 |                   | Database               | Oracle                 |
 |                   | Finance                | DaZhiHui, Fix          |
 |                   | Enterprise_Application | LotusNotes             |
 |                   | Internet_Conferencing  | NetMeeting             |
 |                   | Data_Backup            | Rsync                  |
 |                   | Email                  | GMail                  |
 +-------------------+------------------------+------------------------+

A.2.  Data Transmission Model

   This section lists four types of models for
   applicationTransmissionModel attribute.




Xia & Lin                Expires January 3, 2018               [Page 16]


Internet-Draft           Policy Object for I2NSF               July 2017


+------------------+----------------------------------------------------+
| Model            | Description                                        |
+------------------+----------------------------------------------------+
| Client/Server    | One or more client applications communicate with a |
|                  | communicate with a sever                           |
+------------------+----------------------------------------------------+
| Browser-Based    | Applications run on web browser                    |
+------------------+----------------------------------------------------+
| Network Protocol | Applications that is used for system-to-system     |
|                  | communication                                      |
+------------------+----------------------------------------------------+
| Peer-to-Peer     | Applications directly communicate with each other  |
+------------------+----------------------------------------------------+

A.3.  Vulnerability

   This section lists five types of possible risks for
   applicationVulnerabiltiy attribute.

+---------------------+-------------------------------------------------+
| Vulnerability       | Description                                     |
+---------------------+-------------------------------------------------+
| Exploitable         | Has known vulnerabilities                       |
+---------------------+-------------------------------------------------+
| Evasive             | Used to evade the original purpose and traverse |
|                     | the firewall, for example, a proxy software     |
+---------------------+-------------------------------------------------+
| Data Loss           | Used for transferring files or uploading texts, |
|                     | may cause information leaks                     |
+---------------------+-------------------------------------------------+
| Used by Malware     | Used by malware for propagation, attack, or     |
|                     | data theft, or distributed with malware         |
+---------------------+-------------------------------------------------+
| Bandwidth Consuming | Consume large bandwidths                        |
+---------------------+-------------------------------------------------+

Appendix B.  Example of Application Scenario for Policy Object

   This appendix describes the utilization of policy objects in policy
   rules for enterprise scenario.

   NSFs are key components to protect security in enterprise network.
   For the typical architecture of an enterprise network, NSFs are
   deployed on-premise at network perimeter.  The inbound and outbound
   traffic of the enterprise network are processed according to the
   predefined security policies rules.





Xia & Lin                Expires January 3, 2018               [Page 17]


Internet-Draft           Policy Object for I2NSF               July 2017


   Figure 3 demonstrates an example of enterprise network topology.
   Firewall is a typical NSF that used at the network perimeter to
   protect enterprise intranet.  Assuming that the firewall should be
   provisioned to provide different network access controls for
   marketing departments and R&D departments.

   o  Marketing departments are allowed to access the Internet website
      but could not use entertainment applications such as online games,
      instant messaging software, in work day.

   o  R&D departments are not allowed to access the Internet.  But
      managers of R&D departments have Internet access.

   For Internet users who want to access the public website of this
   enterprise, they are only allowed to access the servers deployed in
   DMZ.



































Xia & Lin                Expires January 3, 2018               [Page 18]


Internet-Draft           Policy Object for I2NSF               July 2017


                            +----------+
                            | Internet |
                            +----------+
                                  |
                             +--------+
                             | Router |
                             +--------+
                                  |
                +-----------------------------------+
                |              Firewall             |
                +-----------------------------------+
                                  |
                +-----------------------------------+   +--------+   +-----+
                |         Core Layer Switch         |---| Switch |---| DMZ |
                +-----------------------------------+   +--------+   +-----+
                /                                   \
       +-----------------+                  +-----------------+
       | Aggregation     |                  | Aggregation     |
       | Layer Switch    |                  | Layer Switch    |
       +-----------------+                  +-----------------+
       /                \                   /                 \
+--------------+  +--------------+  +--------------+   +--------------+
| Access Layer |  | Access Layer |  | Access Layer |   | Access Layer |
| Switch       |  | Switch       |  | Switch       |   | Switch       |
+--------------+  +--------------+  +--------------+   +--------------+
       |                  |                 |                  |
+--------------+  +--------------+  +--------------+   +--------------+
| Marketing    |  | Marketing    |  | R&D          |   | R&D          |
| Department A |  | Department B |  | Department A |   | Department B |
+--------------+  +--------------+  +--------------+   +--------------+

          Figure 3: A Typical Architecture of Enterprise Network

   To set security policy rules for this scenario, the following policy
   objects should be created.
















Xia & Lin                Expires January 3, 2018               [Page 19]


Internet-Draft           Policy Object for I2NSF               July 2017


   +--------------------+----------------------------------------------+
   | Policy Object Name | Description                                  |
   +--------------------+----------------------------------------------+
   | Marketing_A        | User group object for Marketing Department A |
   +--------------------+----------------------------------------------+
   | Marketing_B        | User group object for Marketing Department B |
   +--------------------+----------------------------------------------+
   | R&D_A              | User group object for R&D Department A       |
   +--------------------+----------------------------------------------+
   | R&D_B              | User group object for R&D Department B       |
   +--------------------+----------------------------------------------+
   | R&D_Manager        | Security group object for managers of R&D    |
   |                    | Department A and R&D Department B            |
   +--------------------+----------------------------------------------+
   | Entertainment_App  | Application group object for all recognized  |
   |                    | entertainment applications                   |
   +--------------------+----------------------------------------------+
   | Server_Address     | Address object for servers in DMZ            |
   +--------------------+----------------------------------------------+
   | Web_Service        | Service object for HTTP, HTTPS protocols     |
   +--------------------+----------------------------------------------+
   | Work_Day           | Schedule object for five week days           |
   +--------------------+----------------------------------------------+

B.1.  Security Policy Control for Marketing Departments

   For traffic from marketing departments to Internet, the following
   policy objects can be used as conditions to filter traffic.

             +--------------------------------------+--------+
             | Policy Objects used in Condition     | Action |
             +--------------------------------------+--------+
             | User Group: Marketing_A, Marketing_B | Deny   |
             | Application Group: Entertainment_App |        |
             | Schedule: Work_Day                   |        |
             +--------------------------------------+--------+
             | User Group: Marketing_A, Marketing_B | Permit |
             | Service: Web_Service                 |        |
             +--------------------------------------+--------+

B.2.  Security Policy Control for R&D Departments

   For traffic from R&D departments to Internet, the following policy
   objects can be used as conditions to filter traffic.







Xia & Lin                Expires January 3, 2018               [Page 20]


Internet-Draft           Policy Object for I2NSF               July 2017


             +--------------------------------------+--------+
             | Policy Objects used in Condition     | Action |
             +--------------------------------------+--------+
             | Security Group: R&D_Manager          | Permit |
             +--------------------------------------+--------+
             | User Group: R&D_A, R&D_B             | Deny   |
             +--------------------------------------+--------+

B.3.  Security Policy Control for Server Access of Internet Users

   For traffic from Internet to web servers deployed in DMZ, the
   following policy objects can be used as conditions to filter traffic.

             +--------------------------------------+--------+
             | Policy Objects used in Condition     | Action |
             +--------------------------------------+--------+
             | Address: Server_Address              | Permit |
             +--------------------------------------+--------+

Authors' Addresses

   Liang Xia
   Huawei
   101 Software Avenue, Yuhuatai District
   Nanjing, Jiangsu  210012
   China

   Email: Frank.xialiang@huawei.com


   Qiushi Lin
   Huawei
   Huawei Industrial Base
   Shenzhen, Guangdong  518129
   China

   Email: linqiushi@huawei.com














Xia & Lin                Expires January 3, 2018               [Page 21]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/