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

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

I2NSF                                                       Liang Xia
Internet Draft                                                 Huawei
Intended status: Standard Track                               D Zhang

Expires: July 2015                                    January 29, 2015

        Information Model of Interface to Network Security Functions
                           Capability Interface

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on July 29,2015.

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

Xia, et al.             Expires July 29, 2015                 [Page 1]

Internet-Draft      I2NSF Capability Interface IM         January 2015

   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.


   This draft is focused on the NBI of NSFs and proposes an information
   model for configuring various kinds NSF security functions. The Yang
   structure and use 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. Rule ................................................... 6
      3.3. Objects ................................................ 7
      3.4. Actions ................................................ 8
   4. I2NSF Capability Interface IM Yang Structure ................ 8
   5. Use Examples of I2NSF Capability Interface IM .............. 11
   6. Security Considerations .................................... 11
   7. IANA Considerations ........................................ 11
   8. References ................................................. 11
      8.1. Normative References .................................. 11
      8.2. Informative References ................................ 12
   9. Acknowledgments ............................................ 12

 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.

   Derived from [I-D.dunbar-i2nsf-problem-statement], it should have
   two types of I2NSF interface to consider:

Xia, et al.             Expires July 29, 2015                 [Page 2]

Internet-Draft      I2NSF Capability Interface IM         January 2015

   o Interface between I2NSF user/client with network controller: [I-
      D.xia-i2nsf-service-interface-IM] 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. This interface is decoupled from
      various kinds of security device and their device-level security
      functions. The intent-based information model approach derived
      from RBAC model may be a feasible choice;

   o North-bound interface (NBI) provided by the network security
      functions (NSFs) (e.g., FW, AAA, IPS, Anti-DOS, Anti-Virus, etc),
      no matter whether the NSFs are Virtual Machines (VM) on servers
      or physical appliances. Any network entities (e.g., I2NSF clients,
      network controller, etc) can use this interface to configure the
      required security functions of NSFs. But, the current situation
      is different NSF vendors have different proprietary interfaces
      and information models to configure their security functions.

   This draft is focused on the NBI of NSFs and proposes an information
   model for configuring various kinds NSF security functions. It's
   called "capability interface" in this draft. It's used for the NSFs
   to decouple from the various security services came from the high
   level applications and highlight on the security capabilities it can
   provide. Section 3 defines the information model for capability
   interface. Section 4 gives its grammar by Yang structure. Section 5
   includes some using examples to clarify how to use the information

 2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC-2119 [RFC2119].

  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

Xia, et al.             Expires July 29, 2015                 [Page 3]

Internet-Draft      I2NSF Capability Interface IM         January 2015

  FW - Firewall

  I2NSF - Interface to Network Security Functions

  INCITS - International Committee for Information Technology

  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

   Similar to the switch and router, NSF realizes the security
   capabilities (e.g., antivirus, IPS, FW, etc) in device-level, not in
   service-level. Although in some condition, they have certain
   service-aware abilities, i.e., application recognition, virus
   detection, etc. In other words, the IM of the capability interface
   should be designed by the way of abstracting from the various
   specific security capabilities to a generic model. Then this IM can
   be used to configure NSF directly or by the translation of the
   adaptor easily in NSF.

   Below is the overall information model for I2NSF capability

Xia, et al.             Expires July 29, 2015                 [Page 4]

Internet-Draft      I2NSF Capability Interface IM         January 2015

                                              |Src/dest |
                                            +-> address |
                                            | |  scope  |
                                            | +---------+
                                            | +---------+
                                            +->  User   |
                 +--------+                 | +---------+
                 |        |                 |
              +-->  Rule  |    +---------+  | +---------+
              |  |        |  +-> Objects +--+-> Service |
              |  +--------+  | +---------+  | +---------+
              |              |              |
              |      *       |              | +-----------+
              |      *       |              +->Application|
              |      *       |              | +-----------+
              |              |              |
   +-------+  |  +--------+  |              | +----------+
   |       |  |  |        |  |              +-> Schedule |
   |Policy +--+-->  Rule  +--+              | +----------+
   |       |  |  |        |  |              |
   +-------+  |  +--------+  |              |            +---------+
              |              |              |   *      +->Antivirus|
              |      *       |              +-> *      | +---------+
              |      *       |                  *      |
              |      *       |                         | +---------+
              |              |                         +->  IPS    |
              |              |                         | +---------+
              |  +--------+  |                         |
              |  |        |  |                         | +----------+
              +-->  Rule  |  |                         +->  URL     |
                 |        |  |                         | | Filtering|
                 +--------+  |               +-------+ | +----------+
                             |             +->Permit +-+
                             | +---------+ | +-------+ | +----------+
                             +-> Actions +-+           +->   File   |
                               +---------+ | +-------+ | | Blocking |
                                           +-> Deny  | | +----------+
                                             +-------+ |
                                                       | +----------+
                                                       | |   Data   |
                                                       +-> Filtering|
                                                       | +----------+
                                                       | +------------+
                                                       | | Application|

Xia, et al.             Expires July 29, 2015                 [Page 5]

Internet-Draft      I2NSF Capability Interface IM         January 2015

                                                       +->   control  |
                                                       | +------------+
                                                       |   *
                                                       +-> *
        Figure 1 The overall Information Model for I2NSF Capability

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

   Each rule uses the classic "match & action" style that already
   implemented in most NSFs today to minimize the needed updates on
   existed NSFs and decrease the complexity.

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

   1. The NSF analyzes traffic and retrieves the attributes, including
      source IP address, destination IP address, service (source port,
      destination port, and protocol type), application and schedule;

   2. The NSF compares the attributes with the conditions of objects
      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 traffic 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
      action over the traffic. If the action is deny, the NSF blocks
      the traffic. If the action is permit, the NSF checks whether
      certain profiles are referenced in the rule. If yes, go to step 4.
      If no, the traffic is permitted;

Xia, et al.             Expires July 29, 2015                 [Page 6]

Internet-Draft      I2NSF Capability Interface IM         January 2015

   4. If certain profiles (e.g., Antivirus, IPS, etc) are referenced in
      the rule and the action defined in the rule is permit, 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 and implements appropriate actions based on the check
      result. If any profile determines to block the traffic, the NSF
      blocks the traffic. If all profiles 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.3. Objects

   Objects include various match conditions representing different
   kinds of objects. 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.

   Some general objects are as follows:

   o Source and destination address scope;

   o User: A user is a person who is authorized to access network
      resources. A user can be a 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 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

   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;

Xia, et al.             Expires July 29, 2015                 [Page 7]

Internet-Draft      I2NSF Capability Interface IM         January 2015

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

   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

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

  3.4. Actions

   The action of a security rule is very simple. It's either permit or
   deny. Deny simple means to block the matching traffics. Permit has
   more meanings by performing the referenced security profiles. The
   all profiles in one rule can inspect traffic content for one-pass,
   which greatly improves system performance.

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

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

 4. I2NSF Capability Interface IM Yang Structure

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

   module: Security Policies


Xia, et al.             Expires July 29, 2015                 [Page 8]

Internet-Draft      I2NSF Capability Interface IM         January 2015

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

                   |     +--rw address-scope*

                   |     |  +--rw src-address inet:ip-prefix

                   |     |  +--rw dst-address inet:ip-prefix

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

                   |     |  +--rw login-name string

                   |     |  +--rw display-name string

                   |     |  +--rw group-name string

                   |     |  +--rw description string

                   |     |  +--rw parent-group string

                   |     |  +--rw password string

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

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

                   |     |  +--rw address-binding boolean

                   |     +--rw service* [name]

                   |     |  +--rw name string

                   |     |  +--rw description string

Xia, et al.             Expires July 29, 2015                 [Page 9]

Internet-Draft      I2NSF Capability Interface IM         January 2015

                   |     |  +--rw protocol enumeration

                   |     |  +--rw protocol-num uint8

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

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

                   |     +--rw application* [name]

                   |     |  +--rw name string

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

                   |     |  +--rw protocol enumeration

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

                   |     |  +--rw category enumeration

                   |     |  +--rw subcategory enumeration

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

                   |     |  +--rw risk-level enumeration

                   |     +--rw schedule* [name]

                   |     |  +--rw name string

                   |     |  +--rw type enumeration

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

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

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

              |  +--rw actions

              |     +--rw action  enumeration

              |     +--rw profile-antivirus?

              |     |  ...

              |     +--rw profile-IPS?

Xia, et al.             Expires July 29, 2015                [Page 10]

Internet-Draft      I2NSF Capability Interface IM         January 2015

              |     |  ...

              |     +--rw profile-url-filtering?

              |     |  ...

              |     +--rw profile-file-blocking?

              |     |  ...

              |     +--rw profile-data-filtering?

              |     |  ...

              |     +--rw profile-application-control?

              |     |  ...

 5. Use Examples of I2NSF Capability Interface IM


 6. Security Considerations


 7. IANA Considerations

 8. References

  8.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

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

Xia, et al.             Expires July 29, 2015                [Page 11]

Internet-Draft      I2NSF Capability Interface IM         January 2015

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

 9. Acknowledgments

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

Authors' Addresses

   Liang Xia
   Email: Frank.xialiang@huawei.com

   DaCheng Zhang
   Email: Dacheng.zdc@alibaba-inc.com

Xia, et al.             Expires July 29, 2015                [Page 12]

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