[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 draft-xibassnez-i2nsf-capability

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/