--- 1/draft-ietf-i2nsf-nsf-facing-interface-dm-10.txt 2021-02-02 09:14:03.678657948 -0800 +++ 2/draft-ietf-i2nsf-nsf-facing-interface-dm-11.txt 2021-02-02 09:14:03.838662020 -0800 @@ -1,23 +1,23 @@ I2NSF Working Group J. Kim, Ed. Internet-Draft J. Jeong, Ed. Intended status: Standards Track Sungkyunkwan University -Expires: March 1, 2021 J. Park +Expires: August 6, 2021 J. Park ETRI S. Hares Q. Lin Huawei - August 28, 2020 + February 2, 2021 I2NSF Network Security Function-Facing Interface YANG Data Model - draft-ietf-i2nsf-nsf-facing-interface-dm-10 + draft-ietf-i2nsf-nsf-facing-interface-dm-11 Abstract This document defines a YANG data model for configuring security policy rules on Network Security Functions (NSF) in the Interface to Network Security Functions (I2NSF) framework. The YANG data model in this document corresponds to the information model for NSF-Facing Interface in the I2NSF framework. Status of This Memo @@ -28,672 +28,631 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on March 1, 2021. + This Internet-Draft will expire on August 6, 2021. Copyright Notice - Copyright (c) 2020 IETF Trust and the persons identified as the + Copyright (c) 2021 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 (https://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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 - 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 - 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 4. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 3 - 4.1. General I2NSF Security Policy Rule . . . . . . . . . . . 4 - 4.2. Event Clause . . . . . . . . . . . . . . . . . . . . . . 6 - 4.3. Condition Clause . . . . . . . . . . . . . . . . . . . . 7 - 4.4. Action Clause . . . . . . . . . . . . . . . . . . . . . . 14 - 4.5. I2NSF Internet Key Exchange . . . . . . . . . . . . . . . 15 - 5. YANG Data Model of NSF-Facing Interface . . . . . . . . . . . 15 - 5.1. YANG Module of NSF-Facing Interface . . . . . . . . . . . 16 - 6. XML Configuration Examples of Low-Level Security Policy Rules 86 - 6.1. Security Requirement 1: Block SNS Access during Business - Hours . . . . . . . . . . . . . . . . . . . . . . . . . . 87 - 6.2. Security Requirement 2: Block Malicious VoIP/VoLTE - Packets Coming to a Company . . . . . . . . . . . . . . . 91 - 6.3. Security Requirement 3: Mitigate HTTP and HTTPS Flood - Attacks on a Company Web Server . . . . . . . . . . . . . 94 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 97 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 97 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 98 - 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 98 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 100 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 100 - 11.2. Informative References . . . . . . . . . . . . . . . . . 102 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 103 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 3 + 3.1. General I2NSF Security Policy Rule . . . . . . . . . . . 3 + 3.2. Event Clause . . . . . . . . . . . . . . . . . . . . . . 5 + 3.3. Condition Clause . . . . . . . . . . . . . . . . . . . . 6 + 3.4. Action Clause . . . . . . . . . . . . . . . . . . . . . . 12 + 4. YANG Data Model of NSF-Facing Interface . . . . . . . . . . . 13 + 4.1. YANG Module of NSF-Facing Interface . . . . . . . . . . . 14 + 5. XML Configuration Examples of Low-Level Security Policy Rules 85 + 5.1. Security Requirement 1: Block Social Networking Service + (SNS) Access during Business Hours . . . . . . . . . . . 85 + 5.2. Security Requirement 2: Block Malicious VoIP/VoLTE + Packets Coming to a Company . . . . . . . . . . . . . . . 89 + 5.3. Security Requirement 3: Mitigate HTTP and HTTPS Flood + Attacks on a Company Web Server . . . . . . . . . . . . . 92 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 95 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 95 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 96 + 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 97 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 98 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 98 + 10.2. Informative References . . . . . . . . . . . . . . . . . 101 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 101 1. Introduction This document defines a YANG [RFC6020][RFC7950] data model for security policy rule configuration of Network Security Functions - (NSF). The YANG data model corresponds to the information model - [I-D.ietf-i2nsf-capability] for the NSF-Facing Interface in Interface - to Network Security Functions (I2NSF) [RFC8329]. The YANG data model - in this document focuses on security policy configuration for generic - network security functions. Security policy configuration for - advanced network security functions can be defined in future. + (NSF). The YANG data model in this document is based on the + information model in [I-D.ietf-i2nsf-capability-data-model] for the + NSF-Facing Interface in the Interface to Network Security Functions + (I2NSF) architecture [RFC8329]. The YANG data model in this document + focuses on security policy configuration for generic network security + functions (e.g., firewall, web filter, and Distributed-Denial-of- + Service (DDoS) attack mitigator) + [I-D.ietf-i2nsf-capability-data-model]. Security policy + configuration for advanced network security functions is out of the + scope of this document, such as Intrusion Prevention System (IPS) and + anti-virus [I-D.ietf-i2nsf-capability-data-model]. This YANG data model uses an "Event-Condition-Action" (ECA) policy model that is used as the basis for the design of I2NSF Policy - described in [RFC8329] and [I-D.ietf-i2nsf-capability]. + described in [RFC8329] and [I-D.ietf-i2nsf-capability-data-model]. The "ietf-i2nsf-policy-rule-for-nsf" YANG module defined in this - document provides the following features. - - o Configuration of general security policy rule for generic network - security functions. - - o Configuration of event clause for generic network security - functions. + document provides the configuration of the following features. - o Configuration of condition clause for generic network security - functions. + o A general security policy rule of a generic network security + function. - o Configuration of action clause for generic network security - functions. + o An event clause of a generic network security function. -2. Requirements Language + o A condition clause of a generic network security function. - 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]. + o An action clause of a generic network security function. -3. Terminology +2. Terminology This document uses the terminology described in [RFC8329]. This document follows the guidelines of [RFC8407], uses the common YANG types defined in [RFC6991], and adopts the Network Management Datastore Architecture (NMDA). The meaning of the symbols in tree diagrams is defined in [RFC8340]. -4. YANG Tree Diagram +3. YANG Tree Diagram This section shows a YANG tree diagram of generic network security functions. Advanced network security functions can be defined in - future. The section describes the following subjects: - - o A general I2NSF security policy rule of the generic network - security function. - - o An event clause of the generic network security function. - - o A condition clause of the generic network security function. - - o An action clause of the generic network security function. + future. Advanced network security functions is out of the scope of + this document can be defined in future, such as Intrusion Prevention + System (IPS), Distributed-Denial-of-Service (DDoS) attack mitigator, + and anti-virus [I-D.ietf-i2nsf-capability-data-model]. -4.1. General I2NSF Security Policy Rule +3.1. General I2NSF Security Policy Rule - This section shows the YANG tree diagram for general I2NSF security - policy rules. + This section shows a YANG tree diagram for a general I2NSF security + policy rule for generic network security functions. module: ietf-i2nsf-policy-rule-for-nsf +--rw i2nsf-security-policy - | +--rw system-policy* [system-policy-name] - | +--rw system-policy-name string - | +--rw priority-usage? identityref - | +--rw resolution-strategy? identityref - | +--rw default-action? identityref - | +--rw rules* [rule-name] - | | +--rw rule-name string - | | +--rw rule-description? string - | | +--rw rule-priority? uint8 - | | +--rw rule-enable? boolean - | | +--rw rule-session-aging-time? uint16 - | | +--rw rule-long-connection - | | | +--rw enable? boolean - | | | +--rw duration? uint16 - | | +--rw time-intervals - | | | +--rw absolute-time-interval - | | | | +--rw start-time? start-time-type - | | | | +--rw end-time? end-time-type - | | | +--rw periodic-time-interval - | | | +--rw day - | | | | +--rw every-day? boolean - | | | | +--rw specific-day* day-type - | | | +--rw month - | | | +--rw every-month? boolean - | | | +--rw specific-month* month-type - | | +--rw event-clause-container - | | | ... - | | +--rw condition-clause-container - | | | ... - | | +--rw action-clause-container + +--rw system-policy* [system-policy-name] + +--rw system-policy-name string + +--rw priority-usage? identityref + +--rw resolution-strategy? identityref + +--rw default-action? identityref + +--rw rules* [rule-name] + | +--rw rule-name string + | +--rw rule-description? string + | +--rw rule-priority? uint8 + | +--rw rule-enable? boolean + | +--rw rule-session-aging-time? uint16 + | +--rw rule-long-connection + | | +--rw enable? boolean + | | +--rw duration? uint16 + | +--rw time-intervals + | | +--rw absolute-time-interval + | | | +--rw start-time? start-time-type + | | | +--rw end-time? end-time-type + | | +--rw periodic-time-interval + | | +--rw day + | | | +--rw every-day? boolean + | | | +--rw specific-day* day-type + | | +--rw month + | | +--rw every-month? boolean + | | +--rw specific-month* month-type + | +--rw event-clause-container | | ... - | +--rw rule-group - | +--rw groups* [group-name] - | +--rw group-name string - | +--rw rule-range - | | +--rw start-rule? string - | | +--rw end-rule? string - | +--rw enable? boolean - | +--rw description? string - +--rw i2nsf-ipsec? identityref + | +--rw condition-clause-container + | | ... + | +--rw action-clause-container + | ... + +--rw rule-group + +--rw groups* [group-name] + +--rw group-name string + +--rw rule-range + | +--rw start-rule? string + | +--rw end-rule? string + +--rw enable? boolean + +--rw description? string Figure 1: YANG Tree Diagram for Network Security Policy - This YANG tree diagram shows the general I2NSF security policy rule - for generic network security functions. - The system policy provides for multiple system policies in one NSF, and each system policy is used by one virtual instance of the NSF/ device. The system policy includes system policy name, priority - usage, resolutation strategy, default action, and rules. + usage, resolution strategy, default action, and rules. A resolution strategy is used to decide how to resolve conflicts that occur between the actions of the same or different policy rules that are matched and contained in a particular NSF. The resolution strategy is defined as First Matching Rule (FMR), Last Matching Rule (LMR), Prioritized Matching Rule (PMR) with Errors (PMRE), and Prioritized Matching Rule with No Errors (PMRN). The resolution strategy can be extended according to specific vendor action features. The resolution strategy is described in detail in - [I-D.ietf-i2nsf-capability]. + [I-D.ietf-i2nsf-capability-data-model]. A default action is used to execute I2NSF policy rule when no rule matches a packet. The default action is defined as pass, drop, reject, alert, and mirror. The default action can be extended according to specific vendor action features. The default action is - described in detail in [I-D.ietf-i2nsf-capability]. + described in detail in [I-D.ietf-i2nsf-capability-data-model]. The rules include rule name, rule description, rule priority, rule enable, time zone, event clause container, condition clause container, and action clause container. -4.2. Event Clause +3.2. Event Clause - This section shows the YANG tree diagram for an event clause for - I2NSF security policy rules. + This section shows a YANG tree diagram for an event clause for a + general I2NSF security policy rule for generic network security + functions. module: ietf-i2nsf-policy-rule-for-nsf +--rw i2nsf-security-policy - | +--rw system-policy* [system-policy-name] + +--rw system-policy* [system-policy-name] + ... + +--rw rules* [rule-name] | ... - | +--rw rules* [rule-name] - | | ... - | | +--rw event-clause-container - | | | +--rw event-clause-description? string - | | | +--rw event-clauses - | | | +--rw system-event* identityref - | | | +--rw system-alarm* identityref - | | +--rw condition-clause-container - | | | ... - | | +--rw action-clause-container + | +--rw event-clause-container + | | +--rw event-clause-description? string + | | +--rw event-clauses + | | +--rw system-event* identityref + | | +--rw system-alarm* identityref + | +--rw condition-clause-container | | ... - | +--rw rule-group + | +--rw action-clause-container | ... - +--rw i2nsf-ipsec? identityref + +--rw rule-group + ... Figure 2: YANG Tree Diagram for an Event Clause - This YANG tree diagram shows an event clause of an I2NSF security - policy rule for generic network security functions. An event clause - is any important occurrence at a specific time of a change in the - system being managed, and/or in the environment of the system being - managed. An event clause is used to trigger the evaluation of the - condition clause of the I2NSF Policy Rule. The event clause is - defined as a system event and system alarm + An event clause is any important occurrence at a specific time of a + change in the system being managed, and/or in the environment of the + system being managed. An event clause is used to trigger the + evaluation of the condition clause of the I2NSF Policy Rule. The + event clause is defined as a system event and system alarm [I-D.ietf-i2nsf-nsf-monitoring-data-model]. The event clause can be extended according to specific vendor event features. The event - clause is described in detail in [I-D.ietf-i2nsf-capability]. + clause is described in detail in + [I-D.ietf-i2nsf-capability-data-model]. -4.3. Condition Clause +3.3. Condition Clause - This section shows the YANG tree diagram for a condition clause of - I2NSF security policy rules. + This section shows a YANG tree diagram for a condition clause for a + general I2NSF security policy rule for generic network security + functions. module: ietf-i2nsf-policy-rule-for-nsf +--rw i2nsf-security-policy + ... + +--rw rules* [rule-name] | ... - | +--rw rules* [rule-name] + | +--rw event-clause-container | | ... - | | +--rw event-clause-container - | | | ... - | | +--rw condition-clause-container - | | | +--rw condition-clause-description? string - | | | +--rw packet-security-ipv4-condition - | | | | +--rw ipv4-description? string - | | | | +--rw pkt-sec-ipv4-header-length - | | | | | +--rw (match-type)? - | | | | | +--:(exact-match) - | | | | | | +--rw ipv4-header-length* uint8 - | | | | | +--:(range-match) - | | | | | +--rw range-ipv4-header-length* + | +--rw condition-clause-container + | | +--rw condition-clause-description? string + | | +--rw packet-security-ipv4-condition + | | | +--rw ipv4-description? string + | | | +--rw pkt-sec-ipv4-header-length + | | | | +--rw (match-type)? + | | | | +--:(exact-match) + | | | | | +--rw ipv4-header-length* uint8 + | | | | +--:(range-match) + | | | | +--rw range-ipv4-header-length* [start-ipv4-header-length end-ipv4-header-length] - | | | | | +--rw start-ipv4-header-length uint8 - | | | | | +--rw end-ipv4-header-length uint8 - | | | | +--rw pkt-sec-ipv4-tos* identityref - | | | | +--rw pkt-sec-ipv4-total-length - | | | | | +--rw (match-type)? - | | | | | +--:(exact-match) - | | | | | | +--rw ipv4-total-length* uint16 - | | | | | +--:(range-match) - | | | | | +--rw range-ipv4-total-length* + | | | | +--rw start-ipv4-header-length uint8 + | | | | +--rw end-ipv4-header-length uint8 + | | | +--rw pkt-sec-ipv4-tos* identityref + | | | +--rw pkt-sec-ipv4-total-length + | | | | +--rw (match-type)? + | | | | +--:(exact-match) + | | | | | +--rw ipv4-total-length* uint16 + | | | | +--:(range-match) + | | | | +--rw range-ipv4-total-length* [start-ipv4-total-length end-ipv4-total-length] - | | | | | +--rw start-ipv4-total-length uint16 - | | | | | +--rw end-ipv4-total-length uint16 - | | | | +--rw pkt-sec-ipv4-id* uint16 - | | | | +--rw pkt-sec-ipv4-fragment-flags* identityref - | | | | +--rw pkt-sec-ipv4-fragment-offset - | | | | | +--rw (match-type)? - | | | | | +--:(exact-match) - | | | | | | +--rw ipv4-fragment-offset* uint16 - | | | | | +--:(range-match) - | | | | | +--rw range-ipv4-fragment-offset* + | | | | +--rw start-ipv4-total-length uint16 + | | | | +--rw end-ipv4-total-length uint16 + | | | +--rw pkt-sec-ipv4-id* uint16 + | | | +--rw pkt-sec-ipv4-fragment-flags* identityref + | | | +--rw pkt-sec-ipv4-fragment-offset + | | | | +--rw (match-type)? + | | | | +--:(exact-match) + | | | | | +--rw ipv4-fragment-offset* uint16 + | | | | +--:(range-match) + | | | | +--rw range-ipv4-fragment-offset* [start-ipv4-fragment-offset end-ipv4-fragment-offset] - | | | | | +--rw start-ipv4-fragment-offset uint16 - | | | | | +--rw end-ipv4-fragment-offset uint16 - | | | | +--rw pkt-sec-ipv4-ttl - | | | | | +--rw (match-type)? - | | | | | +--:(exact-match) - | | | | | | +--rw ipv4-ttl* uint8 - | | | | | +--:(range-match) - | | | | | +--rw range-ipv4-ttl* + | | | | +--rw start-ipv4-fragment-offset uint16 + | | | | +--rw end-ipv4-fragment-offset uint16 + | | | +--rw pkt-sec-ipv4-ttl + | | | | +--rw (match-type)? + | | | | +--:(exact-match) + | | | | | +--rw ipv4-ttl* uint8 + | | | | +--:(range-match) + | | | | +--rw range-ipv4-ttl* [start-ipv4-ttl end-ipv4-ttl] - | | | | | +--rw start-ipv4-ttl uint8 - | | | | | +--rw end-ipv4-ttl uint8 - | | | | +--rw pkt-sec-ipv4-protocol* identityref - | | | | +--rw pkt-sec-ipv4-src - | | | | | +--rw (match-type)? - | | | | | +--:(exact-match) - | | | | | | +--rw ipv4-address* [ipv4] - | | | | | | +--rw ipv4 inet:ipv4-address - | | | | | | +--rw (subnet)? - | | | | | | +--:(prefix-length) - | | | | | | | +--rw prefix-length? uint8 - | | | | | | +--:(netmask) - | | | | | | +--rw netmask? yang:dotted-quad - | | | | | +--:(range-match) - | | | | | +--rw range-ipv4-address* + | | | | +--rw start-ipv4-ttl uint8 + | | | | +--rw end-ipv4-ttl uint8 + | | | +--rw pkt-sec-ipv4-protocol* identityref + | | | +--rw pkt-sec-ipv4-src + | | | | +--rw (match-type)? + | | | | +--:(exact-match) + | | | | | +--rw ipv4-address* [ipv4] + | | | | | +--rw ipv4 inet:ipv4-address + | | | | | +--rw (subnet)? + | | | | | +--:(prefix-length) + | | | | | | +--rw prefix-length? uint8 + | | | | | +--:(netmask) + | | | | | +--rw netmask? yang:dotted-quad + | | | | +--:(range-match) + | | | | +--rw range-ipv4-address* [start-ipv4-address end-ipv4-address] - | | | | | +--rw start-ipv4-address inet:ipv4-address - | | | | | +--rw end-ipv4-address inet:ipv4-address - | | | | +--rw pkt-sec-ipv4-dest - | | | | | +--rw (match-type)? - | | | | | +--:(exact-match) - | | | | | | +--rw ipv4-address* [ipv4] - | | | | | | +--rw ipv4 inet:ipv4-address - | | | | | | +--rw (subnet)? - | | | | | | +--:(prefix-length) - | | | | | | | +--rw prefix-length? uint8 - | | | | | | +--:(netmask) - | | | | | | +--rw netmask? yang:dotted-quad - | | | | | +--:(range-match) - | | | | | +--rw range-ipv4-address* + | | | | +--rw start-ipv4-address inet:ipv4-address + | | | | +--rw end-ipv4-address inet:ipv4-address + | | | +--rw pkt-sec-ipv4-dest + | | | | +--rw (match-type)? + | | | | +--:(exact-match) + | | | | | +--rw ipv4-address* [ipv4] + | | | | | +--rw ipv4 inet:ipv4-address + | | | | | +--rw (subnet)? + | | | | | +--:(prefix-length) + | | | | | | +--rw prefix-length? uint8 + | | | | | +--:(netmask) + | | | | | +--rw netmask? yang:dotted-quad + | | | | +--:(range-match) + | | | | +--rw range-ipv4-address* [start-ipv4-address end-ipv4-address] - | | | | | +--rw start-ipv4-address inet:ipv4-address - | | | | | +--rw end-ipv4-address inet:ipv4-address - | | | | +--rw pkt-sec-ipv4-ipopts* identityref - | | | | +--rw pkt-sec-ipv4-sameip? boolean - | | | | +--rw pkt-sec-ipv4-geoip* string - | | | +--rw packet-security-ipv6-condition - | | | | +--rw ipv6-description? string - | | | | +--rw pkt-sec-ipv6-traffic-class* identityref - | | | | +--rw pkt-sec-ipv6-flow-label - | | | | | +--rw (match-type)? - | | | | | +--:(exact-match) - | | | | | | +--rw ipv6-flow-label* uint32 - | | | | | +--:(range-match) - | | | | | +--rw range-ipv6-flow-label* + | | | | +--rw start-ipv4-address inet:ipv4-address + | | | | +--rw end-ipv4-address inet:ipv4-address + | | | +--rw pkt-sec-ipv4-ipopts* identityref + | | | +--rw pkt-sec-ipv4-same-ip? boolean + | | | +--rw pkt-sec-ipv4-geo-ip* string + | | +--rw packet-security-ipv6-condition + | | | +--rw ipv6-description? string + | | | +--rw pkt-sec-ipv6-traffic-class* identityref + | | | +--rw pkt-sec-ipv6-flow-label + | | | | +--rw (match-type)? + | | | | +--:(exact-match) + | | | | | +--rw ipv6-flow-label* uint32 + | | | | +--:(range-match) + | | | | +--rw range-ipv6-flow-label* [start-ipv6-flow-label end-ipv6-flow-label] - | | | | | +--rw start-ipv6-flow-label uint32 - | | | | | +--rw end-ipv6-flow-label uint32 - | | | | +--rw pkt-sec-ipv6-payload-length - | | | | | +--rw (match-type)? - | | | | | +--:(exact-match) - | | | | | | +--rw ipv6-payload-length* uint16 - | | | | | +--:(range-match) - | | | | | +--rw range-ipv6-payload-length* + | | | | +--rw start-ipv6-flow-label uint32 + | | | | +--rw end-ipv6-flow-label uint32 + | | | +--rw pkt-sec-ipv6-payload-length + | | | | +--rw (match-type)? + | | | | +--:(exact-match) + | | | | | +--rw ipv6-payload-length* uint16 + | | | | +--:(range-match) + | | | | +--rw range-ipv6-payload-length* [start-ipv6-payload-length end-ipv6-payload-length] - | | | | | +--rw start-ipv6-payload-length uint16 - | | | | | +--rw end-ipv6-payload-length uint16 - | | | | +--rw pkt-sec-ipv6-next-header* identityref - | | | | +--rw pkt-sec-ipv6-hop-limit - | | | | | +--rw (match-type)? - | | | | | +--:(exact-match) - | | | | | | +--rw ipv6-hop-limit* uint8 - | | | | | +--:(range-match) - | | | | | +--rw range-ipv6-hop-limit* + | | | | +--rw start-ipv6-payload-length uint16 + | | | | +--rw end-ipv6-payload-length uint16 + | | | +--rw pkt-sec-ipv6-next-header* identityref + | | | +--rw pkt-sec-ipv6-hop-limit + | | | | +--rw (match-type)? + | | | | +--:(exact-match) + | | | | | +--rw ipv6-hop-limit* uint8 + | | | | +--:(range-match) + | | | | +--rw range-ipv6-hop-limit* [start-ipv6-hop-limit end-ipv6-hop-limit] - | | | | | +--rw start-ipv6-hop-limit uint8 - | | | | | +--rw end-ipv6-hop-limit uint8 - | | | | +--rw pkt-sec-ipv6-src - | | | | | +--rw (match-type)? - | | | | | +--:(exact-match) - | | | | | | +--rw ipv6-address* [ipv6] - | | | | | | +--rw ipv6 inet:ipv6-address - | | | | | | +--rw prefix-length? uint8 - | | | | | +--:(range-match) - | | | | | +--rw range-ipv6-address* - [start-ipv6-address end-ipv6-address] - | | | | | +--rw start-ipv6-address inet:ipv6-address - | | | | | +--rw end-ipv6-address inet:ipv6-address - | | | | +--rw pkt-sec-ipv6-dest + | | | | +--rw start-ipv6-hop-limit uint8 + | | | | +--rw end-ipv6-hop-limit uint8 + | | | +--rw pkt-sec-ipv6-src | | | | +--rw (match-type)? | | | | +--:(exact-match) | | | | | +--rw ipv6-address* [ipv6] | | | | | +--rw ipv6 inet:ipv6-address | | | | | +--rw prefix-length? uint8 | | | | +--:(range-match) | | | | +--rw range-ipv6-address* [start-ipv6-address end-ipv6-address] | | | | +--rw start-ipv6-address inet:ipv6-address | | | | +--rw end-ipv6-address inet:ipv6-address - | | | +--rw packet-security-tcp-condition - | | | | +--rw tcp-description? string - | | | | +--rw pkt-sec-tcp-src-port-num - | | | | | +--rw (match-type)? - | | | | | +--:(exact-match) - | | | | | | +--rw port-num* inet:port-number - | | | | | +--:(range-match) - | | | | | +--rw range-port-num* - [start-port-num end-port-num] - | | | | | +--rw start-port-num inet:port-number - | | | | | +--rw end-port-num inet:port-number - | | | | +--rw pkt-sec-tcp-dest-port-num - | | | | | +--rw (match-type)? - | | | | | +--:(exact-match) - | | | | | | +--rw port-num* inet:port-number - | | | | | +--:(range-match) - | | | | | +--rw range-port-num* - + | | | +--rw pkt-sec-ipv6-dest + | | | +--rw (match-type)? + | | | +--:(exact-match) + | | | | +--rw ipv6-address* [ipv6] + | | | | +--rw ipv6 inet:ipv6-address + | | | | +--rw prefix-length? uint8 + | | | +--:(range-match) + | | | +--rw range-ipv6-address* + [start-ipv6-address end-ipv6-address] + | | | +--rw start-ipv6-address inet:ipv6-address + | | | +--rw end-ipv6-address inet:ipv6-address + | | +--rw packet-security-tcp-condition + | | | +--rw tcp-description? string + | | | +--rw pkt-sec-tcp-src-port-num + | | | | +--rw (match-type)? + | | | | +--:(exact-match) + | | | | | +--rw port-num* inet:port-number + | | | | +--:(range-match) + | | | | +--rw range-port-num* [start-port-num end-port-num] - | | | | | +--rw start-port-num inet:port-number - | | | | | +--rw end-port-num inet:port-number - | | | | +--rw pkt-sec-tcp-seq-num - | | | | | +--rw (match-type)? - | | | | | +--:(exact-match) - | | | | | | +--rw tcp-seq-num* uint32 - | | | | | +--:(range-match) - | | | | | +--rw range-tcp-seq-num* - [start-tcp-seq-num end-tcp-seq-num] - | | | | | +--rw start-tcp-seq-num uint32 - | | | | | +--rw end-tcp-seq-num uint32 - | | | | +--rw pkt-sec-tcp-ack-num - | | | | | +--rw (match-type)? - | | | | | +--:(exact-match) - | | | | | | +--rw tcp-ack-num* uint32 - | | | | | +--:(range-match) - | | | | | +--rw range-tcp-ack-num* - [start-tcp-ack-num end-tcp-ack-num] - | | | | | +--rw start-tcp-ack-num uint32 - | | | | | +--rw end-tcp-ack-num uint32 - | | | | +--rw pkt-sec-tcp-window-size - | | | | | +--rw (match-type)? - | | | | | +--:(exact-match) - | | | | | | +--rw tcp-window-size* uint16 - | | | | | +--:(range-match) - | | | | | +--rw range-tcp-window-size* - [start-tcp-window-size end-tcp-window-size] - | | | | | +--rw start-tcp-window-size uint16 - | | | | | +--rw end-tcp-window-size uint16 - | | | | +--rw pkt-sec-tcp-flags* identityref - | | | +--rw packet-security-udp-condition - | | | | +--rw udp-description? string - | | | | +--rw pkt-sec-udp-src-port-num - | | | | | +--rw (match-type)? - | | | | | +--:(exact-match) - | | | | | | +--rw port-num* inet:port-number - | | | | | +--:(range-match) - | | | | | +--rw range-port-num* + | | | | +--rw start-port-num inet:port-number + | | | | +--rw end-port-num inet:port-number + | | | +--rw pkt-sec-tcp-dest-port-num + | | | | +--rw (match-type)? + | | | | +--:(exact-match) + | | | | | +--rw port-num* inet:port-number + | | | | +--:(range-match) + | | | | +--rw range-port-num* [start-port-num end-port-num] - | | | | | +--rw start-port-num inet:port-number - | | | | | +--rw end-port-num inet:port-number - | | | | +--rw pkt-sec-udp-dest-port-num - | | | | | +--rw (match-type)? - | | | | | +--:(exact-match) - | | | | | | +--rw port-num* inet:port-number - | | | | | +--:(range-match) - | | | | | +--rw range-port-num* - + | | | | +--rw start-port-num inet:port-number + | | | | +--rw end-port-num inet:port-number + | | | +--rw pkt-sec-tcp-flags* identityref + | | +--rw packet-security-udp-condition + | | | +--rw udp-description? string + | | | +--rw pkt-sec-udp-src-port-num + | | | | +--rw (match-type)? + | | | | +--:(exact-match) + | | | | | +--rw port-num* inet:port-number + | | | | +--:(range-match) + | | | | +--rw range-port-num* [start-port-num end-port-num] - | | | | | +--rw start-port-num inet:port-number - | | | | | +--rw end-port-num inet:port-number - | | | | +--rw pkt-sec-udp-total-length + | | | | +--rw start-port-num inet:port-number + | | | | +--rw end-port-num inet:port-number + | | | +--rw pkt-sec-udp-dest-port-num | | | | +--rw (match-type)? | | | | +--:(exact-match) - | | | | | +--rw udp-total-length* uint32 + | | | | | +--rw port-num* inet:port-number | | | | +--:(range-match) - | | | | +--rw range-udp-total-length* + | | | | +--rw range-port-num* + [start-port-num end-port-num] + | | | | +--rw start-port-num inet:port-number + | | | | +--rw end-port-num inet:port-number + | | | +--rw pkt-sec-udp-total-length + | | | +--rw (match-type)? + | | | +--:(exact-match) + | | | | +--rw udp-total-length* uint32 + | | | +--:(range-match) + | | | +--rw range-udp-total-length* [start-udp-total-length end-udp-total-length] - | | | | +--rw start-udp-total-length uint32 - | | | | +--rw end-udp-total-length uint32 - | | | +--rw packet-security-icmp-condition - | | | | +--rw icmp-description? string - | | | | +--rw pkt-sec-icmp-type-and-code* identityref - | | | +--rw packet-security-url-category-condition - | | | | +--rw url-category-description? string - | | | | +--rw pre-defined-category* string - | | | | +--rw user-defined-category* string - | | | +--rw packet-security-voice-condition - | | | | +--rw voice-description? string - | | | | +--rw pkt-sec-src-voice-id* string - | | | | +--rw pkt-sec-dest-voice-id* string - | | | | +--rw pkt-sec-user-agent* string - | | | +--rw packet-security-ddos-condition - | | | | +--rw ddos-description? string - | | | | +--rw pkt-sec-alert-rate? uint32 - | | | +--rw packet-security-payload-condition - | | | | +--rw packet-payload-description? string - | | | | +--rw pkt-payload-content* string - | | | +--rw context-condition - | | | +--rw context-description? string - | | | +--rw application-condition - | | | | +--rw application-description? string - | | | | +--rw application-object* string - | | | | +--rw application-group* string - | | | | +--rw application-label* string - | | | | +--rw category - | | | | +--rw application-category* + | | | +--rw start-udp-total-length uint32 + | | | +--rw end-udp-total-length uint32 + | | +--rw packet-security-sctp-condition + | | | +--rw sctp-description? string + | | | +--rw pkt-sec-sctp-src-port-num + | | | | +--rw (match-type)? + | | | | +--:(exact-match) + | | | | | +--rw port-num* inet:port-number + | | | | +--:(range-match) + | | | | +--rw range-port-num* + [start-port-num end-port-num] + | | | | +--rw start-port-num inet:port-number + | | | | +--rw end-port-num inet:port-number + | | | +--rw pkt-sec-sctp-dest-port-num + | | | | +--rw (match-type)? + | | | | +--:(exact-match) + | | | | | +--rw port-num* inet:port-number + | | | | +--:(range-match) + | | | | +--rw range-port-num* + [start-port-num end-port-num] + | | | | +--rw start-port-num inet:port-number + | | | | +--rw end-port-num inet:port-number + | | | +--rw pkt-sec-sctp-verification-tag* uint32 + | | | +--rw pkt-sec-sctp-chunk-type* uint8 + | | +--rw packet-security-dccp-condition + | | | +--dccp-description? string + | | | +--rw pkt-sec-dccp-src-port-num + | | | | +--rw (match-type)? + | | | | +--:(exact-match) + | | | | | +--rw port-num* inet:port-number + | | | | +--:(range-match) + | | | | +--rw range-port-num* + [start-port-num end-port-num] + | | | | +--rw start-port-num inet:port-number + | | | | +--rw end-port-num inet:port-number + | | | +--rw pkt-sec-dccp-dest-port-num + | | | | +--rw (match-type)? + | | | | +--:(exact-match) + | | | | | +--rw port-num* inet:port-number + | | | | +--:(range-match) + | | | | +--rw range-port-num* + + [start-port-num end-port-num] + | | | | +--rw start-port-num inet:port-number + | | | | +--rw end-port-num inet:port-number + | | | +--rw pkt-sec-dccp-service-code* uint32 + | | +--rw packet-security-icmp-condition + | | | +--rw icmp-description? string + | | | +--rw pkt-sec-icmp-type-and-code* identityref + | | +--rw packet-security-url-category-condition + | | | +--rw url-category-description? string + | | | +--rw pre-defined-category* string + | | | +--rw user-defined-category* string + | | +--rw packet-security-voice-condition + | | | +--rw voice-description? string + | | | +--rw pkt-sec-src-voice-id* string + | | | +--rw pkt-sec-dest-voice-id* string + | | | +--rw pkt-sec-user-agent* string + | | +--rw packet-security-ddos-condition + | | | +--rw ddos-description? string + | | | +--rw pkt-sec-alert-packet-rate? uint32 + | | | +--rw pkt-sec-alert-flow-rate? uint32 + | | | +--rw pkt-sec-alert-byte-rate? uint32 + | | +--rw packet-security-payload-condition + | | | +--rw packet-payload-description? string + | | | +--rw pkt-payload-content* string + | | +--rw context-condition + | | +--rw context-description? string + | | +--rw application-condition + | | | +--rw application-description? string + | | | +--rw application-object* string + | | | +--rw application-group* string + | | | +--rw application-label* string + | | | +--rw category + | | | +--rw application-category* [name application-subcategory] - | | | | +--rw name string - | | | | +--rw application-subcategory string - | | | +--rw target-condition - | | | | +--rw target-description? string - | | | | +--rw device-sec-context-cond - | | | | +--rw target-device* identityref - | | | +--rw users-condition - | | | | +--rw users-description? 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 - | | | | +--rw security-group string - | | | +--rw gen-context-condition - | | | +--rw gen-context-description? string - | | | +--rw geographic-location - | | | +--rw src-geographic-location* uint32 - | | | +--rw dest-geographic-location* uint32 - | | +--rw action-clause-container - | | ... - | +--rw rule-group + | | | +--rw name string + | | | +--rw application-subcategory string + | | +--rw target-condition + | | | +--rw target-description? string + | | | +--rw device-sec-context-cond + | | | +--rw target-device* identityref + | | +--rw users-condition + | | | +--rw users-description? string + | | | +--rw user [user-name user-id] + | | | +--rw user-name* string + | | | +--rw user-id* uint32 + | | | +--rw group [group-name group-id] + | | | +--rw group-name string + | | | +--rw group-id uint32 + | | | +--rw security-group string + | | +--rw geography-context-condition + | | +--rw geography-context-description? string + | | +--rw geography-location + | | +--rw src-geography-location* string + | | +--rw dest-geography-location* string + | +--rw action-clause-container | ... - +--rw i2nsf-ipsec? identityref + +--rw rule-group + ... Figure 3: YANG Tree Diagram for a Condition Clause - This YANG tree diagram shows a condition clause for an I2NSF security - policy rule for generic network security functions. A condition - clause 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. A - condition clause is classified as a conditions of generic network - security functions, advanced network security functions, or context. - A condition clause of generic network security functions is defined - as packet security IPv4 condition, packet security IPv6 condition, - packet security tcp condition, and packet security icmp condition. A - condition clause of advanced network security functions is defined as - packet security url category condition, packet security voice - condition, packet security DDoS condition, or packet security payload - condition. A condition clause of context is defined as ACL number - condition, application condition, target condition, user condition, - and geography condition. Note that this document deals only with - simple conditions of advanced network security functions. A - condition clause of more advanced network security functions can be - defined as an extension in future. A condition clause can be - extended according to specific vendor condition features. A - condition clause is described in detail in - [I-D.ietf-i2nsf-capability]. - -4.4. Action Clause - - This section shows the YANG tree diagram for an action clause of an - I2NSF security policy rule. - - module: ietf-i2nsf-policy-rule-for-nsf - +--rw i2nsf-security-policy - | ... - | +--rw rules* [rule-name] - | | ... - | | +--rw event-clause-container - | | | ... - | | +--rw condition-clause-container - | | | ... - | | +--rw action-clause-container - | | +--rw action-clause-description? string - | | +--rw packet-action - | | | +--rw ingress-action? identityref - | | | +--rw egress-action? identityref - | | | +--rw log-action? identityref - | | +--rw advanced-action - | | +--rw content-security-control* identityref - | | +--rw attack-mitigation-control* identityref - | +--rw rule-group - | ... - +--rw i2nsf-ipsec? identityref - - Figure 4: YANG Tree Diagram for an Action Clause - - This YANG tree diagram shows an action clause of an I2NSF security - policy rule for generic network security functions. An action is - used to control and monitor aspects of flow-based NSFs when the - policy rule event and condition clauses are satisfied. NSFs provide - security services by executing various actions. The action clause is - defined as ingress action, egress action, or log action for packet - action, and advanced action for additional inspection. The action - clause can be extended according to specific vendor action features. - The action clause is described in detail in - [I-D.ietf-i2nsf-capability]. + A condition clause 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. A condition clause is classified as a condition of generic + network security functions, advanced network security functions, or + context. A condition clause of generic network security functions is + defined as packet security IPv4 condition, packet security IPv6 + condition, packet security tcp condition, and packet security icmp + condition. A condition clause of advanced network security functions + is defined as packet security url category condition, packet security + voice condition, packet security DDoS condition, or packet security + payload condition. A condition clause of context is defined as + application condition, target condition, users condition, and + geography condition. Note that this document deals only with + conditions of several advanced network security functions such as url + filter (i.e., web filter), VoIP/VoLTE security, and DDoS-attack + mitigator. A condition clause of other advanced network security + functions such as Intrusion Prevention System (IPS) and Data Loss + Prevention (DLP) can be defined as an extension in future. A + condition clause can be extended according to specific vendor + condition features. A condition clause is described in detail in + [I-D.ietf-i2nsf-capability-data-model]. -4.5. I2NSF Internet Key Exchange +3.4. Action Clause - This section shows the YANG tree diagram for an I2NSF IPsec. + This section shows a YANG tree diagram for an action clause for a + general I2NSF security policy rule for generic network security + functions. module: ietf-i2nsf-policy-rule-for-nsf +--rw i2nsf-security-policy + ... + +--rw rules* [rule-name] | ... - | +--rw rules* [rule-name] + | +--rw event-clause-container | | ... - | | +--rw event-clause-container - | | | ... - | | +--rw condition-clause-container - | | | ... - | | +--rw action-clause-container + | +--rw condition-clause-container | | ... - | +--rw rule-group - | ... - +--rw i2nsf-ipsec? identityref + | +--rw action-clause-container + | +--rw action-clause-description? string + | +--rw packet-action + | | +--rw ingress-action? identityref + | | +--rw egress-action? identityref + | | +--rw log-action? identityref + | +--rw flow-action + | | +--rw ingress-action? identityref + | | +--rw egress-action? identityref + | | +--rw log-action? identityref + | +--rw advanced-action + | +--rw content-security-control* identityref + | +--rw attack-mitigation-control* identityref + +--rw rule-group + ... - Figure 5: YANG Tree Diagram for I2NSF Internet Key Exchnage + Figure 4: YANG Tree Diagram for an Action Clause - This YANG tree diagram shows an I2NSF IPsec specification for an - Internet Key Exchange IKE). An I2NSF IPsec specification is used to - define a method required to manage IPsec parameters for creating - IPsec Security Associations (SAs) between two NSFs through either the - IKEv2 protocol or the Security Controller - [I-D.ietf-i2nsf-sdn-ipsec-flow-protection]. I2NSF IPsec considers - two cases, the IKE case (i.e., IPsec through IKE) and IKE-less case - (i.e., IPsec not through IKE, but through a Security Controller). - Refer to [I-D.ietf-i2nsf-sdn-ipsec-flow-protection] for the detailed - description of the I2NSF IPsec. + An action is used to control and monitor aspects of flow-based NSFs + when the policy rule event and condition clauses are satisfied. NSFs + provide security services by executing various actions. The action + clause is defined as ingress action, egress action, or log action for + packet action, flow action, and advanced action for additional + inspection. The packet action is an action for an individual packet + such as an IP datagram. The flow action is an action of a traffic + flow such as the packets of a TCP session (e.g., an HTTP/HTTPS + session). The advanced action is an action of an advanced action + (e.g., web filter and DDoS-attack mitigator) for either a packet or a + traffic flow. The action clause can be extended according to + specific vendor action features. The action clause is described in + detail in [I-D.ietf-i2nsf-capability-data-model]. -5. YANG Data Model of NSF-Facing Interface +4. YANG Data Model of NSF-Facing Interface The main objective of this data model is to provide both an information model and the corresponding YANG data model of I2NSF NSF- Facing Interface. This interface can be used to deliver control and management messages between Security Controller and NSFs for the I2NSF low-level security policies. - The semantics of the data model must be aligned with the information - model of the NSF-Facing Interface. The transformation of the - information model is performed so that this YANG data model can - facilitate the efficient delivery of the control or management - messages. - This data model is designed to support the I2NSF framework that can be extended according to the security needs. In other words, the model design is independent of the content and meaning of specific policies as well as the implementation approach. With the YANG data model of I2NSF NSF-Facing Interface, this document suggests use cases for security policy rules such as time-based firewall, web filter, VoIP/VoLTE security service, and DDoS-attack - mitigation in Section 6. + mitigation in Section 5. -5.1. YANG Module of NSF-Facing Interface +4.1. YANG Module of NSF-Facing Interface This section describes a YANG module of NSF-Facing Interface. This YANG module imports from [RFC6991]. It makes references to [RFC0768] - [RFC0791][RFC0792][RFC0793][RFC1700][RFC3232][RFC3261][RFC4443][RFC81 - 77][RFC8200][RFC8329][RFC8335][RFC8344]. + [RFC0791][RFC0792][RFC0793][RFC3261][RFC4443][RFC8200][RFC8329][RFC83 + 35][RFC8344][ISO-Country-Codes][IANA-Protocol-Numbers]. - file "ietf-i2nsf-policy-rule-for-nsf@2020-08-28.yang" + file "ietf-i2nsf-policy-rule-for-nsf@2021-02-02.yang" module ietf-i2nsf-policy-rule-for-nsf { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf"; prefix nsfintf; import ietf-inet-types{ prefix inet; reference "RFC 6991"; } import ietf-yang-types{ prefix yang; reference "RFC 6991"; } - import ietf-key-chain{ - prefix key-chain; - reference "RFC 8177"; - } organization "IETF I2NSF (Interface to Network Security Functions) Working Group"; contact "WG Web: WG List: Editor: Jingyong Tim Kim @@ -690,44 +649,43 @@ organization "IETF I2NSF (Interface to Network Security Functions) Working Group"; contact "WG Web: WG List: Editor: Jingyong Tim Kim - Editor: Jaehoon Paul Jeong "; description "This module is a YANG module for Network Security Functions (NSF)-Facing Interface. - Copyright (c) 2020 IETF Trust and the persons identified as + Copyright (c) 2021 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; - revision "2020-08-28"{ + revision "2021-02-02"{ description "The latest revision."; reference "RFC XXXX: I2NSF Network Security Function-Facing Interface YANG Data Model"; } /* * Identities */ @@ -739,119 +697,118 @@ identity priority-by-order { base priority-usage-type; description "Identity for priority by order"; } identity priority-by-number { base priority-usage-type; description "Identity for priority by number"; - } identity event { description "Base identity for policy events"; + reference - "draft-ietf-i2nsf-nsf-monitoring-data-model-03: I2NSF NSF + "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF Monitoring YANG Data Model - Event"; } identity system-event { base event; description "Identity for system events"; reference - "draft-ietf-i2nsf-nsf-monitoring-data-model-03: I2NSF NSF + "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF Monitoring YANG Data Model - System event"; } identity system-alarm { base event; description "Identity for system alarms"; reference - "draft-ietf-i2nsf-nsf-monitoring-data-model-03: I2NSF NSF + "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF Monitoring YANG Data Model - System alarm"; } identity access-violation { base system-event; description "Identity for access violation system events"; reference - "draft-ietf-i2nsf-nsf-monitoring-data-model-03: I2NSF NSF + "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF Monitoring YANG Data Model - System event for access violation"; } identity configuration-change { base system-event; description "Identity for configuration change system events"; reference - "draft-ietf-i2nsf-nsf-monitoring-data-model-03: I2NSF NSF + "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF Monitoring YANG Data Model - System event for configuration change"; - } identity memory-alarm { base system-alarm; description "Identity for memory alarm system alarms"; reference - "draft-ietf-i2nsf-nsf-monitoring-data-model-03: I2NSF NSF + "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF Monitoring YANG Data Model - System alarm for memory"; } identity cpu-alarm { base system-alarm; description "Identity for CPU alarm system alarms"; reference - "draft-ietf-i2nsf-nsf-monitoring-data-model-03: I2NSF NSF + "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF Monitoring YANG Data Model - System alarm for CPU"; } identity disk-alarm { base system-alarm; description "Identity for disk alarm system alarms"; reference - "draft-ietf-i2nsf-nsf-monitoring-data-model-03: I2NSF NSF + "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF Monitoring YANG Data Model - System alarm for disk"; } identity hardware-alarm { base system-alarm; description "Identity for hardware alarm system alarms"; reference - "draft-ietf-i2nsf-nsf-monitoring-data-model-03: I2NSF NSF + "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF Monitoring YANG Data Model - System alarm for hardware"; } identity interface-alarm { base system-alarm; description "Identity for interface alarm system alarms"; reference - "draft-ietf-i2nsf-nsf-monitoring-data-model-03: I2NSF NSF + "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF Monitoring YANG Data Model - System alarm for interface"; } identity type-of-service { description "Base identity for type of service of IPv4"; reference "RFC 791: Internet Protocol - Type of Service"; } @@ -962,124 +918,116 @@ description "Identity for reserved flags"; reference "RFC 791: Internet Protocol - Fragmentation Flags"; } identity protocol { description "Base identity for protocol of IPv4"; reference - "RFC 3232: Assigned Numbers: RFC 1700 is Replaced by an - On-line Database + "IANA: Assigned Internet Protocol Numbers RFC 791: Internet Protocol - Protocol"; } identity next-header { description "Base identity for IPv6 next header"; reference "RFC 8200: Internet Protocol, Version 6 (IPv6) Specification - Next Header"; } identity icmp { base protocol; base next-header; description "Identity for ICMP IPv4 protocol and - IPv6 nett header"; + IPv6 next header"; reference - "RFC 3232: Assigned Numbers: RFC 1700 is Replaced by an - On-line Database + "IANA: Assigned Internet Protocol Numbers RFC 791: Internet Protocol - Protocol RFC 8200: Internet Protocol, Version 6 (IPv6) Specification - Next Header"; } - identity igmp { base protocol; base next-header; description "Identity for IGMP IPv4 protocol and IPv6 next header"; reference - "RFC 3232: Assigned Numbers: RFC 1700 is Replaced by an - On-line Database + "IANA: Assigned Internet Protocol Numbers RFC 791: Internet Protocol - Protocol RFC 8200: Internet Protocol, Version 6 (IPv6) Specification - Next Header"; } identity tcp { base protocol; base next-header; description "Identity for TCP protocol"; reference - "RFC 3232: Assigned Numbers: RFC 1700 is Replaced by an - On-line Database + "IANA: Assigned Internet Protocol Numbers RFC 791: Internet Protocol - Protocol RFC 8200: Internet Protocol, Version 6 (IPv6) Specification - Next Header"; } identity igrp { base protocol; base next-header; description "Identity for IGRP IPv4 protocol and IPv6 next header"; reference - "RFC 3232: Assigned Numbers: RFC 1700 is Replaced by an - On-line Database + "IANA: Assigned Internet Protocol Numbers RFC 791: Internet Protocol - Protocol RFC 8200: Internet Protocol, Version 6 (IPv6) Specification - Next Header"; } + identity udp { base protocol; base next-header; description "Identity for UDP IPv4 protocol and IPv6 next header"; reference - "RFC 3232: Assigned Numbers: RFC 1700 is Replaced by an - On-line Database + "IANA: Assigned Internet Protocol Numbers RFC 791: Internet Protocol - Protocol RFC 8200: Internet Protocol, Version 6 (IPv6) Specification - Next Header"; } identity gre { base protocol; base next-header; description "Identity for GRE IPv4 protocol and IPv6 next header"; reference - "RFC 3232: Assigned Numbers: RFC 1700 is Replaced by an - On-line Database + "IANA: Assigned Internet Protocol Numbers RFC 791: Internet Protocol - Protocol RFC 8200: Internet Protocol, Version 6 (IPv6) Specification - Next Header"; } identity esp { base protocol; base next-header; description "Identity for ESP IPv4 protocol and IPv6 next header"; reference - "RFC 3232: Assigned Numbers: RFC 1700 is Replaced by an - On-line Database + "IANA: Assigned Internet Protocol Numbers RFC 791: Internet Protocol - Protocol RFC 8200: Internet Protocol, Version 6 (IPv6) Specification - Next Header"; } identity ah { base protocol; base next-header; description "Identity for AH IPv4 protocol @@ -1077,24 +1025,22 @@ RFC 8200: Internet Protocol, Version 6 (IPv6) Specification - Next Header"; } identity ah { base protocol; base next-header; description "Identity for AH IPv4 protocol and IPv6 next header"; - reference - "RFC 3232: Assigned Numbers: RFC 1700 is Replaced by an - On-line Database + "IANA: Assigned Internet Protocol Numbers RFC 791: Internet Protocol - Protocol RFC 8200: Internet Protocol, Version 6 (IPv6) Specification - Next Header"; } identity mobile { base protocol; base next-header; description "Identity for mobile IPv4 protocol @@ -1092,108 +1038,101 @@ RFC 8200: Internet Protocol, Version 6 (IPv6) Specification - Next Header"; } identity mobile { base protocol; base next-header; description "Identity for mobile IPv4 protocol and IPv6 next header"; + reference - "RFC 3232: Assigned Numbers: RFC 1700 is Replaced by an - On-line Database + "IANA: Assigned Internet Protocol Numbers RFC 791: Internet Protocol - Protocol RFC 8200: Internet Protocol, Version 6 (IPv6) Specification - Next Header"; } identity tlsp { base protocol; base next-header; description "Identity for TLSP IPv4 protocol and IPv6 next header"; reference - "RFC 3232: Assigned Numbers: RFC 1700 is Replaced by an - On-line Database + "IANA: Assigned Internet Protocol Numbers RFC 791: Internet Protocol - Protocol RFC 8200: Internet Protocol, Version 6 (IPv6) Specification - Next Header"; } identity skip { base protocol; base next-header; description "Identity for skip IPv4 protocol and IPv6 next header"; reference - "RFC 3232: Assigned Numbers: RFC 1700 is Replaced by an - On-line Database + "IANA: Assigned Internet Protocol Numbers RFC 791: Internet Protocol - Protocol RFC 8200: Internet Protocol, Version 6 (IPv6) Specification - Next Header"; - } identity ipv6-icmp { base protocol; base next-header; description "Identity for IPv6 ICMP next header"; reference - "RFC 3232: Assigned Numbers: RFC 1700 is Replaced by an - On-line Database + "IANA: Assigned Internet Protocol Numbers RFC 4443: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification RFC 8200: Internet Protocol, Version 6 (IPv6) Specification - Next Header"; } identity eigrp { base protocol; base next-header; description "Identity for EIGRP IPv4 protocol and IPv6 next header"; reference - "RFC 3232: Assigned Numbers: RFC 1700 is Replaced by an - On-line Database + "IANA: Assigned Internet Protocol Numbers RFC 791: Internet Protocol - Protocol RFC 8200: Internet Protocol, Version 6 (IPv6) Specification - Next Header"; } identity ospf { base protocol; base next-header; description "Identity for OSPF IPv4 protocol and IPv6 next header"; reference - "RFC 3232: Assigned Numbers: RFC 1700 is Replaced by an - On-line Database + "IANA: Assigned Internet Protocol Numbers RFC 791: Internet Protocol - Protocol RFC 8200: Internet Protocol, Version 6 (IPv6) Specification - Next Header"; } identity l2tp { base protocol; base next-header; description "Identity for L2TP IPv4 protocol and IPv6 next header"; reference - "RFC 3232: Assigned Numbers: RFC 1700 is Replaced by an - On-line Database + "IANA: Assigned Internet Protocol Numbers RFC 791: Internet Protocol - Protocol RFC 8200: Internet Protocol, Version 6 (IPv6) Specification - Next Header"; } identity ipopts { description "Base identity for IP options"; reference "RFC 791: Internet Protocol - Options"; @@ -1826,314 +1775,357 @@ in extended echo reply types"; reference "RFC 792: Internet Control Message Protocol RFC 8335: PROBE: A Utility for Probing Interfaces"; } identity target-device { description "Base identity for target devices"; reference - "draft-ietf-i2nsf-capability-05: Information Model - of NSFs Capabilities"; + "draft-ietf-i2nsf-capability-data-model-15: + I2NSF Capability YANG Data Model"; } - identity pc { + identity computer { base target-device; description - "Identity for pc"; + "Identity for computer such as personal computer (PC) + and server"; } identity mobile-phone { base target-device; description - "Identity for mobile-phone"; + "Identity for mobile-phone such as smartphone and + cellphone"; } identity voip-volte-phone { base target-device; description "Identity for voip-volte-phone"; } identity tablet { base target-device; description "Identity for tablet"; } + identity network-infrastructure-device { + base target-device; + description + "Identity for network infrastructure devices + such as switch, router, and access point"; + } identity iot { base target-device; description - "Identity for IoT"; + "Identity for IoT (Internet of Things)"; } identity vehicle { base target-device; description - "Identity for vehicle"; + "Identity for vehicle that connects to and shares + data through the Internet"; } identity content-security-control { description "Base identity for content security control"; reference "RFC 8329: Framework for Interface to - Network Security Functions - Differences - from ACL Data Models - draft-ietf-i2nsf-capability-05: Information Model - of NSFs Capabilities"; + Network Security Functions - Flow-Based + NSF Capability Characterization + draft-ietf-i2nsf-capability-data-model-15: + I2NSF Capability YANG Data Model"; + } + + identity firewall { + base content-security-control; + description + "Identity for firewall that monitors + incoming and outgoing network traffic + and permits or blocks data packets based + on a set of security rules."; } identity antivirus { base content-security-control; description - "Identity for antivirus"; + "Identity for antivirus that prevents, + scans, detects and deletes viruses + from a computer"; } identity ips { base content-security-control; description - "Identity for ips"; + "Identity for IPS (Intrusion Prevention System) + that prevents malicious activity within a network"; } - identity ids { base content-security-control; description - "Identity for ids"; + "Identity for IDS (Intrusion Detection System) + that detects malicious activity within a network"; } identity url-filtering { base content-security-control; description - "Identity for url filtering"; + "Identity for url filtering that + limits access by comparing the web traffic's URL + with the URLs for web filtering in a database"; } identity mail-filtering { base content-security-control; description - "Identity for mail filtering"; + "Identity for mail filtering that + filters out a malicious email message by + comparing its sender email address with the email + addresses of malicious users in a database"; } identity file-blocking { base content-security-control; description - "Identity for file blocking"; - } - - identity file-isolate { - base content-security-control; - description - "Identity for file isolate"; + "Identity for file blocking that blocks the + download or upload of malicious files with the + information of suspicious files in a database"; } identity pkt-capture { base content-security-control; description - "Identity for packet capture"; + "Identity for packet capture that + intercepts a packet that is crossing or moving + over a specific network."; } identity application-control { base content-security-control; description - "Identity for application control"; + "Identity for application control that + filters out the packets of malicious applications + with the information of those applications in a + database"; } - identity voip-volte { base content-security-control; description - "Identity for voip and volte"; + "Identity for VoIP/VoLTE security service that + filters out the packets of malicious users + with a blacklist of malicious users in a database"; } identity attack-mitigation-control { description "Base identity for attack mitigation control"; reference "RFC 8329: Framework for Interface to - Network Security Functions - Differences - from ACL Data Models - draft-ietf-i2nsf-capability-05: Information Model - of NSFs Capabilities"; + Network Security Functions - Flow-Based + NSF Capability Characterization + draft-ietf-i2nsf-capability-data-model-15: + I2NSF Capability YANG Data Model"; } identity syn-flood { base attack-mitigation-control; description - "Identity for syn flood"; + "Identity for syn flood + that weakens the SYN flood attack"; } identity udp-flood { base attack-mitigation-control; description - "Identity for udp flood"; + "Identity for udp flood + that weakens the UDP flood attack"; } identity icmp-flood { base attack-mitigation-control; description - "Identity for icmp flood"; + "Identity for icmp flood + that weakens the ICMP flood attack"; } identity ip-frag-flood { base attack-mitigation-control; description - "Identity for ip frag flood"; + "Identity for ip frag flood + that weakens the IP fragmentation flood attack"; } - identity ipv6-related { + identity http-and-https-flood { base attack-mitigation-control; description - "Identity for ipv6 related"; + "Identity for http and https flood + that weakens the HTTP and HTTPS flood attack"; } - identity http-and-https-flood { + identity dns-flood { base attack-mitigation-control; description - "Identity for http and https flood"; + "Identity for dns flood + that weakens the DNS flood attack"; } - identity dns-flood { + identity dns-amp-flood { base attack-mitigation-control; description - "Identity for dns flood"; + "Identity for dns amp flood + that weakens the DNS amplification flood attack"; } - identity dns-amp-flood { + identity ntp-amp-flood { base attack-mitigation-control; description - "Identity for dns amp flood"; + "Identity for ntp amp flood + that weakens the NTP amplification flood attack"; } identity ssl-ddos { base attack-mitigation-control; description - "Identity for ssl ddos"; + "Identity for ssl ddos + that weakens the SSL DDoS attack"; } identity ip-sweep { base attack-mitigation-control; description - "Identity for ip sweep"; + "Identity for ip sweep + that weakens the IP sweep attack"; } identity port-scanning { base attack-mitigation-control; description - "Identity for port scanning"; + "Identity for port scanning + that weakens the port scanning attack"; } - identity ping-of-death { base attack-mitigation-control; description - "Identity for ping of death"; + "Identity for ping-of-death + that weakens the ping-of-death attack"; } identity teardrop { base attack-mitigation-control; description - "Identity for teardrop"; + "Identity for teardrop + that weakens the teardrop attack"; } identity oversized-icmp { base attack-mitigation-control; description - "Identity for oversized icmp"; + "Identity for oversized icmp + that weakens the oversized icmp attack"; } identity tracert { base attack-mitigation-control; description - "Identity for tracert"; + "Identity for tracert + that weakens the tracert attack"; } identity ingress-action { description "Base identity for action"; reference - "draft-ietf-i2nsf-capability-05: Information Model - of NSFs Capabilities - Ingress Action"; + "draft-ietf-i2nsf-capability-data-model-15: + I2NSF Capability YANG Data Model - Ingress Action"; } identity egress-action { description "Base identity for egress action"; reference - "draft-ietf-i2nsf-capability-05: Information Model - of NSFs Capabilities - Egress action"; + "draft-ietf-i2nsf-capability-data-model-15: + I2NSF Capability YANG Data Model - Egress Action"; } identity default-action { description "Base identity for default action"; reference - "draft-ietf-i2nsf-capability-05: Information Model - of NSFs Capabilities - Default action"; + "draft-ietf-i2nsf-capability-data-model-15: + I2NSF Capability YANG Data Model - Default Action"; } identity pass { base ingress-action; base egress-action; base default-action; description "Identity for pass"; reference - "draft-ietf-i2nsf-capability-05: Information Model - of NSFs Capabilities - Actions and - default action"; + "draft-ietf-i2nsf-capability-data-model-15: + I2NSF Capability YANG Data Model - Actions and + Default Action"; } identity drop { base ingress-action; base egress-action; base default-action; description "Identity for drop"; reference - "draft-ietf-i2nsf-capability-05: Information Model - of NSFs Capabilities - Actions and - default action"; + "draft-ietf-i2nsf-capability-data-model-15: + I2NSF Capability YANG Data Model - Actions and + Default Action"; } identity reject { base ingress-action; base egress-action; base default-action; description "Identity for reject"; reference - "draft-ietf-i2nsf-capability-05: Information Model - of NSFs Capabilities - Actions and - default action"; + "draft-ietf-i2nsf-capability-data-model-15: + I2NSF Capability YANG Data Model - Actions and + Default Action"; } identity alert { base ingress-action; base egress-action; base default-action; description "Identity for alert"; reference - "draft-ietf-i2nsf-capability-05: Information Model - of NSFs Capabilities - Actions and - default action"; + "draft-ietf-i2nsf-capability-data-model-15: + + I2NSF Capability YANG Data Model - Actions and + Default Action"; } identity mirror { base ingress-action; base egress-action; base default-action; description "Identity for mirror"; reference - "draft-ietf-i2nsf-capability-05: Information Model - of NSFs Capabilities - Actions and - default action"; + "draft-ietf-i2nsf-capability-data-model-15: + I2NSF Capability YANG Data Model - Actions and + Default Action"; } identity log-action { description "Base identity for log action"; } identity rule-log { base log-action; description @@ -2169,106 +2160,113 @@ base egress-action; description "Identity for redirection"; } identity resolution-strategy { description "Base identity for resolution strategy"; reference - "draft-ietf-i2nsf-capability-05: Information Model - of NSFs Capabilities - Resolution Strategy"; + "draft-ietf-i2nsf-capability-data-model-15: + I2NSF Capability YANG Data Model - Resolution Strategy"; } identity fmr { base resolution-strategy; description "Identity for First Matching Rule (FMR)"; reference - "draft-ietf-i2nsf-capability-05: Information Model - of NSFs Capabilities - Resolution Strategy"; - + "draft-ietf-i2nsf-capability-data-model-15: + I2NSF Capability YANG Data Model - Resolution Strategy"; } identity lmr { base resolution-strategy; description "Identity for Last Matching Rule (LMR)"; reference - "draft-ietf-i2nsf-capability-05: Information Model - of NSFs Capabilities - Resolution Strategy"; + "draft-ietf-i2nsf-capability-data-model-15: + I2NSF Capability YANG Data Model - Resolution Strategy"; } identity pmr { base resolution-strategy; description "Identity for Prioritized Matching Rule (PMR)"; reference - "draft-ietf-i2nsf-capability-05: Information Model - of NSFs Capabilities - Resolution Strategy"; + "draft-ietf-i2nsf-capability-data-model-15: + I2NSF Capability YANG Data Model - Resolution Strategy"; } identity pmre { base resolution-strategy; description "Identity for Prioritized Matching Rule with Errors (PMRE)"; reference - "draft-ietf-i2nsf-capability-05: Information Model - of NSFs Capabilities - Resolution Strategy"; + "draft-ietf-i2nsf-capability-data-model-15: + I2NSF Capability YANG Data Model - Resolution Strategy"; } identity pmrn { base resolution-strategy; description "Identity for Prioritized Matching Rule with No Errors (PMRN)"; reference - "draft-ietf-i2nsf-capability-05: Information Model - of NSFs Capabilities - Resolution Strategy"; + "draft-ietf-i2nsf-capability-data-model-15: + I2NSF Capability YANG Data Model - Resolution Strategy"; } - identity i2nsf-ipsec { - description - "Internet Key Exchnage (IKE) for NSFs - in the I2NSF framework"; - reference - "draft-ietf-i2nsf-sdn-ipsec-flow-protection-08: Software-Defined - Networking (SDN)-based IPsec Flow Protection - IPsec method - types can be selected."; + /* + * Typedefs + */ + typedef start-time-type { + type union { + type string { + pattern '\d{2}:\d{2}:\d{2}(\.\d+)?' + + '(Z|[\+\-]\d{2}:\d{2})'; } - identity ike { - base i2nsf-ipsec; + type enumeration { + enum right-away { description - "IKE case: IPsec with IKE in the NSF"; - reference - "draft-ietf-i2nsf-sdn-ipsec-flow-protection-08: Software-Defined - Networking (SDN)-based IPsec Flow Protection - IPsec method - type with IKE is selected."; + "Immediate rule execution + in the system."; + } + } } - identity ikeless { - base i2nsf-ipsec; description - "IKEless case: IPsec without IKEv2 in the NSF"; - reference - "draft-ietf-i2nsf-sdn-ipsec-flow-protection-08: Software-Defined - Networking (SDN)-based IPsec Flow Protection - IPsec method - type without IKE is selected."; + "Start time when the rules are applied."; } - /* - * Typedefs - */ + typedef end-time-type { + type union { + type string { + pattern '\d{2}:\d{2}:\d{2}(\.\d+)?' + + '(Z|[\+\-]\d{2}:\d{2})'; + } + + type enumeration { + enum infinitely { + description + "Infinite rule execution + in the system."; + } + } + } + description + "End time when the rules are applied."; + } typedef day-type { type enumeration { enum sunday { description "Sunday for periodic day"; } enum monday { description "Monday for periodic day"; @@ -2547,23 +2541,23 @@ including a set of security rules according to certain logic, i.e., their similarity or mutual relations, etc. The network security policy can be applied to both the unidirectional and bidirectional traffic across the NSF. The I2NSF security policies use the Event-Condition-Action (ECA) policy model "; reference "RFC 8329: Framework for Interface to Network Security Functions - I2NSF Flow Security Policy Structure - draft-ietf-i2nsf-capability-05: Information Model - of NSFs Capabilities - Design Principles and ECA Policy Model - Overview"; + draft-ietf-i2nsf-capability-data-model-15: + I2NSF Capability YANG Data Model - Design Principles and + ECA Policy Model Overview"; list system-policy { key "system-policy-name"; description "The system-policy represents there could be multiple system policies in one NSF, and each system policy is used by one virtual instance of the NSF/device."; leaf system-policy-name { type string; @@ -2586,38 +2581,38 @@ base resolution-strategy; } default fmr; description "The resolution strategies that can be used to specify how to resolve conflicts that occur between actions of the same or different policy rules that are matched and contained in this particular NSF"; reference - "draft-ietf-i2nsf-capability-05: Information Model - of NSFs Capabilities - Resolution strategy"; + "draft-ietf-i2nsf-capability-data-model-15: + I2NSF Capability YANG Data Model - Resolution strategy"; } leaf default-action { type identityref { base default-action; } default alert; 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."; reference - "draft-ietf-i2nsf-capability-05: Information Model - of NSFs Capabilities - Default action"; + "draft-ietf-i2nsf-capability-data-model-15: + I2NSF Capability YANG Data Model - Default Action"; } list rules { key "rule-name"; description "This is a rule for network security functions."; leaf rule-name { type string; description @@ -2630,78 +2625,76 @@ "This description gives more information about rules."; } leaf rule-priority { type uint8 { range "1..255"; } description "The priority keyword comes with a mandatory - numeric value which can range from 1 till 255."; + numeric value which can range from 1 till 255. + Note that a higher number means a higher priority"; } leaf rule-enable { type boolean; description "True is enable. False is not enable."; } leaf session-aging-time { type uint16; + units "second"; description "This is session aging time."; } container long-connection { description "This is long-connection"; leaf enable { type boolean; description "True is enable. - False is not enbale."; + False is not enable."; } leaf duration { type uint16; description "This is the duration of the long-connection."; } } container time-intervals { description "Time zone when the rules are applied"; container absolute-time-interval { description "Rule execution according to the absolute time. The absolute time interval means the exact time to start or end."; - container start-time { - uses "key-chain:lifetime"; + leaf start-time { + type start-time-type; + default right-away; description "Start time when the rules are applied"; - reference - "RFC 8177: YANG Data Model for Key Chains - - lifetime"; } - container end-time { - uses "key-chain:lifetime"; + leaf end-time { + type end-time-type; + default infinitely; description "End time when the rules are applied"; - reference - "RFC 8177: YANG Data Model for Key Chains - - lifetime"; } } container periodic-time-interval { description "Rule execution according to the periodic time. The periodic time interval means the repeated time such as a day, week, or month."; container day { @@ -2751,44 +2744,44 @@ managed. When used in the context of policy rules for a flow-based NSF, it is used to determine whether the Condition clause of the Policy Rule can be evaluated or not. Examples of an I2NSF event include time and user actions (e.g., logon, logoff, and actions that violate any ACL.)."; reference "RFC 8329: Framework for Interface to Network Security Functions - I2NSF Flow Security Policy Structure - draft-ietf-i2nsf-capability-05: Information Model - of NSFs Capabilities - Design Principles and ECA - Policy Model Overview - draft-ietf-i2nsf-nsf-monitoring-data-model-03: I2NSF + draft-ietf-i2nsf-capability-data-model-15: + I2NSF Capability YANG Data Model - Design Principles and + ECA Policy Model Overview + draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF Monitoring YANG Data Model - Alarms, Events, Logs, and Counters"; leaf event-clause-description { type string; description "Description for an event clause"; } container event-clauses { description "System Event Clause - either a system event or system alarm"; reference "RFC 8329: Framework for Interface to Network Security Functions - I2NSF Flow Security Policy Structure - draft-ietf-i2nsf-capability-05: Information Model - of NSFs Capabilities - Design Principles and ECA Policy - Model Overview - draft-ietf-i2nsf-nsf-monitoring-data-model-03: I2NSF + draft-ietf-i2nsf-capability-data-model-15: + I2NSF Capability YANG Data Model - Design Principles and + ECA Policy Model Overview + draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF Monitoring YANG Data Model - Alarms, Events, Logs, and Counters"; leaf-list system-event { type identityref { base system-event; } description "The security policy rule according to system events."; @@ -2812,30 +2805,29 @@ 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."; reference "RFC 8329: Framework for Interface to Network Security Functions - I2NSF Flow Security Policy Structure - draft-ietf-i2nsf-capability-05: Information Model - of NSFs Capabilities - Design Principles and ECA Policy - Model Overview"; + draft-ietf-i2nsf-capability-data-model-15: + I2NSF Capability YANG Data Model - Design Principles and + ECA Policy Model Overview"; leaf condition-clause-description { type string; description "Description for a condition clause."; } - container packet-security-ipv4-condition { description "The purpose of this container is to represent IPv4 packet header information to determine if the set of policy actions in this ECA policy rule should be executed or not."; reference "RFC 791: Internet Protocol"; leaf ipv4-description { @@ -2834,21 +2826,21 @@ "The purpose of this container is to represent IPv4 packet header information to determine if the set of policy actions in this ECA policy rule should be executed or not."; reference "RFC 791: Internet Protocol"; leaf ipv4-description { type string; description - "ipv4 condition texual description."; + "ipv4 condition textual description."; } container pkt-sec-ipv4-header-length { choice match-type { description "Security policy IPv4 Header length match - exact match and range match."; case exact-match { leaf-list ipv4-header-length { type uint8 { @@ -3087,25 +3075,25 @@ type boolean; description "Match on packets with the same IPv4 source and IPv4 destination address."; } leaf-list pkt-sec-ipv4-geo-ip { type string; description "The geo-ip 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 - uses GeoIP API with MaxMind database format."; - + source and destination IP addresses of network + traffic and to see to which country it belongs."; + reference + "ISO 3166: Codes for the representation of + names of countries and their subdivisions"; } } container packet-security-ipv6-condition { description "The purpose of this container is to represent IPv6 packet header information to determine if the set of policy actions in this ECA policy rule should be executed or not."; reference @@ -3316,140 +3304,20 @@ container pkt-sec-tcp-dest-port-num { uses pkt-sec-port-number; description "The security policy rule according to tcp destination port number."; reference "RFC 793: Transmission Control Protocol - Port number"; } - container pkt-sec-tcp-seq-num { - choice match-type { - description - "There are two types to configure a security - policy for tcp sequence number, - such as exact match and range match."; - case exact-match { - leaf-list tcp-seq-num { - type uint32; - description - "Exact match for an tcp sequence number."; - } - } - case range-match { - list range-tcp-seq-num { - key "start-tcp-seq-num end-tcp-seq-num"; - leaf start-tcp-seq-num { - type uint32; - description - "Start tcp sequence number for a range match."; - } - leaf end-tcp-seq-num { - type uint32; - description - "End tcp sequence number for a range match."; - } - description - "Range match for a tcp sequence number."; - } - } - } - description - "The security policy rule according to - tcp sequence number."; - reference - "RFC 793: Transmission Control Protocol - - Sequence number"; - } - - container pkt-sec-tcp-ack-num { - choice match-type { - description - "There are two types to configure a security - policy for tcp acknowledgement number, - such as exact match and range match."; - case exact-match { - leaf-list tcp-ack-num { - type uint32; - description - "Exact match for an tcp acknowledgement number."; - } - } - case range-match { - list range-tcp-ack-num { - key "start-tcp-ack-num end-tcp-ack-num"; - leaf start-tcp-ack-num { - type uint32; - description - "Start tcp acknowledgement number - for a range match."; - } - leaf end-tcp-ack-num { - type uint32; - description - "End tcp acknowledgement number - for a range match."; - } - description - "Range match for a tcp acknowledgement number."; - } - } - } - description - "The security policy rule according to - tcp acknowledgement number."; - reference - "RFC 793: Transmission Control Protocol - - Acknowledgement number"; - } - - container pkt-sec-tcp-window-size { - choice match-type { - description - "There are two types to configure a security - policy for tcp window size, - such as exact match and range match."; - case exact-match { - leaf-list tcp-window-size { - type uint16; - description - "Exact match for an tcp window size."; - } - } - case range-match { - list range-tcp-window-size { - key "start-tcp-window-size end-tcp-window-size"; - leaf start-tcp-window-size { - type uint16; - description - "Start tcp window size for a range match."; - } - leaf end-tcp-window-size { - type uint16; - description - "End tcp window size for a range match."; - } - description - "Range match for a tcp window size."; - } - } - - } - description - "The security policy rule according to - tcp window size."; - reference - "RFC 793: Transmission Control Protocol - - Window size"; - } - leaf-list pkt-sec-tcp-flags { type identityref { base tcp-flags; } description "The security policy rule according to tcp flags."; reference "RFC 793: Transmission Control Protocol - Flags"; @@ -3470,23 +3338,25 @@ description "This is description for udp condition."; } container pkt-sec-udp-src-port-num { uses pkt-sec-port-number; description "The security policy rule according to udp source port number."; reference - "RFC 793: Transmission Control Protocol - - Port number"; + "RFC 768: User Datagram Protocol + - Total Length"; + } + container pkt-sec-udp-dest-port-num { uses pkt-sec-port-number; description "The security policy rule according to udp destination port number."; reference "RFC 768: User Datagram Protocol - Total Length"; } @@ -3521,21 +3391,121 @@ } } } description "The security policy rule according to udp total length."; reference "RFC 768: User Datagram Protocol - Total Length"; } + } + container packet-security-sctp-condition { + description + "The purpose of this container is to represent + SCTP packet header information to determine + if the set of policy actions in this ECA policy + rule should be executed or not."; + leaf sctp-description { + type string; + description + "This is description for sctp condition."; + } + + container pkt-sec-sctp-src-port-num { + uses pkt-sec-port-number; + description + "The security policy rule according to + sctp source port number."; + reference + "RFC 4960: Stream Control Transmission Protocol + - Port number"; + } + + container pkt-sec-sctp-dest-port-num { + uses pkt-sec-port-number; + description + "The security policy rule according to + sctp destination port number."; + reference + "RFC 4960: Stream Control Transmission Protocol + - Total Length"; + } + + leaf-list pkt-sec-sctp-verification-tag { + type uint32; + description + "The security policy rule according to + udp total length."; + reference + "RFC 4960: Stream Control Transmission Protocol + - Verification Tag"; + } + leaf-list pkt-sec-sctp-chunk-type { + type uint8; + description + "The security policy rule according to + sctp chunk type ID Value."; + reference + "RFC 4960: Stream Control Transmission Protocol + - Chunk Type"; + } + } + + container packet-security-dccp-condition { + description + "The purpose of this container is to represent + DCCP packet header information to determine + if the set of policy actions in this ECA policy + rule should be executed or not."; + leaf dccp-description { + type string; + description + "This is description for dccp condition."; + } + + container pkt-sec-dccp-src-port-num { + uses pkt-sec-port-number; + description + "The security policy rule according to + dccp source port number."; + reference + "RFC 4340: Datagram Congestion Control Protocol (DCCP) + - Port number"; + } + + container pkt-sec-dccp-dest-port-num { + uses pkt-sec-port-number; + description + "The security policy rule according to + dccp destination port number."; + reference + "RFC 4340: Datagram Congestion Control Protocol (DCCP) + - Port number"; + } + + leaf-list pkt-sec-dccp-service-code { + type uint32; + description + "The security policy rule according to + dccp service code."; + + reference + "RFC 4340: Datagram Congestion Control Protocol (DCCP) + - Service Codes + RFC 5595: The Datagram Congestion Control Protocol (DCCP) + Service Codes + RFC 6335: Internet Assigned Numbers Authority (IANA) + Procedures for the Management of the Service Name and + Transport Protocol Port Number Registry - Service Code"; + } } container packet-security-icmp-condition { description "The purpose of this container is to represent ICMP packet header information to determine if the set of policy actions in this ECA policy rule should be executed or not."; reference "RFC 792: Internet Control Message Protocol @@ -3559,23 +3529,23 @@ RFC 8335: PROBE: A Utility for Probing Interfaces"; } } container packet-security-url-category-condition { description "Condition for url category"; leaf url-category-description { type string; description - "This is description for url category condition. - Vendors can write instructions for context condition - that vendor made"; + "This is description for the condition of a URL's + category such as SNS sites, game sites, ecommerce + sites, company sites, and university sites."; } leaf-list pre-defined-category { type string; description "This is pre-defined-category."; } leaf-list user-defined-category { type string; description @@ -3630,57 +3600,66 @@ container packet-security-ddos-condition { description "Condition for DDoS attack."; leaf ddos-description { type string; description "This is description for ddos condition."; } - leaf pkt-sec-alert-rate { + leaf pkt-sec-alert-packet-rate { type uint32; + units "pps"; description - "The alert rate of flood detect for - same packets."; + "The alert rate of flood detection for + packets per second (PPS) of an IP address."; + } + + leaf pkt-sec-alert-flow-rate { + type uint32; + description + "The alert rate of flood detection for + flows per second of an IP address."; + } + + leaf pkt-sec-alert-byte-rate { + type uint32; + units "BPS"; + description + "The alert rate of flood detection for + bytes per second of an IP address."; } } container packet-security-payload-condition { description "Condition for packet payload"; leaf packet-payload-description { type string; description - "This is description for payload condition. - Vendors can write instructions for payload condition - that vendor made"; + "This is description for payload condition."; } 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."; + "This is a condition for packet payload content."; } } container context-condition { description "Condition for context"; leaf context-description { type string; description - "This is description for context condition. - Vendors can write instructions for context condition - that vendor made"; + "This is description for context condition."; } container application-condition { description "Condition for application"; leaf application-description { type string; description "This is description for application condition."; } @@ -3747,182 +3726,197 @@ } } } container users-condition { description "Condition for users"; leaf users-description { type string; description - "This is description for user condition. - Vendors can write instructions for user condition - that vendor made"; + "This is the description for users' condition."; } - container user{ + list 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 + authentication mode and so on. + id is often used in the security policy to + identify the user. + Besides, an 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 + an NSF is able to enforce the security functions over the given user (or user group)"; - - choice user-name { - description - "The name of the user."; - - case tenant { - description - "Tenant information."; - - leaf tenant { - type uint8; + key "user-id"; + leaf user-id { + type uint32; description - "User's tenant information."; - } + "The ID of the user."; } - - case vn-id { - description - "VN-ID information."; - - leaf vn-id { - type uint8; + leaf user-name { + type string; description - "User's VN-ID information."; - } - } + "The name of the user."; } } - - container group { + list 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, - 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 + authentication mode and so on. + id is often used in the security policy to + identify the user. + Besides, an 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 + an NSF is able to enforce the security functions over the given user (or user group)"; - - choice group-name { - description - "The name of the user."; - - case tenant { - description - "Tenant information."; - - leaf tenant { - type uint8; + key "group-id"; + leaf group-id { + type uint32; description - "User's tenant information."; - } + "The ID of the group."; } - - case vn-id { - description - "VN-ID information."; - - leaf vn-id { - type uint8; + leaf group-name { + type string; description - "User's VN-ID information."; - } - } + "The name of the group."; } } leaf security-group { type string; description "security-group."; } } - container gen-context-condition { + container geography-context-condition { description "Condition for generic context"; - leaf gen-context-description { + leaf geography-context-description { type string; description "This is description for generic context condition. Vendors can write instructions for generic context condition that vendor made"; } - container geographic-location { + container geography-location { description - "The location where network traffic is associated - with. The region can be the geographic location + "The location which network traffic flow is associated + with. The region can be the geographical 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; + leaf-list src-geography-location { + type string; description - "This is mapped to ip address. We can acquire - source region through ip address stored in the - database."; + "The src-geography-location is a geographical + location mapped into an IP address. It matches the + mapped IP address to the source IP address of the + traffic flow."; + reference + "ISO 3166: Codes for the representation of + names of countries and their subdivisions"; } - leaf-list dest-geographic-location { - type uint32; + + leaf-list dest-geography-location { + type string; description - "This is mapped to ip address. We can acquire - destination region through ip address stored - in the database."; + "The dest-geography-location is a geographical + location mapped into an IP address. It matches the + mapped IP address to the destination IP address of + the traffic flow."; + reference + "ISO 3166: Codes for the representation of + names of countries and their subdivisions"; } } } } } container action-clause-container { 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."; reference "RFC 8329: Framework for Interface to Network Security Functions - I2NSF Flow Security Policy Structure - draft-ietf-i2nsf-capability-05: Information Model - of NSFs Capabilities - Design Principles and ECA Policy - Model Overview"; + draft-ietf-i2nsf-capability-data-model-15: + I2NSF Capability YANG Data Model - Design Principles and + ECA Policy Model Overview"; leaf action-clause-description { type string; description "Description for an action clause."; } container packet-action { description "Action for packets"; reference "RFC 8329: Framework for Interface to Network Security Functions - I2NSF Flow Security Policy Structure - draft-ietf-i2nsf-capability-05: Information Model - of NSFs Capabilities - Design Principles and ECA - Policy Model Overview"; + draft-ietf-i2nsf-capability-data-model-15: + I2NSF Capability YANG Data Model - Design Principles and + ECA Policy Model Overview"; + + leaf ingress-action { + type identityref { + base ingress-action; + + } + description + "Action: pass, drop, reject, alert, and mirror."; + } + + leaf egress-action { + type identityref { + base egress-action; + } + description + "Egress action: pass, drop, reject, alert, mirror, + invoke-signaling, tunnel-encapsulation, + forwarding, and redirection."; + } + + leaf log-action { + type identityref { + base log-action; + } + description + "Log action: rule log and session log"; + } + + } + + container flow-action { + description + "Action for flows"; + reference + "RFC 8329: Framework for Interface to Network Security + Functions - I2NSF Flow Security Policy Structure + draft-ietf-i2nsf-capability-data-model-15: + I2NSF Capability YANG Data Model - Design Principles and + ECA Policy Model Overview"; leaf ingress-action { type identityref { base ingress-action; } description "Action: pass, drop, reject, alert, and mirror."; } leaf egress-action { @@ -3940,46 +3934,54 @@ base log-action; } description "Log action: rule log and session log"; } } container advanced-action { description - "If the packet need be additionally inspected, - the packet are passed to advanced network - security functions according to the profile."; + "If the packet needs to be additionally inspected, + the packet is passed to advanced network + security functions according to the profile. + The profile means the types of NSFs where the packet + will be forwarded in order to additionally + inspect the packet."; reference "RFC 8329: Framework for Interface to Network Security Functions - Differences from ACL Data Models"; leaf-list content-security-control { type identityref { base content-security-control; } description - "The Profile is divided into content security + "Content-security-control is the NSFs that + inspect the payload of the packet. + The Profile is divided into content security control and attack-mitigation-control. Content security control: antivirus, ips, ids, url filtering, mail filtering, file blocking, file isolate, packet capture, application control, voip and volte."; } leaf-list attack-mitigation-control { type identityref { base attack-mitigation-control; } description - "The Profile is divided into content security + "Attack-mitigation-control is the NSFs that weaken + the attacks related to a denial of service + and reconnaissance. + The Profile is divided into content security control and attack-mitigation-control. Attack mitigation control: syn flood, udp flood, icmp flood, ip frag flood, ipv6 related, http flood, https flood, dns flood, dns amp flood, ssl ddos, ip sweep, port scanning, ping of death, teardrop, oversized icmp, tracert."; } } } } @@ -4011,83 +4013,69 @@ type string; description "This is a end rule"; } } leaf enable { type boolean; description "This is enable False is not enable."; + } leaf description { type string; description - "This is a desription for rule-group"; + "This is a description for rule-group"; } } } } } - - leaf i2nsf-ipsec { - type identityref { - base i2nsf-ipsec; - } - description - "Internet Key Exchnage (IKE) for NSFs - in the I2NSF framework"; - - reference - "draft-ietf-i2nsf-sdn-ipsec-flow-protection-08: Software-Defined - Networking (SDN)-based IPsec Flow Protection - IPsec method - types can be selected."; - } } - Figure 6: YANG Data Module of I2NSF NSF-Facing-Interface + Figure 5: YANG Data Module of I2NSF NSF-Facing-Interface -6. XML Configuration Examples of Low-Level Security Policy Rules +5. XML Configuration Examples of Low-Level Security Policy Rules This section shows XML configuration examples of low-level security policy rules that are delivered from the Security Controller to NSFs over the NSF-Facing Interface. For security requirements, we assume that the NSFs (i.e., General firewall, Time-based firewall, URL filter, VoIP/VoLTE filter, and http and https flood mitigation ) - described in Appendix A. Configuration Examples of - - [I-D.ietf-i2nsf-capability-data-model] are registered in I2NSF - framework. With the registed NSFs, we show configuration examples + described in Section Configuration Examples of + [I-D.ietf-i2nsf-capability-data-model] are registered in the I2NSF + framework. With the registered NSFs, we show configuration examples for security policy rules of network security functions according to - the following three security requirements: (i) Block SNS access - during business hours, (ii) Block malicious VoIP/VoLTE packets coming - to the company, and (iii) Mitigate http and https flood attacks on - company web server. + the following three security requirements: (i) Block Social + Networking Service (SNS) access during business hours, (ii) Block + malicious VoIP/VoLTE packets coming to the company, and (iii) + Mitigate http and https flood attacks on company web server. -6.1. Security Requirement 1: Block SNS Access during Business Hours +5.1. Security Requirement 1: Block Social Networking Service (SNS) + Access during Business Hours This section shows a configuration example for blocking SNS access - during business hours in IPv4 networks [RFC5737] or IPv6 networks - [RFC3849]. + during business hours in IPv4 networks or IPv6 networks. sns_access block_sns_access_during_operation_time - 2019-08-01T09:00:00Z - 2019-12-31T18:00:00Z + 09:00:00Z + 18:00:00Z 192.0.2.11 192.0.2.90 @@ -4095,33 +4083,33 @@ url-filtering - Figure 7: Configuration XML for Time-based Firewall to Block SNS + Figure 6: Configuration XML for Time-based Firewall to Block SNS Access during Business Hours in IPv4 Networks sns_access block_sns_access_during_operation_time - 2019-08-01T09:00:00Z - 2019-12-31T18:00:00Z + 09:00:00Z + 18:00:00Z 2001:DB8:0:1::11 2001:DB8:0:1::90 @@ -4129,48 +4117,54 @@ url-filtering - Figure 8: Configuration XML for Time-based Firewall to Block SNS + Figure 7: Configuration XML for Time-based Firewall to Block SNS Access during Business Hours in IPv6 Networks sns_access block_sns_access_during_operation_time + + + 09:00:00Z + 18:00:00Z + + - facebook - instagram + SNS_1 + SNS_2 - + drop - + - Figure 9: Configuration XML for Web Filter to Block SNS Access during + Figure 8: Configuration XML for Web Filter to Block SNS Access during Business Hours - Figure 7 (or Figure 8) and Figure 9 show the configuration XML + Figure 6 (or Figure 7) and Figure 8 show the configuration XML documents for time-based firewall and web filter to block SNS access during business hours in IPv4 networks (or IPv6 networks). For the security requirement, two NSFs (i.e., a time-based firewall and a web filter) were used because one NSF cannot meet the security requirement. The instances of XML documents for the time-based firewall and the web filter are as follows: Note that a detailed data model for the configuration of the advanced network security function (i.e., web filter) can be defined as an extension in future. Time-based Firewall is as follows: @@ -4190,29 +4184,29 @@ 5. If the outgoing packets match the rules above, the time-based firewall sends the packets to url filtering for additional inspection because the time-based firewall can not inspect contents of the packets for the SNS URL. Web Filter is as follows: 1. The name of the system policy is sns_access. - 2. The name of the rule is block_facebook_and_instagram. + 2. The name of the rule is block_SNS_1_and_SNS_2. 3. The rule inspects URL address to block the access packets to the - facebook or the instagram. + SNS_1 or the SNS_2. 4. If the outgoing packets match the rules above, the packets are blocked. -6.2. Security Requirement 2: Block Malicious VoIP/VoLTE Packets Coming +5.2. Security Requirement 2: Block Malicious VoIP/VoLTE Packets Coming to a Company This section shows a configuration example for blocking malicious VoIP/VoLTE packets coming to a company. voip_volte_inspection @@ -4235,48 +4229,48 @@ voip-volte - Figure 10: Configuration XML for General Firewall to Block Malicious + Figure 9: Configuration XML for General Firewall to Block Malicious VoIP/VoLTE Packets Coming to a Company voip_volte_inspection block_malicious_voice_id - 11111@voip.black.com - 22222@voip.black.com + user1@voip.malicious.example.com + user2@voip.malicious.example.com - + drop - + - Figure 11: Configuration XML for VoIP/VoLTE Filter to Block Malicious + Figure 10: Configuration XML for VoIP/VoLTE Filter to Block Malicious VoIP/VoLTE Packets Coming to a Company - Figure 10 and Figure 11 show the configuration XML documents for + Figure 9 and Figure 10 show the configuration XML documents for general firewall and VoIP/VoLTE filter to block malicious VoIP/VoLTE packets coming to a company. For the security requirement, two NSFs (i.e., a general firewall and a VoIP/VoLTE filter) were used because one NSF can not meet the security requirement. The instances of XML documents for the general firewall and the VoIP/VoLTE filter are as follows: Note that a detailed data model for the configuration of the advanced network security function (i.e., VoIP/VoLTE filter) can be described as an extension in future. General Firewall is as follows: @@ -4297,27 +4291,28 @@ inspection because the general firewall can not inspect contents of the VoIP/VoLTE packets. VoIP/VoLTE Filter is as follows: 1. The name of the system policy is malicious_voice_id. 2. The name of the rule is block_malicious_voice_id. 3. The rule inspects the voice id of the VoIP/VoLTE packets to block - the malicious VoIP/VoLTE packets (i.e., 11111@voip.black.com and - 22222@voip.black.com). + the malicious VoIP/VoLTE packets (i.e., + user1@voip.malicious.example.com and + user2@voip.malicious.example.com). 4. If the incoming packets match the rules above, the packets are blocked. -6.3. Security Requirement 3: Mitigate HTTP and HTTPS Flood Attacks on a +5.3. Security Requirement 3: Mitigate HTTP and HTTPS Flood Attacks on a Company Web Server This section shows a configuration example for mitigating http and https flood attacks on a company web server. flood_attack_mitigation @@ -4340,48 +4335,48 @@ http-and-https-flood - Figure 12: Configuration XML for General Firewall to Mitigate HTTP + Figure 11: Configuration XML for General Firewall to Mitigate HTTP and HTTPS Flood Attacks on a Company Web Server flood_attack_mitigation mitigate_http_and_https_flood_attack - 100 + 100 - + drop - + - Figure 13: Configuration XML for HTTP and HTTPS Flood Attack + Figure 12: Configuration XML for HTTP and HTTPS Flood Attack Mitigation to Mitigate HTTP and HTTPS Flood Attacks on a Company Web Server - Figure 12 and Figure 13 show the configuration XML documents for + Figure 11 and Figure 12 show the configuration XML documents for general firewall and http and https flood attack mitigation to mitigate http and https flood attacks on a company web server. For the security requirement, two NSFs (i.e., a general firewall and a http and https flood attack mitigation) were used because one NSF can not meet the security requirement. The instances of XML documents for the general firewall and http and https flood attack mitigation are as follows: Note that a detailed data model for the configuration of the advanced network security function (i.e., http and https flood attack mitigation) can be defined as an extension in future. @@ -4392,54 +4387,54 @@ 2. The name of the rule is mitigate_http_and_https_flood_attack. 3. The rule inspects a destination IPv4 address (i.e., 192.0.2.11) to inspect the access packets coming into the company web server. 4. The rule inspects a port number (i.e., 80 and 443) to inspect http and https packet. 5. If the packets match the rules above, the general firewall sends the packets to http and https flood attack mitigation for - additional inspection because the general firewall can not contrl - the amount of packets for http and https packets. + additional inspection because the general firewall can not + control the amount of packets for http and https packets. HTTP and HTTPS Flood Attack Mitigation is as follows: 1. The name of the system policy is http_and_https_flood_attack_mitigation. 2. The name of the rule is 100_per_second. 3. The rule controls the http and https packets according to the amount of incoming packets. 4. If the incoming packets match the rules above, the packets are blocked. -7. IANA Considerations +6. IANA Considerations This document requests IANA to register the following URI in the "IETF XML Registry" [RFC3688]: URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. This document requests IANA to register the following YANG module in the "YANG Module Names" registry [RFC7950][RFC8525]. name: ietf-i2nsf-policy-rule-for-nsf namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf prefix: nsfintf reference: RFC XXXX -8. Security Considerations +7. Security Considerations The YANG module specified in this document defines a data schema designed to be accessed through network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the required secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the required secure transport is TLS [RFC8446]. The NETCONF access control model [RFC8341] provides a means of restricting access to specific NETCONF or RESTCONF users to a @@ -4447,57 +4442,86 @@ operations and content. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability: - o ietf-i2nsf-policy-rule-for-nsf: The attacker may provide incorrect - policy information of any target NSFs by illegally modifying this. + o ietf-i2nsf-policy-rule-for-nsf: Writing to almost any element of + this YANG module would directly impact on the configuration of + NSFs, e.g., completely turning off security monitoring and + mitigation capabilities; altering the scope of this monitoring and + mitigation; creating an overwhelming logging volume to overwhelm + downstream analytics or storage capacity; creating logging + patterns which are confusing; or rendering useless trained + statistics or artificial intelligence models. Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability: o ietf-i2nsf-policy-rule-for-nsf: The attacker may gather the security policy information of any target NSFs and misuse the security policy information for subsequent attacks. -9. Acknowledgments + In this YANG data module, note that the identity information of users + can be exchanged for security policy configuration based on a user's + information. This implied that to improve the network security there + is a tradeoff between a user's information privacy and network + security. For container users-conditions in this YANG data module, + the identity information of users can be exchanged between Security + Controller and an NSF for security policy configuration based on + users' information. Thus, for this exchange of the identity + information of users, there is a proportional relationship between + the release level of a user's privacy information and the network + security strength of an NSF. + +8. Acknowledgments This work was supported by Institute of Information & Communications Technology Planning & Evaluation (IITP) grant funded by the Korea MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based Security Intelligence Technology Development for the Customized Security Service Provisioning). This work was supported in part by the IITP (2020-0-00395, Standard Development of Blockchain based Network Management Automation Technology). -10. Contributors +9. Contributors This document is made by the group effort of I2NSF working group. Many people actively contributed to this document, such as Acee - Lindem. The authors sincerely appreciate their contributions. + Lindem and Roman Danyliw. The authors sincerely appreciate their + contributions. The following are co-authors of this document: + Patrick Lingga + Department of Computer Science and Engineering + Sungkyunkwan University + 2066 Seo-ro Jangan-gu + Suwon, Gyeonggi-do 16419 + Republic of Korea + + EMail: patricklink@skku.edu + Hyoungshick Kim Department of Computer Science and Engineering Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, Gyeonggi-do 16419 Republic of Korea + EMail: hyoung@skku.edu Daeyoung Hyun Department of Computer Science and Engineering Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, Gyeonggi-do 16419 Republic of Korea EMail: dyhyun@skku.edu @@ -4528,79 +4552,67 @@ EMail: taejin.ahn@kt.com Se-Hui Lee Korea Telecom 70 Yuseong-Ro, Yuseong-Gu Daejeon, 305-811 Republic of Korea EMail: sehuilee@kt.com -11. References +10. References -11.1. Normative References +10.1. Normative References + + [I-D.ietf-i2nsf-capability-data-model] + Hares, S., Jeong, J., Kim, J., Moskowitz, R., and Q. Lin, + "I2NSF Capability YANG Data Model", draft-ietf-i2nsf- + capability-data-model-15 (work in progress), January 2021. + + [I-D.ietf-i2nsf-sdn-ipsec-flow-protection] + Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez- + Garcia, "Software-Defined Networking (SDN)-based IPsec + Flow Protection", draft-ietf-i2nsf-sdn-ipsec-flow- + protection-12 (work in progress), October 2020. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, . [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, . - [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, - DOI 10.17487/RFC1700, October 1994, - . - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, - . - - [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced - by an On-line Database", RFC 3232, DOI 10.17487/RFC3232, - January 2002, . - [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . - [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix - Reserved for Documentation", RFC 3849, - DOI 10.17487/RFC3849, July 2004, - . - [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, . - [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks - Reserved for Documentation", RFC 5737, - DOI 10.17487/RFC5737, January 2010, - . - [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . @@ -4613,35 +4625,25 @@ . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . - [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. - Zhang, "YANG Data Model for Key Chains", RFC 8177, - DOI 10.17487/RFC8177, June 2017, - . - [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . - [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. - Kumar, "Framework for Interface to Network Security - Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, - . - [RFC8335] Bonica, R., Thomas, R., Linkova, J., Lenart, C., and M. Boucadair, "PROBE: A Utility for Probing Interfaces", RFC 8335, DOI 10.17487/RFC8335, February 2018, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration @@ -4660,42 +4662,41 @@ [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., and R. Wilton, "YANG Library", RFC 8525, DOI 10.17487/RFC8525, March 2019, . -11.2. Informative References +10.2. Informative References - [I-D.ietf-i2nsf-capability] - Xia, L., Strassner, J., Basile, C., and D. Lopez, - "Information Model of NSFs Capabilities", draft-ietf- - i2nsf-capability-05 (work in progress), April 2019. + [I-D.ietf-i2nsf-nsf-monitoring-data-model] + Jeong, J., Lingga, P., Hares, S., Xia, L., and H. + Birkholz, "I2NSF NSF Monitoring YANG Data Model", draft- + ietf-i2nsf-nsf-monitoring-data-model-04 (work in + progress), September 2020. - [I-D.ietf-i2nsf-capability-data-model] - Hares, S., Jeong, J., Kim, J., Moskowitz, R., and Q. Lin, - "I2NSF Capability YANG Data Model", draft-ietf-i2nsf- - capability-data-model-08 (work in progress), August 2020. + [IANA-Protocol-Numbers] + "Assigned Internet Protocol Numbers", Available: + https://www.iana.org/assignments/protocol- + numbers/protocol-numbers.xhtml, January 2021. - [I-D.ietf-i2nsf-nsf-monitoring-data-model] - Jeong, J., Chung, C., Hares, S., Xia, L., and H. Birkholz, - "I2NSF NSF Monitoring YANG Data Model", draft-ietf-i2nsf- - nsf-monitoring-data-model-03 (work in progress), May 2020. + [ISO-Country-Codes] + "Codes for the representation of names of countries and + their subdivisions", ISO 3166, September 2018. - [I-D.ietf-i2nsf-sdn-ipsec-flow-protection] - Lopez, R., Lopez-Millan, G., and F. Pereniguez-Garcia, - "Software-Defined Networking (SDN)-based IPsec Flow - Protection", draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 - (work in progress), June 2020. + [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. + Kumar, "Framework for Interface to Network Security + Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, + . Authors' Addresses Jinyong Tim Kim (editor) Department of Electronic, Electrical and Computer Engineering Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon, Gyeonggi-Do 16419 Republic of Korea