draft-ietf-i2nsf-nsf-facing-interface-dm-09.txt   draft-ietf-i2nsf-nsf-facing-interface-dm-10.txt 
I2NSF Working Group J. Kim I2NSF Working Group J. Kim, Ed.
Internet-Draft J. Jeong Internet-Draft J. Jeong, Ed.
Intended status: Standards Track Sungkyunkwan University Intended status: Standards Track Sungkyunkwan University
Expires: November 8, 2020 J. Park Expires: March 1, 2021 J. Park
ETRI ETRI
S. Hares S. Hares
Q. Lin Q. Lin
Huawei Huawei
May 7, 2020 August 28, 2020
I2NSF Network Security Function-Facing Interface YANG Data Model 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 Abstract
This document defines a YANG data model for configuring security This document defines a YANG data model for configuring security
policy rules on Network Security Functions (NSF) in the Interface to policy rules on Network Security Functions (NSF) in the Interface to
Network Security Functions (I2NSF) framework. The YANG data model in Network Security Functions (I2NSF) framework. The YANG data model in
this document corresponds to the information model for NSF-Facing this document corresponds to the information model for NSF-Facing
Interface in the I2NSF framework. Interface in the I2NSF framework.
Status of This Memo Status of This Memo
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 15
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 4. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 3
4. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4
4.1. General I2NSF Security Policy Rule . . . . . . . . . . . 4 4.1. General I2NSF Security Policy Rule . . . . . . . . . . . 4
4.2. Event Clause . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Event Clause . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Condition Clause . . . . . . . . . . . . . . . . . . . . 7 4.3. Condition Clause . . . . . . . . . . . . . . . . . . . . 7
4.4. Action Clause . . . . . . . . . . . . . . . . . . . . . . 14 4.4. Action Clause . . . . . . . . . . . . . . . . . . . . . . 14
4.5. I2NSF Internet Key Exchange . . . . . . . . . . . . . . . 15 4.5. I2NSF Internet Key Exchange . . . . . . . . . . . . . . . 15
5. YANG Data Module . . . . . . . . . . . . . . . . . . . . . . 15 5. YANG Data Model of NSF-Facing Interface . . . . . . . . . . . 15
5.1. I2NSF NSF-Facing Interface YANG Data Module . . . . . . . 15 5.1. YANG Module of NSF-Facing Interface . . . . . . . . . . . 16
6. XML Configuration Examples of Low-Level Security Policy Rules 86 6. XML Configuration Examples of Low-Level Security Policy Rules 86
6.1. Security Requirement 1: Block SNS Access during Business 6.1. Security Requirement 1: Block SNS Access during Business
Hours . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Hours . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.2. Security Requirement 2: Block Malicious VoIP/VoLTE 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 6.3. Security Requirement 3: Mitigate HTTP and HTTPS Flood
Attacks on a Company Web Server . . . . . . . . . . . . . 92 Attacks on a Company Web Server . . . . . . . . . . . . . 94
7. Security Considerations . . . . . . . . . . . . . . . . . . . 95 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 97
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 96 8. Security Considerations . . . . . . . . . . . . . . . . . . . 97
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 96 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 98
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 96 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 98
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 97 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 100
11.1. Normative References . . . . . . . . . . . . . . . . . . 97 11.1. Normative References . . . . . . . . . . . . . . . . . . 100
11.2. Informative References . . . . . . . . . . . . . . . . . 99 11.2. Informative References . . . . . . . . . . . . . . . . . 102
Appendix A. Changes from draft-ietf-i2nsf-nsf-facing-interface- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 103
dm-08 . . . . . . . . . . . . . . . . . . . . . . . 100
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 100
1. Introduction 1. Introduction
This document defines a YANG [RFC6020][RFC7950] data model for This document defines a YANG [RFC6020][RFC7950] data model for
security policy rule configuration of Network Security Functions security policy rule configuration of Network Security Functions
(NSF). The YANG data model corresponds to the information model (NSF). The YANG data model corresponds to the information model
[draft-ietf-i2nsf-capability] for NSF-Facing Interface in Interface [I-D.ietf-i2nsf-capability] for the NSF-Facing Interface in Interface
to Network Security Functions (I2NSF). The YANG data model in this to Network Security Functions (I2NSF) [RFC8329]. The YANG data model
document focuses on security policy configuration for generic network in this document focuses on security policy configuration for generic
security functions. Note that security policy configuration for network security functions. Security policy configuration for
advanced network security functions are defined in advanced network security functions can be defined in future.
[draft-dong-i2nsf-asf-config].
This YANG data model uses an "Event-Condition-Action" (ECA) policy This YANG data model uses an "Event-Condition-Action" (ECA) policy
model that is used as the basis for the design of I2NSF 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 The "ietf-i2nsf-policy-rule-for-nsf" YANG module defined in this
document provides the following features. document provides the following features.
o Configuration of general security policy rule for generic network o Configuration of general security policy rule for generic network
security functions. security functions.
o Configuration of event clause for generic network security o Configuration of event clause for generic network security
functions. functions.
o Configuration of condition clause for generic network security o Configuration of condition clause for generic network security
functions. functions.
o Configuration of action clause for generic network security o Configuration of action clause for generic network security
functions. functions.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "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 3. Terminology
This document uses the terminology described in [draft-ietf-i2nsf-cap This document uses the terminology described in [RFC8329].
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
A simplified graphical representation of the data model is used in This document follows the guidelines of [RFC8407], uses the common
this document. The meaning of the symbols in these diagrams is YANG types defined in [RFC6991], and adopts the Network Management
referred from [RFC8340]. Datastore Architecture (NMDA). The meaning of the symbols in tree
diagrams is defined in [RFC8340].
4. YANG Tree Diagram 4. YANG Tree Diagram
This section shows a YANG tree diagram of generic network security This section shows a YANG tree diagram of generic network security
functions. Note that a detailed data model for the configuration of functions. Advanced network security functions can be defined in
the advanced network security functions is described in future. The section describes the following subjects:
[draft-dong-i2nsf-asf-config]. The section describes the following
subjects:
o General I2NSF security policy rule of the generic network security o A general I2NSF security policy rule of the generic network
function. security function.
o An event clause 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 A condition clause of the generic network security function.
o An action clause of the generic network security function. o An action clause of the generic network security function.
4.1. General I2NSF Security Policy Rule 4.1. General I2NSF Security Policy Rule
This section shows the YANG tree diagram for general I2NSF security This section shows the YANG tree diagram for general I2NSF security
skipping to change at page 6, line 21 skipping to change at page 6, line 21
usage, resolutation strategy, default action, and rules. usage, resolutation strategy, default action, and rules.
A resolution strategy is used to decide how to resolve conflicts that A resolution strategy is used to decide how to resolve conflicts that
occur between the actions of the same or different policy rules that occur between the actions of the same or different policy rules that
are matched and contained in a particular NSF. The resolution are matched and contained in a particular NSF. The resolution
strategy is defined as First Matching Rule (FMR), Last Matching Rule strategy is defined as First Matching Rule (FMR), Last Matching Rule
(LMR), Prioritized Matching Rule (PMR) with Errors (PMRE), and (LMR), Prioritized Matching Rule (PMR) with Errors (PMRE), and
Prioritized Matching Rule with No Errors (PMRN). The resolution Prioritized Matching Rule with No Errors (PMRN). The resolution
strategy can be extended according to specific vendor action strategy can be extended according to specific vendor action
features. The resolution strategy is described in detail in 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 A default action is used to execute I2NSF policy rule when no rule
matches a packet. The default action is defined as pass, drop, matches a packet. The default action is defined as pass, drop,
reject, alert, and mirror. The default action can be extended reject, alert, and mirror. The default action can be extended
according to specific vendor action features. The default action is 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 The rules include rule name, rule description, rule priority, rule
enable, time zone, event clause container, condition clause enable, time zone, event clause container, condition clause
container, and action clause container. container, and action clause container.
4.2. Event Clause 4.2. Event Clause
This section shows the YANG tree diagram for an event clause for This section shows the YANG tree diagram for an event clause for
I2NSF security policy rules. I2NSF security policy rules.
skipping to change at page 7, line 32 skipping to change at page 7, line 32
+--rw i2nsf-ipsec? identityref +--rw i2nsf-ipsec? identityref
Figure 2: YANG Tree Diagram for an Event Clause Figure 2: YANG Tree Diagram for an Event Clause
This YANG tree diagram shows an event clause of an I2NSF security This YANG tree diagram shows an event clause of an I2NSF security
policy rule for generic network security functions. An event clause policy rule for generic network security functions. An event clause
is any important occurrence at a specific time of a change in the 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 system being managed, and/or in the environment of the system being
managed. An event clause is used to trigger the evaluation of the managed. An event clause is used to trigger the evaluation of the
condition clause of the I2NSF Policy Rule. The event clause is 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 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 4.3. Condition Clause
This section shows the YANG tree diagram for a condition clause of This section shows the YANG tree diagram for a condition clause of
I2NSF security policy rules. I2NSF security policy rules.
module: ietf-i2nsf-policy-rule-for-nsf module: ietf-i2nsf-policy-rule-for-nsf
+--rw i2nsf-security-policy +--rw i2nsf-security-policy
| ... | ...
| +--rw rules* [rule-name] | +--rw rules* [rule-name]
skipping to change at page 13, line 47 skipping to change at page 13, line 48
A condition clause of generic network security functions is defined A condition clause of generic network security functions is defined
as packet security IPv4 condition, packet security IPv6 condition, as packet security IPv4 condition, packet security IPv6 condition,
packet security tcp condition, and packet security icmp condition. A packet security tcp condition, and packet security icmp condition. A
condition clause of advanced network security functions is defined as condition clause of advanced network security functions is defined as
packet security url category condition, packet security voice packet security url category condition, packet security voice
condition, packet security DDoS condition, or packet security payload condition, packet security DDoS condition, or packet security payload
condition. A condition clause of context is defined as ACL number condition. A condition clause of context is defined as ACL number
condition, application condition, target condition, user condition, condition, application condition, target condition, user condition,
and geography condition. Note that this document deals only with and geography condition. Note that this document deals only with
simple conditions of advanced network security functions. A simple conditions of advanced network security functions. A
condition clauses of advanced network security functions are condition clause of more advanced network security functions can be
described in detail in [draft-dong-i2nsf-asf-config]. A condition defined as an extension in future. A condition clause can be
clause can be extended according to specific vendor condition extended according to specific vendor condition features. A
features. A condition clause is described in detail in condition clause is described in detail in
[draft-ietf-i2nsf-capability]. [I-D.ietf-i2nsf-capability].
4.4. Action Clause 4.4. Action Clause
This section shows the YANG tree diagram for an action clause of an This section shows the YANG tree diagram for an action clause of an
I2NSF security policy rule. I2NSF security policy rule.
module: ietf-i2nsf-policy-rule-for-nsf module: ietf-i2nsf-policy-rule-for-nsf
+--rw i2nsf-security-policy +--rw i2nsf-security-policy
| ... | ...
| +--rw rules* [rule-name] | +--rw rules* [rule-name]
skipping to change at page 14, line 45 skipping to change at page 14, line 45
This YANG tree diagram shows an action clause of an I2NSF security This YANG tree diagram shows an action clause of an I2NSF security
policy rule for generic network security functions. An action is policy rule for generic network security functions. An action is
used to control and monitor aspects of flow-based NSFs when the used to control and monitor aspects of flow-based NSFs when the
policy rule event and condition clauses are satisfied. NSFs provide policy rule event and condition clauses are satisfied. NSFs provide
security services by executing various actions. The action clause is security services by executing various actions. The action clause is
defined as ingress action, egress action, or log action for packet defined as ingress action, egress action, or log action for packet
action, and advanced action for additional inspection. The action action, and advanced action for additional inspection. The action
clause can be extended according to specific vendor action features. clause can be extended according to specific vendor action features.
The action clause is described in detail in The action clause is described in detail in
[draft-ietf-i2nsf-capability]. [I-D.ietf-i2nsf-capability].
4.5. I2NSF Internet Key Exchange 4.5. I2NSF Internet Key Exchange
This section shows the YANG tree diagram for an I2NSF IPsec. This section shows the YANG tree diagram for an I2NSF IPsec.
module: ietf-i2nsf-policy-rule-for-nsf module: ietf-i2nsf-policy-rule-for-nsf
+--rw i2nsf-security-policy +--rw i2nsf-security-policy
| ... | ...
| +--rw rules* [rule-name] | +--rw rules* [rule-name]
| | ... | | ...
skipping to change at page 15, line 31 skipping to change at page 15, line 31
| ... | ...
+--rw i2nsf-ipsec? identityref +--rw i2nsf-ipsec? identityref
Figure 5: YANG Tree Diagram for I2NSF Internet Key Exchnage Figure 5: YANG Tree Diagram for I2NSF Internet Key Exchnage
This YANG tree diagram shows an I2NSF IPsec specification for an This YANG tree diagram shows an I2NSF IPsec specification for an
Internet Key Exchange IKE). An I2NSF IPsec specification is used to Internet Key Exchange IKE). An I2NSF IPsec specification is used to
define a method required to manage IPsec parameters for creating define a method required to manage IPsec parameters for creating
IPsec Security Associations (SAs) between two NSFs through either the IPsec Security Associations (SAs) between two NSFs through either the
IKEv2 protocol or the Security Controller 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 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). (i.e., IPsec not through IKE, but through a Security Controller).
Refer to [draft-ietf-i2nsf-sdn-ipsec-flow-protection] for the Refer to [I-D.ietf-i2nsf-sdn-ipsec-flow-protection] for the detailed
detailed description of the I2NSF IPsec. 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 The semantics of the data model must be aligned with the information
security policy rules on network security functions. 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.
<CODE BEGINS> 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].
<CODE BEGINS> file "ietf-i2nsf-policy-rule-for-nsf@2020-08-28.yang"
module ietf-i2nsf-policy-rule-for-nsf { module ietf-i2nsf-policy-rule-for-nsf {
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf"; "urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf";
prefix prefix
nsfintf; nsfintf;
import ietf-inet-types{ import ietf-inet-types{
prefix inet; prefix inet;
skipping to change at page 16, line 27 skipping to change at page 16, line 52
} }
organization organization
"IETF I2NSF (Interface to Network Security Functions) "IETF I2NSF (Interface to Network Security Functions)
Working Group"; Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/i2nsf> "WG Web: <http://tools.ietf.org/wg/i2nsf>
WG List: <mailto:i2nsf@ietf.org> WG List: <mailto:i2nsf@ietf.org>
WG Chair: Linda Dunbar
<mailto:ldunbar@futurewei.com>
WG Chair: Yoav Nir
<mailto:ynir.ietf@gmail.com>
Editor: Jingyong Tim Kim Editor: Jingyong Tim Kim
<mailto:timkim@skku.edu> <mailto:timkim@skku.edu>
Editor: Jaehoon Paul Jeong Editor: Jaehoon Paul Jeong
<mailto:pauljeong@skku.edu> <mailto:pauljeong@skku.edu>";
Editor: Susan Hares
<mailto:shares@ndzh.com>";
description description
"This module defines a YANG data module for the Network Security "This module is a YANG module for Network Security Functions
Functions (NSF) facing interface. (NSF)-Facing Interface.
Copyright (c) 2019 IETF Trust and the persons Copyright (c) 2020 IETF Trust and the persons identified as
identified as authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents 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 This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision "2020-05-07"{ revision "2020-08-28"{
description "The latest revision."; description "The latest revision.";
reference reference
"RFC XXXX: I2NSF Network Security Function-Facing Interface "RFC XXXX: I2NSF Network Security Function-Facing Interface
YANG Data Model"; YANG Data Model";
} }
/* /*
* Identities * Identities
*/ */
skipping to change at page 17, line 37 skipping to change at page 18, line 4
identity priority-by-order { identity priority-by-order {
base priority-usage-type; base priority-usage-type;
description description
"Identity for priority by order"; "Identity for priority by order";
} }
identity priority-by-number { identity priority-by-number {
base priority-usage-type; base priority-usage-type;
description description
"Identity for priority by number"; "Identity for priority by number";
} }
identity event { identity event {
description description
"Base identity for policy events"; "Base identity for policy events";
reference reference
"draft-ietf-i2nsf-nsf-monitoring-data-model-02 "draft-ietf-i2nsf-nsf-monitoring-data-model-03: I2NSF NSF
- Event"; Monitoring YANG Data Model - Event";
} }
identity system-event { identity system-event {
base event; base event;
description description
"Identity for system events"; "Identity for system events";
reference reference
"draft-ietf-i2nsf-nsf-monitoring-data-model-02 "draft-ietf-i2nsf-nsf-monitoring-data-model-03: I2NSF NSF
- System event"; Monitoring YANG Data Model - System event";
} }
identity system-alarm { identity system-alarm {
base event; base event;
description description
"Identity for system alarms"; "Identity for system alarms";
reference reference
"draft-ietf-i2nsf-nsf-monitoring-data-model-02 "draft-ietf-i2nsf-nsf-monitoring-data-model-03: I2NSF NSF
- System alarm"; Monitoring YANG Data Model - System alarm";
} }
identity access-violation { identity access-violation {
base system-event; base system-event;
description description
"Identity for access violation "Identity for access violation
system events"; system events";
reference reference
"draft-ietf-i2nsf-nsf-monitoring-data-model-02 "draft-ietf-i2nsf-nsf-monitoring-data-model-03: I2NSF NSF
- System event"; Monitoring YANG Data Model - System event for access
violation";
} }
identity configuration-change { identity configuration-change {
base system-event; base system-event;
description description
"Identity for configuration change "Identity for configuration change
system events"; system events";
reference reference
"draft-ietf-i2nsf-nsf-monitoring-data-model-02 "draft-ietf-i2nsf-nsf-monitoring-data-model-03: I2NSF NSF
- System event"; Monitoring YANG Data Model - System event for configuration
change";
} }
identity memory-alarm { identity memory-alarm {
base system-alarm; base system-alarm;
description description
"Identity for memory alarm "Identity for memory alarm
system alarms"; system alarms";
reference reference
"draft-ietf-i2nsf-nsf-monitoring-data-model-02 "draft-ietf-i2nsf-nsf-monitoring-data-model-03: I2NSF NSF
- System alarm"; Monitoring YANG Data Model - System alarm for memory";
} }
identity cpu-alarm { identity cpu-alarm {
base system-alarm; base system-alarm;
description description
"Identity for CPU alarm "Identity for CPU alarm
system alarms"; system alarms";
reference reference
"draft-ietf-i2nsf-nsf-monitoring-data-model-02 "draft-ietf-i2nsf-nsf-monitoring-data-model-03: I2NSF NSF
- System alarm"; Monitoring YANG Data Model - System alarm for CPU";
} }
identity disk-alarm { identity disk-alarm {
base system-alarm; base system-alarm;
description description
"Identity for disk alarm "Identity for disk alarm
system alarms"; system alarms";
reference reference
"draft-ietf-i2nsf-nsf-monitoring-data-model-02 "draft-ietf-i2nsf-nsf-monitoring-data-model-03: I2NSF NSF
- System alarm"; Monitoring YANG Data Model - System alarm for disk";
} }
identity hardware-alarm { identity hardware-alarm {
base system-alarm; base system-alarm;
description description
"Identity for hardware alarm "Identity for hardware alarm
system alarms"; system alarms";
reference reference
"draft-ietf-i2nsf-nsf-monitoring-data-model-02 "draft-ietf-i2nsf-nsf-monitoring-data-model-03: I2NSF NSF
- System alarm"; Monitoring YANG Data Model - System alarm for hardware";
} }
identity interface-alarm { identity interface-alarm {
base system-alarm; base system-alarm;
description description
"Identity for interface alarm "Identity for interface alarm
system alarms"; system alarms";
reference reference
"draft-ietf-i2nsf-nsf-monitoring-data-model-02 "draft-ietf-i2nsf-nsf-monitoring-data-model-03: I2NSF NSF
- System alarm"; Monitoring YANG Data Model - System alarm for interface";
} }
identity type-of-service { identity type-of-service {
description description
"Base identity for type of service of IPv4"; "Base identity for type of service of IPv4";
reference reference
"RFC 791: Internet Protocol - Type of Service"; "RFC 791: Internet Protocol - Type of Service";
} }
identity traffic-class { identity traffic-class {
skipping to change at page 48, line 34 skipping to change at page 48, line 47
description description
"Identity for Prioritized Matching Rule "Identity for Prioritized Matching Rule
with No Errors (PMRN)"; with No Errors (PMRN)";
reference reference
"draft-ietf-i2nsf-capability-05: Information Model "draft-ietf-i2nsf-capability-05: Information Model
of NSFs Capabilities - Resolution Strategy"; of NSFs Capabilities - Resolution Strategy";
} }
identity i2nsf-ipsec { identity i2nsf-ipsec {
description description
"Internet Key Exchnage for NSFs "Internet Key Exchnage (IKE) for NSFs
in the I2NSF framework"; in the I2NSF framework";
reference reference
"draft-ietf-i2nsf-sdn-ipsec-flow-protection-04 "draft-ietf-i2nsf-sdn-ipsec-flow-protection-08: Software-Defined
- i2nsf-ipsec"; Networking (SDN)-based IPsec Flow Protection - IPsec method
types can be selected.";
} }
identity ike { identity ike {
base i2nsf-ipsec; base i2nsf-ipsec;
description description
"IKE case: IPsec with IKE in the NSF"; "IKE case: IPsec with IKE in the NSF";
reference reference
"draft-ietf-i2nsf-sdn-ipsec-flow-protection-04 "draft-ietf-i2nsf-sdn-ipsec-flow-protection-08: Software-Defined
- ike"; Networking (SDN)-based IPsec Flow Protection - IPsec method
type with IKE is selected.";
} }
identity ikeless { identity ikeless {
base i2nsf-ipsec; base i2nsf-ipsec;
description description
"IKEless case: IPsec without IKEv2 in the NSF"; "IKEless case: IPsec without IKEv2 in the NSF";
reference reference
"draft-ietf-i2nsf-sdn-ipsec-flow-protection-04 "draft-ietf-i2nsf-sdn-ipsec-flow-protection-08: Software-Defined
- ikeless"; Networking (SDN)-based IPsec Flow Protection - IPsec method
type without IKE is selected.";
} }
/* /*
* Typedefs * Typedefs
*/ */
typedef day-type { typedef day-type {
type enumeration { type enumeration {
enum sunday { enum sunday {
description description
skipping to change at page 59, line 37 skipping to change at page 60, line 5
or not. Examples of an I2NSF event include time and or not. Examples of an I2NSF event include time and
user actions (e.g., logon, logoff, and actions that user actions (e.g., logon, logoff, and actions that
violate any ACL.)."; violate any ACL.).";
reference reference
"RFC 8329: Framework for Interface to Network Security "RFC 8329: Framework for Interface to Network Security
Functions - I2NSF Flow Security Policy Structure Functions - I2NSF Flow Security Policy Structure
draft-ietf-i2nsf-capability-05: Information Model draft-ietf-i2nsf-capability-05: Information Model
of NSFs Capabilities - Design Principles and ECA of NSFs Capabilities - Design Principles and ECA
Policy Model Overview 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, NSF Monitoring YANG Data Model - Alarms, Events, Logs,
and Counters"; and Counters";
leaf event-clause-description { leaf event-clause-description {
type string; type string;
description description
"Description for an event clause"; "Description for an event clause";
} }
container event-clauses { container event-clauses {
description description
"System Event Clause - either a system event or "System Event Clause - either a system event or
system alarm"; system alarm";
reference reference
"RFC 8329: Framework for Interface to Network Security "RFC 8329: Framework for Interface to Network Security
Functions - I2NSF Flow Security Policy Structure Functions - I2NSF Flow Security Policy Structure
draft-ietf-i2nsf-capability-05: Information Model draft-ietf-i2nsf-capability-05: Information Model
of NSFs Capabilities - Design Principles and ECA Policy of NSFs Capabilities - Design Principles and ECA Policy
Model Overview 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, NSF Monitoring YANG Data Model - Alarms, Events, Logs,
and Counters"; and Counters";
leaf-list system-event { leaf-list system-event {
type identityref { type identityref {
base system-event; base system-event;
} }
description description
"The security policy rule according to "The security policy rule according to
system events."; system events.";
} }
skipping to change at page 62, line 29 skipping to change at page 62, line 46
} }
leaf-list pkt-sec-ipv4-tos { leaf-list pkt-sec-ipv4-tos {
type identityref { type identityref {
base type-of-service; base type-of-service;
} }
description description
"The security policy rule according to "The security policy rule according to
IPv4 type of service."; IPv4 type of service.";
reference reference
"RFC 1394: Internet Protocol - Type of service"; "RFC 791: Internet Protocol - Type of service";
} }
container pkt-sec-ipv4-total-length { container pkt-sec-ipv4-total-length {
choice match-type { choice match-type {
description description
"Security policy IPv4 total length matching "Security policy IPv4 total length matching
- exact match and range match."; - exact match and range match.";
case exact-match { case exact-match {
leaf-list ipv4-total-length { leaf-list ipv4-total-length {
type uint16; type uint16;
skipping to change at page 86, line 16 skipping to change at page 86, line 30
} }
} }
} }
} }
leaf i2nsf-ipsec { leaf i2nsf-ipsec {
type identityref { type identityref {
base i2nsf-ipsec; base i2nsf-ipsec;
} }
description description
"Internet Key Exchnage for NSFs "Internet Key Exchnage (IKE) for NSFs
in the I2NSF framework"; in the I2NSF framework";
reference reference
"draft-ietf-i2nsf-sdn-ipsec-flow-protection-04 "draft-ietf-i2nsf-sdn-ipsec-flow-protection-08: Software-Defined
- i2nsf-ipsec"; Networking (SDN)-based IPsec Flow Protection - IPsec method
types can be selected.";
} }
} }
<CODE ENDS> <CODE ENDS>
Figure 6: YANG Data Module of I2NSF NSF-Facing-Interface Figure 6: YANG Data Module of I2NSF NSF-Facing-Interface
6. XML Configuration Examples of Low-Level Security Policy Rules 6. XML Configuration Examples of Low-Level Security Policy Rules
This section shows XML configuration examples of low-level security This section shows XML configuration examples of low-level security
policy rules that are delivered from the Security Controller to NSFs policy rules that are delivered from the Security Controller to NSFs
over the NSF-Facing Interface. For security requirements, we assume over the NSF-Facing Interface. For security requirements, we assume
that the NSFs (i.e., General firewall, Time-based firewall, URL that the NSFs (i.e., General firewall, Time-based firewall, URL
filter, VoIP/VoLTE filter, and http and https flood mitigation ) filter, VoIP/VoLTE filter, and http and https flood mitigation )
described in Appendix A. Configuration Examples of 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 framework. With the registed NSFs, we show configuration examples
for security policy rules of network security functions according to for security policy rules of network security functions according to
the following three security requirements: (i) Block SNS access the following three security requirements: (i) Block SNS access
during business hours, (ii) Block malicious VoIP/VoLTE packets coming during business hours, (ii) Block malicious VoIP/VoLTE packets coming
to the company, and (iii) Mitigate http and https flood attacks on to the company, and (iii) Mitigate http and https flood attacks on
company web server. company web server.
6.1. Security Requirement 1: Block SNS Access during Business Hours 6.1. Security Requirement 1: Block SNS Access during Business Hours
This section shows a configuration example for blocking SNS access This section shows a configuration example for blocking SNS access
during business hours. during business hours in IPv4 networks [RFC5737] or IPv6 networks
[RFC3849].
<i2nsf-security-policy <i2nsf-security-policy
xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf"> xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf">
<system-policy> <system-policy>
<system-policy-name>sns_access</system-policy-name> <system-policy-name>sns_access</system-policy-name>
<rules> <rules>
<rule-name>block_sns_access_during_operation_time</rule-name> <rule-name>block_sns_access_during_operation_time</rule-name>
<time-intervals> <time-intervals>
<absolute-time-interval> <absolute-time-interval>
<start-date-time>2019-08-01T09:00:00Z</start-date-time> <start-date-time>2019-08-01T09:00:00Z</start-date-time>
<end-date-time>2019-12-31T18:00:00Z</end-date-time> <end-date-time>2019-12-31T18:00:00Z</end-date-time>
</absolute-time-interval> </absolute-time-interval>
</time-intervals> </time-intervals>
<condition-clause-container> <condition-clause-container>
<packet-security-ipv4-condition> <packet-security-ipv4-condition>
<pkt-sec-ipv4-src> <pkt-sec-ipv4-src>
<range-ipv4-address> <range-ipv4-address>
<start-ipv4-address>221.159.112.1</start-ipv4-address> <start-ipv4-address>192.0.2.11</start-ipv4-address>
<end-ipv4-address>221.159.112.90</end-ipv4-address> <end-ipv4-address>192.0.2.90</end-ipv4-address>
</range-ipv4-address> </range-ipv4-address>
</pkt-sec-ipv4-src> </pkt-sec-ipv4-src>
</packet-security-ipv4-condition> </packet-security-ipv4-condition>
</condition-clause-container> </condition-clause-container>
<action-clause-container> <action-clause-container>
<advanced-action> <advanced-action>
<content-security-control>url-filtering</content-security-control> <content-security-control>url-filtering</content-security-control>
</advanced-action> </advanced-action>
</action-clause-container> </action-clause-container>
</rules> </rules>
</system-policy> </system-policy>
</i2nsf-security-policy> </i2nsf-security-policy>
Figure 7: Configuration XML for Time-based Firewall to Block SNS Figure 7: Configuration XML for Time-based Firewall to Block SNS
Access during Business Hours Access during Business Hours in IPv4 Networks
<i2nsf-security-policy
xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf">
<system-policy>
<system-policy-name>sns_access</system-policy-name>
<rules>
<rule-name>block_sns_access_during_operation_time</rule-name>
<time-intervals>
<absolute-time-interval>
<start-date-time>2019-08-01T09:00:00Z</start-date-time>
<end-date-time>2019-12-31T18:00:00Z</end-date-time>
</absolute-time-interval>
</time-intervals>
<condition-clause-container>
<packet-security-ipv6-condition>
<pkt-sec-ipv6-src>
<range-ipv6-address>
<start-ipv6-address>2001:DB8:0:1::11</start-ipv6-address>
<end-ipv6-address>2001:DB8:0:1::90</end-ipv6-address>
</range-ipv6-address>
</pkt-sec-ipv6-src>
</packet-security-ipv6-condition>
</condition-clause-container>
<action-clause-container>
<advanced-action>
<content-security-control>url-filtering</content-security-control>
</advanced-action>
</action-clause-container>
</rules>
</system-policy>
</i2nsf-security-policy>
Figure 8: Configuration XML for Time-based Firewall to Block SNS
Access during Business Hours in IPv6 Networks
<i2nsf-security-policy <i2nsf-security-policy
xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf"> xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf">
<system-policy> <system-policy>
<system-policy-name>sns_access</system-policy-name> <system-policy-name>sns_access</system-policy-name>
<rules> <rules>
<rule-name>block_sns_access_during_operation_time</rule-name> <rule-name>block_sns_access_during_operation_time</rule-name>
<condition-clause-container> <condition-clause-container>
<packet-security-url-category-condition> <packet-security-url-category-condition>
<user-defined-category>facebook</user-defined-category> <user-defined-category>facebook</user-defined-category>
skipping to change at page 88, line 26 skipping to change at page 90, line 26
</condition-clause-container> </condition-clause-container>
<action-clause-container> <action-clause-container>
<packet-action> <packet-action>
<egress-action>drop</egress-action> <egress-action>drop</egress-action>
</packet-action> </packet-action>
</action-clause-container> </action-clause-container>
</rules> </rules>
</system-policy> </system-policy>
</i2nsf-security-policy> </i2nsf-security-policy>
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 Business Hours
Figure 7 and Figure 8 show the configuration XML documents for time- Figure 7 (or Figure 8) and Figure 9 show the configuration XML
based firewall and web filter to block SNS access during business documents for time-based firewall and web filter to block SNS access
hours. For the security requirement, two NSFs (i.e., a time-based during business hours in IPv4 networks (or IPv6 networks). For the
firewall and a web filter) were used because one NSF cannot meet the security requirement, two NSFs (i.e., a time-based firewall and a web
security requirement. The instances of XML documents for the time- filter) were used because one NSF cannot meet the security
based firewall and the web filter are as follows: Note that a requirement. The instances of XML documents for the time-based
detailed data model for the configuration of the advanced network firewall and the web filter are as follows: Note that a detailed data
security function (i.e., web filter) is described in model for the configuration of the advanced network security function
[draft-dong-i2nsf-asf-config]. (i.e., web filter) can be defined as an extension in future.
Time-based Firewall is as follows: Time-based Firewall is as follows:
1. The name of the system policy is sns_access. 1. The name of the system policy is sns_access.
2. The name of the rule is block_sns_access_during_operation_time. 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. 3. The rule is operated during the business hours (i.e., from 9 a.m.
to 6 p.m.). to 6 p.m.).
4. The rule inspects a source IPv4 address (i.e., from 221.159.112.1 4. The rule inspects a source IPv4 address (i.e., from 192.0.2.11 to
to 221.159.112.90) to inspect the outgoing packets of employees. 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 5. If the outgoing packets match the rules above, the time-based
firewall sends the packets to url filtering for additional firewall sends the packets to url filtering for additional
inspection because the time-based firewall can not inspect inspection because the time-based firewall can not inspect
contents of the packets for the SNS URL. contents of the packets for the SNS URL.
Web Filter is as follows: Web Filter is as follows:
1. The name of the system policy is sns_access. 1. The name of the system policy is sns_access.
skipping to change at page 90, line 15 skipping to change at page 92, line 15
<i2nsf-security-policy <i2nsf-security-policy
xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf"> xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf">
<system-policy> <system-policy>
<system-policy-name>voip_volte_inspection</system-policy-name> <system-policy-name>voip_volte_inspection</system-policy-name>
<rules> <rules>
<rule-name>block_malicious_voice_id</rule-name> <rule-name>block_malicious_voice_id</rule-name>
<condition-clause-container> <condition-clause-container>
<packet-security-ipv4-condition> <packet-security-ipv4-condition>
<pkt-sec-ipv4-dest> <pkt-sec-ipv4-dest>
<range-ipv4-address> <range-ipv4-address>
<start-ipv4-address>221.159.112.1</start-ipv4-address> <start-ipv4-address>192.0.2.11</start-ipv4-address>
<end-ipv4-address>221.159.112.90</end-ipv4-address> <end-ipv4-address>192.0.2.90</end-ipv4-address>
</range-ipv4-address> </range-ipv4-address>
</pkt-sec-ipv4-dest> </pkt-sec-ipv4-dest>
</packet-security-ipv4-condition> </packet-security-ipv4-condition>
<packet-security-tcp-condition> <packet-security-tcp-condition>
<pkt-sec-tcp-dest-port-num> <pkt-sec-tcp-dest-port-num>
<port-num>5060</port-num> <port-num>5060</port-num>
<port-num>5061</port-num> <port-num>5061</port-num>
</pkt-sec-tcp-dest-port-num> </pkt-sec-tcp-dest-port-num>
</packet-security-tcp-condition> </packet-security-tcp-condition>
</condition-clause-container> </condition-clause-container>
<action-clause-container> <action-clause-container>
<advanced-action> <advanced-action>
<content-security-control>voip-volte</content-security-control> <content-security-control>voip-volte</content-security-control>
</advanced-action> </advanced-action>
</action-clause-container> </action-clause-container>
</rules> </rules>
</system-policy> </system-policy>
</i2nsf-security-policy> </i2nsf-security-policy>
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 Packets Coming to a Company
<i2nsf-security-policy <i2nsf-security-policy
xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf"> xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf">
<system-policy> <system-policy>
<system-policy-name>voip_volte_inspection</system-policy-name> <system-policy-name>voip_volte_inspection</system-policy-name>
<rules> <rules>
<rule-name>block_malicious_voice_id</rule-name> <rule-name>block_malicious_voice_id</rule-name>
<condition-clause-container> <condition-clause-container>
<packet-security-voice-condition> <packet-security-voice-condition>
skipping to change at page 91, line 26 skipping to change at page 93, line 26
</condition-clause-container> </condition-clause-container>
<action-clause-container> <action-clause-container>
<packet-action> <packet-action>
<ingress-action>drop</ingress-action> <ingress-action>drop</ingress-action>
</packet-action> </packet-action>
</action-clause-container> </action-clause-container>
</rules> </rules>
</system-policy> </system-policy>
</i2nsf-security-policy> </i2nsf-security-policy>
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 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 general firewall and VoIP/VoLTE filter to block malicious VoIP/VoLTE
packets coming to a company. For the security requirement, two NSFs packets coming to a company. For the security requirement, two NSFs
(i.e., a general firewall and a VoIP/VoLTE filter) were used because (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 one NSF can not meet the security requirement. The instances of XML
documents for the general firewall and the VoIP/VoLTE filter are as documents for the general firewall and the VoIP/VoLTE filter are as
follows: Note that a detailed data model for the configuration of the follows: Note that a detailed data model for the configuration of the
advanced network security function (i.e., VoIP/VoLTE filter) is advanced network security function (i.e., VoIP/VoLTE filter) can be
described in [draft-dong-i2nsf-asf-config]. described as an extension in future.
General Firewall is as follows: General Firewall is as follows:
1. The name of the system policy is voip_volte_inspection. 1. The name of the system policy is voip_volte_inspection.
2. The name of the rule is block_malicious_voip_volte_packets. 2. The name of the rule is block_malicious_voip_volte_packets.
3. The rule inspects a destination IPv4 address (i.e., from 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 192.0.2.11 to 192.0.2.90) to inspect the packets coming into the
into the company. company.
4. The rule inspects a port number (i.e., 5060 and 5061) to inspect 4. The rule inspects a port number (i.e., 5060 and 5061) to inspect
VoIP/VoLTE packet. VoIP/VoLTE packet.
5. If the incoming packets match the rules above, the general 5. If the incoming packets match the rules above, the general
firewall sends the packets to VoIP/VoLTE filter for additional firewall sends the packets to VoIP/VoLTE filter for additional
inspection because the general firewall can not inspect contents inspection because the general firewall can not inspect contents
of the VoIP/VoLTE packets. of the VoIP/VoLTE packets.
VoIP/VoLTE Filter is as follows: VoIP/VoLTE Filter is as follows:
skipping to change at page 93, line 15 skipping to change at page 95, line 15
<i2nsf-security-policy <i2nsf-security-policy
xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf"> xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf">
<system-policy> <system-policy>
<system-policy-name>flood_attack_mitigation</system-policy-name> <system-policy-name>flood_attack_mitigation</system-policy-name>
<rules> <rules>
<rule-name>mitigate_http_and_https_flood_attack</rule-name> <rule-name>mitigate_http_and_https_flood_attack</rule-name>
<condition-clause-container> <condition-clause-container>
<packet-security-ipv4-condition> <packet-security-ipv4-condition>
<pkt-sec-ipv4-dest> <pkt-sec-ipv4-dest>
<ipv4-address> <ipv4-address>
<ipv4>221.159.112.95</ipv4> <ipv4>192.0.2.11</ipv4>
</ipv4-address> </ipv4-address>
</pkt-sec-ipv4-dest> </pkt-sec-ipv4-dest>
</packet-security-ipv4-condition> </packet-security-ipv4-condition>
<packet-security-tcp-condition> <packet-security-tcp-condition>
<pkt-sec-tcp-dest-port-num> <pkt-sec-tcp-dest-port-num>
<port-num>80</port-num> <port-num>80</port-num>
<port-num>443</port-num> <port-num>443</port-num>
</pkt-sec-tcp-dest-port-num> </pkt-sec-tcp-dest-port-num>
</packet-security-tcp-condition> </packet-security-tcp-condition>
</condition-clause-container> </condition-clause-container>
<action-clause-container> <action-clause-container>
<advanced-action> <advanced-action>
<attack-mitigation-control>http-and-https-flood <attack-mitigation-control>http-and-https-flood
</attack-mitigation-control> </attack-mitigation-control>
</advanced-action> </advanced-action>
</action-clause-container> </action-clause-container>
</rules> </rules>
</system-policy> </system-policy>
</i2nsf-security-policy> </i2nsf-security-policy>
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 and HTTPS Flood Attacks on a Company Web Server
<i2nsf-security-policy <i2nsf-security-policy
xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf"> xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf">
<system-policy> <system-policy>
<system-policy-name>flood_attack_mitigation</system-policy-name> <system-policy-name>flood_attack_mitigation</system-policy-name>
<rules> <rules>
<rule-name>mitigate_http_and_https_flood_attack</rule-name> <rule-name>mitigate_http_and_https_flood_attack</rule-name>
<condition-clause-container> <condition-clause-container>
<packet-security-ddos-condition> <packet-security-ddos-condition>
skipping to change at page 94, line 25 skipping to change at page 96, line 25
</condition-clause-container> </condition-clause-container>
<action-clause-container> <action-clause-container>
<packet-action> <packet-action>
<ingress-action>drop</ingress-action> <ingress-action>drop</ingress-action>
</packet-action> </packet-action>
</action-clause-container> </action-clause-container>
</rules> </rules>
</system-policy> </system-policy>
</i2nsf-security-policy> </i2nsf-security-policy>
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 Mitigation to Mitigate HTTP and HTTPS Flood Attacks on a Company Web
Server 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 general firewall and http and https flood attack mitigation to
mitigate http and https flood attacks on a company web server. For mitigate http and https flood attacks on a company web server. For
the security requirement, two NSFs (i.e., a general firewall and a the security requirement, two NSFs (i.e., a general firewall and a
http and https flood attack mitigation) were used because one NSF can http and https flood attack mitigation) were used because one NSF can
not meet the security requirement. The instances of XML documents not meet the security requirement. The instances of XML documents
for the general firewall and http and https flood attack mitigation for the general firewall and http and https flood attack mitigation
are as follows: Note that a detailed data model for the configuration are as follows: Note that a detailed data model for the configuration
of the advanced network security function (i.e., http and https flood 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: General Firewall is as follows:
1. The name of the system policy is flood_attack_mitigation. 1. The name of the system policy is flood_attack_mitigation.
2. The name of the rule is mitigate_http_and_https_flood_attack. 2. The name of the rule is mitigate_http_and_https_flood_attack.
3. The rule inspects a destination IPv4 address (i.e., 3. The rule inspects a destination IPv4 address (i.e., 192.0.2.11)
221.159.112.95) to inspect the access packets coming into the to inspect the access packets coming into the company web server.
company web server.
4. The rule inspects a port number (i.e., 80 and 443) to inspect 4. The rule inspects a port number (i.e., 80 and 443) to inspect
http and https packet. http and https packet.
5. If the packets match the rules above, the general firewall sends 5. If the packets match the rules above, the general firewall sends
the packets to http and https flood attack mitigation for the packets to http and https flood attack mitigation for
additional inspection because the general firewall can not contrl additional inspection because the general firewall can not contrl
the amount of packets for http and https packets. the amount of packets for http and https packets.
HTTP and HTTPS Flood Attack Mitigation is as follows: HTTP and HTTPS Flood Attack Mitigation is as follows:
skipping to change at page 95, line 23 skipping to change at page 97, line 23
http_and_https_flood_attack_mitigation. http_and_https_flood_attack_mitigation.
2. The name of the rule is 100_per_second. 2. The name of the rule is 100_per_second.
3. The rule controls the http and https packets according to the 3. The rule controls the http and https packets according to the
amount of incoming packets. amount of incoming packets.
4. If the incoming packets match the rules above, the packets are 4. If the incoming packets match the rules above, the packets are
blocked. 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 The YANG module specified in this document defines a data schema
designed to be accessed through network management protocols such as designed to be accessed through network management protocols such as
NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is
the secure transport layer, and the required secure transport is the secure transport layer, and the required secure transport is
Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS,
and the required secure transport is TLS [RFC8446]. and the required secure transport is TLS [RFC8446].
The NETCONF access control model [RFC8341] provides a means of The NETCONF access control model [RFC8341] provides a means of
restricting access to specific NETCONF or RESTCONF users to a restricting access to specific NETCONF or RESTCONF users to a
skipping to change at page 96, line 9 skipping to change at page 98, line 28
Some of the readable data nodes in this YANG module may be considered Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or important to control read access (e.g., via get, get-config, or
notification) to these data nodes. These are the subtrees and data notification) to these data nodes. These are the subtrees and data
nodes and their sensitivity/vulnerability: nodes and their sensitivity/vulnerability:
o ietf-i2nsf-policy-rule-for-nsf: The attacker may gather the 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 of any target NSFs and misuse the
security policy information for subsequent attacks. security policy information for subsequent attacks.
8. IANA Considerations 9. Acknowledgments
This document requests IANA to register the following URI in the This work was supported by Institute of Information & Communications
"IETF XML Registry" [RFC3688]: 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 Hyoungshick Kim
the "YANG Module Names" registry [RFC7950]. 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- EMail: dyhyun@skku.edu
nsf
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 EMail: Frank.Xialiang@huawei.com
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).
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. EMail: taejin.ahn@kt.com
Many people actively contributed to this document. The following are
considered co-authors:
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) 11.1. Normative References
o Tae-Jin Ahn (Korea Telecom)
o Se-Hui Lee (Korea Telecom) [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>.
11. References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
11.1. Normative References [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>.
[RFC1394] Robinson, P., "Relationship of Telex Answerback Codes to [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
Internet Domains", RFC 1394, DOI 10.17487/RFC1394, January RFC 793, DOI 10.17487/RFC0793, September 1981,
1993, <https://www.rfc-editor.org/info/rfc1394>. <https://www.rfc-editor.org/info/rfc793>.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
DOI 10.17487/RFC1700, October 1994,
<https://www.rfc-editor.org/info/rfc1700>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced
an On-line Database", RFC 3232, January 2002. by an On-line Database", RFC 3232, DOI 10.17487/RFC3232,
January 2002, <https://www.rfc-editor.org/info/rfc3232>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
Reserved for Documentation", RFC 3849,
DOI 10.17487/RFC3849, July 2004,
<https://www.rfc-editor.org/info/rfc3849>.
[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,
<https://www.rfc-editor.org/info/rfc4443>.
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
Reserved for Documentation", RFC 5737,
DOI 10.17487/RFC5737, January 2010,
<https://www.rfc-editor.org/info/rfc5737>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>. <https://www.rfc-editor.org/info/rfc6242>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[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", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J.
Zhang, "YANG Data Model for Key Chains", RFC 8177, Zhang, "YANG Data Model for Key Chains", RFC 8177,
DOI 10.17487/RFC8177, June 2017, DOI 10.17487/RFC8177, June 2017,
<https://www.rfc-editor.org/info/rfc8177>. <https://www.rfc-editor.org/info/rfc8177>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
[RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
Kumar, "Framework for Interface to Network Security Kumar, "Framework for Interface to Network Security
Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018,
<https://www.rfc-editor.org/info/rfc8329>. <https://www.rfc-editor.org/info/rfc8329>.
[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,
<https://www.rfc-editor.org/info/rfc8335>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341, Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018, DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>. <https://www.rfc-editor.org/info/rfc8341>.
[RFC8431] Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini, [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management",
S., and N. Bahadur, "A YANG Data Model for the Routing RFC 8344, DOI 10.17487/RFC8344, March 2018,
Information Base (RIB)", RFC 8431, DOI 10.17487/RFC8431, <https://www.rfc-editor.org/info/rfc8344>.
September 2018, <https://www.rfc-editor.org/info/rfc8431>.
[RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of
Documents Containing YANG Data Models", BCP 216, RFC 8407,
DOI 10.17487/RFC8407, October 2018,
<https://www.rfc-editor.org/info/rfc8407>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
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,
<https://www.rfc-editor.org/info/rfc8525>.
[draft-dong-i2nsf-asf-config] 11.2. Informative References
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.
[draft-ietf-i2nsf-capability] [I-D.ietf-i2nsf-capability]
Xia, L., Strassner, J., Basile, C., and D. Lopez, Xia, L., Strassner, J., Basile, C., and D. Lopez,
"Information Model of NSFs Capabilities", draft-ietf- "Information Model of NSFs Capabilities", draft-ietf-
i2nsf-capability-05 (work in progress), April 2019. 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, Hares, S., Jeong, J., Kim, J., Moskowitz, R., and Q. Lin,
"I2NSF Capability YANG Data Model", draft-ietf-i2nsf- "I2NSF Capability YANG Data Model", draft-ietf-i2nsf-
capability-data-model-05 (work in progress), July 2019. capability-data-model-08 (work in progress), August 2020.
[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
The following changes are made from draft-ietf-i2nsf-nsf-facing- [I-D.ietf-i2nsf-nsf-monitoring-data-model]
interface-dm-08: 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 [I-D.ietf-i2nsf-sdn-ipsec-flow-protection]
active status of the draft. 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 Authors' Addresses
Jinyong Tim Kim Jinyong Tim Kim (editor)
Department of Electronic, Electrical and Computer Engineering Department of Electronic, Electrical and Computer Engineering
Sungkyunkwan University Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu 2066 Seobu-Ro, Jangan-Gu
Suwon, Gyeonggi-Do 16419 Suwon, Gyeonggi-Do 16419
Republic of Korea Republic of Korea
Phone: +82 10 8273 0930 Phone: +82 10 8273 0930
EMail: timkim@skku.edu EMail: timkim@skku.edu
Jaehoon Paul Jeong Jaehoon Paul Jeong (editor)
Department of Computer Science and Engineering Department of Computer Science and Engineering
Sungkyunkwan University Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu 2066 Seobu-Ro, Jangan-Gu
Suwon, Gyeonggi-Do 16419 Suwon, Gyeonggi-Do 16419
Republic of Korea Republic of Korea
Phone: +82 31 299 4957 Phone: +82 31 299 4957
Fax: +82 31 290 7996 Fax: +82 31 290 7996
EMail: pauljeong@skku.edu EMail: pauljeong@skku.edu
URI: http://iotlab.skku.edu/people-jaehoon-jeong.php URI: http://iotlab.skku.edu/people-jaehoon-jeong.php
 End of changes. 115 change blocks. 
252 lines changed or deleted 354 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/