<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
    There has to be one entity for each item to be referenced. 
    An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">

]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-xia-i2nsf-security-policy-object-01" ipr="trust200902">

 <front>

   <title abbrev="Policy Object for I2NSF">Policy Object for Interface to Network Security Functions (I2NSF)</title> 

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

     <address>
       <postal>
         <street>101 Software Avenue, Yuhuatai District</street>

         <city>Nanjing</city>

         <region>Jiangsu</region>

         <code>210012</code>

         <country>China</country>
       </postal>

       <phone></phone>

       <email>Frank.xialiang@huawei.com</email>

     </address>
   </author>

   <author fullname="Qiushi Lin" initials="Q.L." surname="Lin">
     <organization>Huawei</organization>

     <address>
       <postal>
         <street>Huawei Industrial Base</street>

         <city>Shenzhen</city>

         <region>Guangdong</region>

         <code>518129</code>

         <country>China</country>
       </postal>

       <phone></phone>

       <email>linqiushi@huawei.com</email>

     </address>
   </author>
   
   <date year="2017" />


   <area>Security</area>

   <workgroup>Interface to Network Security Functions (I2NSF)</workgroup>

   <keyword>Policy Object</keyword>

   <abstract>
     <t>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.</t>
   </abstract>
 </front>

 
 <middle>
 
   <section title="Introduction">
     <t>
	 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 <xref target="I-D.ietf-i2nsf-framework"> I2NSF framework draft </xref>.
	 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. 
	 <xref target="I-D.ietf-i2nsf-capability">Information Model of NSFs Capabilities</xref> 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.
	 </t>
	 
	 <t>
	 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 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.
	 </t>
	 <t><list style="symbols">
	 <t>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.</t>
	 <t>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.
	 </t>
	 </list></t>
	
	 <t>In this document, a set of policy objects are described, and for each policy object, several essential attributes are defined. 
	 </t>

   </section>
   
   <section title="Requirements Language">
       <t>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 <xref
       target="RFC2119">RFC 2119</xref>.</t>
   </section>

   <section title="Terminology">
   <t>This document uses the terminology described in <xref target="I-D.ietf-i2nsf-terminology">Interface to Network Security Functions (I2NSF) Terminology</xref>.</t>
   
   </section>
   
   <section title="Policy Object">
   
     <t>
	 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.
	 </t>
	 
	 <t> Figure 1 shows the policy objects defined in this document and their relationships.
	 </t>
	 
	 <figure align="center" anchor="figure_structure" title="The Policy Objects Overview">
   

       <artwork align="center"><![CDATA[
+-----------------------------------------------------------------+
|                       Policy Object                             |
+-----------------------------------------------------------------+  
    |          |            |           |         |           |
    |          |            |           |         |           |
+-------+  +-------+  +-----------+  +-----+  +--------+      |
|Address|  |Service|  |Application|  |User |  |Security|      |
|Group  |  |Group  |  |Group      |  |Group|  |Group   |      |
+-------+  +-------+  +-----------+  +-----+  +--------+      |
    |          |            |           |         |           |
    |          |            |           +---------+           |    
    |          |            |                |                |
+-------+  +-------+  +-----------+      +------+        +--------+  
|Address|  |Service|  |Application|      |User  |        |Schedule|
|Object |  |Object |  |Object     |      |Object|        |Object  | 
+-------+  +-------+  +-----------+      +------+        +--------+
           ]]></artwork>

       
     </figure>
   
   
     <section title="Address Object">
	 
		<t>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:	 
		</t>
		
		<section title="The addressName Attribute">
			<t>This attribute defines a unique name for the address object. </t>
		</section>
		
		<section title="The addressRange Attribute">
			<t>This attribute defines a set of IPv4/IPv6 addresses or MAC addresses, or a range of contiguous IPv4/IPv6 addresses.</t>
			<t>An IPv4 address range can be defined by one of the following representations:</t>
			<t><list style="symbols">
			<t>IPv4 address with wildcard mask, e.g., 10.10.1.2\0.0.0.255.</t>
			<t>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.</t>
			<t>Start address and end address of the IPv4 address range, e.g., 10.10.1.2-10.10.1.254.</t>
			</list></t>
			<t>An IPv6 address range can be defined by one of the following representations:</t>
			<t><list style="symbols">
			<t>IPv6 address with length of the prefix, e.g., a234::120/120.</t>
			<t>Start address and end address of the IPv6 address range, e.g., a231::a237-b231::b237.</t>
			</list></t>
		</section>
	 
     </section>
	 
     <section title="Address Group Object">
	 
		<t>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: 
		</t>
		
		<section title="The addressGroupName Attribute">
			<t>This attribute defines a unique name for the address group object.</t>
		</section>
	 
		<section title="The addressReference Attribute">
			<t>This attribute refers to the existing address objects or existing address group objects identified by their unique names.</t>
		</section>
		
		<section title="The addressRange Attribute">
			<t>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.</t>
			<t>An IPv4 address range can be defined by one of the following representations:</t>
			<t><list style="symbols">
			<t>IPv4 address with wildcard mask, e.g., 10.10.1.2\0.0.0.255.</t>
			<t>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.</t>
			<t>Start address and end address of the IPv4 address range, e.g., 10.10.1.2-10.10.1.254.</t>
			</list></t>
			<t>An IPv6 address range can be defined by one of the following representations:</t>
			<t><list style="symbols">
			<t>IPv6 address with length of the prefix, e.g., a234::120/120.</t>
			<t>Start address and end address of the IPv6 address range, e.g., a231::a237-b231::b237.</t>
			</list></t>
		</section>
	 
     </section>	 
	 
     <section title="Service Object">
	 
		<t>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 <xref target="serviceList"/> The serviceList Attribute).
		</t>
		<t><list style="symbols">
		<t>IP based service is recognized by the value of the protocol field in IP packet header. </t>
		<t>ICMP or ICMPv6 based service is recognized by two header fields in the ICMP or ICMPv6 packets: type field and code field.</t>
		<t>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.</t>
		</list></t>
		<t>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:
		</t>
		
		<section title="The serviceName Attribute">
			<t>This attribute defines a unique name for the service object.</t>
		</section>
		
		<section anchor="serviceList" title="The serviceList Attribute">
		
			<t>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.</t>
			<t><list style="symbols">
            <t>For IP based service, the serviceProtocolNumber attribute should be specified. </t>
			<t>For ICMP or ICMPv6 based service, the serviceICMPType attribute and serviceICMPCode attribute should be specified.</t>
			<t>For UDP, TCP, or SCTP based service, the serviceSourcePort attribute and serviceDestinationPort attribute should be specified.</t>
			</list></t>
			
			<section title="The serviceProtocol Attribute">
				<t>This attribute defines the protocol type on which the service is based, IP, ICMP, ICMPv6, TCP, UDP, or SCTP.
				</t>
			</section>
			
			<section title="The serviceProtocolNumber Attribute">
				<t>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.
				</t>
			</section>
			
			<section title="The serviceICMPType Attribute">
				<t>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.
				</t>
			</section>
			
			<section title="The serviceICMPCode Attribute">
				<t>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.
				</t>
			</section>
			
			<section title="The serviceSourcePort Attribute">
				<t>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.
				</t>
			</section>
			
			<section title="The serviceDestinationPort Attribute">
				<t>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.
				</t>	
			</section>
					
		</section>
	 
     </section>

     <section title="Service Group Object">
	 
		<t>A service group object is a collection of service objects that require the same policy enforcement. 
		It consists of the following attributes:
		</t>
		
		<section title="The serviceGroupName Attribute">
			<t>This attribute defines a unique name for the service group object.</t>
		</section>
		
		<section title="The serviceReference Attribute">
			<t>This attribute refers to the existing service objects or service group objects identified by their unique names.</t>	
		</section>
		  
     </section>	 
	 
     <section title="Application Object">
	 
		<t>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:
		</t>
		
		<section title="The applicationName Attribute">
			<t>This attribute defines a unique name for the application object.</t>
		</section>
		
		<section title="The applicationCategory Attribute">
			<t>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 <xref target="AppendixA.1"/>.
			Each category is broken down into several subcategories. 
			</t>
		</section>
		
		<section title="The applicationSubCategory Attribute">
			<t>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 <xref target="AppendixA.1"/> for details about subcategory and examples of applications belong to each subcategory.)
			</t>
		</section>

		<section title="The applicationTransmissionModel Attribute">
			<t>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 <xref target="AppendixA.2"/> for more details.)
			</t>
		</section>

		<section title="The applicationVulnerability Attribute">
			<t>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 <xref target="AppendixA.3"/> for more details.)
			</t>
		</section>			
		
		<section title="The applicationRiskLevel Attribute">
			<t>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. 
			</t>
		</section>

     </section>

     <section title="Application Group Object">
		
		<t>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:
		</t>
		
		<section title="The applicationGroupName Attribute">
			<t>This attribute defines a unique name for the application group object.</t>
		</section>
		
		<section title="The applicationReference Attribute">
			<t>This attribute refers to the existing application objects or application group objects identified by their unique names.</t>	
		</section>
		
     </section>

     <section title="Schedule Object">
	 
		<t>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:
		</t>
		
		<section title="The scheduleName Attribute">
			<t>This attribute defines a unique name for the schedule object.</t>
		</section>
		
		<section title="The scheduleList Attribute">
		
			<t>This attribute defines a set of time ranges. A time range can be defined by the following sub-attributes.</t>
			
			<t><list style="symbols">
			<t>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.</t>
			<t>For an absolute time range, the start time and date, and the end time and date, should be specified.</t>
			</list></t>
			
			<section title="The scheduleType Attribute">
			<t>This attribute defines the type of a time range, periodic, absolute.	
			</t>			
			</section>
			
			<section title="The scheduleStartTime Attribute">
			<t>
			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.
			</t>
			</section>

			<section title="The scheduleEndTime Attribute">
			<t>
			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.
			</t>
			</section>	

			<section title="The scheduleWeekDay Attribute">
			<t>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.
			</t>
			</section>				
			
		</section>
		
     </section>	 
	 
	 <section title="User Object">
	 
		<t>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 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. 
		</t>
		
		<figure align="center" anchor="Figure2" title="Hierarchical Structure of User Group">
   

        <artwork align="center"><![CDATA[
         +---------------------------+
         |        UserGroup_3        |
         +---------------------------+
           |                       |
           |                       |
   +--------------+         +--------------+ 
   | UserGroup_1  |         | UserGroup_2  |
   +--------------+         +--------------+ 
     |          |             |          |
     |          |             |          |
+--------+  +--------+   +--------+  +--------+
| User_1 |  | User_2 |   | User_a |  | User_b |
+--------+  +--------+   +--------+  +--------+
           ]]></artwork>

       
     </figure>
   
 
		<t>A user object consists of the following attributes:</t>
   		
		
		<section title="The userName Attribute">
			<t>This attribute refers to the user name that used for user authentication.
			</t>
		</section>
		
		<section title="The userParentGroup Attribute">
			<t>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.
			</t>
		</section>
		
		<section title="The userSecurityGroup Attribute">
			<t>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.
			</t>
		</section>
		
		<section title="The userDomain Attribute">
			<t>This attribute refers to the authentication domain to which this user object belongs.
			</t>
		</section>
		
		<section title="The userPassword Attribute">
			<t>If user is authenticated locally on the NSF, this attribute is mandatory. It defines the password corresponding to the user name.
			</t>
		</section>
		
		<section title="The userExpirationTime Attribute">
			<t>This attribute defines when will this user object expire.
			</t>
		</section>
	 
	 </section>
	 
	 
	 <section title="User Group Object">
		
		<t>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:
		</t>
		
		<section title="The userGroupName Attribute">
			<t>This attribute defines a unique name for the user group object.
			</t>
		</section>	
		
		<section title="The userGroupParentGroup Attribute">
			<t>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.
			</t>
		</section>
		
		<section title="The userGroupDomain Attribute">
			<t>This attribute refers to the authentication domain to which this user group object belongs.
			</t>
		</section>
		
		<section title="The userGroupReference Attribute">
			<t>This attribute refers to the existing user objects or user group objects which belong to this user group object.
			</t>
		</section>
		
	 </section>
	 
	 <section title="Security Group Object">
		<t>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:
		</t>
		
		<section title="The securityGroupName Attribute">
			<t>This attribute defines a unique name for the security group object.</t>
		</section>
		
		<section title="The securityGroupParentGroup Attribute">
			<t>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.
			</t>
		</section>
		
		<section title="The securityGroupDomain Attribute">
			<t>This attribute refers to the authentication domain to which this security group object belongs.
			</t>
		</section>
		
		<section title="The securityGroupType Attribute">
			<t>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.
			</t>
		</section>
		
		<section title="The securityGroupReference Attribute">
			<t>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.
			</t>
		</section>
		
		<section title="The securityGroupFilters Attribute">
			<t>This attribute defines the filtering rules for dynamic security group object.
			</t>
		</section>
		
	 </section>
	 
   </section>
   

   <section anchor="Acknowledgements" title="Acknowledgements">
     <t></t>

   </section>


   <section anchor="IANA" title="IANA Considerations">
     <t>This document requires no IANA actions.</t>

   </section>

   <section anchor="Security" title="Security Considerations">
     <t>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.
	 </t>
   </section>
 </middle>

 <back>


   <references title="Normative References">

     &RFC2119;

 

     <reference target="https://tools.ietf.org/pdf/draft-xibassnez-i2nsf-capability-01.pdf" anchor="I-D.ietf-i2nsf-capability">

       <front>
         <title>Information Model of NSFs Capabilities</title>

         <author initials="L. Xia" surname="Xia">
         </author>
		 
		 <author initials="J. Strassner" surname="Strassner">
         </author>
		 
		 <author initials="C. Basile" surname="Basile">
         </author>
		 
		 <author initials="D. Lopez" surname="Lopez">
         </author>
		 
         <date year="2017" />
       </front>
     </reference>

	 
   </references>

   <references title="Informative References">

	      <reference target="https://tools.ietf.org/pdf/draft-ietf-i2nsf-terminology-03.pdf" anchor="I-D.ietf-i2nsf-terminology">

       <front>
         <title>Interface to Network Security Functions (I2NSF) Terminology</title>

		 <author initials="S. Hares" surname="Hares">
		 </author>

		 <author initials="J. Strassner" surname="Strassner">
		 </author>
		 
		 <author initials="D. Lopez" surname="Lopez">
         </author>
		 
		 <author initials="L. Xia" surname="Xia">
         </author>
		 
		 <author initials="H. Birkholz" surname="Birkholz">
         </author>
		 
         <date year="2017" />
       </front>
     </reference>

     <reference target="https://tools.ietf.org/pdf/draft-ietf-i2nsf-framework-05.pdf" anchor="I-D.ietf-i2nsf-framework">

       <front>
         <title>Framework for Interface to Network Security Functions</title>

         <author initials="D. Lopez" surname="Lopez">
         </author>
		 
		 <author initials="E. Lopez" surname="Lopez">
         </author>

		 <author initials="L. Dunbar" surname="Dunbar">
         </author>
		 
		 <author initials="J. Strassner" surname="Strassner">
         </author>

		 <author initials="R. Kumar" surname="Kumar">
         </author>	 
		 
         <date year="2017" />
       </front>
     </reference>	
   </references>  

   <section anchor="AppendixA" title="Application Attributes">
   
   <t>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.</t>
   
   <section anchor="AppendixA.1" title="Category and Subcategory">
   
   <t>This section lists the possible values for applicationCategory attribute and applicationSubCategory attribute. </t>
   
   <figure align="center" title="">
   

        <artwork align="center"><![CDATA[
+-------------------+------------------------+------------------------+
| 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                  |
+-------------------+------------------------+------------------------+
           ]]></artwork>
       
     </figure>	 
   
   </section>
   
   <section anchor="AppendixA.2" title="Data Transmission Model">
   <t>This section lists four types of models for applicationTransmissionModel attribute.</t>
   
   <figure align="center" title="">
   

        <artwork align="center"><![CDATA[
+------------------+----------------------------------------------------+
| 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  |
+------------------+----------------------------------------------------+
		]]></artwork>
       
     </figure>
		
   </section>
   
   <section anchor="AppendixA.3" title="Vulnerability">
   <t>This section lists five types of possible risks for applicationVulnerabiltiy attribute.</t>
   
   <figure align="center" title="">
   

        <artwork align="center"><![CDATA[
+---------------------+-------------------------------------------------+
| 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                        |
+---------------------+-------------------------------------------------+		
		]]></artwork>
       
     </figure>
   </section>
   
   </section>
   
   <section anchor="AppendixB" title="Example of Application Scenario for Policy Object">
   
   <t>This appendix describes the utilization of policy objects in policy rules for enterprise scenario.</t>
   <t>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.</t>
   
   <t>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&amp;D departments.</t>
   
   <t><list style="symbols">
   <t>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.</t>
   <t>R&amp;D departments are not allowed to access the Internet.  But managers of R&amp;D departments have Internet access.</t>
   </list></t>
   
   <t>For Internet users who want to access the public website of this enterprise, they are only allowed to access the servers deployed in DMZ. </t>

   <figure align="center" title="Figure 3: A Typical Architecture of Enterprise Network">
   

        <artwork align="center"><![CDATA[
                            +----------+
                            | 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 |
+--------------+  +--------------+  +--------------+   +--------------+
		]]></artwork>
       
     </figure>
	 
	 <t>To set security policy rules for this scenario, the following policy objects should be created.</t>
	 
	<figure align="center" title=""> 
	<artwork align="center"><![CDATA[	
+--------------------+----------------------------------------------+
| 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           |
+--------------------+----------------------------------------------+
	]]></artwork>
	</figure>
	
	<section anchor="AppendixB.1" title="Security Policy Control for Marketing Departments">
	
	<t>For traffic from marketing departments to Internet, the following policy objects can be used as conditions to filter traffic.</t>
	
	<figure align="center" title=""> 
	<artwork align="center"><![CDATA[	
+--------------------------------------+--------+
| 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                 |        |
+--------------------------------------+--------+
	]]></artwork>
	</figure>	
	
	</section>
	
    <section anchor="AppendixB.2" title="Security Policy Control for R&amp;D Departments">
	
	<t>For traffic from R&amp;D departments to Internet, the following policy objects can be used as conditions to filter traffic.</t>
	
    <figure align="center" title=""> 
	<artwork align="center"><![CDATA[	
+--------------------------------------+--------+
| Policy Objects used in Condition     | Action |
+--------------------------------------+--------+
| Security Group: R&D_Manager          | Permit |
+--------------------------------------+--------+
| User Group: R&D_A, R&D_B             | Deny   |
+--------------------------------------+--------+		
	]]></artwork>
	</figure>
	
	</section>
	
	<section anchor="AppendixB.3" title="Security Policy Control for Server Access of Internet Users">
	
	<t>For traffic from Internet to web servers deployed in DMZ, the following policy objects can be used as conditions to filter traffic.</t>

	<figure align="center" title=""> 
	<artwork align="center"><![CDATA[	
+--------------------------------------+--------+
| Policy Objects used in Condition     | Action |
+--------------------------------------+--------+
| Address: Server_Address              | Permit |
+--------------------------------------+--------+
	]]></artwork>
	</figure>
	
	</section>

   </section>
   
   
 </back>
</rfc>
