Skip to main content

I2NSF Network Security Functions-Facing Interface YANG Data Model
draft-kim-i2nsf-nsf-facing-interface-data-model-03

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Jinyong Tim Kim , Jaehoon Paul Jeong , Park Jung-Soo , Susan Hares , Liang Xia
Last updated 2017-10-02 (Latest revision 2017-07-03)
Replaced by draft-ietf-i2nsf-nsf-facing-interface-dm
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-kim-i2nsf-nsf-facing-interface-data-model-03
Network Working Group                                             J. Kim
Internet-Draft                                                  J. Jeong
Intended status: Standards Track                 Sungkyunkwan University
Expires: April 5, 2018                                           J. Park
                                                                    ETRI
                                                                S. Hares
                                                                  L. Xia
                                                                  Huawei
                                                         October 2, 2017

   I2NSF Network Security Functions-Facing Interface YANG Data Model
           draft-kim-i2nsf-nsf-facing-interface-data-model-03

Abstract

   This document defines a YANG data model corresponding to the
   information model for Network Security Functions (NSF)-Facing
   Interface in the Interface to Network Security Functions (I2NSF)
   framework.  It describes a data model for the features provided by
   generic security functions.  This data model provides generic
   components whose vendors is well understood so that the generic
   component can be used even if it has some vendor specific functions.
   These generic functions represent a point of interoperability, and
   can be provided by any product that offers the required capabilities.
   Also, if vendors need additional features for their NSFs, they can
   add the features by extending the YANG data model.

Status of This Memo

   This Internet-Draft is submitted to IETF 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.

Kim, et al.               Expires April 5, 2018                 [Page 1]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

   This Internet-Draft will expire on April 5, 2018.

Copyright Notice

   Copyright (c) 2017 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 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.

Kim, et al.               Expires April 5, 2018                 [Page 2]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Tree Diagrams  . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Objective  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  Policy Identification  . . . . . . . . . . . . . . . . . .  5
     4.2.  Event Policy . . . . . . . . . . . . . . . . . . . . . . .  5
     4.3.  Condition Policy . . . . . . . . . . . . . . . . . . . . .  6
     4.4.  Action Policy  . . . . . . . . . . . . . . . . . . . . . .  6
     4.5.  Resolution Strategy Policy . . . . . . . . . . . . . . . .  6
     4.6.  Default Action Policy  . . . . . . . . . . . . . . . . . .  6
   5.  Data Model Structure . . . . . . . . . . . . . . . . . . . . .  6
     5.1.  Network Security Policy Identification . . . . . . . . . .  7
     5.2.  Event Rule . . . . . . . . . . . . . . . . . . . . . . . .  7
     5.3.  Condition Rule . . . . . . . . . . . . . . . . . . . . . .  9
     5.4.  Action Rule  . . . . . . . . . . . . . . . . . . . . . . . 11
     5.5.  Resolution Strategy Policy . . . . . . . . . . . . . . . . 12
     5.6.  Default Action Policy  . . . . . . . . . . . . . . . . . . 13
   6.  YANG Module  . . . . . . . . . . . . . . . . . . . . . . . . . 14
     6.1.  IETF NSF-Facing Interface YANG Data Module . . . . . . . . 14
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 46
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 46
   9.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 46
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 46
     10.2. Informative References . . . . . . . . . . . . . . . . . . 47
   Appendix A.  Example: Extended VoIP-VoLTE Security Function
                Module  . . . . . . . . . . . . . . . . . . . . . . . 47
   Appendix B.  Example: XML Configuration of NSF-Facing
                Interface Module  . . . . . . . . . . . . . . . . . . 48
     B.1.  Example: XML Configuration of Generic Network Security
           Function . . . . . . . . . . . . . . . . . . . . . . . . . 49
     B.2.  Example: XML Configuration of Extended VoIP-VoLTE
           Security Function Module . . . . . . . . . . . . . . . . . 51
   Appendix C.  draft-kim-i2nsf-nsf-facing-interface-data-model-02  . 51

Kim, et al.               Expires April 5, 2018                 [Page 3]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

1.  Introduction

   This document defines a YANG [RFC6020] data model for the
   configuration of security services provided by Network Security
   Functions (NSF)-Facing Interface in the Interface to Network Security
   Functions (I2NSF) framework [i2nsf-framework].  It provides the
   corresponding data model for an information model of NSF-facing
   interface for generic NSFs, as defined in [i2nsf-nsf-cap-im].  With
   this data model, Security Controller can configure and control the
   capabilities of NSFs [i2nsf-framework].

   The "Event-Condition-Action" (ECA) policy model is used as the basis
   for the design of I2NSF policy rules.

   The "ietf-i2nsf-nsf-facing-interface" YANG module defined in this
   document provides the following features:

   o  Configuration of an identification for a generic NSF policy

   o  Configuration of an event for a generic NSF policy

   o  Configuration of a condition for a generic NSF policy

   o  Configuration of an action for a generic NSF policy

   o  Configuration of a strategy for a generic NSF policy

   o  Configuration of a default action for a generic NSF policy

2.  Requirements Language

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

3.  Terminology

   This document uses the terminology described in
   [i2nsf-nsf-cap-im][i2rs-rib-data-model][supa-policy-info-model].
   Especially, the following terms are from [supa-policy-info-model]:

   o  Data Model: A data model is a representation of concepts of
      interest to an environment in a form that is dependent on data
      repository, data definition language, query language,
      implementation language, and protocol.

   o  Information Model: An information model is a representation of
      concepts of interest to an environment in a form that is

Kim, et al.               Expires April 5, 2018                 [Page 4]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

      independent of data repository, data definition language, query
      language, implementation language, and protocol.

3.1.  Tree Diagrams

   A simplified graphical representation of the data model is used in
   this document.  The meaning of the symbols in these diagrams
   [i2rs-rib-data-model] is as follows:

   o  Brackets "[" and "]" enclose list keys.

   o  Abbreviations before data node names: "rw" means configuration
      (read-write) and "ro" state data (read-only).

   o  Symbols after data node names: "?" means an optional node and "*"
      denotes a "list" and "leaf-list".

   o  Parentheses enclose choice and case nodes, and case nodes are also
      marked with a colon (":").

   o  Ellipsis ("...") stands for contents of subtrees that are not
      shown.

4.  Objective

   This section explains the objective of policy identification, event
   policy, condition policy, action policy, resolution strategy policy,
   and default action policy.  The policies of event, condition, action,
   resolution strategy, and default action are defined in
   [i2nsf-nsf-cap-im].

4.1.  Policy Identification

   This subsection explains the identification of a policy for a generic
   NSF.  Objects are defined for policy information and rule
   information.

4.2.  Event Policy

   This subsection explains an event policy for a generic NSF.  An event
   capability is used to specify the capability about an event in a
   managed system or the environment of the system.  When used in the
   context of I2NSF policy rules, it is used to determine whether the
   condition clause of an I2NSF policy rule can be evaluated or not.
   Objects are defined for a user security event, device security event,
   system security event, and time security event.  These objects can be
   extended according to specific vendor event features.

Kim, et al.               Expires April 5, 2018                 [Page 5]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

4.3.  Condition Policy

   This subsection explains a condition policy for a generic NSF.  A
   condition is used to specify a policy with a set of attributes,
   features, and values that are to be compared with a set of known
   attributes, features, and values in order to determine whether or not
   the set of actions in an imperative I2NSF policy rule can be executed
   or not.  Objects are defined for packet security condition, packet
   payload security condition, target security condition, user security
   condition, context condition, and generic context condition.  These
   objects can be extended according to specific vendor condition
   features.

4.4.  Action Policy

   This subsection explains an action policy for a generic NSF.  An
   action is used to specify the policy to control and monitor aspects
   of flow-based NSFs when the event and condition clauses are
   satisfied.  NSFs provide security functions by executing various
   actions.  Objects are defined for an ingress action, egress action,
   and apply-profile (i.e., advanced action) action.  These objects can
   be extended according to specific vendor action features.

4.5.  Resolution Strategy Policy

   This subsection explains a resolution strategy policy for a generic
   NSF.  A resolution strategy policy can be used to specify a policy of
   how to resolve policy rule conflicts that may occur among the actions
   of the same or different policy rules that are matched and contained
   in a particular NSF.  Objects are defined for the first-matching-rule
   policy and last-matching-rule policy.  These objects can be extended
   according to specific vendor resolution strategy features.

4.6.  Default Action Policy

   This subsection explains a default action policy for a generic NSF.
   A default action policy can be used to specify a policy about a
   predefined action when no other alternative action was matched by the
   currently executed I2NSF policy rule.

5.  Data Model Structure

   This section shows the overview of a structure tree of generic NSFs
   defined in the [i2nsf-nsf-cap-im].

Kim, et al.               Expires April 5, 2018                 [Page 6]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

5.1.  Network Security Policy Identification

   The data model for the identification of a network security policy
   has the following structure:

   module: ietf-i2nsf-nsf-facing-interface
   +--rw generic-nsf
      +--rw net-sec-policy* [policy-name]
         +--rw policy-name            string
         +--rw time-zone
         |  +--rw start-time?   yang:date-and-time
         |  +--rw end-time?     yang:date-and-time
         +--rw eca-policy-rules* [rule-id]
         |  +--rw rule-id             uint8
         |  +--rw rule-description?   string
         |  +--rw rule-rev?           uint8
         |  +--rw rule-priority?      uint8
         |  +--rw event
         |  |  ...
         |  +--rw condition
         |  |  ...
         |  +--rw action
         |     ...
         +--rw resolution-strategy
         |  ...
         +--rw default-action
            ...

        Figure 1: Data Model Structure for Network Security Policy
                              Identification

5.2.  Event Rule

   The data model for an event rule has the following structure:

Kim, et al.               Expires April 5, 2018                 [Page 7]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

 module: ietf-i2nsf-nsf-facing-interface
 +--rw generic-nsf
    +--rw net-sec-policy* [policy-name]
       ...
       +--rw eca-policy-rules* [rule-id]
       |  ...
       |  +--rw event
       |  |  +--rw (event-type)?
       |  |     +--:(usr-event)
       |  |     |  +--rw usr-manual?                    string
       |  |     |  +--rw usr-sec-event-content          string
       |  |     |  +--rw usr-sec-event-format           sec-event-format
       |  |     |  +--rw usr-sec-event-type             enumeration
       |  |     +--:(dev-event)
       |  |     |  +--rw dev-manual?                    string
       |  |     |  +--rw dev-sec-event-content          string
       |  |     |  +--rw dev-sec-event-format           sec-event-format
       |  |     |  +--rw dev-sec-event-type             enumeration
       |  |     |  +--rw dev-sec-event-type-severity    enumeration
       |  |     +--:(sys-event)
       |  |     |  +--rw sys-manual?                    string
       |  |     |  +--rw sys-sec-event-content          string
       |  |     |  +--rw sys-sec-event-format           sec-event-format
       |  |     |  +--rw sys-sec-event-type             enumeration
       |  |     +--:(time-event)
       |  |        +--rw time-manual?                   string
       |  |        +--rw time-sec-event-begin    yang:date-and-time
       |  |        +--rw time-sec-event-end      yang:date-and-time
       |  |        +--rw time-sec-event-time-zone       string
       |  +--rw condition
       |  |  ...
       |  +--rw action
       |     ...
       +--rw resolution-strategy
       |  ...
       +--rw default-action
          ...

               Figure 2: Data Model Structure for Event Rule

   Objects are defined for a user security event, device security event,
   system security event, and time security event.  These objects can be
   extended according to specific vendor event features.  We will add
   additional event objects for more generic network security functions.

Kim, et al.               Expires April 5, 2018                 [Page 8]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

5.3.  Condition Rule

   The data model for a condition rule has the following structure:

module: ietf-i2nsf-nsf-facing-interface
+--rw generic-nsf
   +--rw net-sec-policy* [policy-name]
      ...
      +--rw eca-policy-rules* [rule-id]
      |  ...
      |  +--rw event
      |  |  ...
      |  +--rw condition
      |  |  +--rw (condition-type)?
      |  |     +--:(packet-security-condition)
      |  |     |  +--rw packet-manual?                    string
      |  |     |  +--rw packet-security-mac-condition
      |  |     |  |  +--rw pkt-sec-cond-mac-dest*      yang:phys-address
      |  |     |  |  +--rw pkt-sec-cond-mac-src*       yang:phys-address
      |  |     |  |  +--rw pkt-sec-cond-mac-8021q*        string
      |  |     |  |  +--rw pkt-sec-cond-mac-ether-type*   string
      |  |     |  |  +--rw pkt-sec-cond-mac-tci*          string
      |  |     |  +--rw packet-security-ipv4-condition
      |  |     |  |  +--rw pkt-sec-cond-ipv4-header-length*     uint8
      |  |     |  |  +--rw pkt-sec-cond-ipv4-tos*               uint8
      |  |     |  |  +--rw pkt-sec-cond-ipv4-total-length*      uint16
      |  |     |  |  +--rw pkt-sec-cond-ipv4-id*                uint8
      |  |     |  |  +--rw pkt-sec-cond-ipv4-fragment*          uint8
      |  |     |  |  +--rw pkt-sec-cond-ipv4-fragment-offset*   uint16
      |  |     |  |  +--rw pkt-sec-cond-ipv4-ttl*               uint8
      |  |     |  |  +--rw pkt-sec-cond-ipv4-protocol*          uint8
      |  |     |  |  +--rw pkt-sec-cond-ipv4-src*      inet:ipv4-address
      |  |     |  |  +--rw pkt-sec-cond-ipv4-dest*     inet:ipv4-address
      |  |     |  |  +--rw pkt-sec-cond-ipv4-ipopts?            string
      |  |     |  |  +--rw pkt-sec-cond-ipv4-sameip?            boolean
      |  |     |  |  +--rw pkt-sec-cond-ipv4-geoip*             string
      |  |     |  +--rw packet-security-ipv6-condition
      |  |     |  |  +--rw pkt-sec-cond-ipv6-dscp*             string
      |  |     |  |  +--rw pkt-sec-cond-ipv6-ecn*              string
      |  |     |  |  +--rw pkt-sec-cond-ipv6-traffic-class*    uint8
      |  |     |  |  +--rw pkt-sec-cond-ipv6-flow-label*       uint32
      |  |     |  |  +--rw pkt-sec-cond-ipv6-payload-length*   uint16
      |  |     |  |  +--rw pkt-sec-cond-ipv6-next-header*      uint8
      |  |     |  |  +--rw pkt-sec-cond-ipv6-hop-limit*        uint8
      |  |     |  |  +--rw pkt-sec-cond-ipv6-src*      inet:ipv6-address
      |  |     |  |  +--rw pkt-sec-cond-ipv6-dest*     inet:ipv6-address
      |  |     |  +--rw packet-security-tcp-condition
      |  |     |  |  +--rw pkt-sec-cond-tcp-seq-num*       uint32

Kim, et al.               Expires April 5, 2018                 [Page 9]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

      |  |     |  |  +--rw pkt-sec-cond-tcp-ack-num*       uint32
      |  |     |  |  +--rw pkt-sec-cond-tcp-window-size*   uint16
      |  |     |  |  +--rw pkt-sec-cond-tcp-flags*         uint8
      |  |     |  +--rw packet-security-udp-condition
      |  |     |  |  +--rw pkt-sec-cond-udp-length*   string
      |  |     |  +--rw packet-security-icmp-condition
      |  |     |     +--rw pkt-sec-cond-icmp-type*      uint8
      |  |     |     +--rw pkt-sec-cond-icmp-code*      uint8
      |  |     |     +--rw pkt-sec-cond-icmp-seg-num*   uint32
      |  |     +--:(packet-payload-condition)
      |  |     |  +--rw packet-payload-manual?            string
      |  |     |  +--rw pkt-payload-content*              string
      |  |     +--:(target-condition)
      |  |     |  +--rw target-manual?                    string
      |  |     |  +--rw device-sec-context-cond
      |  |     |     +--rw pc?                 boolean
      |  |     |     +--rw mobile-phone?       boolean
      |  |     |     +--rw voip-volte-phone?   boolean
      |  |     |     +--rw tablet?             boolean
      |  |     |     +--rw iot?                boolean
      |  |     |     +--rw vehicle?            boolean
      |  |     +--:(users-condition)
      |  |     |  +--rw users-manual?                     string
      |  |     |  +--rw user
      |  |     |  |  +--rw (user-name)?
      |  |     |  |     +--:(tenant)
      |  |     |  |     |  +--rw tenant    uint8
      |  |     |  |     +--:(vn-id)
      |  |     |  |        +--rw vn-id     uint8
      |  |     |  +--rw group
      |  |     |     +--rw (group-name)?
      |  |     |        +--:(tenant)
      |  |     |        |  +--rw tenant    uint8
      |  |     |        +--:(vn-id)
      |  |     |           +--rw vn-id     uint8
      |  |     +--:(context-condition)
      |  |     |  +--rw context-manual?                   string
      |  |     +--:(gen-context-condition)
      |  |        +--rw gen-context-manual?               string
      |  |        +--rw geographic-location
      |  |           +--rw src-geographic-location*    uint32
      |  |           +--rw dest-geographic-location*   uint32
      |  +--rw action
      |     ...
      +--rw resolution-strategy
      |  ...
      +--rw default-action
         ...

Kim, et al.               Expires April 5, 2018                [Page 10]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

             Figure 3: Data Model Structure for Condition Rule

   Objects are defined for a packet security condition, packet payload
   security condition, target security condition, user security
   condition, context condition, and generic context condition.  These
   objects can be extended according to specific vendor condition
   features.  We will add additional condition objects for more generic
   network security functions.

5.4.  Action Rule

   The data model for an action rule has the following structure:

module: ietf-i2nsf-nsf-facing-interface
+--rw generic-nsf
   +--rw net-sec-policy* [policy-name]
      ...
      +--rw eca-policy-rules* [rule-id]
      |  ...
      |  +--rw event
      |  |  ...
      |  +--rw condition
      |  |  ...
      |  +--rw action
      |     +--rw (action-type)?
      |        +--:(ingress-action)
      |        |  +--rw ingress-manual?                   string
      |        |  +--rw ingress-action-type?              ingress-action
      |        +--:(egress-action)
      |        |  +--rw egress-manual?                    string
      |        |  +--rw egress-action-type?               egress-action
      |        +--:(apply-profile)
      |           +--rw profile-manual?                   string
      |           +--rw (apply-profile-action-type)?
      |              +--:(content-security-control)
      |              |  +--rw content-security-control-types
      |              |     +--rw antivirus?             boolean
      |              |     +--rw ips?                   boolean
      |              |     +--rw ids?                   boolean
      |              |     +--rw url-filtering?         boolean
      |              |     +--rw data-filtering?        boolean
      |              |     +--rw mail-filtering?        boolean
      |              |     +--rw file-blocking?         boolean
      |              |     +--rw file-isolate?          boolean
      |              |     +--rw pkt-capture?           boolean
      |              |     +--rw application-control?   boolean
      |              |     +--rw voip-volte?            boolean
      |              +--:(attack-mitigation-control)

Kim, et al.               Expires April 5, 2018                [Page 11]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

      |                 +--rw (attack-mitigation-control-type)?
      |                    +--:(ddos-attack)
      |                    |  +--rw ddos-attack-type
      |                    |     +--rw network-layer-ddos-attack
      |                    |     |  +--rw network-layer-ddos-attack-type
      |                    |     |     +--rw syn-flood?       boolean
      |                    |     |     +--rw udp-flood?       boolean
      |                    |     |     +--rw icmp-flood?      boolean
      |                    |     |     +--rw ip-frag-flood?   boolean
      |                    |     |     +--rw ipv6-related?    boolean
      |                    |     +--rw app-layer-ddos-attack
      |                    |        +--rw app-ddos-attack-types
      |                    |           +--rw http-flood?      boolean
      |                    |           +--rw https-flood?     boolean
      |                    |           +--rw dns-flood?       boolean
      |                    |           +--rw dns-amp-flood?   boolean
      |                    |           +--rw ssl-ddos?        boolean
      |                    +--:(single-packet-attack)
      |                       +--rw single-packet-attack-type
      |                          +--rw scan-and-sniff-attack
      |                          |  +--rw scan-and-sniff-attack-types
      |                          |     +--rw ip-sweep?        boolean
      |                          |     +--rw port-scanning?   boolean
      |                          +--rw malformed-packet-attack
      |                          |  +--rw malformed-packet-attack-types
      |                          |     +--rw ping-of-death?   boolean
      |                          |     +--rw teardrop?        boolean
      |                          +--rw special-packet-attack
      |                             +--rw special-packet-attack-types
      |                                +--rw oversized-icmp?   boolean
      |                                +--rw tracert?          boolean
      +--rw resolution-strategy
      |  ...
      +--rw default-action
         ...

              Figure 4: Data Model Structure for Action Rule

   Objects are defined for an ingress action, egress action, and apply
   profile action.  These objects can be extended according to specific
   vendor action feature.  We will add additional action objects for
   more generic network security functions.

5.5.  Resolution Strategy Policy

   The data model for a resolution strategy policy has the following
   structure:

Kim, et al.               Expires April 5, 2018                [Page 12]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

   module: ietf-i2nsf-nsf-facing-interface
   +--rw generic-nsf
      +--rw net-sec-policy* [policy-name]
         ...
         +--rw eca-policy-rules* [rule-id]
         |  ...
         |  +--rw event
         |  |  ...
         |  +--rw condition
         |  |  ...
         |  +--rw action
         |     ...
         +--rw resolution-strategy
         |  +--rw (resolution-strategy-type)?
         |     +--:(fmr)
         |     |  +--rw first-matching-rule?   boolean
         |     +--:(lmr)
         |        +--rw last-matching-rule?    boolean
         +--rw default-action
                ...

       Figure 5: Data Model Structure for Resolution Strategy Policy

   Objects are defined for the first-matching-rule and last-matching-
   rule policy.  These objects can be extended according to specific
   vendor resolution strategy features.  We will add additional
   resolution strategy objects for more generic network security
   functions.

5.6.  Default Action Policy

   The data model for a default action policy has the following
   structure:

Kim, et al.               Expires April 5, 2018                [Page 13]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

   module: ietf-i2nsf-nsf-facing-interface
   +--rw generic-nsf
      +--rw net-sec-policy* [policy-name]
         ...
         +--rw eca-policy-rules* [rule-id]
         |  ...
         |  +--rw event
         |  |  ...
         |  +--rw condition
         |  |  ...
         |  +--rw action
         |     ...
         +--rw resolution-strategy
         |  ...
         +--rw default-action
            +--rw default-action-type?   ingress-action

         Figure 6: Data Model Structure for Default Action Policy

6.  YANG Module

6.1.  IETF NSF-Facing Interface YANG Data Module

   This section introduces a YANG module for the information model of
   network security functions, as defined in the [i2nsf-nsf-cap-im].

<CODE BEGINS> file "ietf-i2nsf-nsf-facing-interface@2017-10-02.yang"

module ietf-i2nsf-nsf-facing-interface {
  namespace
    "urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-facing-interface";
  prefix
    nsf-facing-interface;

  import ietf-inet-types{
    prefix inet;
  }
  import ietf-yang-types{
    prefix yang;
  }

  organization
    "IETF I2NSF (Interface to Network Security Functions)
     Working Group";

  contact
    "WG Web: <http://tools.ietf.org/wg/i2nsf>
     WG List: <mailto:i2nsf@ietf.org>

Kim, et al.               Expires April 5, 2018                [Page 14]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

     WG Chair: Adrian Farrel
     <mailto:Adrain@olddog.co.uk>

     WG Chair: Linda Dunbar
     <mailto:Linda.duhbar@huawei.com>

     Editor: Jingyong Tim Kim
     <mailto:timkim@skku.edu>

     Editor: Jaehoon Paul Jeong
     <mailto:pauljeong@skku.edu>

     Editor: Susan Hares
     <mailto:shares@ndzh.com>";

  description
    "This module defines a YANG data module for network security
     functions.";
    revision "2017-10-02"{
    description "The first version";
    reference
      "draft-ietf-i2nsf-capability-00";
  }

  typedef sec-event-format {
      type enumeration {
        enum unknown {
            description
              "If SecEventFormat is unknown";
        }
        enum guid {
            description
              "If SecEventFormat is GUID
              (Generic Unique IDentifier)";
        }
        enum uuid {
            description
              "If SecEventFormat is UUID
              (Universal Unique IDentifier)";
        }
        enum uri {
            description
              "If SecEventFormat is URI
              (Uniform Resource Identifier)";
        }
        enum fqdn {
            description
              "If SecEventFormat is FQDN

Kim, et al.               Expires April 5, 2018                [Page 15]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

              (Fully Qualified Domain Name)";
        }
        enum fqpn {
            description
              "If SecEventFormat is FQPN
              (Fully Qualified Path Name)";
        }
      }
      description
        "This is used for SecEventFormat.";
  }

  typedef ingress-action {
      type enumeration {
        enum pass {
            description
              "If ingress action is pass";
        }
        enum drop {
            description
              "If ingress action is drop";
        }
        enum reject {
            description
              "If ingress action is reject";
        }
        enum alert {
            description
              "If ingress action is alert";
        }
        enum mirror {
            description
              "If ingress action is mirror";
        }
      }
      description
        "This is used for ingress action.";
  }

  typedef egress-action {
      type enumeration {
        enum invoke-signaling {
            description
              "If egress action is invoke signaling";
        }
        enum tunnel-encapsulation {
            description
              "If egress action is tunnel encapsulation";

Kim, et al.               Expires April 5, 2018                [Page 16]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

        }
        enum forwarding {
            description
              "If egress action is forwarding";
        }
        enum redirection {
            description
              "If egress action is redirection";
        }
      }
      description
        "This is used for egress action.";
  }

 container generic-nsf {
  description
    "Configuration for Generic Network Security Functions.";

  list net-sec-policy {
    key "policy-name";
    description
      "policy is a list
       including a set of security rules according to certain logic,
       i.e., their similarity or mutual relations, etc. The network
       security policy is able to apply over both the unidirectional
       and bidirectional traffic across the NSF.";

      leaf policy-name {
        type string;
        mandatory true;
        description
          "The name of the policy.
           This must be unique.";
      }
      container time-zone {
        description
          "This can be used to apply rules according to time";
        leaf start-time {
          type yang:date-and-time;
          description
            "This is start time for time zone";
        }
        leaf end-time {
          type yang:date-and-time;
          description

Kim, et al.               Expires April 5, 2018                [Page 17]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

            "This is end time for time zone";
        }
      }

      list eca-policy-rules {
        key "rule-id";
        description
          "This is a rule for network security functions.";

        leaf rule-id {
          type uint8;
          mandatory true;
          description
            "The id of the rule.
             This must be unique.";
        }

        leaf rule-description {
          type string;
          description
            "This description gives more information about
             rules.";
        }

        leaf rule-rev {
          type uint8;
          description
            "This shows rule version.";
        }

        leaf rule-priority {
          type uint8;
          description
            "The priority keyword comes with a mandatory
             numeric value which can range from 1 till 255.";
        }

        container event {
          description
            " This is abstract. 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

Kim, et al.               Expires April 5, 2018                [Page 18]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

              violate any ACL.).";

          choice event-type {
            description
              "Vendors can use YANG data model to configure rules
              by concreting this event type";
            case usr-event {
              leaf usr-manual {
                type string;
                description
                  "This is manual for user event.
                  Vendors can write instructions for user event
                  that vendor made";
              }

              leaf usr-sec-event-content {
                type string;
                mandatory true;
                description
                 "This is a mandatory string that contains the content
                  of the UserSecurityEvent. The format of the content
                  is specified in the usrSecEventFormat class
                  attribute, and the type of event is defined in the
                  usrSecEventType class attribute. An example of the
                  usrSecEventContent attribute is a string hrAdmin,
                  with the usrSecEventFormat set to 1 (GUID) and the
                  usrSecEventType attribute set to 5 (new logon).";
              }

              leaf usr-sec-event-format {
                type sec-event-format;
                mandatory true;
                description
                 "This is a mandatory uint 8 enumerated integer, which
                  is used to specify the data type of the
                  usrSecEventContent attribute. The content is
                  specified in the usrSecEventContent class attribute,
                  and the type of event is defined in the
                  usrSecEventType class attribute. An example of the
                  usrSecEventContent attribute is string hrAdmin,
                  with the usrSecEventFormat attribute set to 1 (GUID)
                  and the usrSecEventType attribute set to 5
                  (new logon).";
              }

              leaf usr-sec-event-type {
                type enumeration {

Kim, et al.               Expires April 5, 2018                [Page 19]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

                    enum unknown {
                        description
                          "If usrSecEventType is unknown";
                    }
                    enum user-created {
                        description
                          "If usrSecEventType is new user
                          created";
                    }
                    enum user-grp-created {
                        description
                          "If usrSecEventType is new user
                          group created";
                    }
                    enum user-deleted {
                        description
                          "If usrSecEventType is user
                          deleted";
                    }
                    enum user-grp-deleted {
                        description
                          "If usrSecEventType is user
                          group deleted";
                    }
                    enum user-logon {
                        description
                          "If usrSecEventType is user
                          logon";
                    }
                    enum user-logoff {
                        description
                          "If usrSecEventType is user
                          logoff";
                    }
                    enum user-access-request {
                        description
                          "If usrSecEventType is user
                          access request";
                    }
                    enum user-access-granted {
                        description
                          "If usrSecEventType is user
                          granted";
                    }
                    enum user-access-violation {
                        description
                          "If usrSecEventType is user
                          violation";

Kim, et al.               Expires April 5, 2018                [Page 20]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

                    }
                }
                mandatory true;
                description
                 "This is a mandatory uint 8 enumerated integer, which
                  is used to specify the type of event that involves
                  this user. The content and format are specified in
                  the usrSecEventContent and usrSecEventFormat class
                  attributes, respectively. An example of the
                  usrSecEventContent attribute is string hrAdmin,
                  with the usrSecEventFormat attribute set to 1 (GUID)
                  and the usrSecEventType attribute set to 5
                 (new logon).";
              }

            }
            case dev-event {
              leaf dev-manual {
                type string;
                description
                  "This is manual for device event.
                  Vendors can write instructions for device event
                  that vendor made";
              }

              leaf dev-sec-event-content {
                type string;
                mandatory true;
                description
                 "This is a mandatory string that contains the content
                  of the DeviceSecurityEvent. The format of the
                  content is specified in the devSecEventFormat class
                  attribute, and the type of event is defined in the
                  devSecEventType class attribute. An example of the
                  devSecEventContent attribute is alarm, with the
                  devSecEventFormat attribute set to 1 (GUID), the
                  devSecEventType attribute set to 5 (new logon).";
              }

              leaf dev-sec-event-format {
                type sec-event-format;
                mandatory true;
                description
                 "This is a mandatory uint 8 enumerated integer,
                  which is used to specify the data type of the
                  devSecEventContent attribute.";
              }

Kim, et al.               Expires April 5, 2018                [Page 21]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

                leaf dev-sec-event-type {
                  type enumeration {
              enum unknown {
                  description
                    "If devSecEventType is unknown";
              }
              enum comm-alarm {
                  description
                    "If devSecEventType is communications
                    alarm";
              }
              enum quality-of-service-alarm {
                  description
                    "If devSecEventType is quality of service
                    alarm";
              }
              enum process-err-alarm {
                  description
                    "If devSecEventType is processing error
                    alarm";
              }
              enum equipment-err-alarm {
                  description
                    "If devSecEventType is equipment error
                    alarm";
              }
              enum environmental-err-alarm {
                  description
                    "If devSecEventType is environmental error
                    alarm";
              }
                  }
                  mandatory true;
                  description
                   "This is a mandatory uint 8 enumerated integer,
                    which is used to specify the type of event
                    that was generated by this device.";
                }

                leaf dev-sec-event-type-severity {
                  type enumeration {
                      enum unknown {
                          description
                            "If devSecEventType is unknown";
                      }
                      enum cleared {
                          description
                            "If devSecEventTypeSeverity is cleared";

Kim, et al.               Expires April 5, 2018                [Page 22]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

                      }
                      enum indeterminate {
                          description
                            "If devSecEventTypeSeverity is
                            indeterminate";
                      }
                      enum critical {
                          description
                            "If devSecEventTypeSeverity is critical";
                      }
                      enum major{
                          description
                            "If devSecEventTypeSeverity is major";
                      }
                      enum minor {
                          description
                            "If devSecEventTypeSeverity is minor";
                      }
                      enum warning {
                          description
                            "If devSecEventTypeSeverity is warning";
                      }

                  }
                  mandatory true;
                  description
                   "This is a mandatory uint 8 enumerated integer,
                    which is used to specify the perceived
                    severity of the event generated by this
                    Device.";
                }

              }
              case sys-event {
                leaf sys-manual {
                  type string;
                  description
                    "This is manual for system event.
                    Vendors can write instructions for system event
                    that vendor made";
                }

                leaf sys-sec-event-content {
                  type string;
                  mandatory true;
                  description
                   "This is a mandatory string that contains a content
                    of the SystemSecurityEvent. The format of a content

Kim, et al.               Expires April 5, 2018                [Page 23]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

                    is specified in a sysSecEventFormat class attribute,
                    and the type of event is defined in the
                    sysSecEventType class attribute. An example of the
                    sysSecEventContent attribute is string sysadmin3,
                    with the sysSecEventFormat attribute set to 1(GUID),
                    and the sysSecEventType attribute set to 2
                    (audit log cleared).";
                }

                leaf sys-sec-event-format {
                  type sec-event-format;
                  mandatory true;
                  description
                   "This is a mandatory uint 8 enumerated integer, which
                    is used to specify the data type of the
                    sysSecEventContent attribute.";
                }

                leaf sys-sec-event-type {
                  type enumeration {
                      enum unknown {
                          description
                            "If sysSecEventType is unknown";
                      }
                      enum audit-log-written-to {
                          description
                          "If sysSecEventTypeSeverity
                           is that audit log is written to";
                      }
                      enum audit-log-cleared {
                          description
                          "If sysSecEventTypeSeverity
                           is that audit log is cleared";
                      }
                      enum policy-created {
                          description
                          "If sysSecEventTypeSeverity
                           is that policy is created";
                      }
                      enum policy-edited{
                          description
                          "If sysSecEventTypeSeverity
                           is that policy is edited";
                      }
                      enum policy-deleted{
                          description
                          "If sysSecEventTypeSeverity
                           is that policy is deleted";

Kim, et al.               Expires April 5, 2018                [Page 24]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

                      }
                      enum policy-executed{
                          description
                          "If sysSecEventTypeSeverity
                           is that policy is executed";
                      }
                }
                  mandatory true;
                  description
                   "This is a mandatory uint 8 enumerated integer, which
                    is used to specify the type of event that involves
                    this device.";
                }

              }
              case time-event {
                leaf time-manual {
                  type string;
                  description
                    "This is manual for time event.
                    Vendors can write instructions for time event
                    that vendor made";
                }
                leaf time-sec-event-begin {
                  type yang:date-and-time;
                  mandatory true;
                  description
                    "This is a mandatory DateTime attribute, and
                    represents the beginning of a time period.
                    It has a value that has a date and/or a time
                    component (as in the Java or Python libraries).";
                }

                leaf time-sec-event-end {
                  type yang:date-and-time;
                  mandatory true;
                  description
                    "This is a mandatory DateTime attribute, and
                     represents the end of a time period. It has
                     a value that has a date and/or a time component
                     (as in the Java or Python libraries). If this is
                     a single event occurrence, and not a time period
                     when the event can occur, then the
                     timeSecEventPeriodEnd attribute may be ignored.";
                }

                leaf time-sec-event-time-zone {
                  type string;

Kim, et al.               Expires April 5, 2018                [Page 25]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

                  mandatory true;
                  description
                    "This is a mandatory string attribute, and defines a
                     time zone that this event occurred in using the
                     format specified in ISO8601.";
                }
              }
            }

          }

          container condition {
            description
              " This is abstract.  A condition is defined as 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 determine whether or not the
              set of Actions in that (imperative) I2NSF Policy Rule
              can be executed or not. Examples of I2NSF Conditions
              include matching attributes of a packet or flow, and
              comparing the internal state of an NSF to a desired
              state.";

            choice condition-type {
              description
                "Vendors can use YANG data model to configure rules
                by concreting this condition type";

              case packet-security-condition {
                leaf packet-manual {
                  type string;
                  description
                    "This is manual for packet condition.
                    Vendors can write instructions for packet condition
                    that vendor made";
                }

                container packet-security-mac-condition {
                  description
                   "The purpose of this Class is to represent packet MAC
                   packet header information that can be used as part of
                   a test to determine if the set of Policy Actions in
                   this ECA Policy Rule should be execute or not.";

                  leaf-list pkt-sec-cond-mac-dest {
                    type yang:phys-address;
                    description
                      "The MAC destination address (6 octets long).";

Kim, et al.               Expires April 5, 2018                [Page 26]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

                  }

                  leaf-list pkt-sec-cond-mac-src {
                    type yang:phys-address;
                    description
                      "The MAC source address (6 octets long).";
                  }

                  leaf-list pkt-sec-cond-mac-8021q {
                    type string;
                    description
                      "This is an optional string attribute, and defines
                       The 802.1Q tab value (2 octets long).";
                  }

                  leaf-list pkt-sec-cond-mac-ether-type {
                    type string;
                    description
                      "The EtherType field (2 octets long). Values up to
                       and including 1500 indicate the size of the
                       payload in octets; values of 1536 and above
                       define which protocol is encapsulated in the
                       payload of the frame.";
                  }

                  leaf-list pkt-sec-cond-mac-tci {
                    type string;
                    description
                     "This is an optional string attribute, and defines
                      the Tag Control Information. This consists of a 3
                      bit user priority field, a drop eligible indicator
                      (1 bit), and a VLAN identifier (12 bits).";
                  }
                }

                container packet-security-ipv4-condition {
                  description
                    "The purpose of this Class is to represent IPv4
                     packet header information that can be used as
                     part of a test to determine if the set of Policy
                     Actions in this ECA Policy Rule should be executed
                     or not.";

                  leaf-list pkt-sec-cond-ipv4-header-length {
                    type uint8;
                    description
                      "The IPv4 packet header consists of 14 fields,
                       of which 13 are required.";

Kim, et al.               Expires April 5, 2018                [Page 27]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

                  }

                  leaf-list pkt-sec-cond-ipv4-tos {
                    type uint8;
                    description
                      "The ToS field could specify a datagram's priority
                       and request a route for low-delay,
                       high-throughput, or highly-reliable service..";
                  }

                  leaf-list pkt-sec-cond-ipv4-total-length {
                    type uint16;
                    description
                      "This 16-bit field defines the entire packet size,
                       including header and data, in bytes.";
                  }

                  leaf-list pkt-sec-cond-ipv4-id {
                    type uint8;
                    description
                      "This field is an identification field and is
                       primarily used for uniquely identifying
                       the group of fragments of a single IP datagram.";
                  }

                  leaf-list pkt-sec-cond-ipv4-fragment {
                    type uint8;
                    description
                      "IP fragmentation is an Internet Protocol (IP)
                       process that breaks datagrams into smaller pieces
                       (fragments), so that packets may be formed that
                       can pass through a link with a smaller maximum
                       transmission unit (MTU) than the original
                       datagram size.";
                  }

                  leaf-list pkt-sec-cond-ipv4-fragment-offset {
                    type uint16;
                    description
                      "Fragment offset field along with Don't Fragment
                       and More Fragment flags in the IP protocol
                       header are used for fragmentation and reassembly
                       of IP datagrams.";
                  }

                  leaf-list pkt-sec-cond-ipv4-ttl {
                    type uint8;
                    description

Kim, et al.               Expires April 5, 2018                [Page 28]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

                      "The ttl keyword is used to check for a specific
                       IP time-to-live value in the header of
                       a packet.";
                  }

                  leaf-list pkt-sec-cond-ipv4-protocol {
                    type uint8;
                    description
                      "Internet Protocol version 4(IPv4) is the fourth
                       version of the Internet Protocol (IP).";
                  }

                  leaf-list pkt-sec-cond-ipv4-src {
                    type inet:ipv4-address;
                    description
                      "Defines the IPv4 Source Address.";
                  }

                  leaf-list pkt-sec-cond-ipv4-dest {
                    type inet:ipv4-address;
                    description
                      "Defines the IPv4 Destination Address.";
                  }

                  leaf pkt-sec-cond-ipv4-ipopts {
                    type string;
                    description
                      "With the ipopts keyword you can check if
                       a specific ip option is set. Ipopts has
                       to be used at the beginning of a rule.";
                  }

                  leaf pkt-sec-cond-ipv4-sameip {
                    type boolean;
                    description
                      "Every packet has a source IP-address and
                       a destination IP-address. It can be that
                       the source IP is the same as
                       the destination IP.";
                  }

                  leaf-list pkt-sec-cond-ipv4-geoip {
                    type string;
                    description
                      "The geoip keyword enables you to match on
                       the source, destination or source and destination
                       IP addresses of network traffic and to see to
                       which country it belongs. To do this, Suricata

Kim, et al.               Expires April 5, 2018                [Page 29]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

                       uses GeoIP API with MaxMind database format.";
                  }
                }

                container packet-security-ipv6-condition {
                  description
                     "The purpose of this Class is to represent packet
                     IPv6 packet header information that can be used as
                     part of a test to determine if the set of Policy
                     Actions in this ECA Policy Rule should be executed
                     or not.";

                  leaf-list pkt-sec-cond-ipv6-dscp {
                    type string;
                    description
                      "Differentiated Services Code Point (DSCP)
                       of ipv6.";
                  }

                  leaf-list pkt-sec-cond-ipv6-ecn {
                    type string;
                    description
                      "ECN allows end-to-end notification of network
                       congestion without dropping packets.";
                  }

                  leaf-list pkt-sec-cond-ipv6-traffic-class {
                    type uint8;
                    description
                      "The bits of this field hold two values. The 6
                       most-significant bits are used for
                       differentiated services, which is used to
                       classify packets.";
                  }

                  leaf-list pkt-sec-cond-ipv6-flow-label {
                    type uint32;
                    description
                      "The flow label when set to a non-zero value
                       serves as a hint to routers and switches
                       with multiple outbound paths that these
                       packets should stay on the same path so that
                       they will not be reordered.";
                  }

                  leaf-list pkt-sec-cond-ipv6-payload-length {
                    type uint16;
                    description

Kim, et al.               Expires April 5, 2018                [Page 30]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

                      "The size of the payload in octets,
                       including any extension headers.";
                  }

                  leaf-list pkt-sec-cond-ipv6-next-header {
                    type uint8;
                    description
                      "Specifies the type of the next header.
                       This field usually specifies the transport
                       layer protocol used by a packet's payload.";
                  }

                  leaf-list pkt-sec-cond-ipv6-hop-limit {
                    type uint8;
                    description
                      "Replaces the time to live field of IPv4.";
                  }

                  leaf-list pkt-sec-cond-ipv6-src {
                    type inet:ipv6-address;
                    description
                      "The IPv6 address of the sending node.";
                  }

                  leaf-list pkt-sec-cond-ipv6-dest {
                    type inet:ipv6-address;
                    description
                      "The IPv6 address of the destination node(s).";
                  }
                }

                container packet-security-tcp-condition {
                  description
                    "The purpose of this Class is to represent packet
                     TCP packet header information that can be used as
                     part of a test to determine if the set of Policy
                     Actions in this ECA Policy Rule should be executed
                     or not.";

                  leaf-list pkt-sec-cond-tcp-seq-num {
                    type uint32;
                    description
                      "If the SYN flag is set (1), then this is the
                       initial sequence number.";
                  }

                  leaf-list pkt-sec-cond-tcp-ack-num {
                    type uint32;

Kim, et al.               Expires April 5, 2018                [Page 31]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

                    description
                      "If the ACK flag is set then the value of this
                       field is the next sequence number that the sender
                       is expecting.";
                  }

                  leaf-list pkt-sec-cond-tcp-window-size {
                    type uint16;
                    description
                      "The size of the receive window, which specifies
                       the number of windows size units
                       (by default,bytes) (beyond the segment
                       identified by the sequence number in the
                       acknowledgment field) that the sender of this
                       segment is currently willing to recive.";
                  }

                  leaf-list pkt-sec-cond-tcp-flags {
                    type uint8;
                    description
                      "This is a mandatory string attribute, and defines
                       the nine Control bit flags (9 bits).";
                  }
                }

                container packet-security-udp-condition {
                  description
                   "The purpose of this Class is to represent packet UDP
                    packet header information that can be used as part
                    of a test to determine if the set of Policy Actions
                    in this ECA Policy Rule should be executed or not.";

                  leaf-list pkt-sec-cond-udp-length {
                    type string;
                    description
                     "This is a mandatory string attribute, and defines
                      the length in bytes of the UDP header and data
                      (16 bits).";
                  }
                }

                container packet-security-icmp-condition {
                  description
                    "The internet control message protocol condition.";

                  leaf-list pkt-sec-cond-icmp-type {
                    type uint8;
                    description

Kim, et al.               Expires April 5, 2018                [Page 32]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

                      "ICMP type, see Control messages.";
                  }

                  leaf-list pkt-sec-cond-icmp-code {
                    type uint8;
                    description
                      "ICMP subtype, see Control messages.";
                  }

                  leaf-list pkt-sec-cond-icmp-seg-num {
                    type uint32;
                    description
                      "The icmp Sequence Number.";
                  }
                }
              }

              case packet-payload-condition {
                leaf packet-payload-manual {
                  type string;
                  description
                   "This is manual for payload condition.
                   Vendors can write instructions for payload condition
                   that vendor made";
                }
                leaf-list pkt-payload-content {
                  type string;
                  description
                    "The content keyword is very important in
                     signatures. Between the quotation marks you
                     can write on what you would like the
                     signature to match.";
                }
              }
              case target-condition {
                leaf target-manual {
                  type string;
                  description
                    "This is manual for target condition.
                    Vendors can write instructions for target condition
                    that vendor made";
                }

                container device-sec-context-cond {
                  description
                    "The device attribute that can identify a device,
                     including the device type (i.e., router, switch,
                     pc, ios, or android) and the device's owner as

Kim, et al.               Expires April 5, 2018                [Page 33]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

                     well.";

                  leaf pc {
                    type boolean;
                    description
                      "If type of a device is PC.";
                  }

                  leaf mobile-phone {
                    type boolean;
                    description
                      "If type of a device is mobile-phone.";
                  }

                  leaf voip-volte-phone {
                    type boolean;
                    description
                      "If type of a device is voip-volte-phone.";
                  }

                  leaf tablet {
                    type boolean;
                    description
                      "If type of a device is tablet.";
                  }

                  leaf iot {
                    type boolean;
                    description
                      "If type of a device is Internet of Things.";
                  }

                  leaf vehicle {
                    type boolean;
                    description
                      "If type of a device is vehicle.";
                  }
                }
              }
              case users-condition {
                leaf users-manual {
                  type string;
                  description
                    "This is manual for user condition.
                    Vendors can write instructions for user condition
                    that vendor made";
                }

Kim, et al.               Expires April 5, 2018                [Page 34]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

                container user{
                  description
                    "The user (or user group) information with which
                     network flow is associated: The 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 a 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)";

                  choice user-name {
                    description
                      "The name of the user.
                       This must be unique.";

                    case tenant {
                      description
                        "Tenant information.";

                      leaf tenant {
                        type uint8;
                        mandatory true;
                        description
                          "User's tenant information.";
                      }
                    }

                    case vn-id {
                      description
                        "VN-ID information.";

                      leaf vn-id {
                        type uint8;
                        mandatory true;
                        description
                          "User's VN-ID information.";
                      }
                    }
                  }
                }
                container group {
                  description
                    "The user (or user group) information with which
                     network flow is associated: The user has many
                     attributes such as name, id, password, type,

Kim, et al.               Expires April 5, 2018                [Page 35]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

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

                  choice group-name {
                    description
                      "The name of the user.
                       This must be unique.";

                    case tenant {
                      description
                        "Tenant information.";

                      leaf tenant {
                        type uint8;
                        mandatory true;
                        description
                          "User's tenant information.";
                      }
                    }

                    case vn-id {
                      description
                        "VN-ID information.";

                      leaf vn-id {
                        type uint8;
                        mandatory true;
                        description
                          "User's VN-ID information.";
                      }
                    }
                  }
                }

              }
              case context-condition {
                leaf context-manual {
                  type string;
                  description
                    "This is manual for context condition.
                    Vendors can write instructions for context condition
                    that vendor made";
                }

Kim, et al.               Expires April 5, 2018                [Page 36]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

              }
              case gen-context-condition {
                leaf gen-context-manual {
                  type string;
                  description
                    "This is manual for generic context condition.
                    Vendors can write instructions for generic context
                    condition that vendor made";
                }

                container geographic-location {
                  description
                    "The location where network traffic is associated
                     with. The region can be the geographic location
                     such as country, province, and city,
                     as well as the logical network location such as
                     IP address, network section, and network domain.";

                  leaf-list src-geographic-location {
                    type uint32;
                    description
                      "This is mapped to ip address. We can acquire
                       source region through ip address stored the
                       database.";
                  }
                  leaf-list dest-geographic-location {
                    type uint32;
                    description
                      "This is mapped to ip address. We can acquire
                       destination region through ip address stored
                       the database.";
                  }
                }
              }
            }
          }
          container action {
            description
              "An action is used to control and monitor aspects of
               flow-based NSFs when the event and condition clauses
               are satisfied. NSFs provide security functions by
               executing various Actions. Examples of I2NSF Actions
               include providing intrusion detection and/or protection,
               web and flow filtering, and deep packet inspection
               for packets and flows.";

            choice action-type {

Kim, et al.               Expires April 5, 2018                [Page 37]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

              description
                "Vendors can use YANG data model to configure rules
                by concreting this action type";
              case ingress-action {
                leaf ingress-manual {
                  type string;
                  description
                    "This is manual for ingress action.
                    Vendors can write instructions for ingress action
                    that vendor made";
                }
                leaf ingress-action-type {
                  type ingress-action;
                  description
                    "Ingress action type: permit, deny, and mirror.";
                }
              }
              case egress-action {
                leaf egress-manual {
                  type string;
                  description
                    "This is manual for egress action.
                    Vendors can write instructions for egress action
                    that vendor made";
                }
                leaf egress-action-type {
                  type egress-action;
                  description
                    "Egress-action-type: invoke-signaling,
                     tunnel-encapsulation, and forwarding.";
                }
              }
              case apply-profile {
                leaf profile-manual {
                  type string;
                  description
                    "This is manual for apply profile action.
                    Vendors can write instructions for apply
                    profile action that vendor made";
                }

                choice apply-profile-action-type {
                  description
                    "Advanced action types: Content Security Control
                     and Attack Mitigation Control.";

                  case content-security-control {
                    description

Kim, et al.               Expires April 5, 2018                [Page 38]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

                     "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, and blocking
                     illegal web access or data retrieval.";

                    container content-security-control-types {
                      description
                       "Content Security types: Antivirus, IPS, IDS,
                        url-filtering, data-filtering, mail-filtering,
                        file-blocking, file-isolate, pkt-capture,
                        application-control, and voip-volte.";

                      leaf antivirus {
                          type boolean;
                          description
                            "Additional inspection of antivirus.";
                      }

                      leaf ips {
                          type boolean;
                          description
                            "Additional inspection of IPS.";
                      }

                      leaf ids {
                          type boolean;
                          description
                            "Additional inspection of IDS.";
                      }

                      leaf url-filtering {
                          type boolean;
                          description
                            "Additional inspection of URL filtering.";
                      }

                      leaf data-filtering {
                         type boolean;
                         description
                           "Additional inspection of data filtering.";
                      }

                      leaf mail-filtering {
                        type boolean;

Kim, et al.               Expires April 5, 2018                [Page 39]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

                        description
                          "Additional inspection of mail filtering.";
                      }

                      leaf file-blocking {
                        type boolean;
                        description
                          "Additional inspection of file blocking.";
                      }

                      leaf file-isolate {
                        type boolean;
                        description
                          "Additional inspection of file isolate.";
                      }

                      leaf pkt-capture {
                        type boolean;
                        description
                          "Additional inspection of packet capture.";
                      }

                      leaf application-control {
                        type boolean;
                        description
                          "Additional inspection of app control.";
                      }

                      leaf voip-volte {
                        type boolean;
                        description
                          "Additional inspection of VoIP/VoLTE.";
                      }
                    }
                  }

                  case attack-mitigation-control {
                    description
                      "This category of security capabilities is
                       specially used to detect and mitigate various
                       types of network attacks.";

                    choice attack-mitigation-control-type {
                      description
                        "Attack-mitigation types: DDoS-attack and
                         Single-packet attack.";

                      case ddos-attack {

Kim, et al.               Expires April 5, 2018                [Page 40]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

                        description
                          "A distributed-denial-of-service (DDoS) is
                           where the attack source is more than one,
                           often thousands of unique IP addresses.";

                        container ddos-attack-type {
                          description
                            "DDoS-attack types: Network Layer
                            DDoS Attacks and Application Layer
                            DDoS Attacks.";

                          container network-layer-ddos-attack {
                            description
                              "Network layer DDoS-attack.";
                            container network-layer-ddos-attack-type {
                              description
                                "Network layer DDoS attack types:
                                 Syn Flood Attack, UDP Flood Attack,
                                 ICMP Flood Attack, IP Fragment Flood,
                                 IPv6 Related Attacks, and etc";

                              leaf syn-flood {
                                type boolean;
                                description
                                  "Additional Inspection of
                                   Syn Flood Attack.";
                              }

                              leaf udp-flood {
                                type boolean;
                                description
                                  "Additional Inspection of
                                   UDP Flood Attack.";
                              }

                              leaf icmp-flood {
                                type boolean;
                                description
                                  "Additional Inspection of
                                   ICMP Flood Attack.";
                              }

                              leaf ip-frag-flood {
                                type boolean;
                                description
                                  "Additional Inspection of
                                   IP Fragment Flood.";
                              }

Kim, et al.               Expires April 5, 2018                [Page 41]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

                              leaf ipv6-related {
                                type boolean;
                                description
                                  "Additional Inspection of
                                   IPv6 Related Attacks.";
                              }
                            }
                          }

                          container app-layer-ddos-attack {
                            description
                              "Application layer DDoS-attack.";

                            container app-ddos-attack-types {
                              description
                                "Application layer DDoS-attack types:
                                 Http Flood Attack, Https Flood Attack,
                                 DNS Flood Attack, and
                                 DNS Amplification Flood Attack,
                                 SSL DDoS Attack, and etc.";

                              leaf http-flood {
                                type boolean;
                                description
                                  "Additional Inspection of
                                   Http Flood Attack.";
                              }

                              leaf https-flood {
                                type boolean;
                                description
                                  "Additional Inspection of
                                   Https Flood Attack.";
                              }

                              leaf dns-flood {
                                type boolean;
                                description
                                  "Additional Inspection of
                                   DNS Flood Attack.";
                              }

                              leaf dns-amp-flood {
                                type boolean;
                                description
                                  "Additional Inspection of
                                   DNS Amplification Flood Attack.";
                              }

Kim, et al.               Expires April 5, 2018                [Page 42]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

                              leaf ssl-ddos {
                                type boolean;
                                description
                                  "Additional Inspection of
                                   SSL Flood Attack.";
                              }
                            }
                          }
                        }
                      }

                      case single-packet-attack {
                        description
                          "Single Packet Attacks.";
                        container single-packet-attack-type {
                          description
                            "DDoS-attack types: Scanning Attack,
                             Sniffing Attack, Malformed Packet Attack,
                             Special Packet Attack, and etc.";

                          container scan-and-sniff-attack {
                            description
                              "Scanning and Sniffing Attack.";
                            container scan-and-sniff-attack-types {
                              description
                                "Scanning and sniffing attack types:
                                 IP Sweep attack, Port Scanning,
                                 and etc.";

                              leaf ip-sweep {
                                type boolean;
                                description
                                  "Additional Inspection of
                                   IP Sweep Attack.";
                              }

                              leaf port-scanning {
                                type boolean;
                                description
                                  "Additional Inspection of
                                   Port Scanning Attack.";
                              }
                            }
                          }

                          container malformed-packet-attack {
                            description
                              "Malformed Packet Attack.";

Kim, et al.               Expires April 5, 2018                [Page 43]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

                            container malformed-packet-attack-types {
                              description
                                "Malformed packet attack types:
                                 Ping of Death Attack, Teardrop Attack,
                                 and etc.";

                              leaf ping-of-death {
                                type boolean;
                                description
                                  "Additional Inspection of
                                   Ping of Death Attack.";
                              }

                              leaf teardrop {
                                type boolean;
                                description
                                  "Additional Inspection of
                                   Teardrop Attack.";
                              }
                            }
                          }

                          container special-packet-attack {
                            description
                              "special Packet Attack.";
                            container special-packet-attack-types {
                              description
                                "Special packet attack types:
                                 Oversized ICMP Attack, Tracert Attack,
                                 and etc.";

                              leaf oversized-icmp {
                                type boolean;
                                description
                                  "Additional Inspection of
                                   Oversize ICMP Attack.";
                              }

                              leaf tracert {
                                type boolean;
                                description
                                  "Additional Inspection of
                                   Tracrt Attack.";
                              }
                            }
                          }
                        }
                      }

Kim, et al.               Expires April 5, 2018                [Page 44]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

                    }
                  }
                }
              }
            }
          }
        }

        container resolution-strategy {
          description
            "The resolution strategies can be used to
            specify how to resolve conflicts that occur between
            the actions of the same or different policy rules that
            are matched and contained in this particular NSF";

          choice resolution-strategy-type {
            description
              "Vendors can use YANG data model to configure rules";

            case fmr {
              leaf first-matching-rule {
                type boolean;
                description
                  "If the resolution strategy is first matching rule";
              }
            }
            case lmr {
              leaf last-matching-rule {
                type boolean;
                description
                  "If the resolution strategy is last matching rule";
              }
            }

          }
        }

        container default-action {
          description
            "This default action can be used to specify a predefined
            action when no other alternative action was matched
            by the currently executing I2NSF Policy Rule. An analogy
            is the use of a default statement in a C switch statement.";

          leaf default-action-type {
            type ingress-action;
            description

Kim, et al.               Expires April 5, 2018                [Page 45]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

              "Ingress action type: permit, deny, and mirror.";
          }
        }
      }
    }
  }

  <CODE ENDS>

         Figure 7: YANG Data Module of I2NSF NSF-Facing-Interface

7.  Security Considerations

   This document introduces no additional security threats and follows
   the security requirements as stated in [i2nsf-framework].

8.  Acknowledgments

   This work was supported by Institute for Information & communications
   Technology Promotion (IITP) grant funded by the Korea government
   (MSIP) (No.R-20160222-002755, Cloud based Security Intelligence
   Technology Development for the Customized Security Service
   Provisioning).

9.  Contributors

   I2NSF is a group effort.  I2NSF has had a number of contributing
   authors.  The following are considered co-authors:

   o  Hyoungshick Kim (Sungkyunkwan University)

   o  Daeyoung Hyun (Sungkyunkwan University)

   o  Dongjin Hong (Sungkyunkwan University)

   o  Jung-Soo Park (ETRI)

   o  Tae-Jin Ahn (Korea Telecom)

   o  Se-Hui Lee (Korea Telecom)

10.  References

10.1.  Normative References

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

Kim, et al.               Expires April 5, 2018                [Page 46]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

   [RFC6020]                 Bjorklund, M., "YANG - A Data Modeling
                             Language for the Network Configuration
                             Protocol (NETCONF)", RFC 6020,
                             October 2010.

10.2.  Informative References

   [i2nsf-nsf-cap-im]        Xia, L., Strassner, J., Basile, C., and D.
                             Lopez, "Information Model of NSFs
                             Capabilities",
                             draft-ietf-i2nsf-capability-00 (work in
                             progress), September 2017.

   [i2rs-rib-data-model]     Wang, L., Ananthakrishnan, H., Chen, M.,
                             Dass, A., Kini, S., and N. Bahadur, "A YANG
                             Data Model for Routing Information Base
                             (RIB)", draft-ietf-i2rs-rib-data-model-08
                             (work in progress), July 2017.

   [supa-policy-info-model]  Strassner, J., Halpern, J., and S. Meer,
                             "Generic Policy Information Model for
                             Simplified Use of Policy Abstractions
                             (SUPA)", draft-ietf-supa-generic-policy-
                             info-model-03 (work in progress), May 2017.

   [i2nsf-framework]         Lopez, D., Lopez, E., Dunbar, L.,
                             Strassner, J., and R. Kumar, "Framework for
                             Interface to Network Security Functions",
                             draft-ietf-i2nsf-framework-07 (work in
                             progress), August 2017.

Appendix A.  Example: Extended VoIP-VoLTE Security Function Module

   This section gives a simple example of how VoIP-VoLTE Security
   Function module could be extended.

     module
     ex-voip-volte {
       namespace "http://example.com/voip-volte";
       prefix "voip-volte";

       import ietf-i2nsf-nsf-facing-interface{
         prefix nsf;
       }

       augment "/nsf:generic-nsf/nsf:policy/nsf:rules/nsf:condition/" +
               "nsf:condition-type" {

Kim, et al.               Expires April 5, 2018                [Page 47]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

         case voice-condition {
           leaf sip-header-method {
             type string;
             description
               "SIP header method.";
           }

           leaf sip-header-uri {
             type string;
             description
               "SIP header URI.";
           }

           leaf sip-header-from {
             type string;
             description
               "SIP header From.";
           }

           leaf sip-header-to {
             type string;
             description
               "SIP header To.";
           }

           leaf sip-header-expire-time {
             type yang:date-and-time;
             description
               "SIP header expire time.";
           }

           leaf sip-header-user-agent {
             type uint32;
             description
               "SIP header user agent.";
           }
         }
       }
     }

      Figure 8: Example: Extended VoIP-VoLTE Security Function Module

Appendix B.  Example: XML Configuration of NSF-Facing Interface Module

   This section gives an XML example for a configuration of NSF-Facing
   Interface module according to a requirement.

Kim, et al.               Expires April 5, 2018                [Page 48]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

B.1.  Example: XML Configuration of Generic Network Security Function

   This section gives an XML example for a generic NSF configuration
   according to a requirement.

   Requirement: Prevent Facebook (e.g., 31.13.68.35) access during
   business hours (i.e., from 9AM to 6PM) to improve work efficiency of
   employees (e.g., from 221.159.112.1 to 221.159.112.9).

   Here is an XML example for a generic NSF configuration:

Kim, et al.               Expires April 5, 2018                [Page 49]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

    <?xml version="1.0" encoding="UTF-8"?>
    <rpc message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <edit-config>
     <target>
      <running />
     </target>
     <config>
      <generic-nsf xmlns="urn:ietf:params:xml:ns:yang:" +
                         "ietf-i2nsf-nsf-facing-interface">
       <policy>
        <policy-name>i2nsf-facebook-filter</policy-name>
        <time-zone>
         <start-time>09:00:00Z</start-time>
         <end-time>18:00:00Z</end-time>
        </time-zone>
        <rules nc:operation="create">
         <rule-name>facebook-block</rule-name>
         <condition>
         <packet-security-condition>
          <packet-security-ipv4-condition>
            <pkt-sec-cond-ipv4-src>221.159.112.1</pkt-sec-cond-ipv4-src>
            <pkt-sec-cond-ipv4-src>221.159.112.2</pkt-sec-cond-ipv4-src>
            <pkt-sec-cond-ipv4-src>221.159.112.3</pkt-sec-cond-ipv4-src>
            <pkt-sec-cond-ipv4-src>221.159.112.4</pkt-sec-cond-ipv4-src>
            <pkt-sec-cond-ipv4-src>221.159.112.5</pkt-sec-cond-ipv4-src>
            <pkt-sec-cond-ipv4-src>221.159.112.6</pkt-sec-cond-ipv4-src>
            <pkt-sec-cond-ipv4-src>221.159.112.7</pkt-sec-cond-ipv4-src>
            <pkt-sec-cond-ipv4-src>221.159.112.8</pkt-sec-cond-ipv4-src>
            <pkt-sec-cond-ipv4-src>221.159.112.9</pkt-sec-cond-ipv4-src>
            <pkt-sec-cond-ipv4-dest>31.13.13.68</pkt-sec-cond-ipv4-dest>
           </packet-security-ipv4-condition>
          </packet-security-condition>
         </condition>
         <action>
         <ingress-action-type>reject</ingress-action-type>
         </action>
        </rules>
        </policy>
      </generic-nsf>
      </config>
    </edit-config>
    </rpc>

     Figure 9: Example: Configuration XML for Generic Network Security
                                 Function

Kim, et al.               Expires April 5, 2018                [Page 50]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

B.2.  Example: XML Configuration of Extended VoIP-VoLTE Security
      Function Module

   This section gives an XML example for an extended VoIP-VoLTE security
   function (See Figure 8) configuration according to a requirement.

   Requirement: Block the packets of SIP if the values of user agent are
   either eyebeam or friendyly-scanner.

   Here is an XML example for a VoIP-VoLTE security function
   configuration:

 <?xml version="1.0" encoding="UTF-8"?>
 <rpc message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <edit-config>
  <target>
   <running />
  </target>
  <config>
   <generic-nsf xmlns="http://skku.edu/nsf-interface">
    <policy>
     <policy-name>voip-volte</policy-name>
      <rules>
       <rule-name>malicious-sip</rule-name>
       <condition>
        <sip-header-user-agent>eyebeam</sip-header-user-agent>
        <sip-header-user-agent>friendyly-scanner</sip-header-user-agent>
       </condition>
       <action>
        <ingress-action-type>reject</ingress-action-type>
       </action>
      </rules>
    </policy>
   </generic-nsf>
   </config>
 </edit-config>
 </rpc>

       Figure 10: Example: Configuration XML for Extended VoIP/VoLTE
                             Security Function

Appendix C.  draft-kim-i2nsf-nsf-facing-interface-data-model-02

   The following changes are made from
   draft-kim-i2nsf-nsf-facing-interface-data-model-02:

Kim, et al.               Expires April 5, 2018                [Page 51]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

   1.  Objective Section is added to specify the objective of this YANG
       data model.

   2.  Resolution Strategy is added to specify how to resolve policy
       rule conflicts that may occur among the actions of the same or
       different policy rules that are matched and contained in a
       particular NSF.

   3.  Default Action is added to specify a predefined action when no
       other alternative action was matched by the currently executed
       I2NSF policy rule.

   4.  This YANG data model is modified for vendors to extend the YANG
       data model if they need specific features for their NSFs.

   5.  An example is added to extend the YANG data model about a
       specific NSF.

   6.  Examples are added for XML configuration files of a generic NSF
       and an extended VoIP/VoLTE security function.

Authors' Addresses

   Jinyong Tim Kim
   Department of Computer Engineering
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon, Gyeonggi-Do  16419
   Republic of Korea

   Phone: +82 10 8273 0930
   EMail: timkim@skku.edu

   Jaehoon Paul Jeong
   Department of Software
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon, Gyeonggi-Do  16419
   Republic of Korea

   Phone: +82 31 299 4957
   Fax:   +82 31 290 7996
   EMail: pauljeong@skku.edu
   URI:   http://iotlab.skku.edu/people-jaehoon-jeong.php

Kim, et al.               Expires April 5, 2018                [Page 52]
Internet-Draft    NSF-Facing Interface YANG Data Model      October 2017

   Jung-Soo Park
   Electronics and Telecommunications Research Institute
   218 Gajeong-Ro, Yuseong-Gu
   Daejeon  34129
   Republic of Korea

   Phone: +82 42 860 6514
   EMail: pjs@etri.re.kr

   Susan Hares
   Huawei
   7453 Hickory Hill
   Saline, MI  48176
   USA

   Phone: +1-734-604-0332
   EMail: shares@ndzh.com

   Liang Xia (Frank)
   Huawei
   101 Software Avenue, Yuhuatai District
   Nanjing, Jiangsu
   China

   Phone:
   EMail: Frank.xialiang@huawei.com

Kim, et al.               Expires April 5, 2018                [Page 53]