I2NSF L. Xia Internet Draft Huawei Intended status: Standard Track D. Zhang Alibaba E. Lopez Fortinet N. BOUTHORS Qosmos Luyuan Fang Microsoft Expires: September 2016 March 21, 2016 Information Model of Interface to Network Security Functions Capability Interface draft-xia-i2nsf-capability-interface-im-05.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 September 21,2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. Xia, et al. Expires September 21, 2016 [Page 1] Internet-Draft I2NSF Capability Interface IM March 2016 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. 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 ............................................ 4 3. Overall Analysis of Security Capability ..................... 5 3.1. Network Security Control ............................... 5 3.2. Content Security Control ............................... 7 3.3. Attack Mitigation Control .............................. 9 4. Information Model Design .................................... 9 4.1. Overall Structure ...................................... 9 4.2. Information Model for Network Security Control ........ 10 4.3. Information Model for Content Security Control ........ 17 4.4. Information Model for Attack Mitigation Control ....... 18 5. IM Grammar of Security Policy .............................. 19 6. Security Considerations .................................... 22 7. IANA Considerations ........................................ 22 8. References ................................................. 23 8.1. Normative References .................................. 23 8.2. Informative References ................................ 23 9. Acknowledgments ............................................ 23 1. Introduction As with the rapid development and the more deployment of cloud computing, the demand of cloud-based security services is also rapidly growing. Such services can provide security protection in various scenarios, e.g., network devices in an enterprise network, User Equipments (UE) of mobile network, Internet of Things (IoT), or Xia, et al. Expires September 21, 2016 [Page 2] Internet-Draft I2NSF Capability Interface IM March 2016 residential access users [I-D.draft-ietf-i2nsf-problem-and-use- cases]. According to [I-D.draft-merged-i2nsf-framework], there are two types of I2NSF interfaces for security rules provisioning: 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 Interface between NSFs (e.g., FW, AAA, IPS, Anti-DDOS, WAF, or Anti-Virus) with security controller, 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. Nowadays, different NSF vendors have different interfaces and information models for the security functions management. In principle, the capability interface is used to decouple the up- layer security management scheme and the NSFs, and through the interface, a NSF can show its security functions to its controller. The information model proposed in this draft is only about of controlling part of the capability interface, and the monitoring part is out of scope. This document is organized as follows: Section 3 is an analysis of security capability for I2NSF interface. Section 4 presents 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]. Xia, et al. Expires September 21, 2016 [Page 3] Internet-Draft I2NSF Capability Interface IM March 2016 This document references to [I-D.draft-hares-i2nsf-terminology] for more specific security related and I2NSF scoped terminology definitions. 2.1. Terminology AAA -Access control, Authorization, Authentication ACL - Access Control List 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 WAF - Web Application Firewall Xia, et al. Expires September 21, 2016 [Page 4] Internet-Draft I2NSF Capability Interface IM March 2016 3. Overall Analysis of Security Capability At present, a variety of NSFs produced by multiple security vendors provide various security capabilities to customers. Logically, no matter these security capabilities are carried out in VMs or in 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 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 security function very similar as network firewall. 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. By referencing to [I-D.draft-merged-i2nsf-framework], the "Event- Condition-Action" (ECA) policy ruleset is used here as the basis for the security rule design as follows: o Event: An Event is defined as any important occurrence in time of a change in the system being managed, and/or in the environment of the system being managed. When used in the context of policy rules for a flow-based NSF, it is used to determine whether the Condition clause of the Policy Rule can be evaluated or not. Examples of an I2NSF Event include time and user actions (e.g. logon, logoff, and actions that violate any ACL.); Xia, et al. Expires September 21, 2016 [Page 5] Internet-Draft I2NSF Capability Interface IM March 2016 o Condition: A set of attributes, features, and/or values that are to be compared with a set of known attributes, features, and/or values in order to make a decision. When used in the context of policy rules for flow-based NSFs, it is used to determine whether or not the set of Actions in that Policy Rule can be executed or not. The following contents (which are not exhausted) of the received packets can be used in the Condition: - Packet content values: Refer to the kind of information or attributes acquired directly from the packet headers or payloads that can be used in the security policy directly. It can be any fields or attributes in the packet L2/L3/L4 header, or special segment of bytes in the packet payload; - Context values: Refer to the context information for the received packets. It can be (and not limited to): * 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 able to enforce the security functions over the given user (or user group); * Schedule: Time or time range when network flow happens; * Region: The location where network traffic is associated with. The region can be the geographic location such as country, province, and city as well, as well as the logical network location such as IP address, network section and network domain; * 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; Xia, et al. Expires September 21, 2016 [Page 6] Internet-Draft I2NSF Capability Interface IM March 2016 * 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), the session AAA state or the access mode of the devices (i.e., wire, wireless, or vpn); * Direction: the direction of the network flow. o Action: The flow-based NSFs realize the security functions by executing various Actions, which at least includes: - Ingress actions, such as pass, drop, mirroring, etc; - Egress actions, such as invoke signaling, tunnel encapsulation, packet forwarding and/or transformation; - Applying a specific Functional Profile or signature - e.g., an IPS Profile, a signature file, an anti-virus file, or a URL filtering file. The functional profile or signature file corresponds to the security capability for the content security control and attack mitigation control which will be described afterwards. It is one of the key properties that determine the effectiveness of the NSF, and is mostly vendor- specific today. One goal of I2NSF is to standardize the form and functional interface of those security capabilities while supporting vendor-specific implementations of each. The above ECA ruleset is very general and easily extensible, thus 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 September 21, 2016 [Page 7] Internet-Draft I2NSF Capability Interface IM March 2016 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 atomic style design, the security capabilities can be utilized and assembled together freely, and changes of one capability will not influence others; o High abstraction: through the high level of abstraction and consolidation, each capability should have a unified interface to make it programmable, or report its processing result and the 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 rapid changeable network traffic or service request. In addition, the security capability must support the statistics reporting to the security controller to assist its decision on whether it 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 NSF 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 repository. In any case, a standard interface is needed during this automated update process. Xia, et al. Expires September 21, 2016 [Page 8] Internet-Draft I2NSF Capability Interface IM March 2016 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, IPv6 Routing header attack, and IPv6 duplicate address detection attack, 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 which type of device that the NSF belongs. That is, it is assume that the user of the capability interface does not care about Xia, et al. Expires September 21, 2016 [Page 9] Internet-Draft I2NSF Capability Interface IM March 2016 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 I2NSF 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 when they handle the network traffic over network layer. Its basic structure is shown in the following figure: Xia, et al. Expires September 21, 2016 [Page 10] Internet-Draft I2NSF Capability Interface IM March 2016 +--------+ +-->Time | +---------+ | |events | +-> Event +-+ +--------+ | +---------+ | +-------+ | | |User | | +-->actions| | | +-------+ +-----------+ | * |L2/L3/L4 | +-->* +->packet | | * | |header | | +-------+ | +-----------+ | |Packet | | +---------+ | +->content|-+-> Packet | | | |values | | payload | | | +-------+ +---------+ | | | | +----------+ | | +-> User | | | | +----------+ | +---------+ | | +----------+ +----+ +->Condition|-+ +-> Schedule | | | | +---------+ | | +----------+ +-->Rule| | | | +---------+ | | | | | +-------+ +-> Region | | +----+ | | |Context| | +---------+ | | +->values +-+ +---------+ | * | | | +-> Target | | * | +-------+ | +---------+ | * | | +---------+ | | +-> State | | | | +---------+ +------+ | +----+ | | +-----------+ | | | | | | +-> Direction | |Policy+--+-->Rule+--+ +-----------+ | | | | | | +------+ | +----+ | +-------+ | | +->Permit | | * | | +-------+ | * | +--------+ | +-------+ | * | +->Ingress +-+-> Deny | | | | |actions | | +-------+ | | | +--------+ | +-------+ | | | +-> Mirror| | | | | +-------+ | | | | * Xia, et al. Expires September 21, 2016 [Page 11] Internet-Draft I2NSF Capability Interface IM March 2016 | | | +-> * | +----+ | | * | | | | +---------+ | +---------+ +-->Rule| +-> Action +-+ +->Invoke | | | +---------+ | | |signaling| +----+ | +--------+ +---------+ | |Egress | | +-------------+ +->actions +-+->Tunnel | | +--------+ | |encapsulation| | | +-------------+ | | +----------+ | +->Forwarding| | | +----------+ | | * | +-> * | * | +----------+ | +->Antivirus:| | | |profile | | | +----------+ | | +---------+ | +-> IPS: | | | |signature| | | +---------+ | | +----------+ | +------------+ | | URL | +->Other +-+->Filtering:| |security | | |data base | |capabilities| | +----------+ +------------+ | +----------+ | | 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., Xia, et al. Expires September 21, 2016 [Page 12] Internet-Draft I2NSF Capability Interface IM March 2016 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 ECA model. An example of an I2NSF Policy Rule is, in pseudo-code: IF is TRUE IF is TRUE THEN execute END-IF END-IF In the above example, the Event, Condition, and Action portions of a Policy Rule are all **Boolean Clauses**. In summary, the detailed variable definitions of all event clauses and condition clauses are as follows: o Time event: TBD; o User actions event: user related actions such as login, logoff, etc; 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; 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; Xia, et al. Expires September 21, 2016 [Page 13] Internet-Draft I2NSF Capability Interface IM March 2016 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; 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; - Session AAA state: includes authentication state, authorization state, accounting state; - Access mode: the access mode of user or device. Xia, et al. Expires September 21, 2016 [Page 14] Internet-Draft I2NSF Capability Interface IM March 2016 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 | +---------------+-------------------------------------------+ | Time | | | Event | TBD | |---------------+-------------------------------------------+ | User Actions | | | Event | login, logout, violate ACL ... | |---------------+-------------------------------------------+ | 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 | | | sockstress | Xia, et al. Expires September 21, 2016 [Page 15] Internet-Draft I2NSF Capability Interface IM March 2016 +---------------+-------------------------------------------+ | 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 in the event and condition clauses defined in the first rule. If all the results are TRUE, the traffic matches the rule. If one or more clauses are FALSE, the NSF compares the attributes with in event and condition clauses defined in the next rule. If all rules are not met, the NSF denies the traffic by default; Xia, et al. Expires September 21, 2016 [Page 16] Internet-Draft I2NSF Capability Interface IM March 2016 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 | | Packet Capturing | | File Isolation | | ... | | | | | | | | | | Information model | | for content security| | control | +----------------------------------+ Figure 3. The basic structure of information model for content security control Xia, et al. Expires September 21, 2016 [Page 17] Internet-Draft I2NSF Capability Interface IM March 2016 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: Please view in a fixed-width font such as Courier. +-------------------------------------------------+ | | | +---------------------+ +---------------+ | | |Attack mitigation | | General Shared| | | |capabilites: | | Parameters: | | | | SYN flood, | | | | | | UDP flood, | | | | | | ICMP flood, | | | | | | IP fragment flood, | | | | | | IPv6 related attacks| | | | | | 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 Xia, et al. Expires September 21, 2016 [Page 18] Internet-Draft I2NSF Capability Interface IM March 2016 The detailed description about the standard interface and the general shared parameters for all the security capabilities of this category are TBD. 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/outcoming interface of the packet Then, the I2NSF information model grammar of security policy is specified as follows: ::= ( ...) ::= ::= [] [] ::= [ ...] [ ...] ::= [] [] [] [] ::= ( | | | | ) Xia, et al. Expires September 21, 2016 [Page 19] Internet-Draft I2NSF Capability Interface IM March 2016 ::= | | | | ::= ( | | ( )) ::= ::= ::= ::= ( | | ( )) ::= ::= ::= ::= | | ::= | ::= [] [] ::= [] [] [] ::= [ ...] [] [] Xia, et al. Expires September 21, 2016 [Page 20] Internet-Draft I2NSF Capability Interface IM March 2016 [] [] ::= ( ) | | ::= ::= | ::= [] [] [] ::= [] [] [] ::= | | | | ::= ::= | | | ::= | | | | | | | ... ::= | | | | ::= | | | | | Xia, et al. Expires September 21, 2016 [Page 21] Internet-Draft I2NSF Capability Interface IM March 2016 | ::= ::= | | ::= | ::= | | ::= | | | | ::= [] ::= | | | | ::= [] [] [] [] [] [] 6. Security Considerations TBD 7. IANA Considerations Xia, et al. Expires September 21, 2016 [Page 22] Internet-Draft I2NSF Capability Interface IM March 2016 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. [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-ietf-i2nsf-problem-and-use-cases] Hares, S., et.al., "I2NSF Problem Statement and Use cases", Work in Progress, February, 2016. [I-D.draft-merged-i2nsf-framework] Lopez, E., et.al., "Framework for Interface to Network Security Functions", Work in Progress, March, 2016. [I-D.xia-i2nsf-service-interface-DM] Xia, L., et.al., "Data Model of Interface to Network Security Functions Service Interface", February, 2015. 9. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Xia, et al. Expires September 21, 2016 [Page 23] Internet-Draft I2NSF Capability Interface IM March 2016 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 Luyuan Fang Microsoft 15590 NE 31st St Redmond, WA 98052 Email: lufang@microsoft.com Xia, et al. Expires September 21, 2016 [Page 24]