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]