I2NSF L. Xia Internet Draft Huawei Intended status: Standard Track D. Zhang Alibaba E. Lopez Fortinet N. BOUTHORS Qosmos Expires: April 2016 October 19, 2015 Information Model of Interface to Network Security Functions Capability Interface draft-xia-i2nsf-capability-interface-im-04.txt 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 19,2016. Copyright Notice Copyright (c) 2015 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 Xia, et al. Expires April 19, 2016 [Page 1] Internet-Draft I2NSF Capability Interface IM October 2015 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. Abstract This draft is focused on the capability interface of NSFs (Network Security Functions) and proposes its information model for controlling the various network security functions. Table of Contents 1. Introduction ................................................ 2 2. Conventions used in this document ........................... 3 2.1. Terminology ............................................ 3 3. Overall Analysis of Security Capability ..................... 4 3.1. Network Security Control ............................... 5 3.2. Content Security Control ............................... 6 3.3. Attack Mitigation Control .............................. 8 4. Information Model Design .................................... 8 4.1. Overall Structure ...................................... 8 4.2. Information Model for Network Security Control ......... 9 4.3. Information Model for Content Security Control ........ 16 4.4. Information Model for Attack Mitigation Control ....... 17 5. IM Grammar of Security Policy .............................. 18 6. Security Considerations .................................... 21 7. IANA Considerations ........................................ 21 8. References ................................................. 21 8.1. Normative References .................................. 21 8.2. Informative References ................................ 22 9. Acknowledgments ............................................ 22 1. Introduction Due to the rapid development and deployment of cloud computing services, the demand of cloud-based security services is also rapidly growing. The customers of them can be enterprises, User Equipment (UE) of mobile network, Internet of Things (IoT), and residential access users [I-D.draft-pastor-i2nsf-merged-use-cases]. From [I-D.draft-merged-i2nsf-framework], there could be two types of I2NSF interfaces: Xia, et al. Expires April 19, 2016 [Page 2] Internet-Draft I2NSF Capability Interface IM October 2015 o Interface between I2NSF clients with security controller: [I- D.xia-i2nsf-service-interface-DM] describes the information model used by this type of interface. This is a service-oriented interface, the main objective is to unify the communication channel and the security service request information model between various high-level application (e.g., openstack, or various BSS/OSS) with various security controllers. The design goal of the service interface is to decouple the security service in the application layer from various kinds of security devices and their device-level security functions. A feasible model may be the intent-based information model approach derived from RBAC; o North-bound interface provided by NSFs (e.g., FW, AAA, IPS, Anti- DDOS, or Anti-Virus), no matter whether the NSFs are run in Virtual Machines (VMs) or physical appliances. In this document, this type of interface is also referred to as "capability interface". Any network entities (e.g., I2NSF client, or network/security controller) control and monitor the NSFs via this interface. Unfortunately, today's situation is different NSF vendors have different interfaces and information models for the security functions management. In principle, the capability interface is used by the NSFs for decoupling from the up-layer security service requests and highlighting the security capabilities they can provide. Specially, this draft is focused on the information model of controlling part of the capability interface and discusses its contents and structure. The monitoring part is not discussed in this draft. This document is structured as following: Section 3 presents an overall analysis of security capability for I2NSF interface. Section 4 discusses the detailed structure and content of the information model. Section 4 specifies the information model of security policy in Routing Backus-Naur Form [RFC5511]. 2. Conventions used in this document 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]. 2.1. Terminology AAA -Access control, Authorization, Authentication ACL - Access Control List Xia, et al. Expires April 19, 2016 [Page 3] Internet-Draft I2NSF Capability Interface IM October 2015 AD - Active Directory ANSI - American National Standards Institute DDoS - Distributed Deny of Services FW - Firewall I2NSF - Interface to Network Security Functions INCITS - International Committee for Information Technology Standards IoT - Internet of Things IPS - Intrusion Prevention System LDAP - Lightweight Directory Access Protocol NAT - Network Address Translation NBI - North-bound Interface NIST - National Institute of Standard Technology NSF - Network Security Function RBAC - Role Based Access Control UE - User Equipment URL - Uniform/Universal Resource Locator VM - Virtual Machine 3. Overall Analysis of Security Capability At present, a variety of NSFs presented by multiple security vendors provide various security capabilities to customers. Logically, whether these security capabilities are run in VMs or physical appliance, multiple NSFs can be combined together as a whole to provide security services over the given network traffic. Most of today's security capabilities can fall into several categories according to their basic functionalities: network security control, content security control, attack mitigation Xia, et al. Expires April 19, 2016 [Page 4] Internet-Draft I2NSF Capability Interface IM October 2015 control. Each category further covers more specific security capabilities, which are described below. 3.1. Network Security Control Network security control is a category with only one security capability which has the similar goal as network firewall to some level. Its main function is inspecting and processing the network traffic traversing network based on predefined security policies. With respect to the inspecting part, this security capability is abstractly a packet-processing engine that inspects packets traversing networks, either directly or in context to flows to which the packet is associated. Considering from the perspective of packet-processing, the implementations of it differ in the depths of packet headers and/or payloads they can inspect, the various flow and context states they can maintain, and the actions they can apply. Therefore, it can be characterized by the level of packet-processing and context that it can support, and the actions that it can apply, so does its policy design paradigm. Here, a "Subject-Object-Action-Function" paradigm is proposed as the basis for the security policy design: o Subject: Refer to the kind of information or attributes acquired directly from the packet headers or payloads that can be used in the security policy as the match conditions. It can be any fields or attributes in the packet L2/L3/L4 header, or special segment of bytes in the packet payload; o Object: Refer to the context information for the packet or flow. It can be: - User: The user (or user group) information to which network flow is associated: User has many attributes such as name, id, password, type, authentication mode and so on. Name/id is often used in the security policy to identify the user. Besides, NSF is aware of the IP address of the user provided by unified user management system via network. Based on name- address association, NSF is capable of enforcing the security functions over the given user (or user group); - Schedule: Time or time range when network flow happens; Xia, et al. Expires April 19, 2016 [Page 5] Internet-Draft I2NSF Capability Interface IM October 2015 - Region: The location where network traffic is associated with. The region can be the geographic location such as country, province, and city as well. It can also be the logical network location such as IP address, network section and network domain as well; - Target: Under the circumstances of network, it mainly refers to the service, application and device. A service is an application identified by a protocol type and port number, such as TCP, UDP, ICMP and IP. An application is a computer program for a specific task or purpose. It provides a finer granularity than service in matching traffic. The attributes that can identify a device include type (i.e., router, switch, pc, ios, or android) and the device's owner as well; - State: It refers to various states to which the network flow is associated. It can be either the TCP session state (i.e., new, established, related, invalid, or untracked), or the access mode of the devices (i.e., wire, wireless, or vpn). o Action: A variety of actions for traffic filtering or suppression can be performed, which include deny, permit, mirror, diversion, rate limiting, black/white list, QoS actions, route black hole and so on; o Function: Refer to the other security capabilities that can be called for more advanced treatment over the network traffic. The above design paradigm is very general and easily extensible, and so can avoid any potential constraints which could limit the implementation of the network security control capability. 3.2. Content Security Control Content security control is another category of security capabilities applied to application layer. Through detecting the contents carried over the traffic in application layer, these capabilities can realize various security purposes, such as defending against intrusion, inspecting virus, filtering malicious URL or junk email, blocking illegal web access or data retrieve. Generally, each type of threat in application layer has its unique characteristic and requires to be handled with the unique method accordingly, which can be a logically independent security capability. Since there are a large number of types of threats in the application layer, as well as the new type of threat occurs quickly, there will also be a large number of security capabilities. Xia, et al. Expires April 19, 2016 [Page 6] Internet-Draft I2NSF Capability Interface IM October 2015 Therefore, some basic principles for security capabilities' management and utilization need to be considered: o Flexibility: each security capability should be an independent function, with minimum overlap or dependency to other capabilities. By this design, the security capabilities can be utilized and assembled together freely, and changes of one capability will not influence others; o Generality: through a level of abstraction and consolidation, each capability should have an unified interface to make it programmable, or report its process result and some statistics information. Furthermore, it facilitates the intercommunication between multi-vendors; o Scalability: The system must have the capability of scale up/down or scale in/out. Thus it can meet various performance requirements derived from the mutable network traffic or service request. Additionally, the security capability must support reporting its statistics information to the security controller to assist its decision on whether the capability needs to be scale up or not; o Automation: it includes the features of auto-discovery, auto- negotiation, and automatic update. These features are especially useful for the management of a large number of NSFs. Based on the above principles, a set of abstract and vendor-neutral capabilities with standard interface is needed. The security controller can have a common capabilities base to choose the appropriate NSFs (by different vendors), as well as customize each NSF's detailed function by setting the interface parameters, to meet the requirements requested by clients. The security controller does not need to be aware of any detailed implementation of each capability which each vendor differs. This category of security capability is more like a black box compared with the network security control. Furthermore, when an unknown threat (e.g., zero-day exploits, unknown malwares, and APTs) is reported by a network security device, new capability may be created, or existing capability may need to update its intelligence (e.g., signature, and algorithm), to enable the device to acquire the new capability to handle the threat. The new capability and intelligence are provided from different vendors after their analysis on the new threats, and may be sent and stored in a centralized repository or stored separately in their local Xia, et al. Expires April 19, 2016 [Page 7] Internet-Draft I2NSF Capability Interface IM October 2015 repository. In any case, a standard interface is needed during this automation process. 3.3. Attack Mitigation Control This category of security capabilities is specially used to detect and mitigate various types of network attacks. Today's common network attacks are mainly classified into the following sets, and each set further consists of a number of specific attacks: o DDoS attacks: - Network layer DDoS attacks: SYN flood, UDP flood, ICMP flood, IP fragment flood, etc - Application layer DDoS attacks: http flood, https flood, dns flood, dns amplification, ssl DDoS, etc o Single-packet attack: - Scanning and sniffing attacks: IP sweep, port scanning, etc - malformed packet attacks: Ping of Death, Teardrop, etc - special packet attacks: Oversized ICMP, Tracert, IP timestamp option packets, etc Each type of network attack has its own network behaviors and packet/flow characteristics. It therefore needs a special security capability for detection and mitigation. Overall, the implementation and management of this category of security capabilities of attack mitigation control is very similar to content security control. A standard interface is essential here through which the security controller can choose and customize the given security capabilities according to specific requirements. 4. Information Model Design 4.1. Overall Structure The I2NSF capability interface is in charge of controlling and monitoring the NSFs. Based on the analysis above, the controlling part of its information model should at least consist of three blocks: network security control, content security control and attack mitigation control. It's noted that the capability interface only cares about the specific security capabilities rather than to Xia, et al. Expires April 19, 2016 [Page 8] Internet-Draft I2NSF Capability Interface IM October 2015 which type of device that the NSF belongs. That is, it is assume that the user of the capability interface does not care about whether the network entity it is communicating with is a firewall or an IPS. Instead, the user cares about the capability that it has, such as packet filtering or deep packet inspection. The Overall structure is illustrated in the figure below: +---------------------------------------------------------------+ | | | | | +-------------+ +-------------+ +-------------+ | | | | | | | | | | | Content | call | Network | call | Attack | | | | security <-------+ security +-------> mitigation | | | | control | | control | | control | | | | | | | | | | | | | | | | | | | +-------------+ +-------------+ +-------------+ | | | | | | | | Information model for capability interface | +---------------------------------------------------------------+ Figure 1. The overall structure of information model for I2NSF Capability Interface As illustrated in Figure 1, the network security control is the key block of the whole system. It usually runs at the first step to handle traffic (i.e., packet/flow detection and filtering, etc) over the network layer. In the extreme condition, the system can still work without this block, which means network security control is not needed under that condition. The other two blocks are both composed of a number of specific security capabilities, which are enforced either statically according to fixed configuration or dynamically over some given traffic based on the detecting results of network security control. The two enforcement ways have difference in the information model. The more detailed descriptions of information model for each block are given in the following sections. 4.2. Information Model for Network Security Control The information model for network security control specifies the content and structure of a rule. A rule is complied with by the NSFs Xia, et al. Expires April 19, 2016 [Page 9] Internet-Draft I2NSF Capability Interface IM October 2015 when they handle the network traffic over network layer. Its basic structure is shown in the following figure: Xia, et al. Expires April 19, 2016 [Page 10] Internet-Draft I2NSF Capability Interface IM October 2015 +-----------+ |L2/L3/L4 | +->packet | | |header | +-------+ | +-----------+ |Subject| | +---------+ +-> based |-+-> Packet | | | match | | payload | | +-------+ +---------+ | | +----------+ | +-> User | | | +----------+ +-----+ | | +----------+ +----+ +->Match|-+ +-> Schedule | | | | +-----+ | | +----------+ +-->Rule| | | | +---------+ | | | | | +-------+ +-> Region | | +----+ | | |Object | | +---------+ | | +->based +-+ +---------+ | * | |match | +-> Target | | * | +-------+ | +---------+ | * | | +---------+ | | +-> State | | | | +---------+ +------+ | +----+ | | +-----------+ | | | | | | +-> Direction | |Policy+--+-->Rule+--+ +-----------+ | | | | | | +------+ | +----+ | +-------+ | | +->Permit | | * | | +-------+ | * | +--------+ | +-------+ | * | +->Basic +-+-> Deny | | | | |action | | +-------+ | | | +--------+ | +-------+ | | | +-> Mirror| | | | | +-------+ | | | | * | | | +-> * | +----+ | | * | | | | +-------+ | +-->Rule| +->Action +-+ +----------+ | | +-------+ | +->Antivirus:| +----+ | | |profile | | | +----------+ | | +---------+ Xia, et al. Expires April 19, 2016 [Page 11] Internet-Draft I2NSF Capability Interface IM October 2015 | +-> IPS: | | | |signature| | | +---------+ | | +----------+ | +--------+ | | URL | +->Advanced+-+->Filtering:| |action | | |data base | +--------+ | +----------+ | +----------+ | | File | +->Blocking: | | |profile | | +----------+ | +----------+ | | Data | +->Filtering:| | |profile | | +----------+ | * +-> * * Figure 2. The basic structure of information model for network security control As illustrated in Figure 2, at the top level, policy is a container including a set of security rules according to certain logic, i.e., their similarity or mutual relations, etc. The network security policy is able to apply over both the unidirectional and bidirectional traffic across the NSF. Each rule represents some specific security requirements or actions with the classic "match & action" style supported in industry widely. The logic relation among all the conditions in one match is "AND", which means the match result is true only when the traffic matches all the conditions in this match. In summary, the detailed definitions of all match conditions are as follows: o L2/L3/L4 Packet header: all meaningful and useful attributes in L2/L3/L4 packet header, for example: src/dest address, or src/dest port; o Packet payload: any segment of bytes in the packet payload; Xia, et al. Expires April 19, 2016 [Page 12] Internet-Draft I2NSF Capability Interface IM October 2015 o User: The user is a person who is authorized to access network resources. A user can be an internet access user who accesses Internet resources or intranet resources from inside the intranet through a FW, or a remote access user who connects to a FW in VPN, or PPPoE mode to access intranet resources. The NSFs need to know the IP address or other information (i.e., user's tenant or VN-ID) of the user to identify the user's traffic and perform the pre- defined actions. It can also define a group of users to match and perform actions to them together; o Schedule: A schedule defines time range. A rule can reference a schedule to filter traffic that passes through the NSF within the schedule. A schedule can be a periodic schedule, or a one-time schedule; o Region: The location information of the user traffic. The logical definition of the location can be pre-defined in the location signature database by the geographical information, or be manually defined by the user's IP information. o Target: - Service: A service is an application identified by a protocol type and port number. It can be a service or a group of services. The network security control matches the service traffics based on the protocol types and port numbers and applies the security actions to them; - Application: An application is a computer program for a specific task or purpose, and multiple applications constitute an application group. It provides a finer granularity than service in matching traffic. Even if different applications have the same service, they still can be distinguished by analyzing the data packets and comparing the signatures of each application. The hierarchy category method is appropriate for identifying applications. For example, the application of Gmail belongs to the category of business systems, and the subcategory of Email. Other key attributes that belongs to and can be used to identify an application are data transmission model (e.g., client-server, browser-based, networking, or peer-to-peer), risk level (e.g., Exploitable, Evasive, Data-loss, or Bandwidth-consuming); - Device: The attributes that can identify a device include type (i.e., router, switch, pc, ios, or android) and the device's owner as well; Xia, et al. Expires April 19, 2016 [Page 13] Internet-Draft I2NSF Capability Interface IM October 2015 o State: - Session state: any one specific state related to the user/operation sessions, such as authentication state, TCP/UDP session state, or bidirectional state; - Access mode: the access mode of user or device. o Direction: the direction of the network flow. Following table lists the possible attributes with their possible values for all the match conditions: +-----------------------------------------------------------+ |Match Condition| Attributes: Values | +---------------+-------------------------------------------+ | Ethernet | | | Frame | Source/Destination address | | Header | s-VID/c-VID/EtherType | |---------------+-------------------------------------------+ | | src/dest address | | IPv4 | protocol | | Packet | src/dest port | | Header | length | | | flags | | | ttl | +---------------+-------------------------------------------+ | | src/dest address | | IPv6 | protocol/nh | | Packet | src/dest port | | Header | length | | | traffic class | | | hop limit | | | flow label | +---------------+-------------------------------------------+ | TCP | Port | | SCTP | syn | | DCCP | ack | | | fin | | | rst | | | psh | | | urg | | | window | Xia, et al. Expires April 19, 2016 [Page 14] Internet-Draft I2NSF Capability Interface IM October 2015 | | sockstress | +---------------+-------------------------------------------+ | User | | +---------------+-------------------------------------------+ | Schedule | time span | | | days, minutes, seconds, | +---------------+-------------------------------------------+ | Region | country, province, city | | | IP address, network section, | | | network domain | +---------------+-------------------------------------------+ | | service: TCP, UDP, ICMP, HTTP... | | Target | application: Gmail, QQ, MySQL... | | | device: mobile phone, tablet, PC... | +---------------+-------------------------------------------+ | | session state: new, established, related| | State | invalid, untracked | | | access mode: WIFI, 802.1x, PPPOE, SSL...| +---------------+-------------------------------------------+ | | Direction: from_client, from_server, | | Direction | bidirection, reversed | | | | +---------------+-------------------------------------------+ Table 1. Match conditions details Note that match conditions are extensible, new one can be created any time according to the requirements. Network security control policy consists of a number of rules complying with the information model described above. Then it enforces the rules in turn to process the passing traffic. Following is the basic operation process: 1. The NSF compares the attributes with the match conditions defined in the first rule. If all the conditions are met, the traffic matches the rule. If one or more conditions are not met, the NSF compares the attributes with the conditions defined in the next rule. If all rules are not met, the NSF denies the traffic by default; Xia, et al. Expires April 19, 2016 [Page 15] Internet-Draft I2NSF Capability Interface IM October 2015 2. If the traffic matches a rule, the NSF performs the defined actions over the traffic. If the action is "deny", the NSF blocks the traffic. If the basic action is permit/mirror, the NSF resumes checking whether certain other security capabilities are referenced in the rule. If yes, go to step 3. If no, the traffic is permitted; 3. If other security capabilities (e.g., Antivirus or IPS) are referenced in the rule and the action defined in the rule is permit/mirror, the NSF performs the called security capabilities. One policy or rule can be applied multiple times on different places, i.e., links, devices, networks, vpns, etc. It not only guarantees the consistent policy enforcement in the whole network, but also decreases the configuration workload. 4.3. Information Model for Content Security Control The block for content security control is composed of a number of security capabilities, while each one aims for protecting against a specific type of threat in the application layer. Following figure shows a basic structure of the information model: +----------------------------------+ | | | | | Anti-Virus | | Intrusion Prevention | | URL Filtering | | File Blocking | | Data Filtering | | Application Behavior Control | | Mail Filtering | | ... | | | | | | | | | | Information model | | for content security| | control | +----------------------------------+ Figure 3. The basic structure of information model for content security control Xia, et al. Expires April 19, 2016 [Page 16] Internet-Draft I2NSF Capability Interface IM October 2015 The detailed description about the standard interface and the parameters for all the security capabilities of this category are TBD. 4.4. Information Model for Attack Mitigation Control The block for attack mitigation control is composed of a number of security capabilities, while each one aims for mitigating a specific type of network attack. Following figure shows a basic structure of the information model: +-------------------------------------------------+ | | | +-------------------+ +---------------+ | | |Attack mitigation | | General Shared| | | |capabilites: | | Parameters: | | | | SYN flood, | | | | | | UDP flood, | | | | | | ICMP flood, | | | | | | IP fragment flood,| | | | | | HTTP flood, | | | | | | HTTPS flood, | | | | | | DNS flood, | | | | | | DNS amplification,| | | | | | SSL DDoS, | | | | | | IP sweep, | | | | | | Port scanning, | | | | | | Ping of Death, | | | | | | Oversized ICMP | | | | | | | | | | | | ... | | | | | | | | | | | +-------------------+ +---------------+ | | | | Information model | | for attack mitigation| | control | +-------------------------------------------------+ Figure 4. The basic structure of information model for attack mitigation control The detailed description about the standard interface and the general shared parameters for all the security capabilities of this category are TBD. Xia, et al. Expires April 19, 2016 [Page 17] Internet-Draft I2NSF Capability Interface IM October 2015 5. IM Grammar of Security Policy This section specifies the information model of security policy in Routing Backus-Naur Form [RFC5511]. This grammar is intended to help the reader better understand the english text description in order to derive a data model. Firstly, several types of route are specified as follows: o IPv4: Match on destination IP address in the IPv4 header o IPv6: Match on destination IP address in the IPv6 header o MPLS: Match on a MPLS label at the top of the MPLS label stack o MAC: Match on MAC destination addresses in the ethernet header o Interface: Match on incoming interface of the packet Then, the I2NSF information model grammar of security policy is specified as follows: ::= ( ...) ::= ::= [] [] ::= [ ...] [ ...] ::= [] [] [] [] ::= ( | | | | ) ::= | | | | ::= ( | Xia, et al. Expires April 19, 2016 [Page 18] Internet-Draft I2NSF Capability Interface IM October 2015 | ( )) ::= ::= ::= ::= ( | | ( )) ::= ::= ::= ::= | | ::= | ::= [] [] ::= [] [] [] ::= [ ...] [] [] [] [] ::= ( Xia, et al. Expires April 19, 2016 [Page 19] Internet-Draft I2NSF Capability Interface IM October 2015 ) | | ::= ::= | ::= [] [] [] ::= [] [] [] ::= | | | | ::= ::= | | | ::= | | | | | | | ... ::= | | | | ::= | | | | | | Xia, et al. Expires April 19, 2016 [Page 20] Internet-Draft I2NSF Capability Interface IM October 2015 ::= ::= | | ::= | ::= | | ::= | | | | ::= [] ::= | | | | ::= [] [] [] [] [] [] 6. Security Considerations TBD 7. IANA Considerations 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Xia, et al. Expires April 19, 2016 [Page 21] Internet-Draft I2NSF Capability Interface IM October 2015 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, April 2009. 8.2. Informative References [INCITS359 RBAC] NIST/INCITS, "American National Standard for Information Technology - Role Based Access Control", INCITS 359, April, 2003 [I-D.draft-pastor-i2nsf-merged-use-cases] Pastor, A., et.al., "Use Cases and Requirements for an Interface to Network Security Functions", Work in Progress, June, 2015. [I-D.draft-merged-i2nsf-framework] Lopez, E., et.al., "Framework for Interface to Network Security Functions", Work in Progress, June, 2015. [I-D.xia-i2nsf-service-interface-DM] Xia, L., et.al., "Data Model of Interface to Network Security Functions Service Interface", February, 2015. [I-D.lopez-i2nsf-packet] Lopez, E., "Packet-Based Paradigm For Interfaces To NSFs", March, 2015. 9. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Xia, et al. Expires April 19, 2016 [Page 22] Internet-Draft I2NSF Capability Interface IM October 2015 Authors' Addresses Liang Xia (Frank) Huawei 101 Software Avenue, Yuhuatai District Nanjing, Jiangsu 210012 China Email: Frank.xialiang@huawei.com DaCheng Zhang Alibaba Email: Dacheng.zdc@alibaba-inc.com Edward Lopez Fortinet 899 Kifer Road Sunnyvale, CA 94086 Phone: +1 703 220 0988 EMail: elopez@fortinet.com Nicolas BOUTHORS Qosmos Email: Nicolas.BOUTHORS@qosmos.com Xia, et al. Expires April 19, 2016 [Page 23]