Information Model of Interface to Network Security Functions Capability Interface
draft-xia-i2nsf-capability-interface-im-04
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Liang Xia , Dacheng Zhang , Edward Lopez, Nicolas Bouthors | ||
| Last updated | 2015-10-18 | ||
| Replaced by | draft-xibassnez-i2nsf-capability | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-xia-i2nsf-capability-interface-im-04
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:
<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>)
<route-type> ::= <IPV4> | <IPV6> | <MPLS> | <IEEE_MAC> | <INTERFACE>
<ipv4-route> ::= <ip-route-type> (<destination-ipv4-address> |
Xia, et al. Expires April 19, 2016 [Page 18]
Internet-Draft I2NSF Capability Interface IM October 2015
<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>]
[<target>] [<state>]
<user> ::= (<login-name> <group-name> <parent-group> <password>
Xia, et al. Expires April 19, 2016 [Page 19]
Internet-Draft I2NSF Capability Interface IM October 2015
<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> |
<Bandwidth-consuming> | <Tunneling>
Xia, et al. Expires April 19, 2016 [Page 20]
Internet-Draft I2NSF Capability Interface IM October 2015
<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
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]