--- 1/draft-ietf-i2nsf-nsf-facing-interface-dm-09.txt 2020-08-28 09:13:18.847001037 -0700 +++ 2/draft-ietf-i2nsf-nsf-facing-interface-dm-10.txt 2020-08-28 09:13:19.011005173 -0700 @@ -1,23 +1,23 @@ -I2NSF Working Group J. Kim -Internet-Draft J. Jeong +I2NSF Working Group J. Kim, Ed. +Internet-Draft J. Jeong, Ed. Intended status: Standards Track Sungkyunkwan University -Expires: November 8, 2020 J. Park +Expires: March 1, 2021 J. Park ETRI S. Hares Q. Lin Huawei - May 7, 2020 + August 28, 2020 I2NSF Network Security Function-Facing Interface YANG Data Model - draft-ietf-i2nsf-nsf-facing-interface-dm-09 + draft-ietf-i2nsf-nsf-facing-interface-dm-10 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,21 +28,21 @@ 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 November 8, 2020. + This Internet-Draft will expire on March 1, 2021. Copyright Notice Copyright (c) 2020 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 @@ -50,117 +50,97 @@ 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 - 3.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 - 4. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4 + 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 Module . . . . . . . . . . . . . . . . . . . . . . 15 - 5.1. I2NSF NSF-Facing Interface YANG Data Module . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 86 + Hours . . . . . . . . . . . . . . . . . . . . . . . . . . 87 6.2. Security Requirement 2: Block Malicious VoIP/VoLTE - Packets Coming to a Company . . . . . . . . . . . . . . . 89 + Packets Coming to a Company . . . . . . . . . . . . . . . 91 6.3. Security Requirement 3: Mitigate HTTP and HTTPS Flood - Attacks on a Company Web Server . . . . . . . . . . . . . 92 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 95 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 96 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 96 - 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 96 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 97 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 97 - 11.2. Informative References . . . . . . . . . . . . . . . . . 99 - Appendix A. Changes from draft-ietf-i2nsf-nsf-facing-interface- - dm-08 . . . . . . . . . . . . . . . . . . . . . . . 100 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 100 + 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 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 - [draft-ietf-i2nsf-capability] for NSF-Facing Interface in Interface - to Network Security Functions (I2NSF). The YANG data model in this - document focuses on security policy configuration for generic network - security functions. Note that security policy configuration for - advanced network security functions are defined in - [draft-dong-i2nsf-asf-config]. + [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. 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 [draft-ietf-i2nsf-capability]. + described in [RFC8329] and [I-D.ietf-i2nsf-capability]. 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. o Configuration of condition clause for generic network security functions. o Configuration of action clause for generic network security functions. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119][RFC8174]. + document are to be interpreted as described in [RFC2119]. 3. Terminology - This document uses the terminology described in [draft-ietf-i2nsf-cap - ability][RFC8431][draft-ietf-supa-generic-policy-info-model]. - Especially, the following terms are from - [draft-ietf-supa-generic-policy-info-model]: - - o Data Model: A data model is a representation of concepts of - interest to an environment in a form that is dependent on data - repository, data definition language, query language, - implementation language, and protocol. - - o Information Model: An information model is a representation of - concepts of interest to an environment in a form that is - independent of data repository, data definition language, query - language, implementation language, and protocol. - -3.1. Tree Diagrams + This document uses the terminology described in [RFC8329]. - A simplified graphical representation of the data model is used in - this document. The meaning of the symbols in these diagrams is - referred from [RFC8340]. + 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 This section shows a YANG tree diagram of generic network security - functions. Note that a detailed data model for the configuration of - the advanced network security functions is described in - [draft-dong-i2nsf-asf-config]. The section describes the following - subjects: + functions. Advanced network security functions can be defined in + future. The section describes the following subjects: - o General I2NSF security policy rule of the generic network security - function. + 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. 4.1. General I2NSF Security Policy Rule This section shows the YANG tree diagram for general I2NSF security @@ -220,27 +200,27 @@ usage, resolutation 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 - [draft-ietf-i2nsf-capability]. + [I-D.ietf-i2nsf-capability]. 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 [draft-ietf-i2nsf-capability]. + described in detail in [I-D.ietf-i2nsf-capability]. 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 This section shows the YANG tree diagram for an event clause for I2NSF security policy rules. @@ -264,23 +244,24 @@ +--rw i2nsf-ipsec? identityref 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. The event clause can be + 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 [draft-ietf-i2nsf-capability]. + clause is described in detail in [I-D.ietf-i2nsf-capability]. 4.3. Condition Clause This section shows the YANG tree diagram for a condition clause of I2NSF security policy rules. module: ietf-i2nsf-policy-rule-for-nsf +--rw i2nsf-security-policy | ... | +--rw rules* [rule-name] @@ -567,25 +550,25 @@ 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 clauses of advanced network security functions are - described in detail in [draft-dong-i2nsf-asf-config]. A condition - clause can be extended according to specific vendor condition - features. A condition clause is described in detail in - [draft-ietf-i2nsf-capability]. + 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] @@ -611,21 +594,21 @@ 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 - [draft-ietf-i2nsf-capability]. + [I-D.ietf-i2nsf-capability]. 4.5. I2NSF Internet Key Exchange This section shows the YANG tree diagram for an I2NSF IPsec. module: ietf-i2nsf-policy-rule-for-nsf +--rw i2nsf-security-policy | ... | +--rw rules* [rule-name] | | ... @@ -639,34 +622,58 @@ | ... +--rw i2nsf-ipsec? identityref Figure 5: YANG Tree Diagram for I2NSF Internet Key Exchnage 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 - [draft-ietf-i2nsf-sdn-ipsec-flow-protection]. I2NSF IPsec considers + [I-D.ietf-i2nsf-sdn-ipsec-flow-protection]. I2NSF IPsec considers two cases, theIKE case (i.e., IPsec through IKE) and IKE-less case (i.e., IPsec not through IKE, but through a Security Controller). - Refer to [draft-ietf-i2nsf-sdn-ipsec-flow-protection] for the - detailed description of the I2NSF IPsec. + Refer to [I-D.ietf-i2nsf-sdn-ipsec-flow-protection] for the detailed + description of the I2NSF IPsec. -5. YANG Data Module +5. YANG Data Model of NSF-Facing Interface -5.1. I2NSF NSF-Facing Interface YANG Data Module + 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. - This section contains a YANG data module for configuration of - security policy rules on network security functions. + 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. - file "ietf-i2nsf-policy-rule-for-nsf@2020-05-07.yang" + 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. + +5.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]. + + file "ietf-i2nsf-policy-rule-for-nsf@2020-08-28.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; @@ -682,53 +689,45 @@ } organization "IETF I2NSF (Interface to Network Security Functions) Working Group"; contact "WG Web: WG List: - WG Chair: Linda Dunbar - - - WG Chair: Yoav Nir - - Editor: Jingyong Tim Kim + Editor: Jaehoon Paul Jeong - - - Editor: Susan Hares - "; + "; description - "This module defines a YANG data module for the Network Security - Functions (NSF) facing interface. + "This module is a YANG module for Network Security Functions + (NSF)-Facing Interface. - Copyright (c) 2019 IETF Trust and the persons - identified as authors of the code. All rights reserved. + Copyright (c) 2020 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). + 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-05-07"{ + revision "2020-08-28"{ description "The latest revision."; reference "RFC XXXX: I2NSF Network Security Function-Facing Interface YANG Data Model"; } /* * Identities */ @@ -740,117 +739,120 @@ 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-02 - - Event"; + "draft-ietf-i2nsf-nsf-monitoring-data-model-03: 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-02 - - System event"; + "draft-ietf-i2nsf-nsf-monitoring-data-model-03: 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-02 - - System alarm"; + "draft-ietf-i2nsf-nsf-monitoring-data-model-03: 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-02 - - System event"; + "draft-ietf-i2nsf-nsf-monitoring-data-model-03: 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-02 - - System event"; + "draft-ietf-i2nsf-nsf-monitoring-data-model-03: 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-02 - - System alarm"; + "draft-ietf-i2nsf-nsf-monitoring-data-model-03: 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-02 - - System alarm"; + "draft-ietf-i2nsf-nsf-monitoring-data-model-03: 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-02 - - System alarm"; + "draft-ietf-i2nsf-nsf-monitoring-data-model-03: 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-02 - - System alarm"; + "draft-ietf-i2nsf-nsf-monitoring-data-model-03: 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-02 - - System alarm"; + "draft-ietf-i2nsf-nsf-monitoring-data-model-03: 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"; } identity traffic-class { @@ -2230,43 +2223,47 @@ description "Identity for Prioritized Matching Rule with No Errors (PMRN)"; reference "draft-ietf-i2nsf-capability-05: Information Model of NSFs Capabilities - Resolution Strategy"; } identity i2nsf-ipsec { description - "Internet Key Exchnage for NSFs + "Internet Key Exchnage (IKE) for NSFs in the I2NSF framework"; reference - "draft-ietf-i2nsf-sdn-ipsec-flow-protection-04 - - i2nsf-ipsec"; + "draft-ietf-i2nsf-sdn-ipsec-flow-protection-08: Software-Defined + Networking (SDN)-based IPsec Flow Protection - IPsec method + types can be selected."; + } identity ike { base i2nsf-ipsec; description "IKE case: IPsec with IKE in the NSF"; reference - "draft-ietf-i2nsf-sdn-ipsec-flow-protection-04 - - ike"; + "draft-ietf-i2nsf-sdn-ipsec-flow-protection-08: Software-Defined + Networking (SDN)-based IPsec Flow Protection - IPsec method + type with IKE is selected."; } identity ikeless { base i2nsf-ipsec; description "IKEless case: IPsec without IKEv2 in the NSF"; reference - "draft-ietf-i2nsf-sdn-ipsec-flow-protection-04 - - ikeless"; + "draft-ietf-i2nsf-sdn-ipsec-flow-protection-08: Software-Defined + Networking (SDN)-based IPsec Flow Protection - IPsec method + type without IKE is selected."; } /* * Typedefs */ typedef day-type { type enumeration { enum sunday { description @@ -2756,41 +2754,41 @@ 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-02: I2NSF + draft-ietf-i2nsf-nsf-monitoring-data-model-03: 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-02: I2NSF + draft-ietf-i2nsf-nsf-monitoring-data-model-03: 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."; @@ -2892,21 +2891,21 @@ } leaf-list pkt-sec-ipv4-tos { type identityref { base type-of-service; } description "The security policy rule according to IPv4 type of service."; reference - "RFC 1394: Internet Protocol - Type of service"; + "RFC 791: Internet Protocol - Type of service"; } container pkt-sec-ipv4-total-length { choice match-type { description "Security policy IPv4 total length matching - exact match and range match."; case exact-match { leaf-list ipv4-total-length { type uint16; @@ -4030,87 +4027,124 @@ } } } } leaf i2nsf-ipsec { type identityref { base i2nsf-ipsec; } description - "Internet Key Exchnage for NSFs + "Internet Key Exchnage (IKE) for NSFs in the I2NSF framework"; reference - "draft-ietf-i2nsf-sdn-ipsec-flow-protection-04 - - i2nsf-ipsec"; + "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 6. 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 - [draft-ietf-i2nsf-capability-data-model] are registered in I2NSF + + [I-D.ietf-i2nsf-capability-data-model] are registered in I2NSF framework. With the registed 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. 6.1. Security Requirement 1: Block SNS Access during Business Hours This section shows a configuration example for blocking SNS access - during business hours. + during business hours in IPv4 networks [RFC5737] or IPv6 networks + [RFC3849]. sns_access block_sns_access_during_operation_time 2019-08-01T09:00:00Z 2019-12-31T18:00:00Z - 221.159.112.1 - 221.159.112.90 + 192.0.2.11 + 192.0.2.90 url-filtering Figure 7: Configuration XML for Time-based Firewall to Block SNS - Access during Business Hours + 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 + + + + + + + 2001:DB8:0:1::11 + 2001:DB8:0:1::90 + + + + + + + url-filtering + + + + + + + Figure 8: Configuration XML for Time-based Firewall to Block SNS + Access during Business Hours in IPv6 Networks sns_access block_sns_access_during_operation_time facebook @@ -4119,44 +4153,47 @@ drop - Figure 8: Configuration XML for Web Filter to Block SNS Access during + Figure 9: Configuration XML for Web Filter to Block SNS Access during Business Hours - Figure 7 and Figure 8 show the configuration XML documents for time- - based firewall and web filter to block SNS access during business - hours. 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) is described in - [draft-dong-i2nsf-asf-config]. + Figure 7 (or Figure 8) and Figure 9 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: 1. The name of the system policy is sns_access. 2. The name of the rule is block_sns_access_during_operation_time. 3. The rule is operated during the business hours (i.e., from 9 a.m. to 6 p.m.). - 4. The rule inspects a source IPv4 address (i.e., from 221.159.112.1 - to 221.159.112.90) to inspect the outgoing packets of employees. + 4. The rule inspects a source IPv4 address (i.e., from 192.0.2.11 to + 192.0.2.90) to inspect the outgoing packets of employees. For + the case of IPv6 networks, the rule inspects a source IPv6 + address (i.e., from 2001:DB8:0:1::11 to 2001:DB8:0:1::90) to + inspect the outgoing packets of employees. 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. @@ -4177,42 +4214,42 @@ voip_volte_inspection block_malicious_voice_id - 221.159.112.1 - 221.159.112.90 + 192.0.2.11 + 192.0.2.90 5060 5061 voip-volte - Figure 9: Configuration XML for General Firewall to Block Malicious + Figure 10: Configuration XML for General Firewall to Block Malicious VoIP/VoLTE Packets Coming to a Company voip_volte_inspection block_malicious_voice_id @@ -4222,42 +4259,42 @@ drop - Figure 10: Configuration XML for VoIP/VoLTE Filter to Block Malicious + Figure 11: Configuration XML for VoIP/VoLTE Filter to Block Malicious VoIP/VoLTE Packets Coming to a Company - Figure 9 and Figure 10 show the configuration XML documents for + Figure 10 and Figure 11 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) is - described in [draft-dong-i2nsf-asf-config]. + advanced network security function (i.e., VoIP/VoLTE filter) can be + described as an extension in future. General Firewall is as follows: 1. The name of the system policy is voip_volte_inspection. 2. The name of the rule is block_malicious_voip_volte_packets. 3. The rule inspects a destination IPv4 address (i.e., from - 221.159.112.1 to 221.159.112.90) to inspect the packets coming - into the company. + 192.0.2.11 to 192.0.2.90) to inspect the packets coming into the + company. 4. The rule inspects a port number (i.e., 5060 and 5061) to inspect VoIP/VoLTE packet. 5. If the incoming packets match the rules above, the general firewall sends the packets to VoIP/VoLTE filter for additional inspection because the general firewall can not inspect contents of the VoIP/VoLTE packets. VoIP/VoLTE Filter is as follows: @@ -4282,42 +4319,42 @@ flood_attack_mitigation mitigate_http_and_https_flood_attack - 221.159.112.95 + 192.0.2.11 80 443 http-and-https-flood - Figure 11: Configuration XML for General Firewall to Mitigate HTTP + Figure 12: 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 @@ -4326,44 +4363,43 @@ drop - Figure 12: Configuration XML for HTTP and HTTPS Flood Attack + Figure 13: Configuration XML for HTTP and HTTPS Flood Attack Mitigation to Mitigate HTTP and HTTPS Flood Attacks on a Company Web Server - Figure 11 and Figure 12 show the configuration XML documents for + Figure 12 and Figure 13 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) is described in [draft-dong-i2nsf-asf-config]. + attack mitigation) can be defined as an extension in future. General Firewall is as follows: 1. The name of the system policy is flood_attack_mitigation. 2. The name of the rule is mitigate_http_and_https_flood_attack. - 3. The rule inspects a destination IPv4 address (i.e., - 221.159.112.95) to inspect the access packets coming into the - company web server. + 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. HTTP and HTTPS Flood Attack Mitigation is as follows: @@ -4372,21 +4408,38 @@ 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. Security Considerations +7. 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 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 @@ -4407,214 +4460,256 @@ 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. -8. IANA Considerations +9. Acknowledgments - This document requests IANA to register the following URI in the - "IETF XML Registry" [RFC3688]: + 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). - URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf +10. Contributors - Registrant Contact: The IESG. + 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. - XML: N/A; the requested URI is an XML namespace. + The following are co-authors of this document: - This document requests IANA to register the following YANG module in - the "YANG Module Names" registry [RFC7950]. + 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 - name: ietf-i2nsf-policy-rule-for-nsf + Daeyoung Hyun + Department of Computer Science and Engineering + Sungkyunkwan University + 2066 Seo-ro Jangan-gu + Suwon, Gyeonggi-do 16419 + Republic of Korea - namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for- - nsf + EMail: dyhyun@skku.edu - prefix: nsfintf + Dongjin Hong + Department of Electronic, Electrical and Computer Engineering + Sungkyunkwan University + 2066 Seo-ro Jangan-gu + Suwon, Gyeonggi-do 16419 + Republic of Korea - reference: RFC XXXX + EMail: dong.jin@skku.edu -9. Acknowledgments + Liang Xia + Huawei + 101 Software Avenue + Nanjing, Jiangsu 210012 + China - 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). + EMail: Frank.Xialiang@huawei.com -10. Contributors + Tae-Jin Ahn + Korea Telecom + 70 Yuseong-Ro, Yuseong-Gu + Daejeon, 305-811 + Republic of Korea - This document is made by the group effort of I2NSF working group. - Many people actively contributed to this document. The following are - considered co-authors: + EMail: taejin.ahn@kt.com - o Hyoungshick Kim (Sungkyunkwan University) + Se-Hui Lee + Korea Telecom + 70 Yuseong-Ro, Yuseong-Gu + Daejeon, 305-811 + Republic of Korea - o Daeyoung Hyun (Sungkyunkwan University) + EMail: sehuilee@kt.com - o Dongjin Hong (Sungkyunkwan University) +11. References - o Liang Xia (Huawei) - o Tae-Jin Ahn (Korea Telecom) +11.1. Normative References - o Se-Hui Lee (Korea Telecom) + [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + DOI 10.17487/RFC0768, August 1980, + . -11. References + [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, + DOI 10.17487/RFC0791, September 1981, + . -11.1. Normative References + [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, + RFC 792, DOI 10.17487/RFC0792, September 1981, + . - [RFC1394] Robinson, P., "Relationship of Telex Answerback Codes to - Internet Domains", RFC 1394, DOI 10.17487/RFC1394, January - 1993, . + [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., "Assigned Numbers: RFC 1700 is Replaced by - an On-line Database", RFC 3232, January 2002. + [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, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . - [RFC768] Postel, J., "User Datagram Protocol", RFC 768, August - 1980. - - [RFC791] Postel, J., "Internet Protocol", RFC 791, September 1981. - - [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792, - September 1981. - - [RFC793] Postel, J., "Transmission Control Protocol", RFC 793, - September 1981. - [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, . - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC - 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, - May 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 Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . - [RFC8431] Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini, - S., and N. Bahadur, "A YANG Data Model for the Routing - Information Base (RIB)", RFC 8431, DOI 10.17487/RFC8431, - September 2018, . + [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", + RFC 8344, DOI 10.17487/RFC8344, March 2018, + . + + [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of + Documents Containing YANG Data Models", BCP 216, RFC 8407, + DOI 10.17487/RFC8407, October 2018, + . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . -11.2. Informative References + [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., + and R. Wilton, "YANG Library", RFC 8525, + DOI 10.17487/RFC8525, March 2019, + . - [draft-dong-i2nsf-asf-config] - Pan, W. and L. Xia, "Configuration of Advanced Security - Functions with I2NSF Security Controller", draft-dong- - i2nsf-asf-config-01 (work in progress), October 2018. +11.2. Informative References - [draft-ietf-i2nsf-capability] + [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. - [draft-ietf-i2nsf-capability-data-model] + [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-05 (work in progress), July 2019. - - [draft-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-07 (work in progress), August 2019. - - [draft-ietf-supa-generic-policy-info-model] - Strassner, J., Halpern, J., and S. Meer, "Generic Policy - Information Model for Simplified Use of Policy - Abstractions (SUPA)", draft-ietf-supa-generic-policy-info- - model-03 (work in progress), May 2017. - -Appendix A. Changes from draft-ietf-i2nsf-nsf-facing-interface-dm-08 + capability-data-model-08 (work in progress), August 2020. - The following changes are made from draft-ietf-i2nsf-nsf-facing- - interface-dm-08: + [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. - o The version has only a submission date update to maintain the - active status of the draft. + [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. Authors' Addresses - Jinyong Tim Kim + 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 Phone: +82 10 8273 0930 EMail: timkim@skku.edu - Jaehoon Paul Jeong + Jaehoon Paul Jeong (editor) Department of Computer Science and Engineering Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon, Gyeonggi-Do 16419 Republic of Korea Phone: +82 31 299 4957 Fax: +82 31 290 7996 EMail: pauljeong@skku.edu URI: http://iotlab.skku.edu/people-jaehoon-jeong.php