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]. 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: WG List: Kim, et al. Expires April 5, 2018 [Page 14] Internet-Draft NSF-Facing Interface YANG Data Model October 2017 WG Chair: Adrian Farrel WG Chair: Linda Dunbar Editor: Jingyong Tim Kim Editor: Jaehoon Paul Jeong Editor: Susan Hares "; 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."; } } } } } 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 i2nsf-facebook-filter 09:00:00Z 18:00:00Z facebook-block 221.159.112.1 221.159.112.2 221.159.112.3 221.159.112.4 221.159.112.5 221.159.112.6 221.159.112.7 221.159.112.8 221.159.112.9 31.13.13.68 reject 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: voip-volte malicious-sip eyebeam friendyly-scanner reject 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]