Internet DRAFT - draft-xia-i2nsf-capability-interface-im
draft-xia-i2nsf-capability-interface-im
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 <event-clause> is TRUE
IF <condition-clause> is TRUE
THEN execute <action-clause>
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:
<Policy> ::= <policy-name> <policy-id> (<Rule> ...)
<Rule> ::= <rule-name> <rule-id> <Match> <Action>
<Match> ::= [<subject-based-match>] [<object-based-match>]
<subject-based-match> ::= [<L234-packet-header> ...]
[<packet-payload> ...]
<L234-packet-header> ::= [<address-scope>] [<layer-2-header>]
[<layer-3-header>] [<layer-4-header>]
<address-scope> ::= <route-type> (<ipv4-route> | <ipv6-route> |
<mpls-route> | <mac-route> | <interface-route>)
Xia, et al. Expires September 21, 2016 [Page 19]
Internet-Draft I2NSF Capability Interface IM March 2016
<route-type> ::= <IPV4> | <IPV6> | <MPLS> | <IEEE_MAC> | <INTERFACE>
<ipv4-route> ::= <ip-route-type> (<destination-ipv4-address> |
<source-ipv4-address> | (<destination-ipv4-address>
<source-ipv4-address>))
<destination-ipv4-address> ::= <ipv4-prefix>
<source-ipv4-address> ::= <ipv4-prefix>
<ipv4-prefix> ::= <IPV4_ADDRESS> <IPV4_PREFIX_LENGTH>
<ipv6-route> ::= <ip-route-type> (<destination-ipv6-address> |
<source-ipv6-address> | (<destination-ipv6-address>
<source-ipv6-address>))
<destination-ipv6-address> ::= <ipv6-prefix>
<source-ipv6-address> ::= <ipv6-prefix>
<ipv6-prefix> ::= <IPV6_ADDRESS> <IPV6_PREFIX_LENGTH>
<ip-route-type> ::= <SRC> | <DEST> | <DEST_SRC>
<layer-3-header> ::= <ipv4-header> | <ipv6-header>
<ipv4-header> ::= <SOURCE_IPv4_ADDRESS> <DESTINATION_IPv4_ADDRESS>
<PROTOCOL> [<TTL>] [<DSCP>]
<ipv6-header> ::= <SOURCE_IPV6_ADDRESS> <DESTINATION_IPV6_ADDRESS>
<NEXT_HEADER> [<TRAFFIC_CLASS>]
[<FLOW_LABEL>] [<HOP_LIMIT>]
<object-based-match> ::= [<user> ...] [<schedule>] [<region>]
Xia, et al. Expires September 21, 2016 [Page 20]
Internet-Draft I2NSF Capability Interface IM March 2016
[<target>] [<state>]
<user> ::= (<login-name> <group-name> <parent-group> <password>
<expired-date> <allow-multi-account-login>
<address-binding>) | <tenant> | <VN-id>
<schedule> ::= <name> <type> <start-time> <end-time>
<weekly-validity-time>
<type> ::= <once> | <periodic>
<target> ::= [<service>] [<application>] [<device>]
<service> ::= <name> <id> <protocol> [<protocol-num>] [<src-port>]
[<dest-port>]
<protocol> ::= <TCP> | <UDP> | <ICMP> | <ICMPv6> | <IP>
<application> ::= <name> <id> <category> <subcategory>
<data-transmission-model> <risk-level>
<signature>
<category> ::= <business-system> | <Entertainment> | <internet>
<network> | <general>
<subcategory> ::= <Finance> | <Email> | <Game> | <media-sharing> |
<social-network> | <web-posting> | <proxy> | ...
<data-transmission-model> ::= <client-server> | <browser-based> |
<networking> | <peer-to-peer> |
<unassigned>
<risk-level> ::= <Exploitable> | <Productivity-loss> | <Evasive> |
<Data-loss> | <Malware-vehicle> |
Xia, et al. Expires September 21, 2016 [Page 21]
Internet-Draft I2NSF Capability Interface IM March 2016
<Bandwidth-consuming> | <Tunneling>
<signature> ::= <server-address> <protocol> <dest-port-num>
<flow-direction> <object> <keyword>
<flow-direction> ::= <request> | <response> | <bidirection>
<object> ::= <packet> | <flow>
<device> ::= <pc> | <mobile-phone> | <tablet>
<session-state> ::= <new> | <established> | <related> | <invalid> |
<untracked>
<action> ::= <basic-action> [<advanced-action>]
<basic-action> ::= <pass> | <deny> | <mirror> | <call-function> |
<encapsulation>
<advanced-action> ::= [<profile-antivirus>] [<profile-IPS>]
[<profile-url-filtering>]
[<profile-file-blocking>]
[<profile-data-filtering>]
[<profile-application-control>]
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]
