draft-ietf-i2nsf-capability-data-model-13.txt   draft-ietf-i2nsf-capability-data-model-14.txt 
I2NSF Working Group S. Hares, Ed. I2NSF Working Group S. Hares, Ed.
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track J. Jeong, Ed. Intended status: Standards Track J. Jeong, Ed.
Expires: May 6, 2021 J. Kim Expires: July 3, 2021 J. Kim
Sungkyunkwan University Sungkyunkwan University
R. Moskowitz R. Moskowitz
HTT Consulting HTT Consulting
Q. Lin Q. Lin
Huawei Huawei
November 2, 2020 December 30, 2020
I2NSF Capability YANG Data Model I2NSF Capability YANG Data Model
draft-ietf-i2nsf-capability-data-model-13 draft-ietf-i2nsf-capability-data-model-14
Abstract Abstract
This document defines an information model and the corresponding YANG This document defines an information model and the corresponding YANG
data model for the capabilities of various Network Security Functions data model for the capabilities of various Network Security Functions
(NSFs) in the Interface to Network Security Functions (I2NSF) (NSFs) in the Interface to Network Security Functions (I2NSF)
framework to centrally manage the capabilities of the various NSFs. framework to centrally manage the capabilities of the various NSFs.
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 May 6, 2021. This Internet-Draft will expire on July 3, 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 18 skipping to change at page 2, line 18
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Capability Information Model Design . . . . . . . . . . . . . 4 3. Capability Information Model Design . . . . . . . . . . . . . 4
3.1. Design Principles and ECA Policy Model Overview . . . . . 5 3.1. Design Principles and ECA Policy Model Overview . . . . . 5
3.2. Matched Policy Rule . . . . . . . . . . . . . . . . . . . 8 3.2. Matched Policy Rule . . . . . . . . . . . . . . . . . . . 8
3.3. Conflict, Resolution Strategy and Default Action . . . . 8 3.3. Conflict, Resolution Strategy and Default Action . . . . 8
4. Overview of YANG Data Model . . . . . . . . . . . . . . . . . 10 4. Overview of YANG Data Model . . . . . . . . . . . . . . . . . 9
5. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 12 5. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Network Security Function (NSF) Capabilities . . . . . . 12 5.1. Network Security Function (NSF) Capabilities . . . . . . 12
6. YANG Data Model of I2NSF NSF Capability . . . . . . . . . . . 15 6. YANG Data Model of I2NSF NSF Capability . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
8. Security Considerations . . . . . . . . . . . . . . . . . . . 47 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 50
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 9. Security Considerations . . . . . . . . . . . . . . . . . . . 51
9.1. Normative References . . . . . . . . . . . . . . . . . . 47 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
9.2. Informative References . . . . . . . . . . . . . . . . . 50 10.1. Normative References . . . . . . . . . . . . . . . . . . 52
Appendix A. Configuration Examples . . . . . . . . . . . . . . . 52 10.2. Informative References . . . . . . . . . . . . . . . . . 56
Appendix A. Configuration Examples . . . . . . . . . . . . . . . 58
A.1. Example 1: Registration for the Capabilities of a General A.1. Example 1: Registration for the Capabilities of a General
Firewall . . . . . . . . . . . . . . . . . . . . . . . . 52 Firewall . . . . . . . . . . . . . . . . . . . . . . . . 58
A.2. Example 2: Registration for the Capabilities of a Time- A.2. Example 2: Registration for the Capabilities of a Time-
based Firewall . . . . . . . . . . . . . . . . . . . . . 54 based Firewall . . . . . . . . . . . . . . . . . . . . . 60
A.3. Example 3: Registration for the Capabilities of a Web A.3. Example 3: Registration for the Capabilities of a Web
Filter . . . . . . . . . . . . . . . . . . . . . . . . . 55 Filter . . . . . . . . . . . . . . . . . . . . . . . . . 61
A.4. Example 4: Registration for the Capabilities of a A.4. Example 4: Registration for the Capabilities of a
VoIP/VoLTE Filter . . . . . . . . . . . . . . . . . . . . 56 VoIP/VoLTE Filter . . . . . . . . . . . . . . . . . . . . 62
A.5. Example 5: Registration for the Capabilities of a HTTP A.5. Example 5: Registration for the Capabilities of a HTTP
and HTTPS Flood Mitigator . . . . . . . . . . . . . . . . 57 and HTTPS Flood Mitigator . . . . . . . . . . . . . . . . 63
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 58 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 64
Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 59 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 65
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67
1. Introduction 1. Introduction
As the industry becomes more sophisticated and network devices (e.g., As the industry becomes more sophisticated and network devices (e.g.,
Internet of Things, Self-driving vehicles, and smartphone using Voice Internet-of-Things (IoT) devices, autonomous vehicles, and
over IP (VoIP) and Voice over LTE (VoLTE)) requires advanced security smartphones using Voice over IP (VoIP) and Voice over LTE (VoLTE))
protection in various scenario, service providers have a lot of require advanced security protection in various scenario, service
problems described in [RFC8192]. To resolve these problems, this providers have a lot of problems described in [RFC8192]. To resolve
document specifies the information and data model of the capabilities these problems, this document specifies the information and data
of Network Security Functions (NSFs) in a framework of the Interface models of the capabilities of Network Security Functions (NSFs) in a
to Network Security Functions (I2NSF) [RFC8329]. framework of the Interface to Network Security Functions (I2NSF)
[RFC8329].
NSFs produced by multiple security vendors provide various security NSFs produced by multiple security vendors provide various security
capabilities to customers. Multiple NSFs can be combined together to capabilities to customers. Multiple NSFs can be combined together to
provide security services over the given network traffic, regardless provide security services over the given network traffic, regardless
of whether the NSFs are implemented as physical or virtual functions. of whether the NSFs are implemented as physical or virtual functions.
Security Capabilities describe the functions that Network Security Security Capabilities describe the functions that Network Security
Functions (NSFs) are available to provide for security policy Functions (NSFs) are available to provide for security policy
enforcement purposes. Security Capabilities are independent of the enforcement purposes. Security Capabilities are independent of the
actual security control mechanisms that will implement them. actual security control mechanisms that will implement them.
Every NSF SHOULD be described with the set of capabilities it offers. Every NSF SHOULD be described with the set of capabilities it offers.
Security Capabilities enable security functionality to be described Security Capabilities enable security functionality to be described
in a vendor-neutral manner. That is, it is not needed to refer to a in a vendor-neutral manner. That is, it is not needed to refer to a
specific product or technology when designing the network; rather, specific product or technology when designing the network; rather,
the functions characterized by their capabilities are considered. the functions characterized by their capabilities are considered.
Security Capabilities are a market enabler, providing a way to define Security Capabilities are a market enabler, providing a way to define
customized security protection by unambiguously describing the customized security protection by unambiguously describing the
security features offered by a given NSF. security features offered by a given NSF. Note that this YANG data
model outlines an NSF monitoring YANG data model
[I-D.ietf-i2nsf-nsf-monitoring-data-model] and a YANG data model for
Software-Defined Networking (SDN)-based IPsec flow protection
[I-D.ietf-i2nsf-sdn-ipsec-flow-protection].
This document provides an information model and the corresponding This document provides an information model and the corresponding
YANG data model [RFC6020][RFC7950] that defines the capabilities of YANG data model [RFC6020][RFC7950] that defines the capabilities of
NSFs to centrally manage the capabilities of those security devices. NSFs to centrally manage the capabilities of those security devices.
The security devices can register their own capabilities into a The security devices can register their own capabilities into a
Network Operator Management (Mgmt) System (i.e., Security Controller) Network Operator Management (Mgmt) System (i.e., Security Controller)
with this YANG data model through the registration interface with this YANG data model through the registration interface
[RFC8329]. With the database of the capabilities of those security [RFC8329]. With the database of the capabilities of those security
devices maintained centrally, those security devices can be more devices that are maintained centrally, those security devices can be
easily managed [RFC8329]. more easily managed [RFC8329].
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 as model that is used as the basis for the design of I2NSF Policy as
described in [RFC8329] and Section 3.1. The "ietf-i2nsf-capability" described in [RFC8329] and Section 3.1. The "ietf-i2nsf-capability"
YANG module defined in this document provides the following features: YANG module defined in this document provides the following features:
o Definition for time capabilities of network security functions. o Definition for time capabilities of network security functions.
o Definition for event capabilities of generic network security o Definition for event capabilities of generic network security
functions. functions.
skipping to change at page 4, line 30 skipping to change at page 4, line 36
3. Capability Information Model Design 3. Capability Information Model Design
A Capability Information Model (CapIM) is a formalization of the A Capability Information Model (CapIM) is a formalization of the
functionality that an NSF advertises. This enables the precise functionality that an NSF advertises. This enables the precise
specification of what an NSF can do in terms of security policy specification of what an NSF can do in terms of security policy
enforcement, so that computer-based tasks can unambiguously refer to, enforcement, so that computer-based tasks can unambiguously refer to,
use, configure, and manage NSFs. Capabilities MUST be defined in a use, configure, and manage NSFs. Capabilities MUST be defined in a
vendor- and technology-independent manner (e.g., regardless of the vendor- and technology-independent manner (e.g., regardless of the
differences among vendors and individual products). differences among vendors and individual products).
Humans are able to refer to categories of security controls and Humans can refer to categories of security controls and understand
understand each other. For instance, security experts agree on what each other. For instance, network security experts agree on what is
is meant by the terms "NAT", "filtering", and "VPN concentrator". As meant by the terms "NAT", "filtering", and "VPN concentrator". As a
a further example, network security experts unequivocally refer to further example, network security experts unequivocally refer to
"packet filters" as stateless devices able to allow or deny packet "packet filters" as stateless devices that allow or deny packet
forwarding based on various conditions (e.g., source and destination forwarding based on various conditions (e.g., source and destination
IP addresses, source and destination ports, and IP protocol type IP addresses, source and destination ports, and IP protocol type
fields) [Alshaer]. fields) [Alshaer].
However, more information is required in case of other devices, like However, more information is required in case of other devices, like
stateful firewalls or application layer filters. These devices stateful firewalls or application layer filters. These devices
filter packets or communications, but there are differences in the filter packets or communications, but there are differences in the
packets and communications that they can categorize and the states packets and communications that they can categorize and the states
they maintain. Humans deal with these differences by asking more they maintain. Humans deal with these differences by asking more
questions to determine the specific category and functionality of the questions to determine the specific category and functionality of the
device. Machines can follow a similar approach, which is commonly device. Machines can follow a similar approach, which is commonly
referred to as question-answering [Hirschman] [Galitsky]. In this referred to as question-answering [Hirschman] [Galitsky]. In this
context, the CapIM and the derived Data Models provide important and context, the CapIM and the derived data model can provide important
rich information sources. and rich information sources.
Analogous considerations can be applied for channel protection Analogous considerations can be applied for channel protection
protocols, where we all understand that they will protect packets by protocols, where we all understand that they will protect packets by
means of symmetric algorithms whose keys could have been negotiated means of symmetric algorithms whose keys could have been negotiated
with asymmetric cryptography, but they may work at different layers with asymmetric cryptography, but they may work at different layers
and support different algorithms and protocols. To ensure and support different algorithms and protocols. To ensure
protection, these protocols apply integrity, optionally protection, these protocols apply integrity, optionally
confidentiality, anti-reply protections, and authenticate peers. confidentiality, anti-reply protections, and authentication.
The CapIM is intended to clarify these ambiguities by providing a The CapIM is intended to clarify these ambiguities by providing a
formal description of NSF functionality. The set of functions that formal description of NSF functionality. The set of functions that
are advertised MAY be restricted according to the privileges of the are advertised MAY be restricted according to the privileges of the
user or application that is viewing those functions. I2NSF user or application that is viewing those functions. I2NSF
Capabilities enable unambiguous specification of the security Capabilities enable unambiguous specification of the security
capabilities available in a (virtualized) networking environment, and capabilities available in a (virtualized) networking environment, and
their automatic processing by means of computer-based techniques. their automatic processing by means of computer-based techniques.
This includes enabling the security controller to properly identify This CapIM includes enabling a security controller in an I2NSF
and manage NSFs, and allow NSFs to properly declare their framework [RFC8329] to properly identify and manage NSFs, and allow
functionality, so that they can be used in the correct way. NSFs to properly declare their functionality through a Developer's
Management System (DMS) [RFC8329] , so that they can be used in the
correct way.
3.1. Design Principles and ECA Policy Model Overview 3.1. Design Principles and ECA Policy Model Overview
This document defines an information model for representing NSF This document defines an information model for representing NSF
capabilities. Some basic design principles for security capabilities capabilities. Some basic design principles for security capabilities
and the systems that manage them are: and the systems that manage them are:
o Independence: each security capability SHOULD be an independent o Independence: Each security capability SHOULD be an independent
function, with minimum overlap or dependency on other function, with minimum overlap or dependency on other
capabilities. This enables each security capability to be capabilities. This enables each security capability to be
utilized and assembled together freely. More importantly, changes utilized and assembled together freely. More importantly, changes
to one capability SHOULD NOT affect other capabilities. This to one capability SHOULD NOT affect other capabilities. This
follows the Single Responsibility Principle [Martin] [OODSRP]. follows the Single Responsibility Principle [Martin] [OODSRP].
o Abstraction: each capability MUST be defined in a vendor- o Abstraction: Each capability MUST be defined in a vendor-
independent manner. independent manner.
o Advertisement: A dedicated, well-known interface MUST be used to o Advertisement: A dedicated, well-known interface MUST be used to
advertise and register the capabilities of each NSF. This same advertise and register the capabilities of each NSF. This same
interface MUST be used by other I2NSF Components to determine what interface MUST be used by other I2NSF Components to determine what
Capabilities are currently available to them. Capabilities are currently available to them.
o Execution: a dedicated, well-known interface MUST be used to o Execution: Dedicated, well-known interfaces MUST be used to
configure and monitor the use of a capability. This provides a configure and monitor the use of a capability, resepectively.
standardized ability to describe its functionality, and report its
processing results. This facilitates multi-vendor
interoperability.
o Automation: the system MUST have the ability to auto-discover, These provide a standardized ability to describe its
functionality, and report its processing results, resepectively.
These facilitate multi-vendor interoperability.
o Automation: The system MUST have the ability to auto-discover,
auto-negotiate, and auto-update its security capabilities (i.e., auto-negotiate, and auto-update its security capabilities (i.e.,
without human intervention). These features are especially useful without human intervention). These features are especially useful
for the management of a large number of NSFs. They are essential for the management of a large number of NSFs. They are essential
for adding smart services (e.g., refinement, analysis, capability for adding smart services (e.g., refinement, analysis, capability
reasoning, and optimization) to the security scheme employed. reasoning, and optimization) to the security scheme employed.
These features are supported by many design patterns, including These features are supported by many design patterns, including
the Observer Pattern [OODOP], the Mediator Pattern [OODMP], and a the Observer Pattern [OODOP], the Mediator Pattern [OODMP], and a
set of Message Exchange Patterns [Hohpe]. set of Message Exchange Patterns [Hohpe].
o Scalability: the management system SHOULD have the capability to o Scalability: The management system SHOULD have the capability to
scale up/down or scale in/out. Thus, it can meet various scale up/down or scale in/out. Thus, it can meet various
performance requirements derived from changeable network traffic performance requirements derived from changeable network traffic
or service requests. In addition, security capabilities that are or service requests. In addition, security capabilities that are
affected by scalability changes SHOULD support reporting affected by scalability changes SHOULD support reporting
statistics to the security controller to assist its decision on statistics to the security controller to assist its decision on
whether it needs to invoke scaling or not. whether it needs to invoke scaling or not.
Based on the above principles, this document defines a capability Based on the above principles, this document defines a capability
model that enables an NSF to register (and hence advertise) its set model that enables an NSF to register (and hence advertise) its set
of capabilities that other I2NSF Components can use. These of capabilities that other I2NSF Components can use. These
capabilities MAY have their access control restricted by policy; this capabilities MAY have their access control restricted by a policy;
is out of scope for this document. The set of capabilities provided this is out of scope for this document. The set of capabilities
by a given set of NSFs unambiguously define the security offered by provided by a given set of NSFs unambiguously defines the security
the set of NSFs used. The security controller can compare the services offered by the set of NSFs used. The security controller
requirements of users and applications to the set of capabilities can compare the requirements of users and applications with the set
that are currently available in order to choose which capabilities of of capabilities that are currently available in order to choose which
which NSFs are needed to meet those requirements. Note that this capabilities of which NSFs are needed to meet those requirements.
choice is independent of vendor, and instead relies specifically on Note that this choice is independent of vendor, and instead relies
the capabilities (i.e., the description) of the functions provided. specifically on the capabilities (i.e., the description) of the
functions provided.
Furthermore, when an unknown threat (e.g., zero-day exploits and Furthermore, when an unknown threat (e.g., zero-day exploits and
unknown malware) is reported by an NSF, new capabilities may be unknown malware) is reported by an NSF, new capabilities may be
created, and/or existing capabilities may be updated (e.g., by created, and/or existing capabilities may be updated (e.g., by
updating its signature and algorithm). This results in enhancing the updating its signature and algorithm). This results in enhancing the
existing NSFs (and/or creating new NSFs) to address the new threats. existing NSFs (and/or creating new NSFs) to address the new threats.
New capabilities may be sent to and stored in a centralized New capabilities may be sent to and stored in a centralized
repository, or stored separately in a vendor's local repository. In repository, or stored separately in a vendor's local repository. In
either case, a standard interface facilitates the update process. either case, a standard interface facilitates this update process.
This document specifies a metadata model that MAY be used to further
describe and/or prescribe the characteristics and behavior of the
I2NSF capability model. For example, in this case, metadata could be
used to describe the updating of the capability, and prescribe the
particular version that an implementation should use. This initial
version of the model covers and has been validated to describe NSFs
that are designed with a set of capabilities (which covers most of
the existing NSFs). Checking the behavior of the model with systems
that change capabilities dynamically at runtime has been extensively
explored (e.g., impact on automatic registration).
The "Event-Condition-Action" (ECA) policy model in [RFC8329] is used The "Event-Condition-Action" (ECA) policy model in [RFC8329] is used
as the basis for the design of the capability model; definitions of as the basis for the design of the capability model; definitions of
all I2NSF policy-related terms are also defined in all I2NSF policy-related terms are also defined in [RFC8329]. The
[I-D.ietf-i2nsf-terminology]. The following three terms define the following three terms define the structure and behavior of an I2NSF
structure and behavior of an I2NSF imperative policy rule: imperative policy rule:
o Event: An Event is defined as any important occurrence in time of o Event: An Event is defined as any important occurrence in time of
a change in the system being managed, and/or in the environment of a change in the system being managed, and/or in the environment of
the system being managed. When used in the context of I2NSF the system being managed. When used in the context of I2NSF
Policy Rules, it is used to determine whether the Condition clause Policy Rules, it is used to determine whether the condition clause
of the I2NSF Policy Rule can be evaluated or not. Examples of an of an I2NSF Policy Rule can be evaluated or not. Examples of an
I2NSF Event include time and user actions (e.g., logon, logoff, I2NSF Event include time and user actions (e.g., logon, logoff,
and actions that violate an ACL). and actions that violate an ACL).
o Condition: A condition is defined as a set of attributes, o Condition: A condition is defined as a set of attributes,
features, and/or values that are to be compared with a set of features, and/or values that are to be compared with a set of
known attributes, features, and/or values in order to determine known attributes, features, and/or values in order to determine
whether or not the set of Actions in that (imperative) I2NSF whether or not the set of actions in that (imperative) I2NSF
Policy Rule can be executed or not. Examples of I2NSF Conditions Policy Rule can be executed or not. Examples of I2NSF conditions
include matching attributes of a packet or flow, and comparing the include matching attributes of a packet or flow, and comparing the
internal state of an NSF to a desired state. internal state of an NSF with a desired state.
o Action: An action is used to control and monitor aspects of flow- o Action: An action is used to control and monitor aspects of flow-
based NSFs when the event and condition clauses are satisfied. based NSFs when the event and condition clauses are satisfied.
NSFs provide security functions by executing various Actions. NSFs provide security functions by executing various Actions.
Examples of I2NSF Actions include providing intrusion detection Examples of I2NSF actions include providing intrusion detection
and/or protection, web and flow filtering, and deep packet and/or protection, web and flow filtering, and deep packet
inspection for packets and flows. inspection for packets and flows.
An I2NSF Policy Rule is made up of three Boolean clauses: an Event An I2NSF Policy Rule is made up of three Boolean clauses: an Event
clause, a Condition clause, and an Action clause. This structure is clause, a Condition clause, and an Action clause. This structure is
also called an ECA (Event-Condition-Action) Policy Rule. A Boolean also called an ECA (Event-Condition-Action) Policy Rule. A Boolean
clause is a logical statement that evaluates to either TRUE or FALSE. clause is a logical statement that evaluates to either TRUE or FALSE.
It may be made up of one or more terms; if more than one term is It may be made up of one or more terms; if more than one term is
present, then each term in the Boolean clause is combined using present, then each term in the Boolean clause is combined using
logical connectives (i.e., AND, OR, and NOT). logical connectives (i.e., AND, OR, and NOT).
skipping to change at page 8, line 6 skipping to change at page 7, line 51
IF <condition-clause> is TRUE IF <condition-clause> is TRUE
THEN execute <action-clause> [constrained by metadata] THEN execute <action-clause> [constrained by metadata]
END-IF END-IF
END-IF END-IF
Technically, the "Policy Rule" is really a container that aggregates Technically, the "Policy Rule" is really a container that aggregates
the above three clauses, as well as metadata. Aggregating metadata the above three clauses, as well as metadata, which describe the
enables business logic to be used to prescribe behavior. For characteristics and behaviors of a capability (or an NSF).
example, suppose a particular ECA Policy Rule contains three actions Aggregating metadata enables a business logic to be used to prescribe
(A1, A2, and A3, in that order). Action A2 has a priority of 10; a behavior. For example, suppose a particular ECA Policy Rule
actions A1 and A3 have no priority specified. Then, metadata may be contains three actions (A1, A2, and A3, in that order). Action A2
used to restrict the set of actions that can be executed when the has a priority of 10; actions A1 and A3 have no priority specified.
event and condition clauses of this ECA Policy Rule are evaluated to Then, metadata may be used to restrict the set of actions that can be
be TRUE; two examples are: (1) only the first action (A1) is executed when the event and condition clauses of this ECA Policy Rule
executed, and then the policy rule returns to its caller, or (2) all are evaluated to be TRUE; two examples are: (1) only the first action
actions are executed, starting with the highest priority. (A1) is executed, and then the policy rule returns to its caller, or
(2) all actions are executed, starting with the highest priority.
The above ECA policy model is very general and easily extensible. The above ECA policy model is very general and easily extensible.
3.2. Matched Policy Rule 3.2. Matched Policy Rule
The concept of a "matched" policy rule is defined as one in which its The concept of a "matched" policy rule is defined as one in which its
event and condition clauses both evaluate to true. To precisely event and condition clauses both evaluate to true. To precisely
describe what an NSF can do in terms of security, the things need to describe what an NSF can do in terms of security, that a policy rule
describe are the events it can catch, the conditions it can evaluate, needs to describe the events that it can catch, the conditions it can
and the actions it can enforce. evaluate, and the actions that it can enforce.
Therefore, the properties that to characterize the capabilities of a Therefore, the properties to characterize the capabilities of an NSF
NSF are as below: are as follows:
o Ac is the set of Actions currently available from the NSF; o Ac is the set of Actions currently available from the NSF;
o Ec is the set of Events that an NSF can catch. Note that for NSF o Ec is the set of Events that an NSF can catch. Note that for NSF
(e.g., a packet filter) that are not able to react to events, this (e.g., a packet filter) that are not able to react to events, this
set will be empty; set will be empty;
o Cc is the set of Conditions currently available from the NSF; o Cc is the set of Conditions currently available from the NSF;
o EVc defines the set of Condition Clause Evaluation Rules that can o EVc defines the set of Condition Clause Evaluation Rules that can
be used at the NSF to decide when the Condition Clause is true be used by the NSF to decide when the Condition Clause is true
given the result of the evaluation of the individual Conditions. when the results of the individual Conditions under evaluation are
given.
3.3. Conflict, Resolution Strategy and Default Action 3.3. Conflict, Resolution Strategy and Default Action
Formally, two I2NSF Policy Rules conflict with each other if: Formally, two I2NSF Policy Rules conflict with each other if:
o the Event Clauses of each evaluate to TRUE; o the Event Clauses of each evaluate to TRUE;
o the Condition Clauses of each evaluate to TRUE; o the Condition Clauses of each evaluate to TRUE;
o the Action Clauses affect the same object in different ways. o the Action Clauses affect the same object in different ways.
skipping to change at page 9, line 24 skipping to change at page 9, line 24
R4: During 10am-4pm, FTP from all users gets BronzeService R4: During 10am-4pm, FTP from all users gets BronzeService
R3 and R4 are now in conflict, between the hours of 10am and 4pm, R3 and R4 are now in conflict, between the hours of 10am and 4pm,
because the actions of R3 and R4 are different and apply to the same because the actions of R3 and R4 are different and apply to the same
user (i.e., John). user (i.e., John).
Conflicts theoretically compromise the correct functioning of devices Conflicts theoretically compromise the correct functioning of devices
(as happened for routers several year ago). However, NSFs have been (as happened for routers several year ago). However, NSFs have been
designed to cope with these issues. Since conflicts are originated designed to cope with these issues. Since conflicts are originated
by simultaneously matching rules, an additional process decides the by simultaneously matching rules, an additional process decides the
action to be applied, e.g., among the ones the matching rule would action to be applied, e.g., among the ones which the matching rule
have enforced. This process is described by means of a resolution would have enforced. This process is described by means of a
strategy resolution strategy for conflicts.
On the other hand, it may happen that, if an event is caught, none of On the other hand, it may happen that, if an event is caught, none of
the policy rules matches. As a simple case, no rules may match a the policy rules matches the event. As a simple case, no rules may
packet arriving at border firewall. In this case, the packet is match a packet arriving at border firewall. In this case, the packet
usually dropped, that is, the firewall has a default behavior to is usually dropped, that is, the firewall has a default behavior to
manage cases that are not covered by specific rules. manage the cases that are not covered by specific rules.
Therefore, we introduce another security capability that serves to Therefore, this document introduces another security capability that
characterize valid policies for an NSF that solve conflicts with serves to characterize valid policies for an NSF that solve conflicts
resolution strategies and enforce default actions if no rules match: with resolution strategies and enforce default actions if no rules
match:
o RSc is the set of Resolution Strategy that can be used to specify o RSc is the set of Resolution Strategies that can be used to
how to resolve conflicts that occur between the actions of the specify how to resolve conflicts that occur between the actions of
same or different policy rules that are matched and contained in the same or different policy rules that are matched and contained
this particular NSF; in this particular NSF;
o Dc defines the notion of a Default action. This action can be o Dc defines the notion of a Default action. This action can be
either an explicit action that has been chosen {a}, or a set of either an explicit action or a set of actions.
actions {F}, where F is a dummy symbol (i.e., a placeholder value)
that can be used to indicate that the default action can be freely
selected by the policy editor. This is denoted as {F} U {a}.
4. Overview of YANG Data Model 4. Overview of YANG Data Model
This section provides as overview of how the YANG data model can be This section provides an overview of how the YANG data model can be
used in the I2NSF framework described in [RFC8329]. Figure 1 shows used in the I2NSF framework described in [RFC8329]. Figure 1 shows
the capabilities (e.g., firewall and web filter) of NSFs in the I2NSF the capabilities (e.g., firewall and web filter) of NSFs in the I2NSF
Framework. As shown in this figure, an NSF Developer's Management Framework. As shown in this figure, an NSF Developer's Management
System can register NSFs and the capabilities that the network System (DMS) can register NSFs and the capabilities that the NSFs can
security devices can support. To register NSFs in this way, the support. To register NSFs in this way, the DMS utilizes this
Developer's Management System utilizes this standardized capability standardized capability YANG data model through the I2NSF
YANG data model through the I2NSF Registration Interface [RFC8329]. Registration Interface [RFC8329]. That is, this Registration
That is, this Registration Interface uses the YANG module described Interface uses the YANG module described in this document to describe
in this document to describe the capabilities of a network security the capabilities of an NSF that is registered with the Security
function that is registered with the Security Controller. With the Controller. With the database of the capabilities of the NSFs that
capabilities of those network security devices maintained centrally, are maintained centrally, the NSFs can be more easily managed, which
those security devices can be more easily managed, which can resolve can resolve many of the problems described in [RFC8192].
many of the problems described in [RFC8192].
In Figure 1, a new NSF at a Developer's Management Systems has In Figure 1, a new NSF at a Developer's Management System has
capabilities of Firewall (FW) and Web Filter (WF), which are denoted capabilities of Firewall (FW) and Web Filter (WF), which are denoted
as (Cap = {FW, WF}), to support Event-Condition-Action (ECA) policy as (Cap = {FW, WF}), to support Event-Condition-Action (ECA) policy
rules where 'E', 'C', and 'A' mean "Event", "Condition", and rules where 'E', 'C', and 'A' mean "Event", "Condition", and
"Action", respectively. The condition involves IPv4 or IPv6 "Action", respectively. The condition involves IPv4 or IPv6
datagrams, and the action includes "Allow" and "Deny" for those datagrams, and the action includes "Allow" and "Deny" for those
datagrams. datagrams.
Note that the NSF-Facing Interface [RFC8329] is used to configure the Note that the NSF-Facing Interface [RFC8329] is used for the Security
security policy rules of the generic network security functions, and Controller to configure the security policy rules of generic NSFs
the configuration of advanced security functions over the NSF-Facing (e.g., firewall) and advanced NSFs (e.g., anti-virus and Distributed-
Interface is used to configure the security policy rules of advanced Denial-of-Service (DDoS) attack mitigator) with the capabilities of
network security functions (e.g., anti-virus and Distributed-Denial- the NSFs registered with the Security Controller.
of-Service (DDoS) attack mitigator), respectively, according to the
capabilities of NSFs registered with the I2NSF Framework.
+------------------------------------------------------+ +------------------------------------------------------+
| I2NSF User (e.g., Overlay Network Mgmt, Enterprise | | I2NSF User (e.g., Overlay Network Mgmt, Enterprise |
| Network Mgmt, another network domain's mgmt, etc.) | | Network Mgmt, another network domain's mgmt, etc.) |
+--------------------+---------------------------------+ +--------------------+---------------------------------+
I2NSF ^ I2NSF ^
Consumer-Facing Interface | Consumer-Facing Interface |
| |
v I2NSF v I2NSF
+-----------------+------------+ Registration +-------------+ +-----------------+------------+ Registration +-------------+
skipping to change at page 11, line 41 skipping to change at page 11, line 41
C = {IPv4} C = {IPv6} C = {IPv4, IPv6} C = {IPv4} C = {IPv4} C = {IPv6} C = {IPv4, IPv6} C = {IPv4}
A = {Allow, Deny} A = {Allow, Deny} A = {Allow, Deny} A = {Allow, Deny} A = {Allow, Deny} A = {Allow, Deny} A = {Allow, Deny} A = {Allow, Deny}
Developer's Mgmt System A Developer's Mgmt System B Developer's Mgmt System A Developer's Mgmt System B
Figure 1: Capabilities of NSFs in I2NSF Framework Figure 1: Capabilities of NSFs in I2NSF Framework
A use case of an NSF with the capabilities of firewall and web filter A use case of an NSF with the capabilities of firewall and web filter
is described as follows. is described as follows.
o If a network manager wants to apply security policy rules to block o If a network administrator wants to apply security policy rules to
malicious users with firewall and web filter, it is a tremendous block malicious users with firewall and web filter, it is a
burden for a network administrator to apply all of the needed tremendous burden for a network administrator to apply all of the
rules to NSFs one by one. This problem can be resolved by needed rules to NSFs one by one. This problem can be resolved by
managing the capabilities of NSFs in this document. managing the capabilities of NSFs as described in this document.
o If a network administrator wants to block malicious users for IPv4 o If a network administrator wants to block IPv4 or IPv6 packets
or IPv6 traffic, he sends a security policy rule to block the from malicious users, the network administrator sends a security
users to the Network Operator Management System using the I2NSF policy rule to block the users to the Network Operator Management
Consumer-Facing Interface. System (i.e., Security Controller) using the I2NSF Consumer-Facing
Interface.
o When the Network Operator Management System receives the security o When the Network Operator Management System receives the security
policy rule, it automatically sends that security policy rules to policy rule, it automatically sends that security policy rule to
appropriate NSFs (i.e., NSF-m in Developer's Management System A appropriate NSFs (i.e., NSF-m in Developer's Management System A
and NSF-1 in Developer's Management System B) which can support and NSF-1 in Developer's Management System B) which can support
the capabilities (i.e., IPv6). This lets an I2NSF User not the capabilities (i.e., IPv6). This lets an I2NSF User not
consider NSFs where the rule is applied. consider which specific NSF(s) will work for the security policy
rule.
o If NSFs encounter the suspicious IPv4 or IPv6 packets of malicious o If NSFs encounter the suspicious IPv4 or IPv6 packets of malicious
users, they can filter the packets out according to the configured users, they can filter the packets out according to the configured
security policy rule. Therefore, the security policy rule against security policy rule. Therefore, the security policy rule against
the malicious users' packets can be automatically applied to the malicious users' packets can be automatically applied to
appropriate NSFs without human intervention. appropriate NSFs without human intervention.
5. YANG Tree Diagram 5. YANG Tree Diagram
This section shows a YANG tree diagram of capabilities of network This section shows a YANG tree diagram of capabilities of network
skipping to change at page 12, line 32 skipping to change at page 12, line 33
5.1. Network Security Function (NSF) Capabilities 5.1. Network Security Function (NSF) Capabilities
This section explains a YANG tree diagram of NSF capabilities and its This section explains a YANG tree diagram of NSF capabilities and its
features. Figure 2 shows a YANG tree diagram of NSF capabilities. features. Figure 2 shows a YANG tree diagram of NSF capabilities.
The NSF capabilities in the tree include time capabilities, event The NSF capabilities in the tree include time capabilities, event
capabilities, condition capabilities, action capabilities, resolution capabilities, condition capabilities, action capabilities, resolution
strategy capabilities, and default action capabilities. Those strategy capabilities, and default action capabilities. Those
capabilities can be tailored or extended according to a vendor's capabilities can be tailored or extended according to a vendor's
specific requirements. Refer to the NSF capabilities information specific requirements. Refer to the NSF capabilities information
model for detailed discussion Section 3. model for detailed discussion in Section 3.
module: ietf-i2nsf-capability module: ietf-i2nsf-capability
+--rw nsf* [nsf-name] +--rw nsf* [nsf-name]
+--rw nsf-name string +--rw nsf-name string
+--rw time-capabilities* enumeration +--rw time-capabilities* enumeration
+--rw event-capabilities +--rw event-capabilities
| +--rw system-event-capability* identityref | +--rw system-event-capability* identityref
| +--rw system-alarm-capability* identityref | +--rw system-alarm-capability* identityref
+--rw condition-capabilities +--rw condition-capabilities
| +--rw generic-nsf-capabilities | +--rw generic-nsf-capabilities
| | +--rw ipv4-capability* identityref | | +--rw ipv4-capability* identityref
| | +--rw icmp-capability* identityref | | +--rw icmp-capability* identityref
| | +--rw ipv6-capability* identityref | | +--rw ipv6-capability* identityref
| | +--rw icmpv6-capability* identityref | | +--rw icmpv6-capability* identityref
| | +--rw tcp-capability* identityref | | +--rw tcp-capability* identityref
| | +--rw udp-capability* identityref | | +--rw udp-capability* identityref
| | +--rw sctp-capability* identityref | | +--rw sctp-capability* identityref
| | +--rw dccp-capability* identityref
| +--rw advanced-nsf-capabilities | +--rw advanced-nsf-capabilities
| | +--rw anti-virus-capability* identityref | | +--rw anti-virus-capability* identityref
| | +--rw anti-ddos-capability* identityref | | +--rw anti-ddos-capability* identityref
| | +--rw ips-capability* identityref | | +--rw ips-capability* identityref
| | +--rw url-capability* identityref | | +--rw url-capability* identityref
| | +--rw voip-volte-capability* identityref | | +--rw voip-volte-capability* identityref
| +--rw context-capabilities* identityref | +--rw context-capabilities* identityref
+--rw action-capabilities +--rw action-capabilities
| +--rw ingress-action-capability* identityref | +--rw ingress-action-capability* identityref
| +--rw egress-action-capability* identityref | +--rw egress-action-capability* identityref
skipping to change at page 13, line 43 skipping to change at page 13, line 44
+--rw default-action-capabilities* identityref +--rw default-action-capabilities* identityref
+--rw ipsec-method* identityref +--rw ipsec-method* identityref
Figure 2: YANG Tree Diagram of Capabilities of Network Security Figure 2: YANG Tree Diagram of Capabilities of Network Security
Functions Functions
Time capabilities are used to specify the capabilities which describe Time capabilities are used to specify the capabilities which describe
when to execute the I2NSF policy rule. The time capabilities are when to execute the I2NSF policy rule. The time capabilities are
defined in terms of absolute time and periodic time. The absolute defined in terms of absolute time and periodic time. The absolute
time means the exact time to start or end. The periodic time means time means the exact time to start or end. The periodic time means
repeated time like day, week, or month.. repeated time like day, week, or month.
Event capabilities are used to specify the capabilities that describe Event capabilities are used to specify the capabilities that describe
the event that would trigger the evaluation of the condition clause an event that would trigger the evaluation of the condition clause of
of the I2NSF Policy Rule. The defined event capabilities are system the I2NSF Policy Rule. The defined event capabilities are system
event and system alarm. event and system alarm.
Condition capabilities are used to specify capabilities of a set of Condition capabilities are used to specify capabilities of a set of
attributes, features, and/or values that are to be compared with a attributes, features, and/or values that are to be compared with a
set of known attributes, features, and/or values in order to set of known attributes, features, and/or values in order to
determine whether or not the set of actions in that (imperative) determine whether a set of actions needs to be executed or not so
I2NSF policy rule can be executed. The condition capabilities are that an imperative I2NSF policy rule can be executed. In this
classified in terms of generic network security functions and document, two kinds of condition capabilities are used to classify
advanced network security functions. The condition capabilities of different capabilities of NSFs such as generic-nsf-capabilities for
generic network security functions are defined as IPv4 capability, generic NSFs and advanced-nsf-capabilities for advanced NSFs. First,
IPv6 capability, TCP capability, UDP capability, SCTP capability and the generic-nsf-capabilities define the common capabilities of NSFs
ICMP capability. The condition capabilities of advanced network such as IPv4 capability, IPv6 capability, TCP capability, UDP
security functions are defined as anti-virus capability, anti-DDoS capability, SCTP capability, DCCP capability, ICMP capability, and
capability, Intrusion Prevention System (IPS) capability, HTTP ICMPv6 capability. Second, the advanced-nsf-capabilities define
capability, and VoIP/VoLTE capability. See Section 3.1 for more advanced capabilities of NSFs such as anti-virus capability, anti-
information about the condition in the ECA policy model. DDoS capability, Intrusion Prevention System (IPS) capability, HTTP
capability, and VoIP/VoLTE capability. Note that VoIP and VoLTE are
merged into a single capability in this document because VoIP and
VoLTE use the Session Initiation Protocol (SIP) [RFC3261] for a call
setup. See Section 3.1 for more information about the condition in
the ECA policy model.
Action capabilities are used to specify the capabilities that Action capabilities are used to specify the capabilities that
describe the control and monitoring aspects of flow-based NSFs when describe the control and monitoring aspects of flow-based NSFs when
the event and condition clauses are satisfied. The action the event and condition clauses are satisfied. The action
capabilities are defined as ingress-action capability, egress-action capabilities are defined as ingress-action capability, egress-action
capability, and log-action capability. See Section 3.1 for more capability, and log-action capability. See Section 3.1 for more
information about the action in the ECA policy model. Also, see information about the action in the ECA policy model. Also, see
Section 7.2 (NSF-Facing Flow Security Policy Structure) in [RFC8329] Section 7.2 (NSF-Facing Flow Security Policy Structure) in [RFC8329]
for more information about the ingress and egress actions. In for more information about the ingress and egress actions. In
addition, see Section 9.1 (Flow-Based NSF Capability addition, see Section 9.1 (Flow-Based NSF Capability
Characterization) in [RFC8329] for more information about logging at Characterization) in [RFC8329] and Section 7.5 (NSF Logs) in
NSFs. [I-D.ietf-i2nsf-nsf-monitoring-data-model] for more information about
logging at NSFs.
Resolution strategy capabilities are used to specify the capabilities Resolution strategy capabilities are used to specify the capabilities
that describe conflicts that occur between the actions of the same or that describe conflicts that occur between the actions of the same or
different policy rules that are matched and contained in this different policy rules that are matched and contained in this
particular NSF. The resolution strategy capabilities are defined as particular NSF. The resolution strategy capabilities are defined as
First Matching Rule (FMR), Last Matching Rule (LMR), Prioritized First Matching Rule (FMR), Last Matching Rule (LMR), Prioritized
Matching Rule (PMR), Prioritized Matching Rule with Errors (PMRE), Matching Rule (PMR), Prioritized Matching Rule with Errors (PMRE),
and Prioritized Matching Rule with No Errors (PMRN). See Section 3.3 and Prioritized Matching Rule with No Errors (PMRN). See Section 3.3
for more information about the resolution strategy. for more information about the resolution strategy.
skipping to change at page 15, line 10 skipping to change at page 15, line 16
support an Internet Key Exchange (IKE) [RFC7296] for the security support an Internet Key Exchange (IKE) [RFC7296] for the security
communication. The default action capabilities are defined as IKE or communication. The default action capabilities are defined as IKE or
IKE-less. See [I-D.ietf-i2nsf-sdn-ipsec-flow-protection] for more IKE-less. See [I-D.ietf-i2nsf-sdn-ipsec-flow-protection] for more
information about the SDN-based IPsec flow protection in I2NSF. information about the SDN-based IPsec flow protection in I2NSF.
6. YANG Data Model of I2NSF NSF Capability 6. YANG Data Model of I2NSF NSF Capability
This section introduces a YANG module for NSFs' capabilities, as This section introduces a YANG module for NSFs' capabilities, as
defined in the Section 3. defined in the Section 3.
This YANG module imports from [RFC6991]. It makes references to [RFC This YANG module imports from [RFC6991]. It makes references to
0768][IANA-Protocol-Numbers][RFC0791][RFC0792][RFC0793][RFC3261][RFC4
443][RFC4960][RFC8200][RFC8329][I-D.ietf-i2nsf-nsf-monitoring-data-mo
del][I-D.ietf-i2nsf-sdn-ipsec-flow-protection].
<CODE BEGINS> file "ietf-i2nsf-capability@2020-11-02.yang" o [RFC0768]
module ietf-i2nsf-capability { o [RFC0791]
yang-version 1.1;
namespace
"urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability";
prefix
nsfcap;
organization o [RFC0792]
"IETF I2NSF (Interface to Network Security Functions)
Working Group";
contact o [RFC0793]
"WG Web: <http://tools.ietf.org/wg/i2nsf>
WG List: <mailto:i2nsf@ietf.org>
Editor: Jaehoon Paul Jeong o [RFC2474]
<mailto:pauljeong@skku.edu>
Editor: Jinyong Tim Kim o [RFC3168]
<mailto:timkim@skku.edu>
Editor: Susan Hares o [RFC3261]
<mailto:shares@ndzh.com>";
description o [RFC4340]
"This module is a YANG module for I2NSF Network Security
Functions (NSFs)'s Capabilities.
Copyright (c) 2020 IETF Trust and the persons identified as o [RFC4443]
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or o [RFC4960]
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see o [RFC5595]
the RFC itself for full legal notices.";
// RFC Ed.: replace XXXX with an actual RFC number and remove o [RFC6335]
// this note.
revision "2020-11-02"{ o [RFC6437]
description "Initial revision.";
reference
"RFC XXXX: I2NSF Capability YANG Data Model";
// RFC Ed.: replace XXXX with an actual RFC number and remove o [RFC6691]
// this note.
}
/* o [RFC6864]
* Identities
*/
identity event { o [RFC7230]
description
"Base identity for I2NSF events.";
reference
"draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF
Monitoring YANG Data Model - Event";
// RFC Ed.: replace the above draft with an actual RFC in the o [RFC7231]
// YANG module and remove this note.
}
identity system-event-capability { o [RFC7296]
base event; o [RFC7323]
description
"Identity for system event";
reference
"draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF
Monitoring YANG Data Model - System event";
}
identity system-alarm-capability { o [RFC8200]
base event;
description
"Identity for system alarm";
reference
"draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF
Monitoring YANG Data Model - System alarm";
}
identity access-violation { o [RFC8329]
base system-event-capability;
description
"Identity for access violation event";
reference
"draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF
Monitoring YANG Data Model - System event for access
violation";
}
identity configuration-change { o [RFC8519]
base system-event-capability;
description
"Identity for configuration change event";
reference
"draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF
Monitoring YANG Data Model - System event for configuration
change";
}
identity memory-alarm { o [RFC8805]
base system-alarm-capability;
description
"Identity for memory alarm. Alarm when memory usage
exceed the threshold.";
reference
"draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF
Monitoring YANG Data Model - System alarm for memory";
}
identity cpu-alarm { o [IANA-Protocol-Numbers]
base system-alarm-capability;
description
"Identity for CPU alarm. Alarm when CPU usage
exceed the threshold.";
reference
"draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF
Monitoring YANG Data Model - System alarm for CPU";
}
identity disk-alarm { o [I-D.ietf-tcpm-rfc793bis]
base system-alarm-capability;
description
"Identity for disk alarm. Alarm when disk usage
exceed the threshold.";
reference o [I-D.ietf-tcpm-accurate-ecn]
"draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF
Monitoring YANG Data Model - System alarm for disk";
}
identity hardware-alarm { o [I-D.ietf-tsvwg-udp-options]
base system-alarm-capability;
description
"Identity for hardware alarm. Alarm when a hardware failure
occur.";
reference
"draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF
Monitoring YANG Data Model - System alarm for hardware";
}
identity interface-alarm { o [I-D.ietf-i2nsf-nsf-monitoring-data-model]
base system-alarm-capability;
description
"Identity for interface alarm";
reference
"draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF
Monitoring YANG Data Model - System alarm for interface";
}
identity condition { o [I-D.ietf-i2nsf-sdn-ipsec-flow-protection]
description
"Base identity for I2NSF conditions";
}
identity context-capability { <CODE BEGINS> file "ietf-i2nsf-capability@2020-12-30.yang"
base condition;
description
"Base identity for context condition capabilities for an NSF.";
}
identity access-control-list { module ietf-i2nsf-capability {
base context-capability; yang-version 1.1;
description namespace
"Identity for Access Control List (ACL) condition capability"; "urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability";
reference prefix
"RFC 8519: YANG Data Model for Network Access Control Lists nsfcap;
(ACLs) - A user-ordered set of rules used to configure the
forwarding behavior in an NSF.";
}
identity application-layer-filter { organization
base context-capability; "IETF I2NSF (Interface to Network Security Functions)
description Working Group";
"Identity for application-layer-filter condition capability";
}
identity target { contact
base context-capability; "WG Web: <http://tools.ietf.org/wg/i2nsf>
description WG List: <mailto:i2nsf@ietf.org>
"Identity for target condition capability";
reference
"RFC 8519: YANG Data Model for Network Access Control Lists
(ACLs) - An access control for a target (e.g., the
corresponding IP address) in an NSF.";
}
identity user { Editor: Jaehoon Paul Jeong
base context-capability; <mailto:pauljeong@skku.edu>
description
"Identity for user condition capability";
reference
"RFC 8519: YANG Data Model for Network Access Control Lists
(ACLs) - An access control for a user (e.g., the
corresponding IP address) in an NSF.";
}
identity group { Editor: Jinyong Tim Kim
base context-capability; <mailto:timkim@skku.edu>
description
"Identity for group condition capability";
reference
"RFC 8519: YANG Data Model for Network Access Control Lists
(ACLs) - An access control for a group (e.g., the
corresponding IP addresses) in an NSF.";
}
identity geography { Editor: Susan Hares
base context-capability; <mailto:shares@ndzh.com>";
description
"Identity for geography condition capability";
reference
"draft-google-self-published-geofeeds-02: Self-published
IP Geolocation Data - An access control for a geographical
location i.e., geolocation (e.g., the corresponding IP
address).";
}
identity ipv4-capability { description
base condition; "This module is a YANG module for I2NSF Network Security
description Functions (NSFs)'s Capabilities.
"Base identity for IPv4 condition capability";
reference Copyright (c) 2020 IETF Trust and the persons identified as
"RFC 791: Internet Protocol"; authors of the code. All rights reserved.
}
identity exact-ipv4-header-length { Redistribution and use in source and binary forms, with or
base ipv4-capability; without modification, is permitted pursuant to, and subject
description to the license terms contained in, the Simplified BSD License
"Identity for exact-match IPv4 header-length set forth in Section 4.c of the IETF Trust's Legal Provisions
condition capability"; Relating to IETF Documents
reference http://trustee.ietf.org/license-info).
"RFC 791: Internet Protocol - Header Length";
}
identity range-ipv4-header-length { This version of this YANG module is part of RFC XXXX; see
base ipv4-capability; the RFC itself for full legal notices.";
description
"Identity for range-match IPv4 header-length
condition capability";
reference
"RFC 791: Internet Protocol - Header Length";
}
identity ipv4-tos { // RFC Ed.: replace XXXX with an actual RFC number and remove
base ipv4-capability; // this note.
description
"Identity for IPv4 Type-Of-Service (TOS)
condition capability";
reference
"RFC 791: Internet Protocol - Type of Service";
}
identity exact-ipv4-total-length { revision "2020-12-30"{
base ipv4-capability; description "Initial revision.";
description reference
"Identity for exact-match IPv4 total length "RFC XXXX: I2NSF Capability YANG Data Model";
condition capability";
reference
"RFC 791: Internet Protocol - Total Length";
}
identity range-ipv4-total-length { // RFC Ed.: replace XXXX with an actual RFC number and remove
base ipv4-capability; // this note.
description }
"Identity for range-match IPv4 total length
condition capability";
reference
"RFC 791: Internet Protocol - Total Length";
}
identity ipv4-id {
base ipv4-capability;
description
"Identity for IPv4 identification condition capability.
IPv4 ID Field is used for fragmentation";
reference
"RFC 791: Internet Protocol - Identification
RFC 6864: Updated Specification of the IPv4 ID Field";
}
identity ipv4-fragment-flags { /*
base ipv4-capability; * Identities
description */
"Identity for IPv4 fragment flags condition capability";
reference
"RFC 791: Internet Protocol - Fragmentation Flags";
}
identity exact-ipv4-fragment-offset { identity event {
base ipv4-capability; description
description "Base identity for I2NSF events.";
"Identity for exact-match IPv4 fragment offset reference
condition capability"; "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF
reference Monitoring YANG Data Model - Event";
"RFC 791: Internet Protocol - Fragmentation Offset";
}
identity range-ipv4-fragment-offset { // RFC Ed.: replace the above draft with an actual RFC in the
base ipv4-capability; // YANG module and remove this note.
description }
"Identity for range-match IPv4 fragment offset
condition capability";
reference
"RFC 791: Internet Protocol - Fragmentation Offset";
}
identity exact-ipv4-ttl { identity system-event-capability {
base ipv4-capability; base event;
description description
"Identity for exact-match IPv4 Time-To-Live (TTL) "Identity for system event";
condition capability";
reference
"RFC 791: Internet Protocol - Time To Live (TTL)";
}
identity range-ipv4-ttl { reference
base ipv4-capability; "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF
description Monitoring YANG Data Model - System event";
"Identity for range-match IPv4 Time-To-Live (TTL) }
condition capability";
reference
"RFC 791: Internet Protocol - Time To Live (TTL)";
}
identity ipv4-protocol { identity system-alarm-capability {
base ipv4-capability; base event;
description description
"Identity for IPv4 protocol condition capability"; "Identity for system alarm";
reference reference
"IANA Website: Assigned Internet Protocol Numbers "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF
- Protocol Number for IPv4 Monitoring YANG Data Model - System alarm";
RFC 791: Internet Protocol - Protocol"; }
}
identity exact-ipv4-address { identity access-violation {
base ipv4-capability; base system-event-capability;
description description
"Identity for exact-match IPv4 address "Identity for access violation event";
condition capability"; reference
reference "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF
"RFC 791: Internet Protocol - Address"; Monitoring YANG Data Model - System event for access
} violation";
}
identity range-ipv4-address { identity configuration-change {
base ipv4-capability; base system-event-capability;
description description
"Identity for range-match IPv4 address condition "Identity for configuration change event";
capability"; reference
reference "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF
"RFC 791: Internet Protocol - Address"; Monitoring YANG Data Model - System event for configuration
} change";
}
identity ipv4-ip-opts { identity memory-alarm {
base ipv4-capability; base system-alarm-capability;
description description
"Identity for IPv4 option condition capability"; "Identity for memory alarm. Alarm when memory usage
reference exceeds a threshold.";
"RFC 791: Internet Protocol - Options"; reference
} "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF
Monitoring YANG Data Model - System alarm for memory";
}
identity ipv4-geo-ip { identity cpu-alarm {
base ipv4-capability; base system-alarm-capability;
description description
"Identity for geography condition capability"; "Identity for CPU alarm. Alarm when CPU usage
} exceeds a threshold.";
identity ipv6-capability { reference
base condition; "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF
description Monitoring YANG Data Model - System alarm for CPU";
"Base identity for IPv6 condition capabilities"; }
reference
"RFC 8200: Internet Protocol, Version 6 (IPv6)
Specification";
}
identity ipv6-traffic-class { identity disk-alarm {
base ipv6-capability; base system-alarm-capability;
description description
"Identity for IPv6 traffic class "Identity for disk alarm. Alarm when disk usage
condition capability"; exceeds a threshold.";
reference reference
"RFC 8200: Internet Protocol, Version 6 (IPv6) "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF
Specification - Traffic Class"; Monitoring YANG Data Model - System alarm for disk";
} }
identity exact-ipv6-flow-label { identity hardware-alarm {
base ipv6-capability; base system-alarm-capability;
description description
"Identity for exact-match IPv6 flow label "Identity for hardware alarm. Alarm when a hardware failure
condition capability"; or hardware degradation occurs.";
reference reference
"RFC 8200: Internet Protocol, Version 6 (IPv6) "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF
Specification - Flow Label Monitoring YANG Data Model - System alarm for hardware";
RFC 6437: IPv6 Flow Label Specification"; }
}
identity range-ipv6-flow-label { identity interface-alarm {
base ipv6-capability; base system-alarm-capability;
description description
"Identity for range-match IPv6 flow label "Identity for interface alarm. Alarm when interface usage
condition capability"; exceeds a threshold.";
reference reference
"RFC 8200: Internet Protocol, Version 6 (IPv6) "draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF NSF
Specification - Flow Label Monitoring YANG Data Model - System alarm for interface";
RFC 6437: IPv6 Flow Label Specification"; }
}
identity exact-ipv6-payload-length { identity condition {
base ipv6-capability; description
description "Base identity for I2NSF conditions";
"Identity for exact-match IPv6 payload length }
condition capability";
reference
"RFC 8200: Internet Protocol, Version 6 (IPv6)
Specification - Payload Length";
}
identity range-ipv6-payload-length { identity context-capability {
base ipv6-capability; base condition;
description description
"Identity for range-match IPv6 payload length "Base identity for context condition capabilities for an NSF.
The context contains background information of various
entities such as an access control list, application layer
filter, target, user, group, and geography.";
}
identity access-control-list {
base context-capability;
description
"Identity for Access Control List (ACL) condition capability";
reference
"RFC 8519: YANG Data Model for Network Access Control Lists
(ACLs) - A user-ordered set of rules used to configure the
forwarding behavior in an NSF.";
}
identity application-layer-filter {
base context-capability;
description
"Identity for application-layer-filter condition capability.
application-layer-filter capability can examine the contents
of a packet (e.g., a URL contained in an HTTP message).";
reference
"RFC7230: Hypertext Transfer Protocol (HTTP/1.1): Message
Syntax and Routing
RFC7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics
and Content";
}
identity target {
base context-capability;
description
"Identity for target condition capability";
reference
"RFC 8519: YANG Data Model for Network Access Control Lists
(ACLs) - An access control for a target (e.g., the
corresponding IP address) in an NSF.";
}
identity user {
base context-capability;
description
"Identity for user condition capability.
A user (e.g., employee) can be mapped to an IP address of
a computing device (e.g., computer, laptop, and virtual
machine) which the user is using.";
reference
"RFC 8519: YANG Data Model for Network Access Control Lists
(ACLs) - An access control for a user (e.g., the
corresponding IP address) in an NSF.";
}
identity group {
base context-capability;
description
"Identity for group condition capability.
A group (e.g., employees) can be mapped to multiple IP
addresses of computing devices (e.g., computers, laptops,
and virtual machines) which the group is using.";
reference
"RFC 8519: YANG Data Model for Network Access Control Lists
(ACLs) - An access control for a group (e.g., the
corresponding IP addresses) in an NSF.";
}
identity geography {
base context-capability;
description
"Identity for geography condition capability";
reference
"RFC 8805: A Format for Self-Published IP Geolocation Feeds -
An access control for a geographical location (i.e.,
geolocation) that has the corresponding IP prefix.";
}
identity ipv4-capability {
base condition;
description
"Base identity for IPv4 condition capability";
reference
"RFC 791: Internet Protocol";
}
identity exact-ipv4-header-length {
base ipv4-capability;
description
"Identity for exact-match IPv4 header-length
condition capability";
reference
"RFC 791: Internet Protocol - Header Length";
}
identity range-ipv4-header-length {
base ipv4-capability;
description
"Identity for range-match IPv4 header-length
condition capability";
reference
"RFC 791: Internet Protocol - Header Length";
}
identity ipv4-tos-dscp {
base ipv4-capability;
description
"Identity for IPv4 Type-Of-Service (TOS)
Differentiated Services Codepoint (DSCP)
condition capability"; condition capability";
reference reference
"RFC 8200: Internet Protocol, Version 6 (IPv6) "RFC 791: Internet Protocol - Type of Service
Specification - Payload Length"; RFC 2474: Definition of the Differentiated
} Services Field (DS Field) in the IPv4 and
IPv6 Headers";
}
identity ipv6-next-header { identity exact-ipv4-total-length {
base ipv6-capability; base ipv4-capability;
description description
"Identity for IPv6 next header condition capability"; "Identity for exact-match IPv4 total length
reference condition capability";
"IANA Website: Assigned Internet Protocol Numbers reference
- Protocol Number for IPv6 "RFC 791: Internet Protocol - Total Length";
RFC 8200: Internet Protocol, Version 6 (IPv6) }
Specification - Next Header";
}
identity exact-ipv6-hop-limit { identity range-ipv4-total-length {
base ipv6-capability; base ipv4-capability;
description description
"Identity for exact-match IPv6 hop limit condition "Identity for range-match IPv4 total length
capability"; condition capability";
reference reference
"RFC 8200: Internet Protocol, Version 6 (IPv6) "RFC 791: Internet Protocol - Total Length";
Specification - Hop Limit"; }
}
identity range-ipv6-hop-limit { identity ipv4-id {
base ipv6-capability; base ipv4-capability;
description description
"Identity for range-match IPv6 hop limit condition "Identity for IPv4 identification condition capability.
capability"; IPv4 ID field is used for fragmentation and reassembly.";
reference reference
"RFC 8200: Internet Protocol, Version 6 (IPv6) "RFC 791: Internet Protocol - Identification
Specification - Hop Limit"; RFC 6864: Updated Specification of the IPv4 ID Field -
} Fragmentation and Reassembly";
}
identity exact-ipv6-address { identity ipv4-fragment-flags {
base ipv6-capability; base ipv4-capability;
description description
"Identity for exact-match IPv6 address condition "Identity for IPv4 fragment flags condition capability";
capability"; reference
reference "RFC 791: Internet Protocol - Fragmentation Flags";
"RFC 8200: Internet Protocol, Version 6 (IPv6)
Specification - Address";
}
identity range-ipv6-address { }
base ipv6-capability;
description
"Identity for range-match IPv6 address condition
capability";
reference
"RFC 8200: Internet Protocol, Version 6 (IPv6)
Specification - Address";
}
identity ipv6-header-order { identity exact-ipv4-fragment-offset {
base ipv6-capability; base ipv4-capability;
description description
"Identity for header order IPv6 address condition "Identity for exact-match IPv4 fragment offset
capability"; condition capability";
reference reference
"RFC 8200: Internet Protocol, Version 6 (IPv6) "RFC 791: Internet Protocol - Fragmentation Offset";
Specification - Extension Header Order"; }
}
identity ipv6-options { identity range-ipv4-fragment-offset {
base ipv6-capability; base ipv4-capability;
description description
"Identity for options IPv6 address condition "Identity for range-match IPv4 fragment offset
capability"; condition capability";
reference reference
"RFC 8200: Internet Protocol, Version 6 (IPv6) "RFC 791: Internet Protocol - Fragmentation Offset";
Specification - Options"; }
}
identity ipv6-hop-by-hop { identity exact-ipv4-ttl {
base ipv6-capability; base ipv4-capability;
description description
"Identity for hop by hop IPv6 address condition "Identity for exact-match IPv4 Time-To-Live (TTL)
capability"; condition capability";
reference reference
"RFC 8200: Internet Protocol, Version 6 (IPv6) "RFC 791: Internet Protocol - Time To Live (TTL)";
Specification - Options"; }
}
identity ipv6-routing-header { identity range-ipv4-ttl {
base ipv6-capability; base ipv4-capability;
description description
"Identity for routing header IPv6 address condition "Identity for range-match IPv4 Time-To-Live (TTL)
capability"; condition capability";
reference reference
"RFC 8200: Internet Protocol, Version 6 (IPv6) "RFC 791: Internet Protocol - Time To Live (TTL)";
Specification - Routing Header"; }
}
identity ipv6-fragment-header { identity ipv4-protocol {
base ipv6-capability; base ipv4-capability;
description description
"Identity for fragment header IPv6 address condition "Identity for IPv4 protocol condition capability";
reference
"IANA Website: Assigned Internet Protocol Numbers
- Protocol Number for IPv4
RFC 791: Internet Protocol - Protocol";
}
identity prefix-ipv4-address {
base ipv4-capability;
description
"Identity for prefix-match IPv4 address
condition capability. The addresses are
specified by a pair of prefix and prefix
length.";
reference
"RFC 791: Internet Protocol - Address";
}
identity range-ipv4-address {
base ipv4-capability;
description
"Identity for range-match IPv4 address condition
capability. The range addresses are specified
by a start address and an end address.";
reference
"RFC 791: Internet Protocol - Address";
}
identity ipv4-ip-opts {
base ipv4-capability;
description
"Identity for IPv4 option condition capability";
reference
"RFC 791: Internet Protocol - Options";
}
identity ipv4-geo-ip {
base ipv4-capability;
description
"Identity for IPv4 geography condition capability";
reference
"RFC 8805: Self-published IP Geolocation Data - An
access control for a geographical location i.e.,
geolocation (e.g., the corresponding IP address).";
}
identity ipv6-capability {
base condition;
description
"Base identity for IPv6 condition capabilities";
reference
"RFC 8200: Internet Protocol, Version 6 (IPv6)
Specification";
}
identity ipv6-traffic-class-dscp {
base ipv6-capability;
description
"Identity for IPv6 traffic classes
Differentiated Services Codepoint (DSCP)
condition capability";
reference
"RFC 8200: Internet Protocol, Version 6 (IPv6)
Specification - Traffic Class
RFC 2474: Definition of the Differentiated
Services Field (DS Field) in the IPv4 and
IPv6 Headers.";
}
identity exact-ipv6-flow-label {
base ipv6-capability;
description
"Identity for exact-match IPv6 flow label
condition capability";
reference
"RFC 8200: Internet Protocol, Version 6 (IPv6)
Specification - Flow Label
RFC 6437: IPv6 Flow Label Specification";
}
identity range-ipv6-flow-label {
base ipv6-capability;
description
"Identity for range-match IPv6 flow label
condition capability";
reference
"RFC 8200: Internet Protocol, Version 6 (IPv6)
Specification - Flow Label
RFC 6437: IPv6 Flow Label Specification";
}
identity exact-ipv6-payload-length {
base ipv6-capability;
description
"Identity for exact-match IPv6 payload length
condition capability";
reference
"RFC 8200: Internet Protocol, Version 6 (IPv6)
Specification - Payload Length";
}
identity range-ipv6-payload-length {
base ipv6-capability;
description
"Identity for range-match IPv6 payload length
condition capability";
reference
"RFC 8200: Internet Protocol, Version 6 (IPv6)
Specification - Payload Length";
}
identity ipv6-next-header {
base ipv6-capability;
description
"Identity for IPv6 next header condition capability";
reference
"IANA Website: Assigned Internet Protocol Numbers
- Protocol Number for IPv6
RFC 8200: Internet Protocol, Version 6 (IPv6)
Specification - Next Header";
}
identity exact-ipv6-hop-limit {
base ipv6-capability;
description
"Identity for exact-match IPv6 hop limit condition
capability";
reference
"RFC 8200: Internet Protocol, Version 6 (IPv6)
Specification - Hop Limit";
}
identity range-ipv6-hop-limit {
base ipv6-capability;
description
"Identity for range-match IPv6 hop limit condition
capability";
reference
"RFC 8200: Internet Protocol, Version 6 (IPv6)
Specification - Hop Limit";
}
identity prefix-ipv6-address {
base ipv6-capability;
description
"Identity for prefix-match IPv6 address condition
capability. The addresses are specified by a pair
of prefix and prefix length.";
reference
"RFC 8200: Internet Protocol, Version 6 (IPv6)
Specification - Address";
}
identity range-ipv6-address {
base ipv6-capability;
description
"Identity for range-match IPv6 address condition
capability. The addresses are specified by a start
address and an end address.";
reference
"RFC 8200: Internet Protocol, Version 6 (IPv6)
Specification - Address";
}
identity ipv6-header-order {
base ipv6-capability;
description
"Identity for IPv6 extension header order condition
capability";
reference
"RFC 8200: Internet Protocol, Version 6 (IPv6)
Specification - Extension Header Order";
}
identity ipv6-options {
base ipv6-capability;
description
"Identity for IPv6 options type condition
capability";
reference
"RFC 8200: Internet Protocol, Version 6 (IPv6)
Specification - Options";
}
identity ipv6-hop-by-hop {
base ipv6-capability;
description
"Identity for IPv6 hop by hop options header
condition capability";
reference
"RFC 8200: Internet Protocol, Version 6 (IPv6)
Specification - Options";
}
identity ipv6-routing-header {
base ipv6-capability;
description
"Identity for IPv6 routing header condition
capability";
reference
"RFC 8200: Internet Protocol, Version 6 (IPv6)
Specification - Routing Header";
}
identity ipv6-fragment-header {
base ipv6-capability;
description
"Identity for IPv6 fragment header condition
capability";
reference
"RFC 8200: Internet Protocol, Version 6 (IPv6)
Specification - Fragment Header";
}
identity ipv6-destination-options {
base ipv6-capability;
description
"Identity for IPv6 destination options condition
capability";
reference
"RFC 8200: Internet Protocol, Version 6 (IPv6)
Specification - Destination Options";
}
identity ipv6-geo-ip {
base ipv6-capability;
description
"Identity for IPv4 geography condition capability";
reference
"RFC 8805: Self-published IP Geolocation Data - An
access control for a geographical location i.e.,
geolocation (e.g., the corresponding IP address).";
}
identity tcp-capability {
base condition;
description
"Base identity for TCP condition capabilities";
reference
"RFC 793: Transmission Control Protocol
draft-ietf-tcpm-rfc793bis: Transmission Control Protocol
(TCP) Specification";
}
identity exact-tcp-port-num {
base tcp-capability;
description
"Identity for exact-match TCP port number condition
capability"; capability";
reference reference
"RFC 8200: Internet Protocol, Version 6 (IPv6) "RFC 793: Transmission Control Protocol - Port Number
Specification - Fragment Header"; draft-ietf-tcpm-rfc793bis: Transmission Control Protocol
} (TCP) Specification";
}
identity ipv6-destination-options { identity range-tcp-port-num {
base ipv6-capability; base tcp-capability;
description description
"Identity for destination options IPv6 address condition "Identity for range-match TCP port number condition
capability"; capability";
reference reference
"RFC 8200: Internet Protocol, Version 6 (IPv6) "RFC 793: Transmission Control Protocol - Port Number
Specification - Destination Options"; draft-ietf-tcpm-rfc793bis: Transmission Control Protocol
} (TCP) Specification";
}
identity tcp-capability { identity tcp-flags {
base condition; base tcp-capability;
description description
"Base identity for TCP condition capabilities"; "Identity for TCP control bits (flags) condition capability";
reference reference
"RFC 793: Transmission Control Protocol"; "RFC 793: Transmission Control Protocol - Flags
} RFC 3168: The Addition of Explicit Congestion Notification
(ECN) to IP - TCP Header Flags
draft-ietf-tcpm-rfc793bis: Transmission Control Protocol
(TCP) Specification
draft-ietf-tcpm-accurate-ecn: More Accurate ECN Feedback
in TCP";
}
identity exact-tcp-port-num { identity tcp-options {
base tcp-capability; base tcp-capability;
description description
"Identity for exact-match TCP port number condition "Identity for TCP options condition capability";
capability"; reference
reference "RFC 793: Transmission Control Protocol - Options
"RFC 793: Transmission Control Protocol - Port Number"; draft-ietf-tcpm-rfc793bis: Transmission Control Protocol
} (TCP) Specification
RFC 6691: TCP Options and Maximum Segment Size
RFC 7323: TCP Extensions for High Performance";
}
identity range-tcp-port-num { identity udp-capability {
base tcp-capability; base condition;
description description
"Identity for range-match TCP port number condition "Base identity for UDP condition capabilities";
capability"; reference
reference "RFC 768: User Datagram Protocol";
"RFC 793: Transmission Control Protocol - Port Number"; }
}
identity exact-tcp-window-size { identity exact-udp-port-num {
base tcp-capability; base udp-capability;
description description
"Identity for exact-match TCP window size condition capability"; "Identity for exact-match UDP port number condition capability";
reference reference
"RFC 793: Transmission Control Protocol - Window Size"; "RFC 768: User Datagram Protocol - Port Number";
} }
identity range-tcp-window-size { identity range-udp-port-num {
base tcp-capability; base udp-capability;
description description
"Identity for range-match TCP window size condition capability"; "Identity for range-match UDP port number condition capability";
reference reference
"RFC 793: Transmission Control Protocol - Window Size"; "RFC 768: User Datagram Protocol - Port Number";
} }
identity tcp-flags { identity exact-udp-total-length {
base tcp-capability; base udp-capability;
description description
"Identity for TCP flags condition capability"; "Identity for exact-match UDP total-length condition capability.
reference The UDP total length can be smaller than the IP transport
"RFC 793: Transmission Control Protocol - Flags"; length for UDP transport layer options.";
} reference
"RFC 768: User Datagram Protocol - Total Length
draft-ietf-tsvwg-udp-options: Transport Options for UDP";
}
identity udp-capability { identity range-udp-total-length {
base condition; base udp-capability;
description description
"Base identity for UDP condition capabilities"; "Identity for range-match UDP total-length condition capability
reference The UDP total length can be smaller than the IP transport
"RFC 768: User Datagram Protocol"; length for UDP transport layer options.";
} reference
"RFC 768: User Datagram Protocol - Total Length
draft-ietf-tsvwg-udp-options: Transport Options for UDP";
}
identity exact-udp-port-num { identity sctp-capability {
base udp-capability; description
description "Identity for SCTP condition capabilities";
"Identity for exact-match UDP port number condition capability"; reference
reference "RFC 4960: Stream Control Transmission Protocol";
"RFC 768: User Datagram Protocol - Port Number";
}
identity range-udp-port-num { }
base udp-capability;
description
"Identity for range-match UDP port number condition capability";
reference
"RFC 768: User Datagram Protocol - Port Number";
}
identity exact-udp-total-length { identity exact-sctp-port-num {
base udp-capability; base sctp-capability;
description description
"Identity for exact-match UDP total-length condition capability"; "Identity for exact-match SCTP port number condition
reference capability";
"RFC 768: User Datagram Protocol - Total Length"; reference
} "RFC 4960: Stream Control Transmission Protocol - Port Number";
}
identity range-udp-total-length { identity range-sctp-port-num {
base udp-capability; base sctp-capability;
description description
"Identity for range-match UDP total-length condition capability"; "Identity for range-match SCTP port number condition
reference capability";
"RFC 768: User Datagram Protocol - Total Length"; reference
} "RFC 4960: Stream Control Transmission Protocol - Port Number";
}
identity sctp-capability { identity sctp-verification-tag {
base sctp-capability;
description description
"Identity for SCTP condition capabilities"; "Identity for range-match SCTP verification tag condition
reference capability";
"RFC 4960: Stream Control Transmission Protocol"; reference
} "RFC 4960: Stream Control Transmission Protocol - Verification Tag";
}
identity exact-sctp-port-num { identity sctp-chunk-type {
base sctp-capability; base sctp-capability;
description description
"Identity for exact-match SCTP port number condition "Identity for SCTP chunk type condition capability";
capability"; reference
reference "RFC 4960: Stream Control Transmission Protocol - Chunk Type";
"RFC 4960: Stream Control Transmission Protocol - Port Number"; }
}
identity range-sctp-port-num { identity dccp-capability {
base sctp-capability; description
description "Identity for DCCP condition capabilities";
"Identity for range-match SCTP port number condition reference
capability"; "RFC 4340: Datagram Congestion Control Protocol";
reference }
"RFC 4960: Stream Control Transmission Protocol - Port Number";
}
identity sctp-chunk-type { identity exact-dccp-port-num {
base sctp-capability; base dccp-capability;
description description
"Identity for SCTP chunk type condition capability"; "Identity for exact-match DCCP port number condition
reference capability";
"RFC 4960: Stream Control Transmission Protocol - Chunk Type"; reference
} "RFC 4340: Datagram Congestion Control Protocol";
}
identity icmp-capability { identity range-dccp-port-num {
base condition; base dccp-capability;
description description
"Base identity for ICMP condition capability"; "Identity for range-match DCCP port number condition
reference capability";
"RFC 792: Internet Control Message Protocol"; reference
} "RFC 4340: Datagram Congestion Control Protocol";
}
identity icmp-type { identity dccp-service-code {
base icmp-capability; base dccp-capability;
description description
"Identity for ICMP type condition capability"; "Identity for DCCP Service Code condition capabilitiy";
reference reference
"RFC 792: Internet Control Message Protocol"; "RFC 4340: Datagram Congestion Control Protocol
} RFC 5595: The Datagram Congestion Control Protocol (DCCP)
Service Codes
RFC 6335: Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry - Service Code";
}
identity icmp-code { identity icmp-capability {
base icmp-capability; base condition;
description description
"Identity for ICMP code condition capability"; "Base identity for ICMP condition capability";
reference reference
"RFC 792: Internet Control Message Protocol"; "RFC 792: Internet Control Message Protocol";
} }
identity icmpv6-capability { identity icmp-type {
base condition; base icmp-capability;
description description
"Base identity for ICMPv6 condition capability"; "Identity for ICMP type condition capability";
reference reference
"RFC 4443: Internet Control Message Protocol (ICMPv6) "RFC 792: Internet Control Message Protocol";
for the Internet Protocol Version 6 (IPv6) Specification }
- ICMPv6";
}
identity icmpv6-type { identity icmp-code {
base icmpv6-capability; base icmp-capability;
description description
"Identity for ICMPv6 type condition capability"; "Identity for ICMP code condition capability";
reference reference
"RFC 4443: Internet Control Message Protocol (ICMPv6) "RFC 792: Internet Control Message Protocol";
for the Internet Protocol Version 6 (IPv6) Specification }
- ICMPv6";
}
identity icmpv6-code { identity icmpv6-capability {
base icmpv6-capability; base condition;
description description
"Identity for ICMPv6 code condition capability"; "Base identity for ICMPv6 condition capability";
reference reference
"RFC 4443: Internet Control Message Protocol (ICMPv6) "RFC 4443: Internet Control Message Protocol (ICMPv6)
for the Internet Protocol Version 6 (IPv6) Specification for the Internet Protocol Version 6 (IPv6) Specification
- ICMPv6"; - ICMPv6";
} }
identity url-capability { identity icmpv6-type {
base condition; base icmpv6-capability;
description description
"Base identity for URL condition capability"; "Identity for ICMPv6 type condition capability";
} reference
"RFC 4443: Internet Control Message Protocol (ICMPv6)
for the Internet Protocol Version 6 (IPv6) Specification
- ICMPv6";
}
identity pre-defined { identity icmpv6-code {
base url-capability; base icmpv6-capability;
description description
"Identity for pre-defined URL Database condition capability. "Identity for ICMPv6 code condition capability";
The NSF capable of using a predefined public URL Database."; reference
} "RFC 4443: Internet Control Message Protocol (ICMPv6)
for the Internet Protocol Version 6 (IPv6) Specification
- ICMPv6";
}
identity user-defined { identity url-capability {
base url-capability; base condition;
description description
"Identity for user-defined URL Database condition capability. "Base identity for URL condition capability";
The NSF capable of using a URL Database that can be added }
manually by a user.";
}
identity log-action-capability { identity pre-defined {
description base url-capability;
"Base identity for log-action capability"; description
} "Identity for pre-defined URL Database condition capability.
where URL database is a public database for URL filtering.";
}
identity rule-log { identity user-defined {
base log-action-capability; base url-capability;
description description
"Identity for rule log log-action capability. "Identity for user-defined URL Database condition capability.
Log the received packet based on the rule"; that allows a users manual addition of URLs for URL
} filtering.";
}
identity session-log { identity log-action-capability {
base log-action-capability; description
description "Base identity for log-action capability";
"Identity for session log log-action capability. }
Log the received packet based on the session.";
}
identity ingress-action-capability { identity rule-log {
description base log-action-capability;
"Base identity for ingress-action capability"; description
reference "Identity for rule log log-action capability.
"RFC 8329: Framework for Interface to Network Security Log the received packet based on the rule";
Functions - Ingress action"; }
}
identity egress-action-capability { identity session-log {
description base log-action-capability;
"Base identity for egress-action capability"; description
reference "Identity for session log log-action capability.
"RFC 8329: Framework for Interface to Network Security Log the received packet based on the session.";
Functions - Egress action"; }
}
identity default-action-capability { identity ingress-action-capability {
description description
"Base identity for default-action capability"; "Base identity for ingress-action capability";
} reference
"RFC 8329: Framework for Interface to Network Security
Functions - Ingress action";
}
identity pass { identity egress-action-capability {
base ingress-action-capability; description
base egress-action-capability; "Base identity for egress-action capability";
base default-action-capability; reference
description "RFC 8329: Framework for Interface to Network Security
"Identity for pass action capability"; Functions - Egress action";
reference }
"RFC 8329: Framework for Interface to Network Security
Functions - Ingress, egress, and pass actions.";
}
identity drop { identity default-action-capability {
base ingress-action-capability; description
base egress-action-capability; "Base identity for default-action capability";
base default-action-capability; }
description
"Identity for drop action capability";
reference
"RFC 8329: Framework for Interface to Network Security
Functions - Ingress, egress, and drop actions.";
}
identity alert {
base ingress-action-capability;
base egress-action-capability;
base default-action-capability;
description
"Identity for alert action capability";
reference
"RFC 8329: Framework for Interface to Network Security
Functions - Ingress, egress, and alert actions.
draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF
NSF Monitoring YANG Data Model - Alarm (i.e., alert).";
}
identity mirror { identity pass {
base ingress-action-capability; base ingress-action-capability;
base egress-action-capability; base egress-action-capability;
base default-action-capability; base default-action-capability;
description description
"Identity for mirror action capability"; "Identity for pass action capability";
reference reference
"RFC 8329: Framework for Interface to Network Security "RFC 8329: Framework for Interface to Network Security
Functions - Ingress, egress, and mirror actions."; Functions - Ingress, egress, and pass actions.";
} }
identity invoke-signaling { identity drop {
base egress-action-capability; base ingress-action-capability;
description base egress-action-capability;
"Identity for invoke signaling action capability"; base default-action-capability;
reference description
"RFC 8329: Framework for Interface to Network Security "Identity for drop action capability";
Functions - Invoke-signaling action"; reference
} "RFC 8329: Framework for Interface to Network Security
Functions - Ingress, egress, and drop actions.";
}
identity forwarding { identity alert {
base egress-action-capability; base ingress-action-capability;
description base egress-action-capability;
"Identity for forwarding action capability"; base default-action-capability;
reference description
"RFC 8329: Framework for Interface to Network Security "Identity for alert action capability";
Functions - Forwarding action"; reference
} "RFC 8329: Framework for Interface to Network Security
Functions - Ingress, egress, and alert actions.
draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF
NSF Monitoring YANG Data Model - Alarm (i.e., alert).";
}
identity redirection { identity mirror {
base egress-action-capability; base ingress-action-capability;
description base egress-action-capability;
"Identity for redirection action capability"; base default-action-capability;
reference description
"RFC 8329: Framework for Interface to Network Security "Identity for mirror action capability";
Functions - Redirection action"; reference
} "RFC 8329: Framework for Interface to Network Security
Functions - Ingress, egress, and mirror actions.";
}
identity resolution-strategy-capability { identity invoke-signaling {
description base egress-action-capability;
"Base identity for resolution strategy capability"; description
} "Identity for invoke signaling action capability";
identity fmr { reference
base resolution-strategy-capability; "RFC 8329: Framework for Interface to Network Security
description Functions - Invoke-signaling action";
"Identity for First Matching Rule (FMR) resolution }
strategy capability";
}
identity lmr { identity forwarding {
base resolution-strategy-capability; base egress-action-capability;
description description
"Identity for Last Matching Rule (LMR) resolution "Identity for forwarding action capability";
strategy capability"; reference
} "RFC 8329: Framework for Interface to Network Security
Functions - Forwarding action";
}
identity pmr { identity redirection {
base resolution-strategy-capability; base egress-action-capability;
description description
"Identity for Prioritized Matching Rule (PMR) resolution "Identity for redirection action capability";
strategy capability"; reference
} "RFC 8329: Framework for Interface to Network Security
Functions - Redirection action";
}
identity pmre { identity resolution-strategy-capability {
base resolution-strategy-capability; description
description "Base identity for resolution strategy capability";
"Identity for Prioritized Matching Rule with Errors (PMRE) }
resolution strategy capability";
}
identity pmrn { identity fmr {
base resolution-strategy-capability; base resolution-strategy-capability;
description description
"Identity for Prioritized Matching Rule with No Errors (PMRN) "Identity for First Matching Rule (FMR) resolution
resolution strategy capability"; strategy capability";
} }
identity advanced-nsf-capability { identity lmr {
description base resolution-strategy-capability;
"Base identity for advanced Network Security Function (NSF) description
capability. This can be used for advanced NSFs such as "Identity for Last Matching Rule (LMR) resolution
Anti-Virus, Anti-DDoS Attack, IPS, and VoIP/VoLTE Security strategy capability";
Service."; }
reference
"RFC 8329: Framework for Interface to Network Security
Functions - Advanced NSF capability";
}
identity anti-virus-capability { identity pmr {
base advanced-nsf-capability; base resolution-strategy-capability;
description description
"Identity for advanced NSF Anti-Virus capability. "Identity for Prioritized Matching Rule (PMR) resolution
This can be used for an extension point for Anti-Virus strategy capability";
as an advanced NSF."; }
reference identity pmre {
"RFC 8329: Framework for Interface to Network Security base resolution-strategy-capability;
Functions - Advanced NSF Anti-Virus capability"; description
} "Identity for Prioritized Matching Rule with Errors (PMRE)
resolution strategy capability";
}
identity anti-ddos-capability { identity pmrn {
base advanced-nsf-capability; base resolution-strategy-capability;
description description
"Identity for advanced NSF Anti-DDoS Attack capability. "Identity for Prioritized Matching Rule with No Errors (PMRN)
This can be used for an extension point for Anti-DDoS resolution strategy capability";
Attack as an advanced NSF."; }
reference
"RFC 8329: Framework for Interface to Network Security
Functions - Advanced NSF Anti-DDoS Attack capability";
}
identity ips-capability { identity advanced-nsf-capability {
base advanced-nsf-capability; description
description "Base identity for advanced Network Security Function (NSF)
"Identity for advanced NSF IPS capabilities. This can be capability. This can be used for advanced NSFs such as
used for an extension point for IPS as an advanced NSF."; Anti-Virus, Anti-DDoS Attack, IPS, and VoIP/VoLTE Security
reference Service.";
"RFC 8329: Framework for Interface to Network Security reference
Functions - Advanced NSF IPS capability"; "RFC 8329: Framework for Interface to Network Security
} Functions - Advanced NSF capability";
}
identity voip-volte-capability { identity anti-virus-capability {
base advanced-nsf-capability; base advanced-nsf-capability;
description description
"Identity for advanced NSF VoIP/VoLTE Security Service "Identity for advanced NSF Anti-Virus capability.
capability. This can be used for an extension point This can be used for an extension point for Anti-Virus
for VoIP/VoLTE Security Service as an advanced NSF."; as an advanced NSF.";
reference reference
"RFC 3261: SIP: Session Initiation Protocol"; "RFC 8329: Framework for Interface to Network Security
} Functions - Advanced NSF Anti-Virus capability";
identity detect { }
base anti-virus-capability;
description
"Identity for advanced NSF Anti-Virus Detection capability.
This can be used for an extension point for Anti-Virus
Detection as an advanced NSF.";
reference
"RFC 8329: Framework for Interface to Network Security
Functions - Advanced NSF Anti-Virus Detection capability";
}
identity allow-list { identity anti-ddos-capability {
base anti-virus-capability; base advanced-nsf-capability;
description description
"Identity for advanced NSF Anti-Virus Allow List capability. "Identity for advanced NSF Anti-DDoS Attack capability.
This can be used for an extension point for Anti-Virus This can be used for an extension point for Anti-DDoS
Allow List as an advanced NSF."; Attack as an advanced NSF.";
reference reference
"RFC 8329: Framework for Interface to Network Security "RFC 8329: Framework for Interface to Network Security
Functions - Advanced NSF Anti-Virus Allow List capability"; Functions - Advanced NSF Anti-DDoS Attack capability";
} }
identity syn-flood-action { identity ips-capability {
base anti-ddos-capability; base advanced-nsf-capability;
description description
"Identity for advanced NSF Anti-DDoS SYN Flood Action "Identity for advanced NSF IPS capabilities. This can be
capability. This can be used for an extension point for used for an extension point for IPS as an advanced NSF.";
Anti-DDoS SYN Flood Action as an advanced NSF."; reference
reference "RFC 8329: Framework for Interface to Network Security
"RFC 8329: Framework for Interface to Network Security Functions - Advanced NSF IPS capability";
Functions - Advanced NSF Anti-DDoS SYN Flood Action }
capability";
}
identity udp-flood-action { identity voip-volte-capability {
base anti-ddos-capability; base advanced-nsf-capability;
description description
"Identity for advanced NSF Anti-DDoS UDP Flood Action "Identity for advanced NSF VoIP/VoLTE Security Service
capability. This can be used for an extension point for capability. This can be used for an extension point
Anti-DDoS UDP Flood Action as an advanced NSF."; for VoIP/VoLTE Security Service as an advanced NSF.";
reference reference
"RFC 8329: Framework for Interface to Network Security "RFC 3261: SIP: Session Initiation Protocol";
Functions - Advanced NSF Anti-DDoS UDP Flood Action }
capability";
}
identity http-flood-action { identity detect {
base anti-ddos-capability; base anti-virus-capability;
description description
"Identity for advanced NSF Anti-DDoS HTTP Flood Action "Identity for advanced NSF Anti-Virus Detection capability.
capability. This can be used for an extension point for This can be used for an extension point for Anti-Virus
Anti-DDoS HTTP Flood Action as an advanced NSF."; Detection as an advanced NSF.";
reference reference
"RFC 8329: Framework for Interface to Network Security "RFC 8329: Framework for Interface to Network Security
Functions - Advanced NSF Anti-DDoS HTTP Flood Action Functions - Advanced NSF Anti-Virus Detection capability";
capability"; }
}
identity https-flood-action { identity allow-list {
base anti-ddos-capability; base anti-virus-capability;
description description
"Identity for advanced NSF Anti-DDoS HTTPS Flood Action "Identity for advanced NSF Anti-Virus Allow List capability.
capability. This can be used for an extension point for This can be used for an extension point for Anti-Virus
Anti-DDoS HTTPS Flood Action as an advanced NSF."; Allow List as an advanced NSF.";
reference reference
"RFC 8329: Framework for Interface to Network Security "RFC 8329: Framework for Interface to Network Security
Functions - Advanced NSF Anti-DDoS HTTPS Flood Action Functions - Advanced NSF Anti-Virus Allow List capability";
capability"; }
}
identity dns-request-flood-action { identity syn-flood-action {
base anti-ddos-capability; base anti-ddos-capability;
description description
"Identity for advanced NSF Anti-DDoS DNS Request Flood "Identity for advanced NSF Anti-DDoS SYN Flood Action
Action capability. This can be used for an extension capability. This can be used for an extension point for
point for Anti-DDoS DNS Request Flood Action as an Anti-DDoS SYN Flood Action as an advanced NSF.";
advanced NSF."; reference
reference "RFC 8329: Framework for Interface to Network Security
"RFC 8329: Framework for Interface to Network Security Functions - Advanced NSF Anti-DDoS SYN Flood Action
Functions - Advanced NSF Anti-DDoS DNS Request Flood capability";
Action capability"; }
}
identity dns-reply-flood-action { identity udp-flood-action {
base anti-ddos-capability; base anti-ddos-capability;
description description
"Identity for advanced NSF Anti-DDoS DNS Reply Flood "Identity for advanced NSF Anti-DDoS UDP Flood Action
Action capability. This can be used for an extension capability. This can be used for an extension point for
point for Anti-DDoS DNS Reply Flood Action as an Anti-DDoS UDP Flood Action as an advanced NSF.";
advanced NSF."; reference
reference "RFC 8329: Framework for Interface to Network Security
"RFC 8329: Framework for Interface to Network Security Functions - Advanced NSF Anti-DDoS UDP Flood Action
Functions - Advanced NSF Anti-DDoS DNS Reply Flood capability";
Action capability"; }
}
identity icmp-flood-action {
base anti-ddos-capability;
description
"Identity for advanced NSF Anti-DDoS ICMP Flood Action
capability. This can be used for an extension point
for Anti-DDoS ICMP Flood Action as an advanced NSF.";
reference
"RFC 8329: Framework for Interface to Network Security
Functions - Advanced NSF Anti-DDoS ICMP Flood Action
capability";
}
identity icmpv6-flood-action { identity http-flood-action {
base anti-ddos-capability; base anti-ddos-capability;
description description
"Identity for advanced NSF Anti-DDoS ICMPv6 Flood Action "Identity for advanced NSF Anti-DDoS HTTP Flood Action
capability. This can be used for an extension point capability. This can be used for an extension point for
for Anti-DDoS ICMPv6 Flood Action as an advanced NSF."; Anti-DDoS HTTP Flood Action as an advanced NSF.";
reference reference
"RFC 8329: Framework for Interface to Network Security "RFC 8329: Framework for Interface to Network Security
Functions - Advanced NSF Anti-DDoS ICMPv6 Flood Action Functions - Advanced NSF Anti-DDoS HTTP Flood Action
capability"; capability";
} }
identity sip-flood-action { identity https-flood-action {
base anti-ddos-capability; base anti-ddos-capability;
description description
"Identity for advanced NSF Anti-DDoS SIP Flood Action "Identity for advanced NSF Anti-DDoS HTTPS Flood Action
capability. This can be used for an extension point capability. This can be used for an extension point for
for Anti-DDoS SIP Flood Action as an advanced NSF."; Anti-DDoS HTTPS Flood Action as an advanced NSF.";
reference reference
"RFC 8329: Framework for Interface to Network Security "RFC 8329: Framework for Interface to Network Security
Functions - Advanced NSF Anti-DDoS SIP Flood Action Functions - Advanced NSF Anti-DDoS HTTPS Flood Action
capability"; capability";
} }
identity detect-mode { identity dns-request-flood-action {
base anti-ddos-capability; base anti-ddos-capability;
description description
"Identity for advanced NSF Anti-DDoS Detection Mode "Identity for advanced NSF Anti-DDoS DNS Request Flood
capability. This can be used for an extension point Action capability. This can be used for an extension
for Anti-DDoS Detection Mode as an advanced NSF."; point for Anti-DDoS DNS Request Flood Action as an
reference advanced NSF.";
"RFC 8329: Framework for Interface to Network Security
Functions - Advanced NSF Anti-DDoS Detection Mode
capability";
}
identity baseline-learning {
base anti-ddos-capability;
description
"Identity for advanced NSF Anti-DDoS Baseline Learning
capability. This can be used for an extension point
for Anti-DDoS Baseline Learning as an advanced NSF.";
reference
"RFC 8329: Framework for Interface to Network Security
Functions - Advanced NSF Anti-DDoS Baseline Learning
capability";
}
identity signature-set { reference
base ips-capability; "RFC 8329: Framework for Interface to Network Security
description Functions - Advanced NSF Anti-DDoS DNS Request Flood
"Identity for advanced NSF IPS Signature Set capability. Action capability";
This can be used for an extension point for IPS Signature }
Set as an advanced NSF.";
reference
"RFC 8329: Framework for Interface to Network Security
Functions - Advanced NSF IPS Signature Set capability";
}
identity ips-exception-signature { identity dns-reply-flood-action {
base ips-capability; base anti-ddos-capability;
description description
"Identity for advanced NSF IPS Exception Signature "Identity for advanced NSF Anti-DDoS DNS Reply Flood
capability. This can be used for an extension point for Action capability. This can be used for an extension
IPS Exception Signature as an advanced NSF."; point for Anti-DDoS DNS Reply Flood Action as an
reference advanced NSF.";
"RFC 8329: Framework for Interface to Network Security reference
Functions - Advanced NSF IPS Exception Signature Set "RFC 8329: Framework for Interface to Network Security
capability"; Functions - Advanced NSF Anti-DDoS DNS Reply Flood
} Action capability";
}
identity voip-volte-call-id { identity icmp-flood-action {
base voip-volte-capability; base anti-ddos-capability;
description description
"Identity for advanced NSF VoIP/VoLTE Call-ID capability. "Identity for advanced NSF Anti-DDoS ICMP Flood Action
This can be used for an extension point for VoIP/VoLTE capability. This can be used for an extension point
Voice-ID as an advanced NSF."; for Anti-DDoS ICMP Flood Action as an advanced NSF.";
reference reference
"RFC 3261: SIP: Session Initiation Protocol"; "RFC 8329: Framework for Interface to Network Security
Functions - Advanced NSF Anti-DDoS ICMP Flood Action
capability";
}
} identity icmpv6-flood-action {
base anti-ddos-capability;
description
"Identity for advanced NSF Anti-DDoS ICMPv6 Flood Action
capability. This can be used for an extension point
for Anti-DDoS ICMPv6 Flood Action as an advanced NSF.";
reference
"RFC 8329: Framework for Interface to Network Security
Functions - Advanced NSF Anti-DDoS ICMPv6 Flood Action
capability";
}
identity user-agent { identity sip-flood-action {
base voip-volte-capability; base anti-ddos-capability;
description description
"Identity for advanced NSF VoIP/VoLTE User Agent capability. "Identity for advanced NSF Anti-DDoS SIP Flood Action
This can be used for an extension point for VoIP/VoLTE capability. This can be used for an extension point
User Agent as an advanced NSF."; for Anti-DDoS SIP Flood Action as an advanced NSF.";
reference reference
"RFC 3261: SIP: Session Initiation Protocol"; "RFC 8329: Framework for Interface to Network Security
} Functions - Advanced NSF Anti-DDoS SIP Flood Action
capability";
}
identity ipsec-capability { identity detect-mode {
description base anti-ddos-capability;
"Base identity for an IPsec capability"; description
reference "Identity for advanced NSF Anti-DDoS Detection Mode
"draft-ietf-i2nsf-sdn-ipsec-flow-protection-08: capability. This can be used for an extension point
Software-Defined Networking (SDN)-based IPsec Flow for Anti-DDoS Detection Mode as an advanced NSF.";
Protection - IPsec methods such as IKE and IKE-less"; reference
} "RFC 8329: Framework for Interface to Network Security
Functions - Advanced NSF Anti-DDoS Detection Mode
capability";
}
identity ike { identity baseline-learning {
base ipsec-capability; base anti-ddos-capability;
description description
"Identity for an IPsec Internet Key Exchange (IKE) "Identity for advanced NSF Anti-DDoS Baseline Learning
capability. This can be used for an extension point
for Anti-DDoS Baseline Learning as an advanced NSF.";
reference
"RFC 8329: Framework for Interface to Network Security
Functions - Advanced NSF Anti-DDoS Baseline Learning
capability"; capability";
reference }
"draft-ietf-i2nsf-sdn-ipsec-flow-protection-08:
Software-Defined Networking (SDN)-based IPsec Flow
Protection - IPsec method with IKE.
RFC 7296: Internet Key Exchange Protocol Version 2
(IKEv2) - IKE as a component of IPsec used for
performing mutual authentication and establishing and
maintaining Security Associations (SAs).";
}
identity ikeless { identity signature-set {
base ipsec-capability; base ips-capability;
description description
"Identity for an IPsec without Internet Key Exchange (IKE) "Identity for advanced NSF IPS Signature Set capability.
This can be used for an extension point for IPS Signature
Set as an advanced NSF.";
reference
"RFC 8329: Framework for Interface to Network Security
Functions - Advanced NSF IPS Signature Set capability";
}
identity ips-exception-signature {
base ips-capability;
description
"Identity for advanced NSF IPS Exception Signature
capability. This can be used for an extension point for
IPS Exception Signature as an advanced NSF.";
reference
"RFC 8329: Framework for Interface to Network Security
Functions - Advanced NSF IPS Exception Signature Set
capability"; capability";
reference }
"draft-ietf-i2nsf-sdn-ipsec-flow-protection-08:
Software-Defined Networking (SDN)-based IPsec Flow
Protection - IPsec method without IKE";
}
/* identity voip-volte-call-id {
* Grouping base voip-volte-capability;
*/ description
"Identity for advanced NSF VoIP/VoLTE Call Identifier (ID)
capability. This can be used for an extension point for
VoIP/VoLTE Call ID as an advanced NSF.";
reference
"RFC 3261: SIP: Session Initiation Protocol";
}
grouping nsf-capabilities { identity user-agent {
description base voip-volte-capability;
"Network Security Function (NSF) Capabilities"; description
reference "Identity for advanced NSF VoIP/VoLTE User Agent capability.
"RFC 8329: Framework for Interface to Network Security This can be used for an extension point for VoIP/VoLTE
Functions - I2NSF Flow Security Policy Structure."; User Agent as an advanced NSF.";
reference
"RFC 3261: SIP: Session Initiation Protocol";
}
leaf-list time-capabilities { identity ipsec-capability {
type enumeration { description
enum absolute-time { "Base identity for an IPsec capability";
description reference
"absolute time capabilities. "draft-ietf-i2nsf-sdn-ipsec-flow-protection-12:
If a network security function has the absolute time Software-Defined Networking (SDN)-based IPsec Flow
capability, the network security function supports Protection - IPsec methods such as IKE and IKE-less";
rule execution according to absolute time."; }
}
enum periodic-time {
description
"periodic time capabilities.
If a network security function has the periodic time
capability, the network security function supports
rule execution according to periodic time.";
}
}
description
"Time capabilities";
}
container event-capabilities { identity ike {
description base ipsec-capability;
"Capabilities of events. description
If a network security function has the event capabilities, "Identity for an IPsec Internet Key Exchange (IKE)
the network security function supports rule execution capability";
according to system event and system alarm."; reference
"draft-ietf-i2nsf-sdn-ipsec-flow-protection-12:
Software-Defined Networking (SDN)-based IPsec Flow
Protection - IPsec method with IKE.
RFC 7296: Internet Key Exchange Protocol Version 2
(IKEv2) - IKE as a component of IPsec used for
performing mutual authentication and establishing and
maintaining Security Associations (SAs).";
reference }
"RFC 8329: Framework for Interface to Network Security
Functions - I2NSF Flow Security Policy Structure.
draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF
NSF Monitoring YANG Data Model - System Alarm and
System Events.";
leaf-list system-event-capability { identity ikeless {
type identityref { base ipsec-capability;
base system-event-capability; description
} "Identity for an IPsec without Internet Key Exchange (IKE)
description capability";
"System event capabilities"; reference
} "draft-ietf-i2nsf-sdn-ipsec-flow-protection-12:
leaf-list system-alarm-capability { Software-Defined Networking (SDN)-based IPsec Flow
type identityref { Protection - IPsec method without IKE";
base system-alarm-capability; }
}
description
"System alarm capabilities";
}
}
container condition-capabilities { /*
description * Grouping
"Conditions capabilities."; */
container generic-nsf-capabilities { grouping nsf-capabilities {
description description
"Conditions capabilities. "Network Security Function (NSF) Capabilities";
If a network security function has the condition reference
capabilities, the network security function "RFC 8329: Framework for Interface to Network Security
supports rule execution according to conditions of Functions - I2NSF Flow Security Policy Structure.";
IPv4, IPv6, TCP, UDP, SCTP, ICMP, ICMPv6, or payload.";
reference
"RFC 791: Internet Protocol - IPv4.
RFC 792: Internet Control Message Protocol - ICMP.
RFC 793: Transmission Control Protocol - TCP.
RFC 768: User Datagram Protocol - UDP.
RFC 4960: Stream Control Transmission Protocol - SCTP.
RFC 8200: Internet Protocol, Version 6 (IPv6)
Specification - IPv6.
RFC 4443: Internet Control Message Protocol (ICMPv6)
for the Internet Protocol Version 6 (IPv6) Specification
- ICMPv6.
RFC 8329: Framework for Interface to Network Security
Functions - I2NSF Flow Security Policy Structure.";
leaf-list ipv4-capability { leaf-list time-capabilities {
type identityref { type enumeration {
base ipv4-capability; enum absolute-time {
} description
description "absolute time capabilities.
"IPv4 packet capabilities"; If a network security function has the absolute time
reference capability, the network security function supports
"RFC 791: Internet Protocol"; rule execution according to absolute time.";
} }
enum periodic-time {
description
"periodic time capabilities.
If a network security function has the periodic time
capability, the network security function supports
rule execution according to periodic time.";
}
}
description
"Time capabilities";
}
leaf-list icmp-capability { container event-capabilities {
type identityref { description
base icmp-capability; "Capabilities of events.
}
description
"ICMP packet capabilities";
reference
"RFC 792: Internet Control Message Protocol - ICMP";
}
leaf-list ipv6-capability { If a network security function has the event capabilities,
type identityref { the network security function supports rule execution
base ipv6-capability; according to system event and system alarm.";
}
description
"IPv6 packet capabilities";
reference
"RFC 8200: Internet Protocol, Version 6 (IPv6)
Specification - IPv6";
}
leaf-list icmpv6-capability { reference
type identityref { "RFC 8329: Framework for Interface to Network Security
base icmpv6-capability; Functions - I2NSF Flow Security Policy Structure.
} draft-ietf-i2nsf-nsf-monitoring-data-model-04: I2NSF
description NSF Monitoring YANG Data Model - System Alarm and
"ICMPv6 packet capabilities"; System Events.";
reference
"RFC 4443: Internet Control Message Protocol (ICMPv6)
for the Internet Protocol Version 6 (IPv6) Specification
- ICMPv6";
}
leaf-list tcp-capability { leaf-list system-event-capability {
type identityref { type identityref {
base tcp-capability; base system-event-capability;
} }
description description
"TCP packet capabilities"; "System event capabilities";
reference }
"RFC 793: Transmission Control Protocol - TCP";
}
leaf-list udp-capability { leaf-list system-alarm-capability {
type identityref { type identityref {
base udp-capability; base system-alarm-capability;
} }
description description
"UDP packet capabilities"; "System alarm capabilities";
reference }
"RFC 768: User Datagram Protocol - UDP"; }
}
leaf-list sctp-capability {
type identityref {
base sctp-capability;
}
description
"SCTP packet capabilities";
reference
"RFC 4960: Stream Control Transmission Protocol - SCTP";
}
}
container advanced-nsf-capabilities { container condition-capabilities {
description description
"Advanced Network Security Function (NSF) capabilities, "Conditions capabilities.";
such as Anti-Virus, Anti-DDoS, IPS, and VoIP/VoLTE.
This container contains the leaf-lists of advanced
NSF capabilities";
reference
"RFC 8329: Framework for Interface to Network Security
Functions - Advanced NSF capabilities";
leaf-list anti-virus-capability { container generic-nsf-capabilities {
type identityref { description
base anti-virus-capability; "Conditions capabilities.
} If a network security function has the condition
description capabilities, the network security function
"Anti-Virus capabilities"; supports rule execution according to conditions of
reference IPv4, IPv6, TCP, UDP, SCTP, DCCP, ICMP, ICMPv6, or
"RFC 8329: Framework for Interface to Network Security payload.";
Functions - Advanced NSF Anti-Virus capabilities"; reference
} "RFC 791: Internet Protocol - IPv4.
RFC 792: Internet Control Message Protocol - ICMP.
RFC 793: Transmission Control Protocol - TCP.
RFC 768: User Datagram Protocol - UDP.
RFC 4960: Stream Control Transmission Protocol - SCTP.
RFC 8200: Internet Protocol, Version 6 (IPv6)
Specification - IPv6.
leaf-list anti-ddos-capability { RFC 4443: Internet Control Message Protocol (ICMPv6)
type identityref { for the Internet Protocol Version 6 (IPv6) Specification
base anti-ddos-capability; - ICMPv6.
} RFC 8329: Framework for Interface to Network Security
description Functions - I2NSF Flow Security Policy Structure.";
"Anti-DDoS Attack capabilities";
reference
"RFC 8329: Framework for Interface to Network Security
Functions - Advanced NSF Anti-DDoS Attack capabilities";
}
leaf-list ips-capability { leaf-list ipv4-capability {
type identityref { type identityref {
base ips-capability; base ipv4-capability;
} }
description description
"IPS capabilities"; "IPv4 packet capabilities";
reference reference
"RFC 8329: Framework for Interface to Network Security "RFC 791: Internet Protocol";
Functions - Advanced NSF IPS capabilities"; }
}
leaf-list url-capability { leaf-list icmp-capability {
type identityref { type identityref {
base url-capability; base icmp-capability;
} }
description description
"URL capabilities"; "ICMP packet capabilities";
reference reference
"RFC 8329: Framework for Interface to Network Security "RFC 792: Internet Control Message Protocol - ICMP";
Functions - Advanced NSF URL capabilities"; }
}
leaf-list voip-volte-capability { leaf-list ipv6-capability {
type identityref { type identityref {
base voip-volte-capability; base ipv6-capability;
} }
description description
"VoIP/VoLTE capabilities"; "IPv6 packet capabilities";
reference reference
"RFC 8329: Framework for Interface to Network Security "RFC 8200: Internet Protocol, Version 6 (IPv6)
Functions - Advanced NSF VoIP/VoLTE capabilities"; Specification - IPv6";
} }
}
leaf-list context-capabilities { leaf-list icmpv6-capability {
type identityref { type identityref {
base context-capability; base icmpv6-capability;
} }
description description
"Security context capabilities"; "ICMPv6 packet capabilities";
} reference
} "RFC 4443: Internet Control Message Protocol (ICMPv6)
for the Internet Protocol Version 6 (IPv6) Specification
- ICMPv6";
}
leaf-list tcp-capability {
type identityref {
base tcp-capability;
}
description
"TCP packet capabilities";
reference
"RFC 793: Transmission Control Protocol - TCP
draft-ietf-tcpm-rfc793bis-19: Transmission Control Protocol
(TCP) Specification";
}
container action-capabilities { leaf-list udp-capability {
description type identityref {
"Action capabilities. base udp-capability;
If a network security function has the action capabilities, }
the network security function supports the attendant description
actions for policy rules."; "UDP packet capabilities";
reference
"RFC 768: User Datagram Protocol - UDP";
}
leaf-list ingress-action-capability { leaf-list sctp-capability {
type identityref { type identityref {
base ingress-action-capability; base sctp-capability;
}
description
"SCTP packet capabilities";
reference
"RFC 4960: Stream Control Transmission Protocol - SCTP";
}
} leaf-list dccp-capability {
description type identityref {
"Ingress-action capabilities"; base dccp-capability;
} }
description
"DCCP packet capabilities";
reference
"RFC 4340: Datagram Congestion Control Protocol - DCCP";
}
}
leaf-list egress-action-capability { container advanced-nsf-capabilities {
type identityref { description
base egress-action-capability; "Advanced Network Security Function (NSF) capabilities,
} such as Anti-Virus, Anti-DDoS, IPS, and VoIP/VoLTE.
description This container contains the leaf-lists of advanced
"Egress-action capabilities"; NSF capabilities";
} reference
"RFC 8329: Framework for Interface to Network Security
Functions - Advanced NSF capabilities";
leaf-list log-action-capability { leaf-list anti-virus-capability {
type identityref { type identityref {
base log-action-capability; base anti-virus-capability;
}
description
"Anti-Virus capabilities";
reference
"RFC 8329: Framework for Interface to Network Security
Functions - Advanced NSF Anti-Virus capabilities";
}
leaf-list anti-ddos-capability {
type identityref {
base anti-ddos-capability;
}
description
"Anti-DDoS Attack capabilities";
reference
"RFC 8329: Framework for Interface to Network Security
Functions - Advanced NSF Anti-DDoS Attack capabilities";
}
leaf-list ips-capability {
type identityref {
base ips-capability;
}
description
"IPS capabilities";
reference
"RFC 8329: Framework for Interface to Network Security
Functions - Advanced NSF IPS capabilities";
}
leaf-list url-capability {
type identityref {
base url-capability;
}
description
"URL capabilities";
reference
"RFC 8329: Framework for Interface to Network Security
Functions - Advanced NSF URL capabilities";
}
leaf-list voip-volte-capability {
type identityref {
base voip-volte-capability;
} }
description description
"Log-action capabilities"; "VoIP/VoLTE capabilities";
} reference
} "RFC 8329: Framework for Interface to Network Security
Functions - Advanced NSF VoIP/VoLTE capabilities";
}
}
leaf-list resolution-strategy-capabilities { leaf-list context-capabilities {
type identityref { type identityref {
base resolution-strategy-capability; base context-capability;
} }
description description
"Resolution strategy capabilities. "Security context capabilities";
The resolution strategies can be used to specify how }
to resolve conflicts that occur between the actions }
of the same or different policy rules that are matched
for the same packet and by particular NSF";
}
leaf-list default-action-capabilities { container action-capabilities {
type identityref { description
base default-action-capability; "Action capabilities.
} If a network security function has the action capabilities,
description the network security function supports the attendant
"Default action capabilities. actions for policy rules.";
A default action is used to execute I2NSF policy rules
when no rule matches a packet. The default action is
defined as pass, drop, alert, or mirror.";
reference
"RFC 8329: Framework for Interface to Network Security
Functions - Ingress and egress actions.";
}
leaf-list ipsec-method {
type identityref {
base ipsec-capability;
}
description
"IPsec method capabilities";
reference
"draft-ietf-i2nsf-sdn-ipsec-flow-protection-08:
Software-Defined Networking (SDN)-based IPsec Flow
Protection - IPsec methods such as IKE and IKE-less";
}
}
/* leaf-list ingress-action-capability {
* Data nodes type identityref {
*/ base ingress-action-capability;
}
description
"Ingress-action capabilities";
}
list nsf { leaf-list egress-action-capability {
key "nsf-name"; type identityref {
description base egress-action-capability;
"The list of Network Security Functions (NSFs)"; }
leaf nsf-name { description
type string; "Egress-action capabilities";
mandatory true; }
description
"The name of Network Security Function (NSF)";
}
uses nsf-capabilities;
}
}
<CODE ENDS> leaf-list log-action-capability {
type identityref {
base log-action-capability;
}
description
"Log-action capabilities";
}
}
leaf-list resolution-strategy-capabilities {
type identityref {
base resolution-strategy-capability;
}
description
"Resolution strategy capabilities.
The resolution strategies can be used to specify how
to resolve conflicts that occur between the actions
of the same or different policy rules that are matched
for the same packet and by particular NSF.";
}
leaf-list default-action-capabilities {
type identityref {
base default-action-capability;
}
description
"Default action capabilities.
A default action is used to execute I2NSF policy rules
when no rule matches a packet. The default action is
defined as pass, drop, alert, or mirror. Note that
alert makes a packet dropped and logged.";
reference
"RFC 8329: Framework for Interface to Network Security
Functions - Ingress and egress actions.";
}
leaf-list ipsec-method {
type identityref {
base ipsec-capability;
}
description
"IPsec method capabilities";
reference
"draft-ietf-i2nsf-sdn-ipsec-flow-protection-12:
Software-Defined Networking (SDN)-based IPsec Flow
Protection - IPsec methods such as IKE and IKE-less";
}
}
/*
* Data nodes
*/
list nsf {
key "nsf-name";
description
"The list of Network Security Functions (NSFs)";
leaf nsf-name {
type string;
mandatory true;
description
"The name of Network Security Function (NSF)";
}
uses nsf-capabilities;
}
}
<CODE ENDS>
Figure 3: YANG Data Module of I2NSF Capability Figure 3: YANG Data Module of I2NSF Capability
7. IANA Considerations 7. IANA Considerations
This document requests IANA to register the following URI in the This document requests IANA to register the following URI in the
"IETF XML Registry" [RFC3688]: "IETF XML Registry" [RFC3688]:
ID: yang:ietf-i2nsf-capability ID: yang:ietf-i2nsf-capability
URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability
skipping to change at page 47, line 14 skipping to change at page 50, line 45
This document requests IANA to register the following YANG module in This document requests IANA to register the following YANG module in
the "YANG Module Names" registry [RFC7950][RFC8525]: the "YANG Module Names" registry [RFC7950][RFC8525]:
Name: ietf-i2nsf-capability Name: ietf-i2nsf-capability
Maintained by IANA? N Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability
Prefix: nsfcap Prefix: nsfcap
Module: Module:
Reference: [ RFC-to-be ] Reference: [ RFC-to-be ]
8. Security Considerations 8. Privacy Considerations
This YANG module specified in this document make a trade-off between
privacy and security. Some part of the YANG data model specified in
this document might use highly sensitive private data of the client.
The data used in this YANG data model can be used for the NSFs to
improve the security of the network.
In regards to the privacy data used, the security for accessibility
of the data should be tightly secured and monitored. The Security
Considerations are discussed in Section 9.
9. 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 layer of NETCONF
the secure transport layer, and the required transport secure protocol layers can use Secure Shell (SSH) [RFC4254][RFC6242] as a
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer secure transport layer. The lowest layer of RESTCONF protocol layers
is HTTPS, and the required transport secure transport is TLS can use HTTP over Transport Layer Security (TLS), that is, HTTPS
[RFC8446]. [RFC7230][RFC8446] as a secure transport layer.
The NETCONF access control model [RFC8341] provides a means of The Network Configuration Access Control Model (NACM) [RFC8341]
restricting access to specific NETCONF or RESTCONF users to a provides a means of restricting access to specific NETCONF or
preconfigured subset of all available NETCONF or RESTCONF protocol RESTCONF users to a preconfigured subset of all available NETCONF or
operations and content. RESTCONF protocol operations and contents. Thus, NACM can be used to
restrict the NSF registration from unauthorized users.
There are a number of data nodes defined in this YANG module that are There are a number of data nodes defined in this YANG module that are
writable, creatable, and deletable (i.e., config true, which is the writable, creatable, and deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations to these data nodes in some network environments. Write operations to these data nodes
could have a negative effect on network and security operations. could have a negative effect on network and security operations.
These data nodes are collected into a single list node. This list
node is defined by list nsf with the following sensitivity/
vulnerability:
o list nsf: An attacker could alter the security capabilities o list nsf: An attacker could alter the security capabilities
associated with an NSF whereby disabling or enabling the evasion associated with an NSF by disabling or enabling the functionality
of security mitigations. of the security capabilities of the NSF.
9. References Some of the features that this document defines capability indicators
for are highly sensitive and/or privileged operations (e.g.,
listening to VoIP/VoLTE audio to identify individuals and web
filtering) that inherently require access to individuals' private
data. It is noted that private information is made accessible in
this manner. Thus, the nodes/entities given access to this data need
to be tightly secured and monitored, to prevent leakage or other
unauthorized disclosure of private data. Refer to [RFC6973] for the
description of privacy aspects that protocol designers (including
YANG data model designers) should consider along with regular
security and privacy analysis.
9.1. Normative References 10. References
[I-D.google-self-published-geofeeds] 10.1. Normative References
Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W.
Kumari, "A Format for Self-published IP Geolocation
Feeds", draft-google-self-published-geofeeds-09 (work in
progress), February 2020.
[I-D.ietf-i2nsf-nsf-monitoring-data-model] [I-D.ietf-i2nsf-nsf-monitoring-data-model]
Jeong, J., Lingga, P., Hares, S., Xia, L., and H. Jeong, J., Lingga, P., Hares, S., Xia, L., and H.
Birkholz, "I2NSF NSF Monitoring YANG Data Model", draft- Birkholz, "I2NSF NSF Monitoring YANG Data Model", draft-
ietf-i2nsf-nsf-monitoring-data-model-04 (work in ietf-i2nsf-nsf-monitoring-data-model-04 (work in
progress), September 2020. progress), September 2020.
[I-D.ietf-i2nsf-sdn-ipsec-flow-protection] [I-D.ietf-i2nsf-sdn-ipsec-flow-protection]
Lopez, R., Lopez-Millan, G., and F. Pereniguez-Garcia, Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez-
"Software-Defined Networking (SDN)-based IPsec Flow Garcia, "Software-Defined Networking (SDN)-based IPsec
Protection", draft-ietf-i2nsf-sdn-ipsec-flow-protection-12 Flow Protection", draft-ietf-i2nsf-sdn-ipsec-flow-
(work in progress), October 2020. protection-12 (work in progress), October 2020.
[I-D.ietf-tcpm-accurate-ecn]
Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More
Accurate ECN Feedback in TCP", draft-ietf-tcpm-accurate-
ecn-13 (work in progress), November 2020.
[I-D.ietf-tcpm-rfc793bis]
Eddy, W., "Transmission Control Protocol (TCP)
Specification", draft-ietf-tcpm-rfc793bis-19 (work in
progress), October 2020.
[I-D.ietf-tsvwg-udp-options]
Touch, J., "Transport Options for UDP", draft-ietf-tsvwg-
udp-options-09 (work in progress), November 2020.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>. <https://www.rfc-editor.org/info/rfc768>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
skipping to change at page 48, line 38 skipping to change at page 53, line 10
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[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>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>.
[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, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Connection Protocol", RFC 4254, DOI 10.17487/RFC4254,
January 2006, <https://www.rfc-editor.org/info/rfc4254>.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340,
DOI 10.17487/RFC4340, March 2006,
<https://www.rfc-editor.org/info/rfc4340>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89, Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006, RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>. <https://www.rfc-editor.org/info/rfc4443>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007, RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/info/rfc4960>. <https://www.rfc-editor.org/info/rfc4960>.
[RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol
(DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595,
September 2009, <https://www.rfc-editor.org/info/rfc5595>.
[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>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011,
<https://www.rfc-editor.org/info/rfc6335>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011,
<https://www.rfc-editor.org/info/rfc6437>.
[RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)",
RFC 6691, DOI 10.17487/RFC6691, July 2012,
<https://www.rfc-editor.org/info/rfc6691>.
[RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field",
RFC 6864, DOI 10.17487/RFC6864, February 2013,
<https://www.rfc-editor.org/info/rfc6864>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>.
[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>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>. 2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7323] Borman, D., Braden, B., Jacobson, V., and R.
Scheffenegger, Ed., "TCP Extensions for High Performance",
RFC 7323, DOI 10.17487/RFC7323, September 2014,
<https://www.rfc-editor.org/info/rfc7323>.
[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>.
[RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R.,
and J. Jeong, "Interface to Network Security Functions and J. Jeong, "Interface to Network Security Functions
skipping to change at page 50, line 38 skipping to change at page 56, line 24
[RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair,
"YANG Data Model for Network Access Control Lists (ACLs)", "YANG Data Model for Network Access Control Lists (ACLs)",
RFC 8519, DOI 10.17487/RFC8519, March 2019, RFC 8519, DOI 10.17487/RFC8519, March 2019,
<https://www.rfc-editor.org/info/rfc8519>. <https://www.rfc-editor.org/info/rfc8519>.
[RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K.,
and R. Wilton, "YANG Library", RFC 8525, and R. Wilton, "YANG Library", RFC 8525,
DOI 10.17487/RFC8525, March 2019, DOI 10.17487/RFC8525, March 2019,
<https://www.rfc-editor.org/info/rfc8525>. <https://www.rfc-editor.org/info/rfc8525>.
[RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W. 10.2. Informative References
Kumari, "A Format for Self-Published IP Geolocation
Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020,
<https://www.rfc-editor.org/info/rfc8805>.
9.2. Informative References
[Alshaer] Shaer, Al., Hamed, E., and H. Hamed, "Modeling and [Alshaer] Shaer, Al., Hamed, E., and H. Hamed, "Modeling and
management of firewall policies", 2004. management of firewall policies", 2004.
[Galitsky] [Galitsky]
Galitsky, B. and R. Pampapathi, "Can many agents answer Galitsky, B. and R. Pampapathi, "Can many agents answer
questions better than one", First questions better than one", First
Monday http://dx.doi.org/10.5210/fm.v10i1.1204, 2005. Monday http://dx.doi.org/10.5210/fm.v10i1.1204, 2005.
[Hirschman] [Hirschman]
Hirschman, L. and R. Gaizauskas, "Natural Language Hirschman, L. and R. Gaizauskas, "Natural Language
Question Answering: The View from Here", Natural Language Question Answering: The View from Here", Natural Language
Engineering 7:4, pgs 275-300, Cambridge University Press , Engineering 7:4, pgs 275-300, Cambridge University Press ,
Nov 2001. Nov 2001.
[Hohpe] Hohpe, G. and B. Woolf, "Enterprise Integration Patterns", [Hohpe] Hohpe, G. and B. Woolf, "Enterprise Integration Patterns",
ISBN 0-32-120068-3 , 2003. ISBN 0-32-120068-3 , 2003.
[I-D.ietf-i2nsf-terminology]
Hares, S., Strassner, J., Lopez, D., Xia, L., and H.
Birkholz, "Interface to Network Security Functions (I2NSF)
Terminology", draft-ietf-i2nsf-terminology-08 (work in
progress), July 2019.
[I-D.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.
[IANA-Protocol-Numbers] [IANA-Protocol-Numbers]
"Assigned Internet Protocol Numbers", Available: "Assigned Internet Protocol Numbers", Available:
https://www.iana.org/assignments/protocol- https://www.iana.org/assignments/protocol-
numbers/protocol-numbers.xhtml, September 2020. numbers/protocol-numbers.xhtml, September 2020.
[Martin] Martin, R., "Agile Software Development, Principles, [Martin] Martin, R., "Agile Software Development, Principles,
Patterns, and Practices", Prentice-Hall , ISBN: Patterns, and Practices", Prentice-Hall , ISBN:
0-13-597444-5 , 2002. 0-13-597444-5 , 2002.
[OODMP] "http://www.oodesign.com/mediator-pattern.html". [OODMP] "http://www.oodesign.com/mediator-pattern.html".
[OODOP] "http://www.oodesign.com/mediator-pattern.html". [OODOP] "http://www.oodesign.com/mediator-pattern.html".
[OODSRP] "http://www.oodesign.com/mediator-pattern.html". [OODSRP] "http://www.oodesign.com/mediator-pattern.html".
[RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W.
Kumari, "A Format for Self-Published IP Geolocation
Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020,
<https://www.rfc-editor.org/info/rfc8805>.
Appendix A. Configuration Examples Appendix A. Configuration Examples
This section shows configuration examples of "ietf-i2nsf-capability" This section shows configuration examples of "ietf-i2nsf-capability"
module for capabilities registration of general firewall. module for capabilities registration of general firewall.
A.1. Example 1: Registration for the Capabilities of a General Firewall A.1. Example 1: Registration for the Capabilities of a General Firewall
This section shows a configuration example for the capabilities This section shows a configuration example for the capabilities
registration of a general firewall in either an IPv4 network or an registration of a general firewall in either an IPv4 network or an
IPv6 network. IPv6 network.
<nsf xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability"> <nsf xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability">
<nsf-name>general_firewall</nsf-name> <nsf-name>general_firewall</nsf-name>
<condition-capabilities> <condition-capabilities>
<generic-nsf-capabilities> <generic-nsf-capabilities>
<ipv4-capability>ipv4-protocol</ipv4-capability> <ipv4-capability>ipv4-protocol</ipv4-capability>
<ipv4-capability>exact-ipv4-address</ipv4-capability> <ipv4-capability>prefix-ipv4-address</ipv4-capability>
<ipv4-capability>range-ipv4-address</ipv4-capability> <ipv4-capability>range-ipv4-address</ipv4-capability>
<tcp-capability>exact-fourth-layer-port-num</tcp-capability> <tcp-capability>exact-tcp-port-num</tcp-capability>
<tcp-capability>range-fourth-layer-port-num</tcp-capability> <tcp-capability>range-tcp-port-num</tcp-capability>
<udp-capability>exact-udp-port-num</udp-capability>
<udp-capability>range-udp-port-num</udp-capability>
</generic-nsf-capabilities> </generic-nsf-capabilities>
</condition-capabilities> </condition-capabilities>
<action-capabilities> <action-capabilities>
<ingress-action-capability>pass</ingress-action-capability> <ingress-action-capability>pass</ingress-action-capability>
<ingress-action-capability>drop</ingress-action-capability> <ingress-action-capability>drop</ingress-action-capability>
<ingress-action-capability>alert</ingress-action-capability> <ingress-action-capability>alert</ingress-action-capability>
<egress-action-capability>pass</egress-action-capability> <egress-action-capability>pass</egress-action-capability>
<egress-action-capability>drop</egress-action-capability> <egress-action-capability>drop</egress-action-capability>
<egress-action-capability>alert</egress-action-capability> <egress-action-capability>alert</egress-action-capability>
</action-capabilities> </action-capabilities>
skipping to change at page 52, line 46 skipping to change at page 58, line 48
Figure 4: Configuration XML for the Capabilities Registration of a Figure 4: Configuration XML for the Capabilities Registration of a
General Firewall in an IPv4 Network General Firewall in an IPv4 Network
Figure 4 shows the configuration XML for the capabilities Figure 4 shows the configuration XML for the capabilities
registration of a general firewall as an NSF in an IPv4 network. Its registration of a general firewall as an NSF in an IPv4 network. Its
capabilities are as follows. capabilities are as follows.
1. The name of the NSF is general_firewall. 1. The name of the NSF is general_firewall.
2. The NSF can inspect a protocol, an exact IPv4 address, and a 2. The NSF can inspect a protocol, a prefix of IPv4 addresses, and a
range of IPv4 addresses for IPv4 packets. range of IPv4 addresses for IPv4 packets.
3. The NSF can inspect an exact port number and a range of port 3. The NSF can inspect an exact port number and a range of port
numbers for the fourth layer packets. numbers for the transport layer (TCP and UDP).
4. The NSF can control whether the packets are allowed to pass, 4. The NSF can control whether the packets are allowed to pass,
drop, or alert. drop, or alert.
<nsf xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability"> <nsf xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability">
<nsf-name>general_firewall</nsf-name> <nsf-name>general_firewall</nsf-name>
<condition-capabilities> <condition-capabilities>
<generic-nsf-capabilities> <generic-nsf-capabilities>
<ipv6-capability>ipv6-next-header</ipv6-capability> <ipv6-capability>ipv6-next-header</ipv6-capability>
<ipv6-capability>exact-ipv6-address</ipv6-capability> <ipv6-capability>prefix-ipv6-address</ipv6-capability>
<ipv6-capability>range-ipv6-address</ipv6-capability> <ipv6-capability>range-ipv6-address</ipv6-capability>
<tcp-capability>exact-fourth-layer-port-num</tcp-capability> <tcp-capability>exact-tcp-port-num</tcp-capability>
<tcp-capability>range-fourth-layer-port-num</tcp-capability> <tcp-capability>range-tcp-port-num</tcp-capability>
<udp-capability>exact-udp-port-num</udp-capability>
<udp-capability>range-udp-port-num</udp-capability>
</generic-nsf-capabilities> </generic-nsf-capabilities>
</condition-capabilities> </condition-capabilities>
<action-capabilities> <action-capabilities>
<ingress-action-capability>pass</ingress-action-capability> <ingress-action-capability>pass</ingress-action-capability>
<ingress-action-capability>drop</ingress-action-capability> <ingress-action-capability>drop</ingress-action-capability>
<ingress-action-capability>alert</ingress-action-capability> <ingress-action-capability>alert</ingress-action-capability>
<egress-action-capability>pass</egress-action-capability> <egress-action-capability>pass</egress-action-capability>
<egress-action-capability>drop</egress-action-capability> <egress-action-capability>drop</egress-action-capability>
<egress-action-capability>alert</egress-action-capability> <egress-action-capability>alert</egress-action-capability>
</action-capabilities> </action-capabilities>
skipping to change at page 53, line 38 skipping to change at page 59, line 43
Figure 5: Configuration XML for the Capabilities Registration of a Figure 5: Configuration XML for the Capabilities Registration of a
General Firewall in an IPv6 Network General Firewall in an IPv6 Network
In addition, Figure 5 shows the configuration XML for the In addition, Figure 5 shows the configuration XML for the
capabilities registration of a general firewall as an NSF in an IPv6 capabilities registration of a general firewall as an NSF in an IPv6
network. Its capabilities are as follows. network. Its capabilities are as follows.
1. The name of the NSF is general_firewall. 1. The name of the NSF is general_firewall.
2. The NSF can inspect a protocol (Next-Header), an exact IPv6 2. The NSF can inspect a protocol (Next-Header), a prefix of IPv6
address, and a range of IPv6 addresses for IPv6 packets. addresses, and a range of IPv6 addresses for IPv6 packets.
3. The NSF can inspect an exact port number and a range of port 3. The NSF can inspect an exact port number and a range of port
numbers for the fourth layer packets. numbers for the transport layer (TCP and UDP).
4. The NSF can control whether the packets are allowed to pass, 4. The NSF can control whether the packets are allowed to pass,
drop, or alert. drop, or alert.
A.2. Example 2: Registration for the Capabilities of a Time-based A.2. Example 2: Registration for the Capabilities of a Time-based
Firewall Firewall
This section shows a configuration example for the capabilities This section shows a configuration example for the capabilities
registration of a time-based firewall in either an IPv4 network or an registration of a time-based firewall in either an IPv4 network or an
IPv6 network. IPv6 network.
<nsf xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability"> <nsf xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability">
<nsf-name>time_based_firewall</nsf-name> <nsf-name>time_based_firewall</nsf-name>
<time-capabilities>absolute-time</time-capabilities> <time-capabilities>absolute-time</time-capabilities>
<time-capabilities>periodic-time</time-capabilities> <time-capabilities>periodic-time</time-capabilities>
<condition-capabilities> <condition-capabilities>
<generic-nsf-capabilities> <generic-nsf-capabilities>
<ipv4-capability>ipv4-next-header</ipv4-capability> <ipv4-capability>ipv4-protocol</ipv4-capability>
<ipv4-capability>exact-ipv4-address</ipv4-capability> <ipv4-capability>prefix-ipv4-address</ipv4-capability>
<ipv4-capability>range-ipv4-address</ipv4-capability> <ipv4-capability>range-ipv4-address</ipv4-capability>
</generic-nsf-capabilities> </generic-nsf-capabilities>
</condition-capabilities> </condition-capabilities>
<action-capabilities> <action-capabilities>
<ingress-action-capability>pass</ingress-action-capability> <ingress-action-capability>pass</ingress-action-capability>
<ingress-action-capability>drop</ingress-action-capability> <ingress-action-capability>drop</ingress-action-capability>
<ingress-action-capability>alert</ingress-action-capability> <ingress-action-capability>alert</ingress-action-capability>
<egress-action-capability>pass</egress-action-capability> <egress-action-capability>pass</egress-action-capability>
<egress-action-capability>drop</egress-action-capability> <egress-action-capability>drop</egress-action-capability>
<egress-action-capability>alert</egress-action-capability> <egress-action-capability>alert</egress-action-capability>
skipping to change at page 55, line 12 skipping to change at page 61, line 12
4. The NSF can control whether the packets are allowed to pass, 4. The NSF can control whether the packets are allowed to pass,
drop, or alert. drop, or alert.
<nsf xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability"> <nsf xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability">
<nsf-name>time_based_firewall</nsf-name> <nsf-name>time_based_firewall</nsf-name>
<time-capabilities>absolute-time</time-capabilities> <time-capabilities>absolute-time</time-capabilities>
<time-capabilities>periodic-time</time-capabilities> <time-capabilities>periodic-time</time-capabilities>
<condition-capabilities> <condition-capabilities>
<generic-nsf-capabilities> <generic-nsf-capabilities>
<ipv6-capability>ipv6-next-header</ipv6-capability> <ipv6-capability>ipv6-next-header</ipv6-capability>
<ipv6-capability>exact-ipv6-address</ipv6-capability> <ipv6-capability>prefix-ipv6-address</ipv6-capability>
<ipv6-capability>range-ipv6-address</ipv6-capability> <ipv6-capability>range-ipv6-address</ipv6-capability>
</generic-nsf-capabilities> </generic-nsf-capabilities>
</condition-capabilities> </condition-capabilities>
<action-capabilities> <action-capabilities>
<ingress-action-capability>pass</ingress-action-capability> <ingress-action-capability>pass</ingress-action-capability>
<ingress-action-capability>drop</ingress-action-capability> <ingress-action-capability>drop</ingress-action-capability>
<ingress-action-capability>alert</ingress-action-capability> <ingress-action-capability>alert</ingress-action-capability>
<egress-action-capability>pass</egress-action-capability> <egress-action-capability>pass</egress-action-capability>
<egress-action-capability>drop</egress-action-capability> <egress-action-capability>drop</egress-action-capability>
<egress-action-capability>alert</egress-action-capability> <egress-action-capability>alert</egress-action-capability>
skipping to change at page 56, line 31 skipping to change at page 62, line 31
Figure 8: Configuration XML for the Capabilities Registration of a Figure 8: Configuration XML for the Capabilities Registration of a
Web Filter Web Filter
Figure 8 shows the configuration XML for the capabilities Figure 8 shows the configuration XML for the capabilities
registration of a web filter as an NSF. Its capabilities are as registration of a web filter as an NSF. Its capabilities are as
follows. follows.
1. The name of the NSF is web_filter. 1. The name of the NSF is web_filter.
2. The NSF can inspect URL matched from a user-defined URL Database. 2. The NSF can inspect a URL matched from a user-defined URL
User can add a new URL into the database. Database. User can add the new URL to the database.
3. The NSF can control whether the packets are allowed to pass, 3. The NSF can control whether the packets are allowed to pass,
drop, or alert. drop, or alert.
A.4. Example 4: Registration for the Capabilities of a VoIP/VoLTE A.4. Example 4: Registration for the Capabilities of a VoIP/VoLTE
Filter Filter
This section shows a configuration example for the capabilities This section shows a configuration example for the capabilities
registration of a VoIP/VoLTE filter. registration of a VoIP/VoLTE filter.
<nsf xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability"> <nsf xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability">
<nsf-name>voip_volte_filter</nsf-name> <nsf-name>voip_volte_filter</nsf-name>
<condition-capabilities> <condition-capabilities>
<advanced-nsf-capabilities> <advanced-nsf-capabilities>
<voip-volte-capability>voice-id</voip-volte-capability> <voip-volte-capability>voip-volte-call-id</voip-volte-capability>
</advanced-nsf-capabilities> </advanced-nsf-capabilities>
</condition-capabilities> </condition-capabilities>
<action-capabilities> <action-capabilities>
<ingress-action-capability>pass</ingress-action-capability> <ingress-action-capability>pass</ingress-action-capability>
<ingress-action-capability>drop</ingress-action-capability> <ingress-action-capability>drop</ingress-action-capability>
<ingress-action-capability>alert</ingress-action-capability> <ingress-action-capability>alert</ingress-action-capability>
<egress-action-capability>pass</egress-action-capability> <egress-action-capability>pass</egress-action-capability>
<egress-action-capability>drop</egress-action-capability> <egress-action-capability>drop</egress-action-capability>
<egress-action-capability>alert</egress-action-capability> <egress-action-capability>alert</egress-action-capability>
</action-capabilities> </action-capabilities>
skipping to change at page 57, line 31 skipping to change at page 63, line 31
Figure 9: Configuration XML for the Capabilities Registration of a Figure 9: Configuration XML for the Capabilities Registration of a
VoIP/VoLTE Filter VoIP/VoLTE Filter
Figure 9 shows the configuration XML for the capabilities Figure 9 shows the configuration XML for the capabilities
registration of a VoIP/VoLTE filter as an NSF. Its capabilities are registration of a VoIP/VoLTE filter as an NSF. Its capabilities are
as follows. as follows.
1. The name of the NSF is voip_volte_filter. 1. The name of the NSF is voip_volte_filter.
2. The NSF can inspect a voice id for VoIP/VoLTE packets. 2. The NSF can inspect a voice call id for VoIP/VoLTE packets.
3. The NSF can control whether the packets are allowed to pass, 3. The NSF can control whether the packets are allowed to pass,
drop, or alert. drop, or alert.
A.5. Example 5: Registration for the Capabilities of a HTTP and HTTPS A.5. Example 5: Registration for the Capabilities of a HTTP and HTTPS
Flood Mitigator Flood Mitigator
This section shows a configuration example for the capabilities This section shows a configuration example for the capabilities
registration of a HTTP and HTTPS flood mitigator. registration of a HTTP and HTTPS flood mitigator.
 End of changes. 257 change blocks. 
1559 lines changed or deleted 1842 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/