[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
                                                          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]


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