Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Liang Xia , Qiushi Lin
Last updated 2017-03-13
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-xia-i2nsf-security-policy-object-00
Interface to Network Security Functions (I2NSF)                   L. Xia
Internet-Draft                                                    Q. Lin
Intended status: Standards Track                                  Huawei
Expires: September 13, 2017                               March 12, 2017

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

Abstract

   This document describes policy objects used in the Interface to
   Network Security Functions (I2NSF) policy rules and defines the
   attributes of 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 September 13, 2017.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (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 September 13, 2017               [Page 1]
Internet-Draft           Policy Object for I2NSF              March 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.  Domain Group Object . . . . . . . . . . . . . . . . . . .   6
       4.3.1.  The domainGroupName Attribute . . . . . . . . . . . .   6
       4.3.2.  The domainNameList Attribute  . . . . . . . . . . . .   7
     4.4.  Region Object . . . . . . . . . . . . . . . . . . . . . .   7
       4.4.1.  The regionName Attribute  . . . . . . . . . . . . . .   7
       4.4.2.  The regionLocation Attribute  . . . . . . . . . . . .   7
         4.4.2.1.  The regionLongitude Attribute . . . . . . . . . .   7
         4.4.2.2.  The regionLatitude Attribute  . . . . . . . . . .   7
       4.4.3.  The regionIPAddress Attribute . . . . . . . . . . . .   7
     4.5.  Region Group Object . . . . . . . . . . . . . . . . . . .   8
       4.5.1.  The regionGroupName Attribute . . . . . . . . . . . .   8
       4.5.2.  The regionGroupReference Attribute  . . . . . . . . .   8
     4.6.  Service Object  . . . . . . . . . . . . . . . . . . . . .   8
       4.6.1.  The serviceName Attribute . . . . . . . . . . . . . .   8
       4.6.2.  The serviceList Attribute . . . . . . . . . . . . . .   8
         4.6.2.1.  The serviceProtocol Attribute . . . . . . . . . .   8
         4.6.2.2.  The serviceProtocolNumber Attribute . . . . . . .   8
         4.6.2.3.  The serviceSourcePort Attribute . . . . . . . . .   9
         4.6.2.4.  The serviceDestinationPort Attribute  . . . . . .   9
         4.6.2.5.  The serviceICMPType Attribute . . . . . . . . . .   9
     4.7.  Service Group Object  . . . . . . . . . . . . . . . . . .   9
       4.7.1.  The serviceGroupName Attribute  . . . . . . . . . . .   9
       4.7.2.  The serviceReference Attribute  . . . . . . . . . . .   9
     4.8.  Application Object  . . . . . . . . . . . . . . . . . . .  10
       4.8.1.  The applicationName Attribute . . . . . . . . . . . .  10
       4.8.2.  The applicationCategory Attribute . . . . . . . . . .  10
       4.8.3.  The applicationSubCategory Attribute  . . . . . . . .  10
       4.8.4.  The applicationTransmissionModel Attribute  . . . . .  10
       4.8.5.  The applicationLabel Attribute  . . . . . . . . . . .  10
       4.8.6.  The applicationRiskLevel Attribute  . . . . . . . . .  10
     4.9.  Application Group Object  . . . . . . . . . . . . . . . .  10
       4.9.1.  The applicationGroupName Attribute  . . . . . . . . .  11
       4.9.2.  The applicationReference Attribute  . . . . . . . . .  11
     4.10. Schedule Object . . . . . . . . . . . . . . . . . . . . .  11
       4.10.1.  The scheduleName Attribute . . . . . . . . . . . . .  11

Xia & Lin              Expires September 13, 2017               [Page 2]
Internet-Draft           Policy Object for I2NSF              March 2017

       4.10.2.  The scheduleList Attribute . . . . . . . . . . . . .  11
         4.10.2.1.  The scheduleType Attribute . . . . . . . . . . .  11
         4.10.2.2.  The scheduleStartTime Attribute  . . . . . . . .  11
         4.10.2.3.  The scheduleEndTime Attribute  . . . . . . . . .  11
         4.10.2.4.  The scheduleWeekDay Attribute  . . . . . . . . .  11
     4.11. User Object . . . . . . . . . . . . . . . . . . . . . . .  12
       4.11.1.  The userName Attribute . . . . . . . . . . . . . . .  12
       4.11.2.  The userParentGroup Attribute  . . . . . . . . . . .  12
       4.11.3.  The userSecurityGroup Attribute  . . . . . . . . . .  12
       4.11.4.  The userDomain Attribute . . . . . . . . . . . . . .  12
       4.11.5.  The userPassword Attribute . . . . . . . . . . . . .  12
       4.11.6.  The userExpirationTime Attribute . . . . . . . . . .  12
       4.11.7.  The userAllowSharing Attribute . . . . . . . . . . .  13
       4.11.8.  The userBindingStatus Attribute  . . . . . . . . . .  13
       4.11.9.  The userBindingAddress Attribute . . . . . . . . . .  13
     4.12. User Group Object . . . . . . . . . . . . . . . . . . . .  13
       4.12.1.  The userGroupName Attribute  . . . . . . . . . . . .  13
       4.12.2.  The userGroupParentGroup Attribute . . . . . . . . .  13
       4.12.3.  The userGroupDomain Attribute  . . . . . . . . . . .  14
       4.12.4.  The userGroupReference Attribute . . . . . . . . . .  14
       4.12.5.  The userGroupAllowSharing Attribute  . . . . . . . .  14
     4.13. Security Group Object . . . . . . . . . . . . . . . . . .  14
       4.13.1.  The securityGroupName Attribute  . . . . . . . . . .  14
       4.13.2.  The securityGroupParentGroup Attribute . . . . . . .  14
       4.13.3.  The securityGroupDomain Attribute  . . . . . . . . .  14
       4.13.4.  The securityGroupType Attribute  . . . . . . . . . .  14
       4.13.5.  The securityGroupReference Attribute . . . . . . . .  15
       4.13.6.  The securityGroupFilters Attribute . . . . . . . . .  15
       4.13.7.  The securityGroupAllowSharing Attribute  . . . . . .  15
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

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 Framework for Interface to
   Network Security Functions [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 or illustrates attributes of
   different Condition subclasses.  When configuring policy rules by

Xia & Lin              Expires September 13, 2017               [Page 3]
Internet-Draft           Policy Object for I2NSF              March 2017

   using attributes, it is no surprise to see that the same value of an
   attribute or the same value set of several attributes are configured
   for several times or more.  And modifications of the policy rules are
   also very complex 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 can be
   identified by a set of data items, such as IP addresses, TCP/UDP
   ports, and domain names.  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 related 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

   Policy objects are collections of commonly used condition attributes.
   Different policy objects consist of different attributes.  For each
   policy object, a description of this policy object may be an optional
   attribute.  The following figure shows the policy objects defined in
   this document.

Xia & Lin              Expires September 13, 2017               [Page 4]
Internet-Draft           Policy Object for I2NSF              March 2017

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

                       Figure 1: The policy objects

4.1.  Address Object

   An address object is a collection of IPv4/IPv6 addresses or MAC
   addresses.  It consists of the following attributes:

4.1.1.  The addressName Attribute

   This attribute defines the unique name of 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.

   The IPv4 address range can be defined by IPv4 address with wildcard
   mask, or IPv4 address with subnet mask (subnet mask address or length
   of the subnet mask), or the start address and the end address of the
   IPv4 address range.

Xia & Lin              Expires September 13, 2017               [Page 5]
Internet-Draft           Policy Object for I2NSF              March 2017

   The IPv6 address range can be defined by IPv6 address with length of
   the prefix, or the start address and the end address of the IPv6
   address range.

4.2.  Address Group Object

   An address group object is composed 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 the unique name of 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.

   The IPv4 address range can be defined by IPv4 address with wildcard
   mask, or IPv4 address with subnet mask (subnet mask address or length
   of the subnet mask), or the start address and the end address of the
   IPv4 address range.

   The IPv6 address range can be defined by IPv6 address with length of
   the prefix, or the start address and the end address of the IPv6
   address range.

4.3.  Domain Group Object

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

4.3.1.  The domainGroupName Attribute

   This attribute defines the unique name of the domain group object.

Xia & Lin              Expires September 13, 2017               [Page 6]
Internet-Draft           Policy Object for I2NSF              March 2017

4.3.2.  The domainNameList Attribute

   This attribute defines a set of domain names.  The domain name can be
   matched in two modes: exact match and suffix match.  Thus a domain
   name can be added by using the full string of the domain name (e.g.,
   www.example.com) or a domain name begins with a wildcard (e.g.,
   *.example.com).

4.4.  Region Object

   A region object is an IPv4/IPv6 address of a geographical region or a
   collection of IPv4/IPv6 addresses located in the same geographical
   region.  A set of region objects which can be referenced directly
   should be predefined by NSFs.  A region object consists of the
   following attributes:

4.4.1.  The regionName Attribute

   This attribute defines the unique name of the region object.

4.4.2.  The regionLocation Attribute

   This attribute defines the longitude and latitude of the region.  It
   consists of two sub-attributes:

4.4.2.1.  The regionLongitude Attribute

   This attribute defines the longitude of the region.

4.4.2.2.  The regionLatitude Attribute

   This attribute defines the latitude of the region.

4.4.3.  The regionIPAddress Attribute

   This attribute defines a set of IPv4/IPv6 addresses or a range of
   contiguous IPv4/IPv6 addresses.  And an IP address can only belong to
   one region object.

   The IPv4 address range can be defined by IPv4 address with wildcard
   mask, IPv4 address with subnet mask (subnet mask address or length of
   the subnet mask), or the start address and the end address of the
   IPv4 address range.

   The IPv6 address range can be defined by IPv6 address with length of
   the prefix, or the start address and the end address of the IPv6
   address range.

Xia & Lin              Expires September 13, 2017               [Page 7]
Internet-Draft           Policy Object for I2NSF              March 2017

4.5.  Region Group Object

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

4.5.1.  The regionGroupName Attribute

   This attribute defines the unique name of the region group object.

4.5.2.  The regionGroupReference Attribute

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

4.6.  Service Object

   A service object is one or more services that can be identified by
   certain information, such as protocol type, source port number and
   destination port number.  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.6.1.  The serviceName Attribute

   This attribute defines the unique name of the service object.

4.6.2.  The serviceList Attribute

   This attribute defined a set of services.  A service can be defined
   by the following sub-attributes.

4.6.2.1.  The serviceProtocol Attribute

   This attribute defines the protocol type of the service.  The value
   of this attribute is selected from six types of protocols: TCP, UDP,
   SCTP, ICMP, ICMPv6 or IP.

4.6.2.2.  The serviceProtocolNumber Attribute

   This attribute defines the protocol number for IP protocol.  The
   protocol number is the protocol field value in IP packet which
   identifies which kind of upper layer protocol is used.

Xia & Lin              Expires September 13, 2017               [Page 8]
Internet-Draft           Policy Object for I2NSF              March 2017

4.6.2.3.  The serviceSourcePort Attribute

   This attribute defines the source port number range for TCP, UDP or
   SCTP protocol.  A single port number or a range of port numbers can
   be set.

4.6.2.4.  The serviceDestinationPort Attribute

   This attribute defines the destination port number range for TCP, UDP
   or SCTP protocol.  A single port number or a range of port numbers
   can be set.

4.6.2.5.  The serviceICMPType Attribute

   This attribute defines the ICMP/ICMPv6 type for ICMP or ICMPv6
   protocol.  The ICMP/ICMPv6 type can be identified by ICMP/ICMPv6 type
   number and ICMP/ICMPv6 message code.  Thus, this attribute has two
   sub-attributes: serviceICMPTypeNumber and serviceICMPMessageCode.

   The serviceICMPTypeNumber Attribute: It defines the ICMP/ICMPv6 type
   number and shall be defined together with the serviceICMPMessageCode
   attribute.  For example, if the ICMP packet type is Echo, this
   attribute shall be set to 8 and the serviceICMPMessageCode attribute
   shall be set to 0.

   The serviceICMPMessageCode Attribute: It defines the ICMP/ICMPv6
   message code and shall be defined together with the
   serviceICMPTypeNumber attribute.  For example, if the ICMP packet
   type is Echo, this attribute shall be set to 0 and the
   serviceICMPTypeNumber attribute shall be set to 8.

4.7.  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:

4.7.1.  The serviceGroupName Attribute

   This attribute defines the unique name of the service group object.

4.7.2.  The serviceReference Attribute

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

Xia & Lin              Expires September 13, 2017               [Page 9]
Internet-Draft           Policy Object for I2NSF              March 2017

4.8.  Application Object

   An application object is a kind of application that can be identified
   by several features, such as category, subcategory or risk level.  A
   set of well-known application objects should be predefined by NSFs to
   support direct reference.  An application object consists of the
   following attributes:

4.8.1.  The applicationName Attribute

   This attribute defines the unique name of the application object.

4.8.2.  The applicationCategory Attribute

   This attribute defines the category of the application.  The value of
   this attribute is selected from a predefined set of categories, e.g.,
   general category, network application category.

4.8.3.  The applicationSubCategory Attribute

   This attribute defines the subcategory of the application.  The value
   of this attribute is selected from a predefined set of subcategories,
   e.g., search engine subcategory, electronic commerce subcategory.

4.8.4.  The applicationTransmissionModel Attribute

   This attribute defines the data transmission model of the
   application.  The value of this attribute is selected from a
   predefined set of transmission models, e.g., client/server model,
   peer-to-peer model.

4.8.5.  The applicationLabel Attribute

   This attribute defines a set of labels for the application.  The
   values of this attribute are selected from a predefined set of
   labels, e.g., database, encrypted-communication.

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

4.9.  Application Group Object

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

Xia & Lin              Expires September 13, 2017              [Page 10]
Internet-Draft           Policy Object for I2NSF              March 2017

4.9.1.  The applicationGroupName Attribute

   This attribute defines the unique name of the application group
   object.

4.9.2.  The applicationReference Attribute

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

4.10.  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:

4.10.1.  The scheduleName Attribute

   This attribute defines the unique name of the schedule object.

4.10.2.  The scheduleList Attribute

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

4.10.2.1.  The scheduleType Attribute

   This attribute defines the type of a time range.  The value of this
   attribute is selected from the two types: periodic, absolute.

4.10.2.2.  The scheduleStartTime Attribute

   For a periodic time range, this attribute defines the start time in a
   day.  For an absolute time range, this attribute defines the start
   time and start date.

4.10.2.3.  The scheduleEndTime Attribute

   For a periodic time range, this attribute defines the end time in a
   day.  For an absolute time range, this attribute defines the end time
   and end date.

4.10.2.4.  The scheduleWeekDay Attribute

   This attribute defines the days in a week that the periodic time
   range takes effect.

Xia & Lin              Expires September 13, 2017              [Page 11]
Internet-Draft           Policy Object for I2NSF              March 2017

4.11.  User Object

   A user object identifies a person who may access network resources.
   It is the basis of implementing user-based I2NSF policy.  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
   security group objects.  The user group objects are organized as a
   hierarchical structure.  A security group object consists of user
   objects from different user group objects that require the same
   policy enforcement.  A user object consists of the following
   attributes:

4.11.1.  The userName Attribute

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

4.11.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.11.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.11.4.  The userDomain Attribute

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

4.11.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.11.6.  The userExpirationTime Attribute

   This attribute defines when will this user object expire.

Xia & Lin              Expires September 13, 2017              [Page 12]
Internet-Draft           Policy Object for I2NSF              March 2017

4.11.7.  The userAllowSharing Attribute

   This attribute defines whether this user account identified by the
   userName and userPassword attribute is allowed to be shared by
   different persons.  If allowed, this user object can be logged on to
   several devices simultaneously.

4.11.8.  The userBindingStatus Attribute

   This attribute defines whether the user object is bound to IP
   addresses, or MAC addresses, or IP/MAC address pairs.  It is selected
   from three binding modes: no binding, unidirectional binding, and
   bidirectional binding.  For no binding mode, the user object is not
   bound to any IP or MAC address or IP/MAC address pair.  For
   unidirectional binding mode, the addresses or address pairs bound to
   this user object also can be bound to other users.  For bidirectional
   binding mode, the addresses or address pairs bound to this user
   should not be bound to other bidirectional binding user object.

4.11.9.  The userBindingAddress Attribute

   This attribute defines the bound IP addresses, or MAC addresses, or
   IP/MAC address pairs.  If the userBindingStatus is unidirectional
   binding or bidirectional binding, this attribute is mandatory.

4.12.  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.12.1.  The userGroupName Attribute

   This attribute defines the unique name of the user group object.

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

Xia & Lin              Expires September 13, 2017              [Page 13]
Internet-Draft           Policy Object for I2NSF              March 2017

4.12.3.  The userGroupDomain Attribute

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

4.12.4.  The userGroupReference Attribute

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

4.12.5.  The userGroupAllowSharing Attribute

   This attribute defines whether the user objects of this user group
   object are allowed to be shared by different persons.  If allowed,
   all user objects of this user group object can be logged on to
   several devices simultaneously.

4.13.  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:

4.13.1.  The securityGroupName Attribute

   This attribute defines the unique name of the security group object.

4.13.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.13.3.  The securityGroupDomain Attribute

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

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

Xia & Lin              Expires September 13, 2017              [Page 14]
Internet-Draft           Policy Object for I2NSF              March 2017

4.13.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.13.6.  The securityGroupFilters Attribute

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

4.13.7.  The securityGroupAllowSharing Attribute

   This attribute defines whether the user objects of this security
   group object are allowed to be shared by different persons.  If
   allowed, all user objects of this security group object can be logged
   on to several devices simultaneously.

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.

8.  References

8.1.  Normative References

   [I-D.ietf-i2nsf-capability]
              Xia, L., Strassner, J., Zhang, D., Li, K., Basile, C.,
              Lioy, A., Lopez, D., Lopez, E., BOUTHORS, N., and L. Fang,
              "Information Model of NSFs Capabilities", 2016,
              <https://tools.ietf.org/pdf/draft-xibassnez-i2nsf-
              capability-00.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>.

Xia & Lin              Expires September 13, 2017              [Page 15]
Internet-Draft           Policy Object for I2NSF              March 2017

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", 2016, <https://tools.ietf.org/pdf/draft-ietf-
              i2nsf-framework-04.pdf>.

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

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 September 13, 2017              [Page 16]