Information Model of Interface to Network Security Functions Capability Interface
draft-xia-i2nsf-capability-interface-im-03

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Last updated 2015-07-20
Replaced by draft-xibassnez-i2nsf-capability
Stream (None)
Intended RFC status (None)
Formats pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
I2NSF                                                          L. Xia
Internet Draft                                                 Huawei
Intended status: Standard Track                              D. Zhang
                                                              Alibaba
                                                             E. Lopez
                                                             Fortinet
                                                          N. BOUTHORS
                                                               Qosmos

Expires: January 2016                                    July 20, 2015

        Information Model of Interface to Network Security Functions
                           Capability Interface
              draft-xia-i2nsf-capability-interface-im-03.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 January 20,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 January 20, 2016                [Page 1]
Internet-Draft      I2NSF Capability Interface IM            July 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 north-bound interface of NSFs (Network
   Security Functions) and proposes an information model for
   configuring various kinds NSF security functions, based on the
   packet-based paradigm. The Yang structure and application examples
   are also presented to clarify how to use the information model.

Table of Contents

   1. Introduction ................................................ 2
   2. Conventions used in this document ........................... 3
      2.1. Terminology ............................................ 3
   3. Information Model for Capability Interface .................. 4
      3.1. Overview ............................................... 4
      3.2. Packet-Based Paradigm .................................. 7
      3.3. Rule .................................................. 10
      3.4. Match ................................................. 11
      3.5. Action ................................................ 13
   4. I2NSF Capability Interface Policy IM Grammar ............... 14
   5. I2NSF Capability Interface IM Yang Structure ............... 18
   6. Use Examples of I2NSF Capability Interface IM .............. 21
   7. Security Considerations .................................... 21
   8. IANA Considerations ........................................ 22
   9. References ................................................. 22
      9.1. Normative References .................................. 22
      9.2. Informative References ................................ 22
   10. Acknowledgments ........................................... 23

 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 [I-
   D.zarny-i2nsf-data-center-use-cases], User Equipment (UE) of mobile
   network and Internet of Things (IoT) [I-D.qi-i2nsf-access-network-
   usecase], residential access users [I-D.pastor-i2nsf-access-
   usecases], and so on.

Xia, et al.           Expires January 20, 2016                [Page 2]
Internet-Draft      I2NSF Capability Interface IM            July 2015

   Derived from [I-D.dunbar-i2nsf-problem-statement], there could be
   two types of I2NSF interfaces:

   o Interface between I2NSF user/client with network/security
      controller: [I-D.xia-i2nsf-service-interface-DM] describes the
      information model used by this type of interface. It's 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, various BSS/OSS, etc) with various network controllers.
      The design goal of the service interface is to decouple security
      service in application layer from various kinds of security
      devices and their device-level security functions. The intent-
      based information model approach derived from RBAC model can be a
      feasible option for it;

   o North-bound interface provided by NSFs (e.g., FW, AAA, IPS, Anti-
      DDOS, Anti-Virus, etc), no matter whether the NSFs are performed
      by 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 clients,
      network/security controller, etc) can use this interface to
      configure the required security functions of NSFs. Nowadays
      different NSF vendors have different proprietary interfaces and
      information models for configuring their security functions.

   This draft is focused on the capability interfaces and proposes an
   information model for configuring various kinds NSFs. It's used by
   the NSFs to decouple from the various security services came from
   the application layer and highlight the security capabilities they
   can provide. Section 3 defines the information model for capability
   interface. Section 4 gives its representation by Yang data model.
   Section 5 includes some using examples to clarify how to use the
   information model.

 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 January 20, 2016                [Page 3]
Internet-Draft      I2NSF Capability Interface IM            July 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. Information Model for Capability Interface

  3.1. Overview

   The capability interface cares about the specific security
   capabilities that NSF can provide rather than the 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 NSF that it is
   communicating with is a firewall or an IPS. Instead, the user cares
   about the capability that the NSF has, such as, packet filtering,
   deep packet inspection, and etc. Based on this consideration, the
   capability interface discussed in this memo is designed based on a

Xia, et al.           Expires January 20, 2016                [Page 4]
Internet-Draft      I2NSF Capability Interface IM            July 2015

   generic IM that is abstracted from the various specific security
   capabilities.

   The information model specified for I2NSF capability interface is
   shown in Figure 1.

Xia, et al.           Expires January 20, 2016                [Page 5]
Internet-Draft      I2NSF Capability Interface IM            July 2015

                                            +-----------+
                                            |Packet     |
                                          +->header or  |
                                          | |payload    |
                                 +------+ | +-----------+
                                 |Packet| | +---------+
                               +->based |-+-> Service |
                               | |match | | +---------+
                               | +------+ | +-----------+
                               |          +->Application|
                               |            +-----------+
                               |
                               |             +----------+
                               |           +->  User    |
                               |           | |  group   |
             +----+    +-----+ |           | +----------+
             |    |  +->Match|-+             +----------+
          +-->Rule|  | +-----+ |           +-> Session  |
          |  |    |  |         |           | | state    |
          |  +----+  |         | +-------+ | +----------+
          |          |         | |context| | +----------+
          |    *     |         +->based  +-+-> Schedule |
          |    *     |           |match  | | +----------+
          |    *     |           +-------+ | +---------+
          |          |                     | | Region  |
          |          |                     +-> group   |
+------+     +----+  |                       |         |
|      |  |  |    |  |                       +---------+
|Policy+--+-->Rule+--+
|      |  |  |    |  |                         +-------+
+------+  |  +----+  |                       +->Permit +
          |          |                       | +-------+
          |    *     |             +-------+ | +-------+
          |    *     |           +->Basic  +-+-> Deny  |
          |    *     |           | |action | | +-------+
          |          |           | +-------+ | +-------+
          |          |           |           +-> Mirror|
          |          |           |             +-------+
          |          |           |
          |          |           |              +----------+
          |          |           |            +->Antivirus:|
          |  +----+  |           |            | |profile   |
          |  |    |  | +-------+ |            | +----------+
          +-->Rule|  +->Action +-+            | +---------+
             |    |    +-------+ |            +->  IPS:   |
             +----+                           | |signature|
                                 |            | +---------+

Xia, et al.           Expires January 20, 2016                [Page 6]
Internet-Draft      I2NSF Capability Interface IM            July 2015

                                 |            | +----------+
                                 |            | | URL      |
                                 |            +->Filtering:|
                                              | |data base |
                                 |            | +----------+
                                 | +--------+ | +----------+
                                 +->Advanced+-+ |  File    |
                                   |action  | +->Blocking: |
                                   +--------+ | |profile   |
                                              | +----------+
                                              | +----------+
                                              | |  Data    |
                                              +->Filtering:|
                                              | |profile   |
                                              | +----------+
                                              | +-----------+
                                              | |Application|
                                              +->  control  |
                                              | +-----------+
                                              |   *
                                              +-> *
                                                  *
        Figure 1. The Overall Information Model for I2NSF Capability
                                Interface

   As illustrated in Figure 1, at the top level, policy is a container
   including a set of security rules. Each rule represents some
   specific security requirements or actions. Security policy combines
   these rules together according to some logic, i.e., their similarity
   or mutual relations, etc.

   A Security policy is created and assigned to any NSFs depending on
   specific requirements and scenarios. For example, a security policy
   can be responsible for an enterprise branch, or can be used for the
   access control to one set of services.

  3.2. Packet-Based Paradigm

   It is clarified in [I-D.lopez-i2nsf-packet] that abstractly all NSFs
   are packet-processing engines that inspect packets traversing
   networks, either directly or in context to sessions to which the
   packet is associated. This draft uses this packet-based paradigm for
   the design of NSF capability interface IM. This packet-based design
   approach is very general and easily extensible, and so can avoid any
   potential constraints which could limit NSFs' functional
   capabilities.

Xia, et al.           Expires January 20, 2016                [Page 7]
Internet-Draft      I2NSF Capability Interface IM            July 2015

   Considering from the perspective of packet-processing, NSFs differ
   in the depths of packet headers and/or payloads they can inspect,
   the various session/context states they can maintain, and the
   actions or specific profiles they can apply. Therefore, the NSF
   capabilities can be characterized by the level of packet-processing
   and context that a NSF can support, and the actions and profiles
   that the NSF can apply. In the other hand, NSF Vendors can register
   their provided NSF capabilities by using the Subject-Object-Action-
   Function categories described by [I-D.lopez-i2nsf-packet].

   Table 1-4 below lists some examples included in the categories for
   constructing the NSF capability:

     +-----------------------------------------------------------+
     |         Subject (packet) Capability Index                 |
     +---------------+-------------------------------------------+
     | Layer 2       | Layer 2 header fields:                    |
     | Header        | Source/Destination/s-VID/c-VID/EtherType/.|
     |               |                                           |
     |---------------+-------------------------------------------+
     | Layer 3       | Layer header fields:                      |
     |               |            protocol                       |
     | IPv4 objects  |            port                           |
     |               |            src port                       |
     |               |            dscp                           |
     |               |            length                         |
     |               |            flags                          |
     |               |            ttl                            |
     |               |                                           |
     | IPv6 Object   |                                           |
     |               |            addr                           |
     |               |            protocol/nh                    |
     |               |            src port                       |
     |               |            length                         |
     |               |            traffic class                  |
     |               |            hop limit                      |
     |               |            flow label                     |
     |               |                                           |
     | TCP           |            Port                           |
     | SCTP          |            syn                            |
     | DCCP          |            ack                            |
     |               |            fin                            |
     |               |            rst                            |

Xia, et al.           Expires January 20, 2016                [Page 8]
Internet-Draft      I2NSF Capability Interface IM            July 2015

     |               |            psh                            |
     |               |            urg                            |
     |               |            window                         |
     |               |            sockstress                     |
     | UDP           |                                           |
     |               |            flood abuse                    |
     |               |            fragment abuse                 |
     |               |            Port                           |
     | HTTP layer    |                                           |
     |               |            hash collision                 |
     |               |            http - get flood               |
     |               |            http - post flood              |
     |               |            http - random/invalid url      |
     |               |            http - slowloris               |
     |               |            http - slow read               |
     |               |            http - r-u-dead-yet (rudy)     |
     |               |            http - malformed request       |
     |               |            http - xss                     |
     |               |            https - ssl session exhaustion |
     +---------------+-------------------------------------------+
     | IETF PCP      | Configurable                              |
     |               | Ports                                     |
     |               |                                           |
     +---------------+-------------------------------------------+
     | IETF TRAM     | profile                                   |
     |               |                                           |
     |               |                                           |
     |---------------+-------------------------------------------+
               Table 1. Subject (packet) Capability Index

     +-----------------------------------------------------------+
     |      Object (context) Capability Index                    |
     +---------------+-------------------------------------------+
     | Session       |   Session state: new, established, related|
     |               |   invalid, untracked                      |
     |               |                                           |
     +---------------+-------------------------------------------+
     | Time          |   time span                               |
     |               |   days, minutes, seconds,                 |
     |               |   Events                                  |
     +---------------+-------------------------------------------+

Xia, et al.           Expires January 20, 2016                [Page 9]
Internet-Draft      I2NSF Capability Interface IM            July 2015

     | Events        |   Event URL, variables                    |
     +---------------+-------------------------------------------+
               Table 2. Object (context) Capability Index

     +-----------------------------------------------------------+
     |      Actions Capability Index                             |
     +---------------+-------------------------------------------+
     | Ingress port  |   SFC header termination ,                |
     +---------------+-------------------------------------------+
     |               |   Pass                                    |
     | Egress port   |   Deny                                    |
     |               |   Mirror                                  |
     |               |   Functional call                         |
     |               |   Encap various header                    |
     +---------------+-------------------------------------------+
                   Table 3. Actions Capability Index

     +-----------------------------------------------------------+
     | Functional profile (advanced actions) Capability Index    |
     +---------------+-------------------------------------------+
     | Profile types |   Vendor specific                         |
     |               |   Flexible Profile URL                    |
     |               |   Accept external                         |
     |               |                                           |
     +---------------+-------------------------------------------+

     Table 4. Functional profile (advanced actions) Capability Index

  3.3. Rule

   Each rule is defined in the classic "match & action" style that
   already implemented in most NSFs today.

   The NSF follows the rules one by one to process the passing traffic
   as follows:

Xia, et al.           Expires January 20, 2016               [Page 10]
Internet-Draft      I2NSF Capability Interface IM            July 2015

   1. The NSF analyzes traffics in a packet-based match fashion or a
      context-based match fashion, or both. In the packet-based match
      fashion, the NSF only inspects the packet header and/or payload
      to retrieve the attributes at the network or the application
      layers. Such attributes could include address, length of payload,
      port, protocol, user, and etc. When performing a context-based
      match, besides retrieving and analyzing the attributes from the
      packet, the NSF also needs to check some of the attributes
      against contextual attributes (e.g., session state, schedule and
      region) in order to decide the ways of processing the packets;

   2. 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 of objects defined in
      the next rule. If all rules are not met, the NSF denies the
      traffic by default;

   3. If the traffic matches a rule, the NSF performs the defined basic
      actions over the traffic. If the basic action is deny, the NSF
      blocks the traffic. If the basic action is permit/mirror, the NSF
      resumes checking whether certain advanced actions are referenced
      in the rule. If yes, go to step 4. If no, the traffic is
      permitted;

   4. If certain advanced actions (e.g., Antivirus, IPS, etc) are
      referenced in the rule and the basic action defined in the rule
      is permit/mirror, the NSF performs integrated checks on the
      content carried over the traffic. The integrated check inspects
      the content carried over the traffic based on the conditions
      defined in the referenced profiles of advanced action and
      implements appropriate actions based on the check result. If any
      advanced action determines to block the traffic, the NSF blocks
      the traffic. If all advanced actions determine to permit the
      traffic, the NSF allows the traffic through.

   One 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.

  3.4. Match

   Match (aka, Objects) consists of two categories of match condition:
   packet-based match and context-based match. Each category includes
   various match conditions representing different kinds of objects.
   Derived from the packet-based paradigm, the former match is based on

Xia, et al.           Expires January 20, 2016               [Page 11]
Internet-Draft      I2NSF Capability Interface IM            July 2015

   the packet content directly; the latter match is based on the
   context to sessions to which the packet is associated. In other
   words, the context includes some environment relevant
   characteristics that are not directly in the packet but need to be
   derived from session analysis.

   The logic relation among all the conditions is flexible, it can be
   "AND", "OR". The former means the traffic must match all the
   conditions, while the latter means the traffic only needs to match
   one of the conditions.

   The general objects for packet-based match are as follows:

   o Packet header or payload: all meaningful and useful attributes in
      packet header or payload, for example: src/dest address, src/dest
      port, payload fragment, etc;

   o Service: A service is an application identified by a protocol
      type and port number. It can be a service or a group of services.
      NSF matches the service traffics based on the protocol types and
      port numbers and applies the security actions to them;

   o 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, peer-to-peer, etc), risk level (e.g.,
      Exploitable, Evasive, Data-loss, Bandwidth-consuming, etc).

   The general objects for context-based match are as follows:

Xia, et al.           Expires January 20, 2016               [Page 12]
Internet-Draft      I2NSF Capability Interface IM            July 2015

   o User group: A group of user information. The user is a person
      application 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 Session state: any one specific state related to the
      user/operation sessions, such as authentication state, TCP/UDP
      session state, bidirectional state, etc;

   o Schedule: A schedule defines time ranges. 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 group: A group of user's location information. The logical
      definition of users' location can be pre-defined in the location
      signature database by the geographical information, or be manual
      defined by the user's IP information.

   Objects are extensible, new match conditions can be defined and
   added into them any time according to requirements.

  3.5. Action

   The action of a security rule is also divided into two categories
   logically: basic actions and advanced actions. Basic actions are
   either permit, deny or mirror. Deny simple means to block the
   matching traffics. Permit and mirror have more meanings by
   performing the referenced advanced actions. The all advanced actions
   in one rule can inspect traffic content during one-pass, which
   greatly improves system performance.

   Every advanced action includes its own matching conditions to
   identify specific traffic and perform required actions. The advanced
   action is defined by specific requirements or for specific scenarios.
   Some typical advanced actions are Antivirus, IPS, URL filtering,
   File blocking, Data filtering, Application control, and so on.

   To deal with the situation of emerging new threats, i.e., zero-day
   exploits, unknown malwares, APTs, NSF's advanced actions (aka
   functions) should have the capability of dynamic update. A NSF

Xia, et al.           Expires January 20, 2016               [Page 13]
Internet-Draft      I2NSF Capability Interface IM            July 2015

   should be able to load the new advanced action and/or update the
   signature used by existing functions when an unknown threat is
   identified. The new advanced actions and signature can be provided
   by different security vendors after their research on the new
   threats and sent and stored in a centralized policy repository or
   stored separately in their local policy repository. Anyway, a
   standard interface is needed when the NSF negotiates with the policy
   repository about the new functions/signatures needed. Additionally,
   I2NSF capability interface should have the unified information model
   to configure and apply all these functions/signatures. The details
   will be added in future version.

   By combining advanced actions and using them appropriately, NSFs can
   defend against possible attacks and reduce the waste of system
   resources.

 4. I2NSF Capability Interface Policy IM Grammar

   This section specifies the RIB information model 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 capability interface policy IM grammar is specified
   as follows:

   <Policy> ::= <policy-name> <policy-id> (<Rule> ...)

   <Rule> ::= <rule-name> <rule-id> <Match> <Action>

   <Match> ::= [<packet-based-match>] [<context-based-match>]

Xia, et al.           Expires January 20, 2016               [Page 14]
Internet-Draft      I2NSF Capability Interface IM            July 2015

   <packet-based-match> ::= [<packet-header-payload> ...]

                            [<service> ...]

                            [<application> ...]

   <packet-header-payload> ::= [<address-scope>] [<layer-2-header>]

                              [<layer-3-header>] [<layer-4-header>]

                              [<payload>]

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

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

Xia, et al.           Expires January 20, 2016               [Page 15]
Internet-Draft      I2NSF Capability Interface IM            July 2015

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

   <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 January 20, 2016               [Page 16]
Internet-Draft      I2NSF Capability Interface IM            July 2015

   <signature> ::= <server-address> <protocol> <dest-port-num>

                   <flow-direction> <object> <keyword>

   <flow-direction> ::= <request> | <response> | <bidirection>

   <object> ::= <packet> | <flow>

   <context based match> ::= [<user-group> ...] [<session-state>]

                             [<schedule>] [<region-group>]

   <user-group> ::= <user>...

   <user> ::= (<login-name> <group-name> <parent-group> <password>

               <expired-date> <allow-multi-account-login>

               <address-binding>) | <tenant> | <VN-id>

   <session-state> ::= <new> | <established> | <related> | <invalid> |

                       <untracked>

   <schedule> ::= <name> <type> <start-time> <end-time>

                  <weekly-validity-time>

   <type> ::= <once> | <periodic>

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

Xia, et al.           Expires January 20, 2016               [Page 17]
Internet-Draft      I2NSF Capability Interface IM            July 2015

                        [<profile-data-filtering>]

                        [<profile-application-control>]

 5. I2NSF Capability Interface IM Yang Structure

   This section specifies the I2NSF capability interface information
   model in Yang structure [RFC6020].

   module: Security Policies

         +--security-policies

            +--rw policy-set* [policy-name]

               +--rw policy-name string

               +--rw policy-id  uint16

               +--rw security-rules

                   +--rw rule-set* [rule-name]

                     +--rw rule-name  string

                     +--rw rule-id  uint16

                     +--rw Match

                     |  +--rw packet-based-match

                 |  |  +--rw user* [login-name]

                     |  |  |  +--rw login-name string

                     |  |  |  +--rw group-name string

                     |  |  |  +--rw parent-group string

                     |  |  |  +--rw password string

                     |  |  |  +--rw expired-date data-and-time

                     |  |  |  +--rw allow-multi-account-login boolean

Xia, et al.           Expires January 20, 2016               [Page 18]
Internet-Draft      I2NSF Capability Interface IM            July 2015

                     |  |  |  +--rw address-binding Boolean

                     |  |  |  +--rw tenant? uint32

                     |  |  |  +--rw VN-id? uint32

                     |  |  +--rw address*

                     |  |  |  +--rw route-type route-type-def

                     |  |  |  +--rw value

                     |  |  |     +--rw (route-type)?

                     |  |  |        +--:(ipv4)

                     |  |  |        |  ...

                     |  |  |        +--:(ipv6)

                     |  |  |        |  ...

                     |  |  |        +--:(mpls-route)

                     |  |  |        |  ...

                     |  |  |        +--:(mac-route)

                     |  |  |        |  ...

                     |  |  |        +--:(interface-route)

                     |  |  |        |  ...

                 |  |  +--rw layer-header-payload*

                     |  |  |  ...

                     |  |  +--rw service* [name]

                     |  |  |  +--rw name string

                     |  |  |  +--rw id uint16

                     |  |  |  +--rw protocol enumeration

                     |  |  |  +--rw protocol-num uint8

Xia, et al.           Expires January 20, 2016               [Page 19]
Internet-Draft      I2NSF Capability Interface IM            July 2015

                     |  |  |  +--rw src-port-num uint16

                     |  |  |  +--rw dest-port-num uint16

                     |  |  +--rw application* [name]

                     |  |  |  +--rw name string

                     |  |  |  +--rw id uint16

                     |  |  |  +--rw category enumeration

                     |  |  |  +--rw subcategory enumeration

                     |  |  |  +--rw data-transmission-model enumeration

                     |  |  |  +--rw risk-level enumeration

                     |  |  |  +--rw signature

                     |  |  |  |  +--rw server-address inet:ip-address

                     |  |  |  |  +--rw protocol enumeration

                     |  |  |  |  +--rw dest-port-num uint16

                     |  |  |  |  +--rw flow-direction enumeration

                     |  |  |  |  +--rw object enumeration

                     |  |  |  |  +--rw keyword string

                     |  +--rw context-based-match

                     |     +--rw session-state*

                     |     |  ...

                     |     +--rw schedule* [name]

                     |     |  +--rw name string

                     |     |  +--rw type enumeration

                     |     |  +--rw start-time data-and-time

                     |     |  +--rw end-time data-and-time

Xia, et al.           Expires January 20, 2016               [Page 20]
Internet-Draft      I2NSF Capability Interface IM            July 2015

                     |     |  +--rw weekly-validity-time? data-and-time

                 |     +--rw region*

                     |        ...

                   +--rw actions

                      +--rw basic-actions enumeration

                   +--rw advanced-actions* [name]

                      +--rw name string

                         +--rw profile-antivirus?

                         |  ...

                         +--rw profile-IPS?

                         |  ...

                         +--rw profile-url-filtering?

                         |  ...

                         +--rw profile-file-blocking?

                         |  ...

                         +--rw profile-data-filtering?

                         |  ...

                         +--rw profile-application-control?

                         |  ...

 6. Use Examples of I2NSF Capability Interface IM

   TBD

 7. Security Considerations

   TBD

Xia, et al.           Expires January 20, 2016               [Page 21]
Internet-Draft      I2NSF Capability Interface IM            July 2015

 8. IANA Considerations

 9. References

  9.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.

  9.2. Informative References

   [INCITS359 RBAC]   NIST/INCITS, "American National Standard for
             Information Technology - Role Based Access Control",
             INCITS 359, April, 2003

   [I-D.zarny-i2nsf-data-center-use-cases] Zarny, M., et.al., "I2NSF
             Data Center Use Cases", Work in Progress, October 2014.

   [I-D.qi-i2nsf-access-network-usecase] Qi, M., et.al., "Integrated
             Security with Access Network Use Case", Work in Progress,
             October, 2014.

   [I-D.pastor-i2nsf-access-usecases] Pastor, A., et.al., "Access Use
             Cases for an Open OAM Interface to Virtualized Security
             Services", Work in Progress, October, 2014.

   [I-D.dunbar-i2nsf-problem-statement] Dunbar, L., et.al., "Interface
             to Network Security Functions Problem Statement", Work in
             Progress, September, 2014.

   [I-D.xia-i2nsf-service-interface-DM] Xia, L., et.al., "Data Model of
             Interface to Network Security Functions Service Interface",
             February, 2015.

Xia, et al.           Expires January 20, 2016               [Page 22]
Internet-Draft      I2NSF Capability Interface IM            July 2015

   [I-D.lopez-i2nsf-packet] Lopez, E., "Packet-Based Paradigm For
             Interfaces To NSFs", March, 2015.

 10. Acknowledgments

   This document was prepared using 2-Word-v2.0.template.dot.

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 January 20, 2016               [Page 23]