draft-ietf-i2nsf-capability-data-model-02.txt   draft-ietf-i2nsf-capability-data-model-03.txt 
I2NSF Working Group S. Hares I2NSF Working Group S. Hares
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track J. Jeong Intended status: Standards Track J. Jeong
Expires: May 8, 2019 J. Kim Expires: September 12, 2019 J. Kim
Sungkyunkwan University Sungkyunkwan University
R. Moskowitz R. Moskowitz
HTT Consulting HTT Consulting
Q. Lin Q. Lin
Huawei Huawei
November 4, 2018 March 11, 2019
I2NSF Capability YANG Data Model I2NSF Capability YANG Data Model
draft-ietf-i2nsf-capability-data-model-02 draft-ietf-i2nsf-capability-data-model-03
Abstract Abstract
This document defines a YANG data model for capabilities that enable This document defines a YANG data model for capabilities of various
a user to control various Network Security Functions (NSFs) in the Network Security Functions (NSFs) in Interface to Network Security
framework for Interface to Network Security Functions (I2NSF). Functions (I2NSF) framework to cetrally manage capabilities of varios
NSFs.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 8, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. The Structure and Objective of NSF Capabilities . . . . . . . 6 5. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Generic Network Security Function Identification . . . . 6 5.1. Capabilities of Network Security Function . . . . . . . . 6
5.2. Event Capabilities . . . . . . . . . . . . . . . . . . . 6 6. YANG Data Modules . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Condition Capabilities . . . . . . . . . . . . . . . . . 7 6.1. I2NSF Capability YANG Data Module . . . . . . . . . . . . 9
5.4. Action Capabilities . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
5.5. Resolution Strategy Capabilities . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 37
5.6. Default Action Capabilities . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.7. RPC for Acquiring Appropriate Network Security Function . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 37
6. Data Model Structure . . . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 39
6.1. Network Security Function Identification . . . . . . . . 8 Appendix A. Changes from draft-ietf-i2nsf-capability-data-
6.2. Capabilities of Generic Network Security Function . . . . 9 model-02 . . . . . . . . . . . . . . . . . . . . . . 40
6.2.1. Event Capabilities . . . . . . . . . . . . . . . . . 10 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 40
6.2.2. Condition Capabilities . . . . . . . . . . . . . . . 12 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 40
6.2.3. Action Capabilities . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
6.2.4. Resolution Strategy Capabilities . . . . . . . . . . 16
6.2.5. Capabilities of Advanced Network Security Function . 16
6.2.6. Content Security Capabilities . . . . . . . . . . . . 17
6.2.7. Attack Mitigation Capabilities . . . . . . . . . . . 18
6.2.8. RPC for Acquiring Appropriate Network Security
Function . . . . . . . . . . . . . . . . . . . . . . 19
7. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. I2NSF Capability YANG Data Module . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57
9. Security Considerations . . . . . . . . . . . . . . . . . . . 57
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 57
10.1. Normative References . . . . . . . . . . . . . . . . . . 57
10.2. Informative References . . . . . . . . . . . . . . . . . 57
Appendix A. Example: Extended VoIP-VoLTE Security Function
Capabilities Module . . . . . . . . . . . . . . . . 59
Appendix B. Example: Configuration XML of Capability Module . . 60
B.1. Example: Configuration XML of Generic Network Security
Function Capabilities . . . . . . . . . . . . . . . . . . 60
B.2. Example: Configuration XML of Extended VoIP/VoLTE
Security Function Capabilities Module . . . . . . . . . . 62
Appendix C. Changes from draft-ietf-i2nsf-capability-data-
model-01 . . . . . . . . . . . . . . . . . . . . . . 63
Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 64
Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64
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 VoIP/VoLTE Internet of Things, Self-driving vehicles, and VoIP/VoLTE
smartphones), service providers have a lot of problems mentioned in smartphones), service providers have a lot of problems mentioned in
[RFC8192]. To resolve these problems, [i2nsf-nsf-cap-im] specifies [RFC8192]. To resolve these problems, [i2nsf-nsf-cap-im] specifies
the information model of the capabilities of Network Security the information model of the capabilities of Network Security
Functions (NSFs). Functions (NSFs).
This document provides a data model using YANG [RFC6020][RFC7950] This document provides a data model using YANG [RFC6020][RFC7950]
that defines the capabilities of NSFs to express capabilities of that defines the capabilities of NSFs to centrally manage
those security devices. This YANG data model is based on the capabilities of those security devices. The security devices can
information model for I2NSF NSF capabilities [i2nsf-nsf-cap-im]. The register their own capabilities into Network Operator Management
security devices can register their own capabilities into Network (Mgmt) System (i.e., Security Controller) with this YANG data model
Operator Management (Mgmt) System (i.e., Security Controller) with through the registration interface [RFC8329]. With the capabilities
this YANG data model through the registration interface [RFC8329]. of those security devices registered centrally, those security
After the capabilities of the NSFs are registered, this YANG data devices can be easily managed [RFC8329]. This YANG data model is
model can be used by the IN2SF user or Service Function Forwarder based on the information model for I2NSF NSF capabilities
(SFF) [i2nsf-sfc] to acquire appropriate NSFs that can be controlled [i2nsf-nsf-cap-im].
by the Network Operator Mgmt System.
The "Event-Condition-Action" (ECA) policy model is used as the basis This YANG data model uses an "Event-Condition-Action" (ECA) policy
for the design of I2NSF Policy Rules. The "ietf-i2nsf-capability" model that is used as the basis for the design of I2NSF Policy
YANG module defined in this document provides the following features: described in [RFC8329] and [i2nsf-nsf-cap-im]. Rules. The "ietf-
i2nsf-capability" YANG module defined in this document provides the
following features:
o Configuration of identification for generic network security o Definition for general capabilities of network security functions.
function policy
o Configuration of event capabilities for generic network security o Definition for event capabilities of generic network security
function policy function.
o Configuration of condition capabilities for generic network o Definition for condition capabilities of generic network security
security function policy function.
o Configuration of action capabilities for generic network security o Definition for condition capabilities of advanced network security
function policy function.
o Configuration of strategy capabilities for generic network o Definition for action capabilities of generic network security
security function policy function.
o Configuration of default action capabilities for generic network o Definition for resolution strategy capabilities of generic network
security function policy security function.
o RPC for acquiring appropriate network security function according o Definition for default action capabilities of generic network
to type of NSF and/or target devices. security function.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119][RFC8174].
3. Terminology 3. Terminology
This document uses the terminology described in This document uses the terminology described in
[i2nsf-terminology][i2nsf-nsf-cap-im] [i2nsf-terminology][i2nsf-nsf-cap-im]
[RFC8431][supa-policy-info-model]. Especially, the following terms [RFC8431][supa-policy-info-model]. Especially, the following terms
are from [supa-policy-info-model]: are from [supa-policy-info-model]:
o Data Model: A data model is a representation of concepts of o Data Model: A data model is a representation of concepts of
interest to an environment in a form that is dependent on data interest to an environment in a form that is dependent on data
skipping to change at page 4, line 35 skipping to change at page 4, line 9
o Information Model: An information model is a representation of o Information Model: An information model is a representation of
concepts of interest to an environment in a form that is concepts of interest to an environment in a form that is
independent of data repository, data definition language, query independent of data repository, data definition language, query
language, implementation language, and protocol. language, implementation language, and protocol.
3.1. Tree Diagrams 3.1. Tree Diagrams
A simplified graphical representation of the data model is used in A simplified graphical representation of the data model is used in
this document. The meaning of the symbols in these diagrams this document. The meaning of the symbols in these diagrams
[RFC8431] is as follows: [RFC8340] is as follows:
o Brackets "[" and "]" enclose list keys. o Brackets "[" and "]" enclose list keys.
o Abbreviations before data node names: "rw" means configuration o Abbreviations before data node names: "rw" means configuration
(read-write) and "ro" state data (read-only). (read-write) and "ro" state data (read-only).
o Symbols after data node names: "?" means an optional node and "*" o Symbols after data node names: "?" means an optional node and "*"
denotes a "list" and "leaf-list". denotes a "list" and "leaf-list".
o Parentheses enclose choice and case nodes, and case nodes are also o Parentheses enclose choice and case nodes, and case nodes are also
marked with a colon (":"). marked with a colon (":").
o Ellipsis ("...") stands for contents of subtrees that are not o Ellipsis ("...") stands for contents of subtrees that are not
shown. shown.
4. Overview 4. Overview
This section explains overview how the YANG data model can be used by This section explains overview how the YANG data model can be used in
I2NSF User, Developer's Mgmt System, and SFF. Figure 1 shows I2NSF framework described in [RFC8329]. Figure 1 shows capabilities
capabilities of NSFs in I2NSF Framework. As shown in this figure, of NSFs in I2NSF Framework. As shown in this figure, Developer's
Developer's Mgmt System can register NSFs with capabilities that the Mgmt System can register NSFs with capabilities that the network
device can support. To register NSFs in this way, the Developer's security device can support. To register NSFs in this way, the
Mgmt System utilizes this standardized capabilities YANG data model Developer's Mgmt System utilizes this standardized capabilities YANG
through registration interface. Through this registration of data model through registration interface. With the capabilities of
capabilities, the a lot of problems [RFC8192] can be resolved. The those network security devices registered centrally, those security
following shows use cases. devices can be easily managed, which can resolve the a lot of
problems described in [RFC8192]. The following shows use cases.
Note [i2nsf-nsf-yang] is used to configure rules of NSFs in I2NSF Note [i2nsf-nsf-yang] is used to configure security policy rules of
Framework. generic network security functions and [i2nsf-advanced-nsf-dm] is
used to configure security policy rules of advanced network security
functions according to the capabilities of network security devices
registed in 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.) |
+--------------------+----------------------------------+ +--------------------+----------------------------------+
| |
Consumer-Facing Interface | Consumer-Facing Interface |
| |
| I2NSF | I2NSF
+-----------------+------------+ Registration +-------------+ +-----------------+------------+ Registration +-------------+
skipping to change at page 5, line 51 skipping to change at page 5, line 36
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+
NSF-1 NSF-m NSF-1 NSF-n NSF-1 NSF-m NSF-1 NSF-n
E = {} E = {user} E = {dev} E = {time} E = {} E = {user} E = {dev} E = {time}
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 Mgmt System A Developer Mgmt System B Developer Mgmt System A Developer Mgmt System B
Figure 1: Capabilities of NSFs in I2NSF Framework Figure 1: Capabilities of NSFs in I2NSF Framework
o If I2NSF User wants to apply rules about blocking malicious users, o If network manager wants to apply security policy rules about
it is a tremendous burden to apply all of these rules to NSFs one blocking malicious users, it is a tremendous burden to apply all
by one. This problem can be resolved by standardizing the of these rules to NSFs one by one. This problem can be resolved
capabilities of NSFs. If I2NSF User wants to block malicious by managing the capabilities of NSFs. If network manager wants to
users with IPv6, I2NSF User sends the rules about blocking the block malicious users with IPv6, network manager sends the
users to Network Operator Mgmt System. When the Network Operator security policy rules about blocking the users to Network Operator
Mgmt System receives the rules, it sends that rules to appropriate Mgmt System using I2NSF user (i.e., a web browser or a software).
NSFs (i.e., NSF-m in Developer Mgmt System A and NSF-1 in When the Network Operator Mgmt System receives the security policy
Developer Mgmt System B) which can support the capabilities (i.e., rules, it automatically sends that security policy rules to
IPv6). Therefore, I2NSF User need not consider NSFs where to appropriate NSFs (i.e., NSF-m in Developer Mgmt System A and NSF-1
apply the rules. in Developer Mgmt System B) which can support the capabilities
(i.e., IPv6). Therefore, I2NSF User need not consider NSFs where
to apply the rules.
o If NSFs find the malicious packets, it is a tremendous burden for o If NSFs find the malicious packets, it is a tremendous burden for
I2NSF User to apply the rule about blocking the malicious packets network manager to apply the rule about blocking the malicious
to NSFs one by one. This problem can be resolved by standardizing packets to NSFs one by one. This problem can be resolved by
the capabilities of NSFs. If NSFs find the malicious packets with managing the capabilities of NSFs. If NSFs find the suspicious
IPv4, they can ask the Network Operator Mgmt System to alter packets with IPv4, they can ask the Network Operator Mgmt System
for information about the suspicious packets with IPv4. to alter
specific rules and/or configurations. When the Network Operator specific rules and/or configurations. When the Network Operator
Mgmt System receives the rules for malicious packets, it inspects Mgmt System receives information, it inspects the information
whether the rules are reasonable and sends the rules to about the suspicious packets with IPv4. If the suspicious packets
appropriate NSFs (i.e., NSF-1 in Developer Mgmt System A and NSF-1 are determined to be malicious packets, the Network Operator Mgmt
and NSF-n in Developer Mgmt System B) which can support the System creates and sends the security policy rule against
capabilities (i.e., IPv4). Therefore, the new rules can be malicious packets to appropriate NSFs (i.e., NSF-1 in Developer
applied to appropriate NSFs without control of I2NSF USer. Mgmt System A and NSF-1 and NSF-n in Developer Mgmt System B)
which can support the capabilities (i.e., IPv4). Therefore, the
o If NSFs of Service Function Chaining (SFC) [i2nsf-sfc] fail, it is new security policy rule against malicious packets can be applied
a tremendous burden for I2NSF User to reconfigure the policy of to appropriate NSFs without intervention of humans.
SFC immediately. This problem can be resolved by periodically
acquiring information of appropriate NSFs of SFC. If SFF needs
information of Web Application Firewall for SFC, it can ask the
Network Operator Mgmt System to acquire the location information
of appropriate Web Application Firewall. When the Network
Operator Mgmt System receives requested information from SFF, it
sends location information of Web Application Firewall to the SFF.
Therefore, the policy about the NSFs of SFC can be periodically
updated without control of I2NSF USer.
5. The Structure and Objective of NSF Capabilities
5.1. Generic Network Security Function Identification
This shows a identification for generic network security functions.
These objects are defined as location information and target device
information.
5.2. Event Capabilities
This shows a event capabilities for generic network security
functions policy. This is used to specify capabilities about any
important occurrence in time of a change in the system being managed,
and/or in the environment of the system being managed. When used in
the context of I2NSF Policy Rules, it is used to determine whether
the Condition clause of the I2NSF Policy Rule can be evaluated or
not. These object of event capabilities is defined as user security
event capabilities, device security event capabilities, system
security event capabilities, and time security event capabilities.
These object of event capabilities can be extended according to
specific vendor event features.
5.3. Condition Capabilities
This shows a condition capabilities for generic network security
functions policy. This is used to specify capabilities about a set
of attributes, features, and/or values that are to be compared with a
set of known attributes, features, and/or values in order to
determine whether or not the set of Actions in that (imperative)
I2NSF Policy Rule can be executed or not. These object of condition
capabilities is defined as packet security condition capabilities,
packet payload security condition capabilities, target security
condition capabilities, user security condition capabilities, context
condition capabilities, and generic context condition capabilities.
These object of condition capabilities can be extended according to
specific vendor condition features.
5.4. Action Capabilities
This shows a action capabilities for generic network security
functions policy. This is used to specify capabilities to control
and monitor aspects of flow-based NSFs when the event and condition
clauses are satisfied. NSFs provide security functions by executing
various Actions. These object of action capabilities is defined as
ingress action capabilities, egress action capabilities, and apply
profile action capabilities. These object of action capabilities can
be extended according to specific vendor action features.
5.5. Resolution Strategy Capabilities
This shows a resolution strategy capabilities for generic network
security functions policy. This can be used to specify capabilities
how to resolve conflicts that occur between the actions of the same
or different policy rules that are matched and contained in this
particular NSF. These objects are defined as first-matching-rule
capability and last-matching-rule capability. These objects can be
extended according to specific vendor resolution strategy features.
5.6. Default Action Capabilities
This shows a default action policy for generic network security
functions. This can be used to specify capabilities about a
predefined action when no other alternative action was matched by the
currently executing I2NSF Policy Rule.
5.7. RPC for Acquiring Appropriate Network Security Function
This shows a RPC for acquiring an appropriate network security
function according to type of NSF and/or target devices. If the SFF
[i2nsf-sfc]does not have the location information of network security
functions that it should send in own cache table, this can be used to
acquire the information. These objects are defined as input data
(i.e., NSF type and target devices) and output data (i.e., location
information of NSF).
6. Data Model Structure 5. YANG Tree Diagram
This section shows an overview of a structure tree of capabilities This section shows an YANG tree diagram of capabilities for network
for generic network security functions, as defined in the security functions, as defined in the [i2nsf-nsf-cap-im].
[i2nsf-nsf-cap-im].
6.1. Network Security Function Identification 5.1. Capabilities of Network Security Function
The data model for network security function identification has the This section shows YANG tree diagram for capabilities of network
following structure: security functions.
module: ietf-i2nsf-capability module: ietf-i2nsf-capability
+--rw nsf* [nsf-name] +--rw nsf
+--rw nsf-name string +--rw time-capabilities* enumeration
+--rw nsf-type? nsf-type +--rw event-capabilities
+--rw nsf-address | +--rw system-event-capa* identityref
| +--rw (nsf-address-type)? | +--rw system-alarm-capa* identityref
| +--:(ipv4-address) +--rw condition-capabilities
| | +--rw ipv4-address inet:ipv4-address | +--rw generic-nsf-capabilities
| +--:(ipv6-address) | | +--rw ipv4-capa* identityref
| +--rw ipv6-address inet:ipv6-address | | +--rw ipv6-capa* identityref
+--rw target-device | | +--rw tcp-capa* identityref
| +--rw pc? boolean | | +--rw udp-capa* identityref
| +--rw mobile-phone? boolean | | +--rw icmp-capa* identityref
| +--rw voip-volte-phone? boolean | +--rw advanced-nsf-capabilities
| +--rw tablet? boolean | +--rw antivirus-capa* identityref
| +--rw iot? boolean | +--rw antiddos-capa* identityref
| +--rw vehicle? boolean | +--rw ips-capa* identityref
+--rw generic-nsf-capabilities | +--rw http-capa* identityref
| +--rw net-sec-capabilities | +--rw voip-volte-capa* identityref
| uses net-sec-caps +--rw action-capabilities
+--rw advanced-nsf-capabilities | +--rw ingress-action-capa* identityref
| +--rw advaneced-sec-capabilities | +--rw egress-action-capa* identityref
| uses advaneced-sec-caps | +--rw log-action-capa* identityref
+--rw complete-nsf-capabilities +--rw resolution-strategy-capabilities* identityref
+--rw con-sec-control-capabilities +--rw default-action-capabilities* identityref
| uses i2nsf-con-sec-control-caps
+--rw attack-mitigation-capabilities
uses i2nsf-attack-mitigation-control-caps
Figure 2: Data Model Structure for NSF-Identification
This document also utilizes a formal model for policy reconciliation
proposed by Basile et al. [Policy-Reconciliation], which handles
conflict resolution, the use of external data, and target device.
The nsf-type object can be used for configuration about type of a
NSF. The types of NSF consists of Network Firewall, Web Application
Firewall, Anti-Virus, IDS, IPS, and DDoS Mitigator. The nsf-address
object can be used for configuration about location of a NSF. The
target-device object can be used for configuration about target
devices. We will add additional type of a NSF for more generic
network security functions.
6.2. Capabilities of Generic Network Security Function
The data model for Generic NSF capabilities has the following
structure:
+--rw generic-nsf-capabilities
+--rw net-sec-capabilities
uses i2nsf-net-sec-caps
Figure 3: Data Model Structure for Capabilities of Network Security
Function
6.2.1. Event Capabilities
The data model for event capabilities has the following structure:
+--rw i2nsf-net-sec-caps
+--rw net-sec-capabilities
+--rw time
| +--rw time-zone
| | +--rw time-zone-offset? boolean
| +--rw time-inteval
| +--rw absolute-time-inteval
| | +--rw start-time? boolean
| | +--rw end-time? boolean
| +--rw periodic-time-inteval
| +--rw day? boolean
| +--rw month? boolean
+--rw event
| +--rw usr-event
| | +--rw usr-sec-event-content? boolean
| | +--rw usr-sec-event-format
| | | +--rw unknown? boolean
| | | +--rw guid? boolean
| | | +--rw uuid? boolean
| | | +--rw uri? boolean
| | | +--rw fqdn? boolean
| | | +--rw fqpn? boolean
| | +--rw usr-sec-event-type
| | +--rw unknown? boolean
| | +--rw user-created? boolean
| | +--rw user-grp-created? boolean
| | +--rw user-deleted? boolean
| | +--rw user-grp-deleted? boolean
| | +--rw user-logon? boolean
| | +--rw user-logoff? boolean
| | +--rw user-access-request? boolean
| | +--rw user-access-granted? boolean
| | +--rw user-access-violation? boolean
| +--rw dev-event
| | +--rw dev-sec-event-content boolean
| | +--rw dev-sec-event-format
| | | +--rw unknown? boolean
| | | +--rw guid? boolean
| | | +--rw uuid? boolean
| | | +--rw uri? boolean
| | | +--rw fqdn? boolean
| | | +--rw fqpn? boolean
| | +--rw dev-sec-event-type
| | | +--rw unknown? boolean
| | | +--rw comm-alarm? boolean
| | | +--rw quality-of-service-alarm? boolean
| | | +--rw process-err-alarm? boolean
| | | +--rw equipment-err-alarm? boolean
| | | +--rw environmental-err-alarm? boolean
| | +--rw dev-sec-event-type-severity
| | +--rw unknown? boolean
| | +--rw cleared? boolean
| | +--rw indeterminate? boolean
| | +--rw critical? boolean
| | +--rw major? boolean
| | +--rw minor? boolean
| | +--rw warning? boolean
| +--rw sys-event
| | +--rw sys-sec-event-content? boolean
| | +--rw sys-sec-event-format
| | | +--rw unknown? boolean
| | | +--rw guid? boolean
| | | +--rw uuid? boolean
| | | +--rw uri? boolean
| | | +--rw fqdn? boolean
| | | +--rw fqpn? boolean
| | +--rw sys-sec-event-type
| | +--rw unknown? boolean
| | +--rw audit-log-written-to? boolean
| | +--rw audit-log-cleared? boolean
| | +--rw policy-created? boolean
| | +--rw policy-edited? boolean
| | +--rw policy-deleted? boolean
| | +--rw policy-executed? boolean
| +--rw time-event
| +--rw time-sec-event-begin? boolean
| +--rw time-sec-event-end? boolean
| +--rw time-sec-event-time-zone? boolean
+--rw condition
| ...
+--rw action
| ...
+--rw resolution-strategy
...
Figure 4: Data Model Structure for Event Capabilities of Network
Security Function
These objects are defined as capabilities of user security event,
device security event, system security event, and time security
event. These objects can be extended according to specific vendor
event features. We will add additional event objects for more
generic network security functions.
6.2.2. Condition Capabilities
The data model for condition capabilities has the following
structure:
+--rw i2nsf-net-sec-caps
+--rw net-sec-capabilities
+--rw time
| +--rw time-zone
| | +--rw time-zone-offset? boolean
| +--rw time-inteval
| +--rw absolute-time-inteval
| | +--rw start-time? boolean
| | +--rw end-time? boolean
| +--rw periodic-time-inteval
| +--rw day? boolean
| +--rw month? boolean
+--rw event
| ...
+--rw condition
| +--rw packet-security-condition
| | +--rw packet-security-mac-condition
| | | +--rw pkt-sec-cond-mac-dest? boolean
| | | +--rw pkt-sec-cond-mac-src? boolean
| | | +--rw pkt-sec-cond-mac-8021q? boolean
| | | +--rw pkt-sec-cond-mac-ether-type? boolean
| | | +--rw pkt-sec-cond-mac-tci? string
| | +--rw packet-security-ipv4-condition
| | | +--rw pkt-sec-cond-ipv4-header-length? boolean
| | | +--rw pkt-sec-cond-ipv4-tos? boolean
| | | +--rw pkt-sec-cond-ipv4-total-length? boolean
| | | +--rw pkt-sec-cond-ipv4-id? boolean
| | | +--rw pkt-sec-cond-ipv4-fragment? boolean
| | | +--rw pkt-sec-cond-ipv4-fragment-offset? boolean
| | | +--rw pkt-sec-cond-ipv4-ttl? boolean
| | | +--rw pkt-sec-cond-ipv4-protocol? boolean
| | | +--rw pkt-sec-cond-ipv4-src? boolean
| | | +--rw pkt-sec-cond-ipv4-dest? boolean
| | | +--rw pkt-sec-cond-ipv4-ipopts? boolean
| | | +--rw pkt-sec-cond-ipv4-sameip? boolean
| | | +--rw pkt-sec-cond-ipv4-geoip? boolean
| | +--rw packet-security-ipv6-condition
| | | +--rw pkt-sec-cond-ipv6-dscp? boolean
| | | +--rw pkt-sec-cond-ipv6-ecn? boolean
| | | +--rw pkt-sec-cond-ipv6-traffic-class? boolean
| | | +--rw pkt-sec-cond-ipv6-flow-label? boolean
| | | +--rw pkt-sec-cond-ipv6-payload-length? boolean
| | | +--rw pkt-sec-cond-ipv6-next-header? boolean
| | | +--rw pkt-sec-cond-ipv6-hop-limit? boolean
| | | +--rw pkt-sec-cond-ipv6-src? boolean
| | | +--rw pkt-sec-cond-ipv6-dest? boolean
| | +--rw packet-security-tcp-condition
| | | +--rw pkt-sec-cond-tcp-src-port? boolean
| | | +--rw pkt-sec-cond-tcp-dest-port? boolean
| | | +--rw pkt-sec-cond-tcp-seq-num? boolean
| | | +--rw pkt-sec-cond-tcp-ack-num? boolean
| | | +--rw pkt-sec-cond-tcp-window-size? boolean
| | | +--rw pkt-sec-cond-tcp-flags? boolean
| | +--rw packet-security-udp-condition
| | | +--rw pkt-sec-cond-udp-src-port? boolean
| | | +--rw pkt-sec-cond-udp-dest-port? boolean
| | | +--rw pkt-sec-cond-udp-length? boolean
| | +--rw packet-security-icmp-condition
| | +--rw pkt-sec-cond-icmp-type? boolean
| | +--rw pkt-sec-cond-icmp-code? boolean
| | +--rw pkt-sec-cond-icmp-seg-num? boolean
| +--rw packet-payload-condition
| | +--rw pkt-payload-content? boolean
| +--rw acl-number? boolean
| +--rw application-condition
| | +--rw application-object? boolean
| | +--rw application-group? boolean
| | +--rw application-label? boolean
| | +--rw category
| | +--rw application-category? boolean
| +--rw target-condition
| | +--rw device-sec-context-cond? boolean
| +--rw users-condition
| | +--rw user
| | | +--rw (user-name)?
| | | +--:(tenant)
| | | | +--rw tenant? boolean
| | | +--:(vn-id)
| | | +--rw vn-id? boolean
| | +--rw group
| | +--rw (group-name)?
| | | +--:(tenant)
| | | | +--rw tenant? boolean
| | | +--:(vn-id)
| | | +--rw vn-id? boolean
| | +--rw security-grup boolean
| +--rw url-category-condition
| | +--rw pre-defined-category? boolean
| | +--rw user-defined-category? boolean
| +--rw context-condition
| | +--rw temp? string
| +--rw gen-context-condition
| +--rw geographic-location
| +--rw src-geographic-location? boolean
| +--rw dest-geographic-location? boolean
+--rw action
| ...
+--rw resolution-strategy
...
Figure 5: Data Model Structure for Condition Capabilities of Network
Security Function
These objects are defined as capabilities of packet security
condition, packet payload security condition, target security
condition, user security condition, context condition, and generic
context condition. These objects can be extended according to
specific vendor condition features. We will add additional condition
objects for more generic network security functions.
6.2.3. Action Capabilities
The data model for action capabilities has the following structure:
+--rw i2nsf-net-sec-caps
+--rw net-sec-capabilities
+--rw time
| +--rw time-zone
| | +--rw time-zone-offset? boolean
| +--rw time-inteval
| +--rw absolute-time-inteval
| | +--rw start-time? boolean
| | +--rw end-time? boolean
| +--rw periodic-time-inteval
| +--rw day? boolean
| +--rw month? boolean
+--rw event
| ...
+--rw condition
| ...
+--rw action
| +--rw rule-log? boolean
| +--rw session-log? boolean
| +--rw ingress-action
| | +--rw ingress-action-type
| | +--rw pass? boolean
| | +--rw drop? boolean
| | +--rw reject? boolean
| | +--rw alert? boolean
| | +--rw mirror? boolean
| +--rw egress-action
| +--rw egress-action-type
| +--rw invoke-signaling? boolean
| +--rw tunnel-encapsulation? boolean
| +--rw forwarding? boolean
| +--rw redirection? boolean
+--rw resolution-strategy
...
Figure 6: Data Model Structure for Action Capabilities of Network
Security Function
These objects are defined capabilities as ingress action, egress
action, and apply profile action. These objects can be extended
according to specific vendor action feature. We will add additional
action objects for more generic network security functions.
6.2.4. Resolution Strategy Capabilities
The data model for resolution strategy capabilities has the following
structure:
+--rw i2nsf-net-sec-caps
+--rw net-sec-capabilities
+--rw time
| +--rw time-zone
| | +--rw time-zone-offset? boolean
| +--rw time-inteval
| +--rw absolute-time-inteval
| | +--rw start-time? boolean
| | +--rw end-time? boolean
| +--rw periodic-time-inteval
| +--rw day? boolean
| +--rw month? boolean
+--rw event
| ...
+--rw condition
| ...
+--rw action
| ...
+--rw resolution-strategy
+--rw first-matching-rule? boolean
+--rw last-matching-rule? boolean
Figure 7: Data Model Structure for Resolution Strategy Capabilities Figure 2: YANG Tree Diagram for Capabilities of Network Security
of Network Security Function Functions
These objects are defined capabilities as first-matching-rule and This YANG tree diagram shows capabilities of network security
last-matching-rule. These objects can be extended according to
specific vendor resolution strategy features. We will add additional
resolution strategy objects for more generic network security
functions. functions.
6.2.5. Capabilities of Advanced Network Security Function The NSF includes NSF capabilities. The NSF capabilities include time
capabilities, event capabilities, condition capabilities, action
The data model for advanced NSF capabilities has the following capabilities, resolution strategy capabilities, and default action
structure: capabilities.
+--rw advanced-nsf-capabilities
| +--rw advanced-sec-capabilities
| +--rw antivirus
| | +--rw detect? boolean
| | +--rw exception-application? boolean
| | +--rw exception-signature? boolean
| | +--rw whitelists? boolean
| +--rw antiddos
| | +--rw syn-flood-action? boolean
| | +--rw udp-flood-action? boolean
| | +--rw http-flood-action? boolean
| | +--rw https-flood-action? boolean
| | +--rw dns-request-flood-action? boolean
| | +--rw dns-reply-flood-action? boolean
| | +--rw icmp-flood-action? boolean
| | +--rw sip-flood-action? boolean
| | +--rw detect-mode? boolean
| | +--rw baseline-learn? boolean
| +--rw ips
| +--rw signature-set? boolean
| +--rw exception-signature? boolean
...
Figure 8: Data Model Structure for Capabilities of Advanced Network
Security Function
These objects are defined capabilities of advanced network security
functions such as antivirus, antiddos, and ips. A detailed data
model for the configuration of the advanced network security
functions is described in [i2nsf-advanced-nsf-dm].
6.2.6. Content Security Capabilities
The data model for content security capabilities has the following
structure:
+--rw complete-nsf-capabilities
+--rw con-sec-control-capabilities
| +--rw anti-virus? boolean
| +--rw ips? boolean
| +--rw ids? boolean
| +--rw url-filter? boolean
| +--rw data-filter? boolean
| +--rw mail-filter? boolean
| +--rw sql-filter? boolean
| +--rw file-blocking? boolean
| +--rw file-isolate? boolean
| +--rw pkt-capture? boolean
| +--rw application-behavior? boolean
| +--rw voip-volte? boolean
+--rw attack-mitigation-capabilities
...
Figure 9: Data Model Structure for Content Security Capabilities of
Network Security Function
Content security is composed of a number of distinct security Time capabilities are used to specify capabilities when to execute
Capabilities; each such Capability protects against a specific type the I2NSF policy rule. The time capabilities are defined as absolute
of threat in the application layer. Content security is a type of time and periodic time.
Generic Network Security Function (GNSF), which summarizes a well-
defined set of security Capabilities.
6.2.7. Attack Mitigation Capabilities Event capabilities are used to specify capabilities how to trigger
the evaluation of the condition clause of the I2NSF Policy Rule. The
event capabilities are defined as system event and system alarm. The
event capability can be extended according to specific vendor
condition features. The event capability is described in detail in
[i2nsf-nsf-cap-im].
The data model for attack mitigation capabilities has the following Condition capabilities are used to specify capabilities of a set of
structure: attributes, features, and/or values that are to be compared with a
set of known attributes, features, and/or values in order to
determine whether or not the set of actions in that (imperative)
I2NSF policy rule can be executed or not. The condition capability
is classified as condition capabilities of generic network security
functions and advanced network security functions. The condition
capabilities of generic network security functions are defined as
IPv4 capability, IPv6 capability, tcp capability, udp capability, and
icmp capability. The condition capabilities of advanced network
security functions are defined as antivirus capability, antiddos
capability, ips capability, http capability, and VoIP/VoLTE
capability. The condition capability can be extended according to
specific vendor condition features. The condition capability is
described in detail in [i2nsf-nsf-cap-im].
+--rw complete-nsf-capabilities Action capabilities is used to specify capabilities how to control
... and monitor aspects of flow-based NSFs when the event and condition
+--rw attack-mitigation-capabilities clauses are satisfied. The action capabilities are defined as
+--rw (attack-mitigation-control-type)? ingress action capability, egress action capability, and log action
+--:(ddos-attack) capability. The action capability can be extended according to
| +--rw (ddos-attack-type)? specific vendor action features. The action capability is described
| +--:(network-layer-ddos-attack) in detail in [i2nsf-nsf-cap-im].
| | +--rw network-layer-ddos-attack-types
| | +--rw syn-flood-attack? boolean
| | +--rw udp-flood-attack? boolean
| | +--rw icmp-flood-attack? boolean
| | +--rw ip-fragment-flood-attack? boolean
| | +--rw ipv6-related-attack? boolean
| +--:(app-layer-ddos-attack)
| +--rw app-layer-ddos-attack-types
| +--rw http-flood-attack? boolean
| +--rw https-flood-attack? boolean
| +--rw dns-flood-attack? boolean
| +--rw dns-amp-flood-attack? boolean
| +--rw ssl-flood-attack? boolean
+--:(single-packet-attack)
+--rw (single-packet-attack-type)?
+--:(scan-and-sniff-attack)
| +--rw ip-sweep-attack? boolean
| +--rw port-scanning-attack? boolean
+--:(malformed-packet-attack)
| +--rw ping-of-death-attack? boolean
| +--rw teardrop-attack? boolean
+--:(special-packet-attack)
+--rw oversized-icmp-attack? boolean
+--rw tracert-attack? boolean
Figure 10: Data Model Structure for Attack Mitigation Capabilities of Resolution strategy capabilities are used to specify capabilities how
Network Security Function to resolve conflicts that occur between the actions of the same or
different policy rules that are matched and contained in this
particular NSF. The resolution strategy capabilities are defined as
First Matching Rule (FMR), Last Matching Rule (LMR), Prioritized
Matching Rule (PMR) with Errors (PMRE), and Prioritized Matching Rule
with No Errors (PMRN). The resolution strategy capability can be
extended according to specific vendor action features. The
resolution strategy capability is described in detail in
[i2nsf-nsf-cap-im].
Attack mitigation is composed of a number of GNSFs; each one protects Default action capabilities are used to specify capabilities how to
against a specific type of network attack. Attack Mitigation execute I2NSF policy rule when no rule matches a packet. The default
security is a type of GNSF, which summarizes a well-defined set of action capabilities are defined as pass, drop, reject, alert, and
security Capabilities. mirror. The default action capability can be extended according to
specific vendor action features. The default action capability is
described in detail in [i2nsf-nsf-cap-im].
6.2.8. RPC for Acquiring Appropriate Network Security Function 6. YANG Data Modules
6.1. I2NSF Capability YANG Data Module
The data model for RPC for Acquiring Appropriate Network Security This section introduces an YANG data module for capabilities of
Function has the following structure: network security functions, as defined in the [i2nsf-nsf-cap-im].
rpcs: <CODE BEGINS> file "ietf-i2nsf-capability@2019-03-11.yang"
+---x call-appropriate-nsf
+---w input
| +---w nsf-type nsf-type
| +---w target-device
| +---w pc? boolean
| +---w mobile-phone? boolean
| +---w voip-volte-phone? boolean
| +---w tablet? boolean
| +---w iot? boolean
| +---w vehicle? boolean
+--ro output
+--ro nsf-address
+--ro (nsf-address-type)?
+--:(ipv4-address)
| +--ro ipv4-address inet:ipv4-address
+--:(ipv6-address)
+--ro ipv6-address inet:ipv6-address
Figure 11: RPC for Acquiring Appropriate Network Security Function module ietf-i2nsf-capability {
yang-version 1.1;
namespace
"urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability";
prefix
iicapa;
This shows a RPC for acquiring an appropriate network security organization
function according to type of NSF and/or target devices. If the SFF "IETF I2NSF (Interface to Network Security Functions)
[i2nsf-sfc]does not have the location information of network security Working Group";
functions that it should send in own cache table, this can be used to
acquire the information. These objects are defined as input data
(i.e., NSF type and target devices) and output data (i.e., location
information of NSF).
7. YANG Modules contact
"WG Web: <http://tools.ietf.org/wg/i2nsf>
WG List: <mailto:i2nsf@ietf.org>
7.1. I2NSF Capability YANG Data Module WG Chair: Adrian Farrel
<mailto:Adrain@olddog.co.uk>
This section introduces a YANG module for the information model of WG Chair: Linda Dunbar
network security functions, as defined in the [i2nsf-nsf-cap-im]. <mailto:Linda.duhbar@huawei.com>
<CODE BEGINS> file "ietf-i2nsf-capability@2018-11-04.yang" Editor: Susan Hares
<mailto:shares@ndzh.com>
module ietf-i2nsf-capability { Editor: Jaehoon Paul Jeong
namespace <mailto:pauljeong@skku.edu>
"urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability";
prefix
i2nsf-capability;
import ietf-inet-types{ Editor: Jinyong Tim Kim
prefix inet; <mailto:timkim@skku.edu>";
}
organization
"IETF I2NSF (Interface to Network Security Functions)
Working Group";
contact description
"WG Web: <http://tools.ietf.org/wg/i2nsf> "This module describes a capability model
WG List: <mailto:i2nsf@ietf.org> for I2NSF devices.
WG Chair: Adrian Farrel Copyright (c) 2018 IETF Trust and the persons
<mailto:Adrain@olddog.co.uk> identified as authors of the code. All rights reserved.
WG Chair: Linda Dunbar Redistribution and use in source and binary forms, with or
<mailto:Linda.duhbar@huawei.com> 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).
Editor: Susan Hares This version of this YANG module is part of RFC 8341; see
<mailto:shares@ndzh.com> the RFC itself for full legal notices.";
Editor: Jaehoon Paul Jeong revision "2019-03-11"{
<mailto:pauljeong@skku.edu> description "Initial revision.";
reference
"RFC XXXX: I2NSF Capability YANG Data Model";
}
Editor: Jinyong Tim Kim /*
<mailto:timkim@skku.edu>"; * Identities
*/
identity event {
description description
"This module describes a capability model "Base identity for event of policy.";
for I2NSF devices."; reference
"draft-hong-i2nsf-nsf-monitoring-data-model-06
revision "2018-11-04"{ - Event";
description "The fifth revision"; }
reference
"draft-ietf-i2nsf-capability-04";
}
grouping i2nsf-nsf-location {
description
"This provides a location for capabilities.";
container nsf-address {
description
"This is location information for capabilities.";
choice nsf-address-type {
description
"nsf address type: ipv4 and ipv4";
case ipv4-address {
description
"ipv4 case";
leaf ipv4-address {
type inet:ipv4-address;
mandatory true;
description
"nsf address type is ipv4";
}
}
case ipv6-address {
description
"ipv6 case";
leaf ipv6-address {
type inet:ipv6-address;
mandatory true;
description
"nsf address type is ipv6";
}
}
}
}
}
typedef nsf-type { identity system-event-capa {
type enumeration { base event;
enum network-firewall { description
description "Identity for system event";
"If type of a NSF is Network Firewall."; reference
} "draft-hong-i2nsf-nsf-monitoring-data-model-06
- System alarm";
}
enum web-app-firewall { identity system-alarm-capa {
description base event;
"If type of a NSF is Web Application description
Firewall."; "Identity for system alarm";
} reference
"draft-hong-i2nsf-nsf-monitoring-data-model-06
- System alarm";
}
enum anti-virus { identity access-violation {
description base system-event-capa;
"If type of a NSF is Anti-Virus"; description
} "Identity for access violation
among system events";
enum ids { reference
description "draft-hong-i2nsf-nsf-monitoring-data-model-06
"If type of a NSF is IDS."; - System event";
} }
enum ips { identity configuration-change {
description base system-event-capa;
"If type of a NSF is IPS."; description
} "Identity for configuration change
enum ddos-mitigator { among system events";
description reference
"If type of a NSF is DDoS Mitigator."; "draft-hong-i2nsf-nsf-monitoring-data-model-06
} - System event";
} }
description
"This is used for type of NSF.";
}
grouping i2nsf-it-resources { identity memory-alarm {
description base system-alarm-capa;
"This provides a link between capabilities description
and IT resources. This has a list of IT resources "Identity for memory alarm
by name."; among system alarms";
container target-device { reference
description "draft-hong-i2nsf-nsf-monitoring-data-model-06
"it-resources"; - System alarm";
}
leaf pc { identity cpu-alarm {
type boolean; base system-alarm-capa;
description description
"If type of a device is PC."; "Identity for cpu alarm
} among system alarms";
reference
"draft-hong-i2nsf-nsf-monitoring-data-model-06
- System alarm";
}
leaf mobile-phone { identity disk-alarm {
type boolean; base system-alarm-capa;
description description
"If type of a device is mobile-phone."; "Identity for disk alarm
} among system alarms";
reference
"draft-hong-i2nsf-nsf-monitoring-data-model-06
- System alarm";
}
leaf voip-volte-phone { identity hardware-alarm {
type boolean; base system-alarm-capa;
description description
"If type of a device is voip-volte-phone."; "Identity for hardware alarm
} among system alarms";
reference
"draft-hong-i2nsf-nsf-monitoring-data-model-06
- System alarm";
}
leaf tablet { identity interface-alarm {
type boolean; base system-alarm-capa;
description description
"If type of a device is tablet."; "Identity for interface alarm
} among system alarms";
reference
"draft-hong-i2nsf-nsf-monitoring-data-model-06
- System alarm";
}
leaf iot { identity condition {
type boolean; description
description "Base identity for conditions of policy";
"If type of a device is Internet of Things."; }
}
leaf vehicle {
type boolean;
description
"If type of a device is vehicle.";
}
} identity ipv4-capa {
} base condition;
description
"Identity for capabilities of IPv4 condition";
reference
"RFC 791: Internet Protocol";
}
grouping capabilities-information { identity exact-ipv4-header-length {
description base ipv4-capa;
"This includes information of capabilities."; description
"Identity for exact header length capability
of IPv4 condition";
reference
"RFC 791: Internet Protocol - Header Length";
}
leaf nsf-type { identity range-ipv4-header-length {
type nsf-type; base ipv4-capa;
description description
"This is type of NSF."; "Identity for range header length capability
} of IPv4 condition";
uses i2nsf-nsf-location; reference
uses i2nsf-it-resources; "RFC 791: Internet Protocol - Header Length";
} }
identity ipv4-tos {
base ipv4-capa;
description
"Identity for type of service capability
of IPv4 condition";
reference
"RFC 791: Internet Protocol - Type of Service";
}
grouping i2nsf-net-sec-caps { identity exact-ipv4-total-length {
description base ipv4-capa;
"i2nsf-net-sec-caps"; description
container net-sec-capabilities { "Identity for exact total length capability
description of IPv4 condition";
"net-sec-capabilities"; reference
"RFC 791: Internet Protocol - Total Length";
}
container time { identity range-ipv4-total-length {
description base ipv4-capa;
"This is capabilities for time"; description
container time-zone { "Identity for range total length capability
description of IPv4 condition";
"This can be used to apply rules reference
according to time zone"; "RFC 791: Internet Protocol - Total Length";
}
leaf time-zone-offset { identity ipv4-id {
type boolean; base ipv4-capa;
description description
"This is offset for UTC time zone"; "Identity for identification capability
} of IPv4 condition";
reference
"RFC 791: Internet Protocol - Identification";
}
} identity ipv4-fragment-flags {
base ipv4-capa;
description
"Identity for fragment flags capability
of IPv4 condition";
reference
"RFC 791: Internet Protocol - Fragmentation Flags";
}
container time-inteval { identity exact-ipv4-fragment-offset {
description base ipv4-capa;
"This can be used to apply rules description
according to time inteval"; "Identity for exact fragment offset capability
container absolute-time-inteval { of IPv4 condition";
description reference
"This can be used to apply rules according to "RFC 791: Internet Protocol - Fragmentation Offset";
absolute time inteval"; }
leaf start-time {
type boolean;
description
"This is start time for absolute time inteval";
}
leaf end-time {
type boolean;
description
"This is end time for absolute time inteval";
}
}
container periodic-time-inteval {
description
"This can be used to apply rules according to
periodic time inteval";
leaf day {
type boolean;
description
"This is day for periodic time inteval";
}
leaf month {
type boolean;
description
"This is month for periodic time inteval";
}
}
}
}
container event { identity range-ipv4-fragment-offset {
description base ipv4-capa;
" This is abstract. An event is defined as any important description
occurrence in time of a change in the system being "Identity for range fragment offset capability
managed, and/or in the environment of the system being of IPv4 condition";
managed. When used in the context of policy rules for reference
a flow-based NSF, it is used to determine whether the "RFC 791: Internet Protocol - Fragmentation Offset";
Condition clause of the Policy Rule can be evaluated }
or not. Examples of an I2NSF event include time and
user actions (e.g., logon, logoff, and actions that
violate any ACL.).";
container usr-event { identity exact-ipv4-ttl {
description "TBD"; base ipv4-capa;
leaf usr-sec-event-content { description
type boolean; "Identity for exact time to live capability
description of IPv4 condition";
"This is a mandatory string that contains the content reference
of the UserSecurityEvent. The format of the content "RFC 791: Internet Protocol - Time To Live (TTL)";
is specified in the usrSecEventFormat class }
attribute, and the type of event is defined in the
usrSecEventType class attribute. An example of the
usrSecEventContent attribute is a string hrAdmin,
with the usrSecEventFormat set to 1 (GUID) and the
usrSecEventType attribute set to 5 (new logon).";
}
container usr-sec-event-format { identity range-ipv4-ttl {
description base ipv4-capa;
"This is a mandatory uint 8 enumerated integer, which description
is used to specify the data type of the "Identity for range time to live capability
usrSecEventContent attribute. The content is of IPv4 condition";
specified in the usrSecEventContent class attribute, reference
and the type of event is defined in the "RFC 791: Internet Protocol - Time To Live (TTL)";
usrSecEventType class attribute. An example of the }
usrSecEventContent attribute is string hrAdmin,
with the usrSecEventFormat attribute set to 1 (GUID)
and the usrSecEventType attribute set to 5
(new logon).";
leaf unknown {
type boolean;
description
"If SecEventFormat is unknown";
}
leaf guid {
type boolean;
description
"If SecEventFormat is GUID
(Generic Unique IDentifier)";
}
leaf uuid {
type boolean;
description
"If SecEventFormat is UUID
(Universal Unique IDentifier)";
}
leaf uri {
type boolean;
description
"If SecEventFormat is URI
(Uniform Resource Identifier)";
}
leaf fqdn {
type boolean;
description
"If SecEventFormat is FQDN
(Fully Qualified Domain Name)";
}
leaf fqpn {
type boolean;
description
"If SecEventFormat is FQPN
(Fully Qualified Path Name)";
}
}
container usr-sec-event-type { identity ipv4-protocol {
leaf unknown { base ipv4-capa;
type boolean; description
description "Identity for protocol capability
"If usrSecEventType is unknown"; of IPv4 condition";
} reference
leaf user-created { "RFC 790: Assigned numbers - Assigned Internet
type boolean; Protocol Number
description RFC 791: Internet Protocol - Protocol";
"If usrSecEventType is new user }
created";
}
leaf user-grp-created {
type boolean;
description
"If usrSecEventType is new user
group created";
}
leaf user-deleted {
type boolean;
description
"If usrSecEventType is user
deleted";
}
leaf user-grp-deleted {
type boolean;
description
"If usrSecEventType is user
group deleted";
}
leaf user-logon {
type boolean;
description
"If usrSecEventType is user
logon";
}
leaf user-logoff {
type boolean;
description
"If usrSecEventType is user
logoff";
}
leaf user-access-request {
type boolean;
description
"If usrSecEventType is user
access request";
}
leaf user-access-granted {
type boolean;
description
"If usrSecEventType is user
granted";
}
leaf user-access-violation {
type boolean;
description
"If usrSecEventType is user
violation";
}
description
"This is a mandatory uint 8 enumerated integer, which
is used to specify the type of event that involves
this user. The content and format are specified in
the usrSecEventContent and usrSecEventFormat class
attributes, respectively. An example of the
usrSecEventContent attribute is string hrAdmin,
with the usrSecEventFormat attribute set to 1 (GUID)
and the usrSecEventType attribute set to 5
(new logon).";
}
} identity exact-ipv4-address {
container dev-event { base ipv4-capa;
description "TBD"; description
"Identity for exact address capability
of IPv4 condition";
reference
"RFC 791: Internet Protocol - Address";
}
leaf dev-sec-event-content { identity range-ipv4-address {
type boolean; base ipv4-capa;
mandatory true; description
description "Identity for range-address capability
"This is a mandatory string that contains the content of IPv4 condition";
of the DeviceSecurityEvent. The format of the reference
content is specified in the devSecEventFormat class "RFC 791: Internet Protocol - Address";
attribute, and the type of event is defined in the }
devSecEventType class attribute. An example of the
devSecEventContent attribute is alarm, with the
devSecEventFormat attribute set to 1 (GUID), the
devSecEventType attribute set to 5 (new logon).";
}
container dev-sec-event-format { identity ipv4-ipopts {
description base ipv4-capa;
"This is a mandatory uint 8 enumerated integer, description
which is used to specify the data type of the "Identity for option capability
devSecEventContent attribute."; of IPv4 condition";
reference
"RFC 791: Internet Protocol - Options";
}
leaf unknown { identity ipv4-sameip {
type boolean; base ipv4-capa;
description description
"If SecEventFormat is unknown"; "Identity for sameIP capability
} of IPv4 condition";
leaf guid { }
type boolean;
description
"If SecEventFormat is GUID
(Generic Unique IDentifier)";
}
leaf uuid {
type boolean;
description
"If SecEventFormat is UUID
(Universal Unique IDentifier)";
}
leaf uri {
type boolean;
description
"If SecEventFormat is URI
(Uniform Resource Identifier)";
}
leaf fqdn {
type boolean;
description
"If SecEventFormat is FQDN
(Fully Qualified Domain Name)";
}
leaf fqpn {
type boolean;
description
"If SecEventFormat is FQPN
(Fully Qualified Path Name)";
}
}
container dev-sec-event-type { identity ipv4-geoip {
description base ipv4-capa;
"This is a mandatory uint 8 enumerated integer, description
which is used to specify the type of event "Identity for geography capability
that was generated by this device."; of IPv4 condition";
}
leaf unknown { identity ipv6-capa {
type boolean; base condition;
description description
"If devSecEventType is unknown"; "Identity for capabilities of IPv6 condition";
} reference
leaf comm-alarm { "RFC 2460: Internet Protocol, Version 6 (IPv6)
type boolean; Specification";
description }
"If devSecEventType is communications
alarm";
}
leaf quality-of-service-alarm {
type boolean;
description
"If devSecEventType is quality of service
alarm";
}
leaf process-err-alarm {
type boolean;
description
"If devSecEventType is processing error
alarm";
}
leaf equipment-err-alarm {
type boolean;
description
"If devSecEventType is equipment error
alarm";
}
leaf environmental-err-alarm {
type boolean;
description
"If devSecEventType is environmental error
alarm";
}
} identity ipv6-traffic-class {
container dev-sec-event-type-severity { base ipv6-capa;
description description
"This is a mandatory uint 8 enumerated integer, "Identity for traffic class capability
which is used to specify the perceived of IPv6 condition";
severity of the event generated by this reference
Device."; "RFC 2460: Internet Protocol, Version 6 (IPv6)
Specification - Traffic Class";
}
leaf unknown { identity exact-ipv6-flow-label {
type boolean; base ipv6-capa;
description description
"If devSecEventType is unknown"; "Identity for exact flow label capability
} of IPv6 condition";
leaf cleared { reference
type boolean; "RFC 2460: Internet Protocol, Version 6 (IPv6)
description Specification - Flow Label";
"If devSecEventTypeSeverity is cleared"; }
}
leaf indeterminate {
type boolean;
description
"If devSecEventTypeSeverity is
indeterminate";
}
leaf critical {
type boolean;
description
"If devSecEventTypeSeverity is critical";
}
leaf major{
type boolean;
description
"If devSecEventTypeSeverity is major";
}
leaf minor {
type boolean;
description
"If devSecEventTypeSeverity is minor";
}
leaf warning {
type boolean;
description
"If devSecEventTypeSeverity is warning";
}
}
}
container sys-event {
description "TBD";
leaf sys-sec-event-content {
type boolean;
description
"This is a mandatory string that contains a content
of the SystemSecurityEvent. The format of a content
is specified in a sysSecEventFormat class attribute,
and the type of event is defined in the
sysSecEventType class attribute. An example of the
sysSecEventContent attribute is string sysadmin3,
with the sysSecEventFormat attribute set to 1(GUID),
and the sysSecEventType attribute set to 2
(audit log cleared).";
}
container sys-sec-event-format { identity range-ipv6-flow-label {
description base ipv6-capa;
"This is a mandatory uint 8 enumerated integer, which description
is used to specify the data type of the "Identity for range flow label capability
sysSecEventContent attribute."; of IPv6 condition";
reference
"RFC 2460: Internet Protocol, Version 6 (IPv6)
Specification - Flow Label";
}
leaf unknown { identity exact-ipv6-payload-length {
type boolean; base ipv6-capa;
description description
"If SecEventFormat is unknown"; "Identity for exact payload length capability
} of IPv6 condition";
leaf guid { reference
type boolean; "RFC 2460: Internet Protocol, Version 6 (IPv6)
description Specification - Payload Length";
"If SecEventFormat is GUID }
(Generic Unique IDentifier)";
}
leaf uuid {
type boolean;
description
"If SecEventFormat is UUID
(Universal Unique IDentifier)";
}
leaf uri {
type boolean;
description
"If SecEventFormat is URI
(Uniform Resource Identifier)";
}
leaf fqdn {
type boolean;
description
"If SecEventFormat is FQDN
(Fully Qualified Domain Name)";
} identity range-ipv6-payload-length {
leaf fqpn { base ipv6-capa;
type boolean; description
description "Identity for range payload length capability
"If SecEventFormat is FQPN of IPv6 condition";
(Fully Qualified Path Name)"; reference
} "RFC 2460: Internet Protocol, Version 6 (IPv6)
} Specification - Payload Length";
}
identity ipv6-next-header {
base ipv6-capa;
description
"Identity for next header capability
of IPv6 condition";
reference
"RFC 2460: Internet Protocol, Version 6 (IPv6)
Specification - Next Header";
}
container sys-sec-event-type { identity exact-ipv6-hop-limit {
description base ipv6-capa;
"This is a mandatory uint 8 enumerated integer, which description
is used to specify the type of event that involves "Identity for exact hop limit capability
this device."; of IPv6 condition";
reference
"RFC 2460: Internet Protocol, Version 6 (IPv6)
Specification - Hop Limit";
}
leaf unknown { identity range-ipv6-hop-limit {
type boolean; base ipv6-capa;
description description
"If sysSecEventType is unknown"; "Identity for range hop limit capability
} of IPv6 condition";
leaf audit-log-written-to { reference
type boolean; "RFC 2460: Internet Protocol, Version 6 (IPv6)
description Specification - Hop Limit";
"If sysSecEventTypeSeverity }
is that audit log is written to";
}
leaf audit-log-cleared {
type boolean;
description
"If sysSecEventTypeSeverity
is that audit log is cleared";
}
leaf policy-created {
type boolean;
description
"If sysSecEventTypeSeverity
is that policy is created";
}
leaf policy-edited{
type boolean;
description
"If sysSecEventTypeSeverity
is that policy is edited";
}
leaf policy-deleted{
type boolean;
description
"If sysSecEventTypeSeverity
is that policy is deleted";
}
leaf policy-executed{
type boolean;
description
"If sysSecEventTypeSeverity
is that policy is executed";
}
}
}
container time-event {
description "TBD";
leaf time-sec-event-begin { identity exact-ipv6-address {
type boolean; base ipv6-capa;
description description
"This is a mandatory DateTime attribute, and "Identity for exact address capability
represents the beginning of a time period. of IPv6 condition";
It has a value that has a date and/or a time reference
component (as in the Java or Python libraries)."; "RFC 2460: Internet Protocol, Version 6 (IPv6)
} Specification - Address";
}
leaf time-sec-event-end { identity range-ipv6-address {
type boolean; base ipv6-capa;
description description
"This is a mandatory DateTime attribute, and "Identity for range address capability
represents the end of a time period. It has of IPv6 condition";
a value that has a date and/or a time component reference
(as in the Java or Python libraries). If this is "RFC 2460: Internet Protocol, Version 6 (IPv6)
a single event occurrence, and not a time period Specification - Address";
when the event can occur, then the
timeSecEventPeriodEnd attribute may be ignored.";
}
leaf time-sec-event-time-zone { }
type boolean;
description
"This is a mandatory string attribute, and defines a
time zone that this event occurred in using the
format specified in ISO8601.";
}
}
} identity tcp-capa {
base condition;
description
"Identity for capabilities of tcp condition";
reference
"RFC 793: Transmission Control Protocol";
}
container condition { identity exact-tcp-port-num {
description base tcp-capa;
" This is abstract. A condition is defined as a set description
of attributes, features, and/or values that are to be "Identity for exact port number capability
compared with a set of known attributes, features, of tcp condition";
and/or values in order to determine whether or not the reference
set of Actions in that (imperative) I2NSF Policy Rule "RFC 793: Transmission Control Protocol - Port Number";
can be executed or not. Examples of I2NSF Conditions }
include matching attributes of a packet or flow, and
comparing the internal state of an NSF to a desired state.";
container packet-security-condition { identity range-tcp-port-num {
description "TBD"; base tcp-capa;
description
"Identity for range port number capability
of tcp condition";
reference
"RFC 793: Transmission Control Protocol - Port Number";
}
container packet-security-mac-condition { identity exact-tcp-seq-num {
description base tcp-capa;
"The purpose of this Class is to represent packet MAC description
packet header information that can be used as part of "Identity for exact sequence number capability
a test to determine if the set of Policy Actions in of tcp condition";
this ECA Policy Rule should be execute or not."; reference
"RFC 793: Transmission Control Protocol - Sequence Number";
}
leaf pkt-sec-cond-mac-dest { identity range-tcp-seq-num {
type boolean; base tcp-capa;
description description
"The MAC destination address (6 octets long)."; "Identity for range sequence number capability
} of tcp condition";
reference
"RFC 793: Transmission Control Protocol - Sequence Number";
}
leaf pkt-sec-cond-mac-src { identity exact-tcp-ack-num {
type boolean; base tcp-capa;
description description
"The MAC source address (6 octets long)."; "Identity for exact acknowledgement number capability
} of tcp condition";
reference
"RFC 793: Transmission Control Protocol - Acknowledgement Number";
}
leaf pkt-sec-cond-mac-8021q { identity range-tcp-ack-num {
type boolean; base tcp-capa;
description description
"This is an optional string attribute, and defines "Identity for range acknowledgement number capability
The 802.1Q tab value (2 octets long)."; of tcp condition";
} reference
"RFC 793: Transmission Control Protocol - Acknowledgement Number";
}
leaf pkt-sec-cond-mac-ether-type { identity exact-tcp-window-size {
type boolean; base tcp-capa;
description description
"The EtherType field (2 octets long). Values up to "Identity for exact window size capability
and including 1500 indicate the size of the payload of tcp condition";
in octets; values of 1536 and above define which reference
protocol is encapsulated in the payload of the "RFC 793: Transmission Control Protocol - Window Size";
frame."; }
}
leaf pkt-sec-cond-mac-tci {
type string;
description
"This is an optional string attribute, and defines
the Tag Control Information. This consists of a 3
bit user priority field, a drop eligible indicator
(1 bit), and a VLAN identifier (12 bits).";
}
}
container packet-security-ipv4-condition { identity range-tcp-window-size {
description base tcp-capa;
"The purpose of this Class is to represent packet IPv4 description
packet header information that can be used as part of "Identity for range window size capability
a test to determine if the set of Policy Actions in of tcp condition";
this ECA Policy Rule should be executed or not."; reference
"RFC 793: Transmission Control Protocol - Window Size";
}
leaf pkt-sec-cond-ipv4-header-length { identity tcp-flags {
type boolean; base tcp-capa;
description description
"The IPv4 packet header consists of 14 fields, "Identity for flags capability
of which 13 are required."; of tcp condition";
} reference
"RFC 793: Transmission Control Protocol - Flags";
}
leaf pkt-sec-cond-ipv4-tos { identity udp-capa {
type boolean; base condition;
description description
"The ToS field could specify a datagram's priority "Identity for capabilities of udp condition";
and request a route for low-delay, high-throughput, reference
or highly-reliable service.."; "RFC 768: User Datagram Protocol";
} }
leaf pkt-sec-cond-ipv4-total-length { identity exact-udp-port-num {
type boolean; base udp-capa;
description description
"This 16-bit field defines the entire packet size, "Identity for exact port number capability
including header and data, in bytes."; of udp condition";
} reference
"RFC 768: User Datagram Protocol - Port Number";
}
leaf pkt-sec-cond-ipv4-id { identity range-udp-port-num {
type boolean; base udp-capa;
description description
"This field is an identification field and is "Identity for range port number capability
primarily used for uniquely identifying of udp condition";
the group of fragments of a single IP datagram."; reference
} "RFC 768: User Datagram Protocol - Port Number";
}
leaf pkt-sec-cond-ipv4-fragment { identity exact-udp-total-length {
type boolean; base udp-capa;
description description
"IP fragmentation is an Internet Protocol (IP) "Identity for exact total-length capability
process that breaks datagrams into smaller pieces of udp condition";
(fragments), so that packets may be formed that reference
can pass through a link with a smaller maximum "RFC 768: User Datagram Protocol - Total Length";
transmission unit (MTU) than the original }
datagram size.";
}
leaf pkt-sec-cond-ipv4-fragment-offset { identity range-udp-total-length {
type boolean; base udp-capa;
description description
"Fragment offset field along with Don't Fragment "Identity for range total-length capability
and More Fragment flags in the IP protocol of udp condition";
header are used for fragmentation and reassembly reference
of IP datagrams."; "RFC 768: User Datagram Protocol - Total Length";
} }
leaf pkt-sec-cond-ipv4-ttl { identity icmp-capa {
type boolean; base condition;
description description
"The ttl keyword is used to check for a specific "Identity for capabilities of icmp condition";
IP time-to-live value in the header of reference
a packet."; "RFC 792: Internet Control Message Protocol";
} }
leaf pkt-sec-cond-ipv4-protocol { identity icmp-type {
type boolean; base icmp-capa;
description description
"Internet Protocol version 4(IPv4) is the fourth "Identity for icmp type capability
version of the Internet Protocol (IP)."; of icmp condition";
} reference
"RFC 792: Internet Control Message Protocol";
}
leaf pkt-sec-cond-ipv4-src { identity http-capa {
type boolean; base condition;
description description
"Defines the IPv4 Source Address."; "Identity for capabilities of http condition";
} }
leaf pkt-sec-cond-ipv4-dest { identity uri {
type boolean; base http-capa;
description description
"Defines the IPv4 Destination Address."; "Identity for uri capabilities of
} http condition";
}
leaf pkt-sec-cond-ipv4-ipopts { identity url {
type boolean; base http-capa;
description description
"With the ipopts keyword you can check if "Identity for url capabilities of
a specific ip option is set. Ipopts has http condition";
to be used at the beginning of a rule."; }
}
leaf pkt-sec-cond-ipv4-sameip { identity log-action-capa {
type boolean; description
description "Identity for capabilities of log action";
"Every packet has a source IP-address and }
a destination IP-address. It can be that
the source IP is the same as
the destination IP.";
}
leaf pkt-sec-cond-ipv4-geoip { identity rule-log {
type boolean; base log-action-capa;
description description
"The geoip keyword enables you to match on "Identity for rule log capability
the source, destination or source and destination of log action";
IP addresses of network traffic and to see to }
which country it belongs. To do this, Suricata
uses GeoIP API with MaxMind database format.";
}
}
container packet-security-ipv6-condition { identity session-log {
description base log-action-capa;
"The purpose of this Class is to represent packet description
IPv6 packet header information that can be used as "Identity for session log capability
part of a test to determine if the set of Policy of log action";
Actions in this ECA Policy Rule should be executed }
or not.";
leaf pkt-sec-cond-ipv6-dscp { identity ingress-action-capa {
type boolean; description
description "Identity for capabilities of ingress action";
"Differentiated Services Code Point (DSCP) reference
of ipv6."; "draft-ietf-i2nsf-capability-04: Information Model
} of NSFs Capabilities - Action";
}
leaf pkt-sec-cond-ipv6-ecn { identity egress-action-capa {
type boolean; description
description "Base identity for egress action";
"ECN allows end-to-end notification of network }
congestion without dropping packets.";
}
leaf pkt-sec-cond-ipv6-traffic-class {
type boolean;
description
"The bits of this field hold two values. The 6
most-significant bits are used for
differentiated services, which is used to
classify packets.";
}
leaf pkt-sec-cond-ipv6-flow-label { identity default-action-capa {
type boolean; description
description "Identity for capabilities of default action";
"The flow label when set to a non-zero value reference
serves as a hint to routers and switches "draft-ietf-i2nsf-capability-04: Information Model
with multiple outbound paths that these of NSFs Capabilities - Default action";
packets should stay on the same path so that }
they will not be reordered.";
}
leaf pkt-sec-cond-ipv6-payload-length { identity pass {
type boolean; base ingress-action-capa;
description base egress-action-capa;
"The size of the payload in octets, base default-action-capa;
including any extension headers."; description
} "Identity for pass";
reference
"draft-ietf-i2nsf-capability-04: Information Model
of NSFs Capabilities - Actions and
default action";
}
leaf pkt-sec-cond-ipv6-next-header { identity drop {
type boolean; base ingress-action-capa;
description base egress-action-capa;
"Specifies the type of the next header. base default-action-capa;
This field usually specifies the transport description
layer protocol used by a packet's payload."; "Identity for drop";
} reference
"draft-ietf-i2nsf-capability-04: Information Model
of NSFs Capabilities - Actions and
default action";
}
leaf pkt-sec-cond-ipv6-hop-limit { identity reject {
type boolean; base ingress-action-capa;
description base egress-action-capa;
"Replaces the time to live field of IPv4."; base default-action-capa;
} description
"Identity for reject";
reference
"draft-ietf-i2nsf-capability-04: Information Model
of NSFs Capabilities - Actions and
default action";
}
leaf pkt-sec-cond-ipv6-src { identity alert {
type boolean; base ingress-action-capa;
description base egress-action-capa;
"The IPv6 address of the sending node."; base default-action-capa;
} description
"Identity for alert";
reference
"draft-ietf-i2nsf-capability-04: Information Model
of NSFs Capabilities - Actions and
default action";
}
leaf pkt-sec-cond-ipv6-dest { identity mirror {
type boolean; base ingress-action-capa;
description base egress-action-capa;
"The IPv6 address of the destination node(s)."; base default-action-capa;
} description
} "Identity for mirror";
reference
"draft-ietf-i2nsf-capability-04: Information Model
of NSFs Capabilities - Actions and
default action";
}
container packet-security-tcp-condition { identity invoke-signaling {
description base egress-action-capa;
"The purpose of this Class is to represent packet description
TCP packet header information that can be used as "Identity for invoke signaling";
part of a test to determine if the set of Policy }
Actions in this ECA Policy Rule should be executed
or not.";
leaf pkt-sec-cond-tcp-src-port { identity tunnel-encapsulation {
type boolean; base egress-action-capa;
description description
"This is a mandatory string attribute, and "Identity for tunnel encapsulation";
defines the Source Port number (16 bits)."; }
}
leaf pkt-sec-cond-tcp-dest-port { identity forwarding {
type boolean; base egress-action-capa;
description description
"This is a mandatory string attribute, and "Identity for forwarding";
defines the Destination Port number (16 bits).";
}
leaf pkt-sec-cond-tcp-seq-num { }
type boolean;
description
"If the SYN flag is set (1), then this is the
initial sequence number.";
}
leaf pkt-sec-cond-tcp-ack-num { identity redirection {
type boolean; base egress-action-capa;
description description
"If the ACK flag is set then the value of this "Identity for redirection";
field is the next sequence number that the sender }
is expecting.";
}
leaf pkt-sec-cond-tcp-window-size { identity resolution-strategy-capa {
type boolean; description
description "Base identity for resolution strategy";
"The size of the receive window, which specifies reference
the number of windows size units (by default,bytes) "draft-ietf-i2nsf-capability-04: Information Model
(beyond the segment identified by the sequence of NSFs Capabilities - Resolution Strategy";
number in the acknowledgment field) that the sender }
of this segment is currently willing to recive.";
}
leaf pkt-sec-cond-tcp-flags { identity fmr {
type boolean; base resolution-strategy-capa;
description description
"This is a mandatory string attribute, and defines "Identity for First Matching Rule (FMR)";
the nine Control bit flags (9 bits)."; reference
} "draft-ietf-i2nsf-capability-04: Information Model
} of NSFs Capabilities - Resolution Strategy";
}
container packet-security-udp-condition { identity lmr {
description base resolution-strategy-capa;
"The purpose of this Class is to represent packet UDP description
packet header information that can be used as part "Identity for Last Matching Rule (LMR)";
of a test to determine if the set of Policy Actions reference
in this ECA Policy Rule should be executed or not."; "draft-ietf-i2nsf-capability-04: Information Model
of NSFs Capabilities - Resolution Strategy";
}
leaf pkt-sec-cond-udp-src-port { identity pmr {
type boolean; base resolution-strategy-capa;
description description
"This is a mandatory string attribute, and "Identity for Prioritized Matching Rule (PMR)";
defines the UDP Source Port number (16 bits)."; reference
} "draft-ietf-i2nsf-capability-04: Information Model
of NSFs Capabilities - Resolution Strategy";
}
leaf pkt-sec-cond-udp-dest-port { identity pmre {
type boolean; base resolution-strategy-capa;
description description
"This is a mandatory string attribute, and "Identity for Prioritized Matching Rule
defines the UDP Destination Port number (16 bits)."; with Errors (PMRE)";
}
leaf pkt-sec-cond-udp-length { reference
type boolean; "draft-ietf-i2nsf-capability-04: Information Model
description of NSFs Capabilities - Resolution Strategy";
"This is a mandatory string attribute, and defines }
the length in bytes of the UDP header and data
(16 bits).";
}
}
container packet-security-icmp-condition { identity pmrn {
description base resolution-strategy-capa;
"The internet control message protocol condition."; description
"Identity for Prioritized Matching Rule
with No Errors (PMRN)";
reference
"draft-ietf-i2nsf-capability-04: Information Model
of NSFs Capabilities - Resolution Strategy";
}
leaf pkt-sec-cond-icmp-type { identity advanced-nsf-capa {
type boolean; description
description "Base identity for advanced
"ICMP type, see Control messages."; network security function capabilities";
} reference
"RFC 8329: Framework for Interface to Network Security
Functions - Differences from ACL Data Models
draft-dong-i2nsf-asf-config-01: Configuration of
Advanced Security Functions with I2NSF Security
Controller";
}
leaf pkt-sec-cond-icmp-code { identity antivirus-capa {
type boolean; base advanced-nsf-capa;
description description
"ICMP subtype, see Control messages."; "Identity for antivirus capabilities";
} reference
"RFC 8329: Framework for Interface to Network Security
Functions - Differences from ACL Data Models
draft-dong-i2nsf-asf-config-01: Configuration of
Advanced Security Functions with I2NSF Security
Controller - Antivirus";
}
leaf pkt-sec-cond-icmp-seg-num { identity antiddos-capa {
type boolean; base advanced-nsf-capa;
description description
"The icmp Sequence Number."; "Identity for antiddos capabilities";
} reference
} "RFC 8329: Framework for Interface to Network Security
} Functions - Differences from ACL Data Models
draft-dong-i2nsf-asf-config-01: Configuration of
Advanced Security Functions with I2NSF Security
Controller - Antiddos";
}
container packet-payload-condition { identity ips-capa {
description "TBD"; base advanced-nsf-capa;
leaf pkt-payload-content { description
type boolean; "Identity for IPS capabilities";
description reference
"The content keyword is very important in "RFC 8329: Framework for Interface to Network Security
signatures. Between the quotation marks you Functions - Differences from ACL Data Models
can write on what you would like the draft-dong-i2nsf-asf-config-01: Configuration of
signature to match."; Advanced Security Functions with I2NSF Security
} Controller - Intrusion Prevention System";
} }
leaf acl-number {
type boolean;
description
"This is acl-number.";
}
container application-condition { identity voip-volte-capa {
description base advanced-nsf-capa;
"TBD"; description
"Identity for VoIP/VoLTE capabilities";
reference
"RFC 3261: SIP: Session Initiation Protocol
RFC 8329: Framework for Interface to Network Security
Functions - Differences from ACL Data Models
draft-dong-i2nsf-asf-config-01: Configuration of
Advanced Security Functions with I2NSF Security
Controller";
}
leaf application-object { identity detect {
type boolean; base antivirus-capa;
description description
"This is application object."; "Identity for detect capabilities
} of antivirus";
leaf application-group { reference
type boolean; "draft-dong-i2nsf-asf-config-01: Configuration of
description Advanced Security Functions with I2NSF Security
"This is application group."; Controller - Antivirus";
}
} identity exception-application {
leaf application-label { base antivirus-capa;
type boolean; description
description "Identity for exception application capabilities
"This is application label."; of antivirus";
} reference
container category { "draft-dong-i2nsf-asf-config-01: Configuration of
description Advanced Security Functions with I2NSF Security
"TBD"; Controller - Antivirus";
leaf application-category {
type boolean;
description
"TBD";
} }
}
}
container target-condition { identity exception-signature {
description "TBD"; base antivirus-capa;
description
"Identity for exception signature capabilities
of antivirus";
reference
"draft-dong-i2nsf-asf-config-01: Configuration of
Advanced Security Functions with I2NSF Security
Controller - Antivirus";
}
leaf device-sec-context-cond { identity whitelists {
type boolean; base antivirus-capa;
description description
"The device attribute that can identify a device, "Identity for whitelists capabilities
including the device type (i.e., router, switch, of antivirus";
pc, ios, or android) and the device's owner as reference
well."; "draft-dong-i2nsf-asf-config-01: Configuration of
} Advanced Security Functions with I2NSF Security
} Controller - Antivirus";
container users-condition { }
description "TBD";
container user{ identity syn-flood-action {
description base antiddos-capa;
"The user (or user group) information with which description
network flow is associated: The user has many "Identity for syn flood action capabilities
attributes such as name, id, password, type, of antiddos";
authentication mode and so on. Name/id is often reference
used in the security policy to identify the user. "draft-dong-i2nsf-asf-config-01: Configuration of
Besides, NSF is aware of the IP address of the Advanced Security Functions with I2NSF Security
user provided by a unified user management system Controller - Antiddos";
via network. Based on name-address association, }
NSF is able to enforce the security functions
over the given user (or user group)";
choice user-name { identity udp-flood-action {
description base antiddos-capa;
"The name of the user. description
This must be unique."; "Identity for udp flood action capabilities
of antiddos";
reference
"draft-dong-i2nsf-asf-config-01: Configuration of
Advanced Security Functions with I2NSF Security
Controller - Antiddos";
}
case tenant { identity http-flood-action {
description base antiddos-capa;
"Tenant information."; description
"Identity for http flood action capabilities
of antiddos";
reference
"draft-dong-i2nsf-asf-config-01: Configuration of
Advanced Security Functions with I2NSF Security
Controller - Antiddos";
}
leaf tenant { identity https-flood-action {
type boolean; base antiddos-capa;
description description
"User's tenant information."; "Identity for https flood action capabilities
} of antiddos";
} reference
"draft-dong-i2nsf-asf-config-01: Configuration of
Advanced Security Functions with I2NSF Security
Controller - Antiddos";
}
case vn-id { identity dns-request-flood-action {
description base antiddos-capa;
"VN-ID information."; description
"Identity for dns request flood action capabilities
of antiddos";
reference
"draft-dong-i2nsf-asf-config-01: Configuration of
Advanced Security Functions with I2NSF Security
Controller - Antiddos";
}
leaf vn-id { identity dns-reply-flood-action {
type boolean; base antiddos-capa;
description description
"User's VN-ID information."; "Identity for dns reply flood action capabilities
} of antiddos";
} reference
} "draft-dong-i2nsf-asf-config-01: Configuration of
} Advanced Security Functions with I2NSF Security
container group { Controller - Antiddos";
description }
"The user (or user group) information with which
network flow is associated: The user has many
attributes such as name, id, password, type,
authentication mode and so on. Name/id is often
used in the security policy to identify the user.
Besides, NSF is aware of the IP address of the
user provided by a unified user management system
via network. Based on name-address association,
NSF is able to enforce the security functions
over the given user (or user group)";
choice group-name { identity icmp-flood-action {
description base antiddos-capa;
"The name of the user. description
This must be unique."; "Identity for icmp flood action capabilities
of antiddos";
reference
"draft-dong-i2nsf-asf-config-01: Configuration of
Advanced Security Functions with I2NSF Security
Controller - Antiddos";
}
case tenant { identity sip-flood-action {
description base antiddos-capa;
"Tenant information."; description
"Identity for sip flood action capabilities
of antiddos";
reference
"draft-dong-i2nsf-asf-config-01: Configuration of
Advanced Security Functions with I2NSF Security
Controller - Antiddos";
}
leaf tenant { identity detect-mode {
type boolean; base antiddos-capa;
description description
"User's tenant information."; "Identity for detect mode capabilities
} of antiddos";
} reference
"draft-dong-i2nsf-asf-config-01: Configuration of
Advanced Security Functions with I2NSF Security
Controller - Antiddos";
}
case vn-id { identity baseline-learn {
description base antiddos-capa;
"VN-ID information."; description
"Identity for baseline learn capabilities
of antiddos";
reference
"draft-dong-i2nsf-asf-config-01: Configuration of
Advanced Security Functions with I2NSF Security
Controller - Antiddos";
}
leaf vn-id { identity signature-set {
type boolean; base ips-capa;
description description
"User's VN-ID information."; "Identity for signature set capabilities
} of IPS";
} reference
} "draft-dong-i2nsf-asf-config-01: Configuration of
leaf security-grup { Advanced Security Functions with I2NSF Security
type boolean; Controller - Intrusion Prevention System";
mandatory true; }
description identity ips-exception-signature {
"security-grup."; base ips-capa;
} description
} "Identity for ips exception signature capabilities
} of IPS";
reference
"draft-dong-i2nsf-asf-config-01: Configuration of
Advanced Security Functions with I2NSF Security
Controller - Intrusion Prevention System";
}
container url-category-condition { identity voice-id {
description base voip-volte-capa;
"TBD"; description
leaf pre-defined-category { "Identity for voice-id capabilities
type boolean; of VoIP/VoLTE";
description reference
"This is pre-defined-category."; "RFC 3261: SIP: Session Initiation Protocol";
} }
leaf user-defined-category {
type boolean;
description
"This user-defined-category.";
}
}
container context-condition { identity user-agent {
description "TBD"; base voip-volte-capa;
leaf temp { description
type string; "Identity for user agent capabilities
description of VoIP/VoLTE";
"This is temp for context condition."; reference
"RFC 3261: SIP: Session Initiation Protocol";
}
} /*
} * Grouping
container gen-context-condition { */
description "TBD";
container geographic-location { grouping nsf-capabilities {
description description
"The location where network traffic is associated "Capabilities of network security funtion";
with. The region can be the geographic location reference
such as country, province, and city, "RFC 8329: Framework for Interface to Network Security
as well as the logical network location such as Functions - I2NSF Flow Security Policy Structure
IP address, network section, and network domain."; draft-ietf-i2nsf-capability-04: Information Model
of NSFs Capabilities - Capability Information Model Design";
leaf src-geographic-location { leaf-list time-capabilities {
type boolean; type enumeration {
description enum absolute-time {
"This is mapped to ip address. We can acquire
source region through ip address stored the
database.";
}
leaf dest-geographic-location {
type boolean;
description
"This is mapped to ip address. We can acquire
destination region through ip address stored
the database.";
}
}
}
}
container action {
description description
"An action is used to control and monitor aspects of "Capabilities of absolute time.
flow-based NSFs when the event and condition clauses If network security function has the absolute time
are satisfied. NSFs provide security functions by capability, the network security function
executing various Actions. Examples of I2NSF Actions supports rule execution according to absolute time.";
include providing intrusion detection and/or protection,
web and flow filtering, and deep packet inspection
for packets and flows.";
leaf rule-log {
type boolean;
description
"rule-log";
}
leaf session-log {
type boolean;
description
"session-log";
}
container ingress-action {
description "TBD";
container ingress-action-type {
description
"Ingress action type: permit, deny, and mirror.";
leaf pass {
type boolean;
description
"If ingress action is pass";
}
leaf drop {
type boolean;
description
"If ingress action is drop";
}
leaf reject {
type boolean;
description
"If ingress action is reject";
}
leaf alert {
type boolean;
description
"If ingress action is alert";
}
leaf mirror {
type boolean;
description
"If ingress action is mirror";
}
}
}
container egress-action {
description "TBD";
container egress-action-type {
description
"Egress-action-type: invoke-signaling,
tunnel-encapsulation, and forwarding.";
leaf invoke-signaling {
type boolean;
description
"If egress action is invoke signaling";
}
leaf tunnel-encapsulation {
type boolean;
description
"If egress action is tunnel encapsulation";
}
leaf forwarding {
type boolean;
description
"If egress action is forwarding";
}
leaf redirection {
type boolean;
description
"If egress action is redirection";
}
}
}
} }
container resolution-strategy { enum periodic-time {
description description
"The resolution strategies can be used to "Capabilities of periodic time.
specify how to resolve conflicts that occur between If network security function has the periodic time
the actions of the same or different policy rules that capability, the network security function
are matched and contained in this particular NSF"; supports rule execution according to periodic time.";
leaf first-matching-rule {
type boolean;
description
"If the resolution strategy is first matching rule";
}
leaf last-matching-rule {
type boolean;
description
"If the resolution strategy is last matching rule";
}
} }
} }
description
"This is capabilities for time";
} }
grouping i2nsf-advanced-sec-caps { container event-capabilities {
description description
"i2nsf-advanced-sec-caps"; "Capabilities of events.
container advanced-sec-capabilities { If network security function has
description the event capabilities, the network security functions
"net-sec-capabilities"; supports rule execution according to system event
and system alarm.";
container antivirus {
description
"antivirus";
leaf detect {
type boolean;
description
"detect capability";
}
leaf exception-application {
type boolean;
description
"exception-application capability";
}
leaf exception-signature {
type boolean;
description
"exception-signature capability";
}
leaf whitelists {
type boolean;
description
"exception-signature capability";
}
}
container antiddos { reference
description "RFC 8329: Framework for Interface to Network Security
"antiddos"; Functions - I2NSF Flow Security Policy Structure
draft-ietf-i2nsf-capability-04: Information Model
of NSFs Capabilities - Design Principles and ECA
Policy Model Overview
draft-hong-i2nsf-nsf-monitoring-data-model-06: A YANG
Data Model for Monitoring I2NSF Network Security
Functions - System Alarm and System Events";
leaf syn-flood-action { leaf-list system-event-capa {
type boolean; type identityref {
description base system-event-capa;
"syn-flood-action capability";
}
leaf udp-flood-action {
type boolean;
description
"udp-flood-action capability";
}
leaf http-flood-action {
type boolean;
description
"http-flood-action capability";
}
leaf https-flood-action {
type boolean;
description
"https-flood-action capability";
}
leaf dns-request-flood-action {
type boolean;
description
"dns-request-flood-action capability";
}
leaf dns-reply-flood-action {
type boolean;
description
"dns-reply-flood-action capability";
}
leaf icmp-flood-action {
type boolean;
description
"icmp-flood-action capability";
}
leaf sip-flood-action {
type boolean;
description
"sip-flood-action capability";
}
leaf detect-mode {
type boolean;
description
"detect mode capability";
}
leaf baseline-learn {
type boolean;
description
"baseline-learn capability";
}
} }
description
"Capabilities for a system event";
}
container ips { leaf-list system-alarm-capa {
description type identityref {
"ips"; base system-alarm-capa;
leaf signature-set {
type boolean;
description
"signature-set capability";
}
leaf exception-signature {
type boolean;
description
"exception-signature capability";
}
} }
description
"Capabilities for a system alarm";
} }
} }
grouping i2nsf-con-sec-control-caps { container condition-capabilities {
description description
"i2nsf-con-sec-control-caps"; "Capabilities of conditions.";
container con-sec-control-capabilities { container generic-nsf-capabilities {
description description
"content-security-control-capabilities"; "Capabilities of conditions.
If a network security function has
the condition capabilities, the network security function
supports rule execution according to conditions of IPv4,
IPv6, foruth layer, ICMP, and payload.";
reference
"RFC 791: Internet Protocol
RFC 792: Internet Control Message Protocol
RFC 793: Transmission Control Protocol
RFC 2460: Internet Protocol, Version 6 (IPv6)
Specification - Next Header
RFC 8329: Framework for Interface to Network Security
Functions - I2NSF Flow Security Policy Structure
draft-ietf-i2nsf-capability-04: Information Model
of NSFs Capabilities - Design Principles and ECA Policy
Model Overview";
leaf anti-virus { leaf-list ipv4-capa {
type boolean; type identityref {
description base ipv4-capa;
"antivirus"; }
}
leaf ips {
type boolean;
description description
"ips"; "Capabilities for an IPv4 packet";
reference
"RFC 791: Internet Protocol";
} }
leaf ids { leaf-list ipv6-capa {
type boolean; type identityref {
base ipv6-capa;
}
description description
"ids"; "Capabilities for an IPv6 packet";
reference
"RFC 2460: Internet Protocol, Version 6 (IPv6)
Specification - Next Header";
} }
leaf url-filter { leaf-list tcp-capa {
type boolean; type identityref {
description base tcp-capa;
"url-filter"; }
}
leaf data-filter {
type boolean;
description description
"data-filter"; "Capabilities for a tcp packet";
reference
"RFC 793: Transmission Control Protocol";
} }
leaf mail-filter {
type boolean; leaf-list udp-capa {
type identityref {
base udp-capa;
}
description description
"mail-filter"; "Capabilities for an udp packet";
reference
"RFC 768: User Datagram Protocol";
} }
leaf sql-filter {
type boolean; leaf-list icmp-capa {
type identityref {
base icmp-capa;
}
description description
"sql-filter"; "Capabilities for an ICMP packet";
reference
"RFC 2460: Internet Protocol, Version 6 (IPv6) ";
} }
leaf file-blocking { }
type boolean;
container advanced-nsf-capabilities {
description
"Capabilities of advanced network security functions,
such as anti virus, anti DDoS, IPS, and VoIP/VoLTE.";
reference
"RFC 8329: Framework for Interface to Network Security
Functions - Differences from ACL Data Models
draft-dong-i2nsf-asf-config-01: Configuration of
Advanced Security Functions with I2NSF Security
Controller";
leaf-list antivirus-capa {
type identityref {
base antivirus-capa;
}
description description
"file-blocking"; "Capabilities for an antivirus";
reference
"draft-dong-i2nsf-asf-config-01: Configuration of
Advanced Security Functions with I2NSF Security
Controller";
} }
leaf file-isolate {
type boolean; leaf-list antiddos-capa {
type identityref {
base antiddos-capa;
}
description description
"file-isolate"; "Capabilities for an antiddos";
reference
"draft-dong-i2nsf-asf-config-01: Configuration of
Advanced Security Functions with I2NSF Security
Controller";
} }
leaf pkt-capture {
type boolean; leaf-list ips-capa {
type identityref {
base ips-capa;
}
description description
"pkt-capture"; "Capabilities for an ips";
reference
"draft-dong-i2nsf-asf-config-01: Configuration of
Advanced Security Functions with I2NSF Security
Controller";
} }
leaf application-behavior {
type boolean; leaf-list http-capa {
type identityref {
base http-capa;
}
description description
"application-behavior"; "Capabilities for a http";
reference
"draft-dong-i2nsf-asf-config-01: Configuration of
Advanced Security Functions with I2NSF Security
Controller";
} }
leaf voip-volte {
type boolean; leaf-list voip-volte-capa {
type identityref {
base voip-volte-capa;
}
description description
"voip-volte"; "Capabilities for a voip and volte";
reference
"draft-dong-i2nsf-asf-config-01: Configuration of
Advanced Security Functions with I2NSF Security
Controller";
} }
} }
} }
container action-capabilities {
grouping i2nsf-attack-mitigation-control-caps {
description description
"i2nsf-attack-mitigation-control-caps"; "Capabilities of actions.
If network security function has
container attack-mitigation-capabilities { the action capabilities, the network security function
description supports rule execution according to actions.";
"attack-mitigation-capabilities";
choice attack-mitigation-control-type {
description
"attack-mitigation-control-type";
case ddos-attack {
description
"ddos-attack";
choice ddos-attack-type {
description
"ddos-attack-type";
case network-layer-ddos-attack {
description
"network-layer-ddos-attack";
container network-layer-ddos-attack-types {
description
"network-layer-ddos-attack-type";
leaf syn-flood-attack {
type boolean;
description
"syn-flood-attack";
}
leaf udp-flood-attack {
type boolean;
description
"udp-flood-attack";
}
leaf icmp-flood-attack {
type boolean;
description
"icmp-flood-attack";
}
leaf ip-fragment-flood-attack {
type boolean;
description
"ip-fragment-flood-attack";
}
leaf ipv6-related-attack {
type boolean;
description
"ip-fragment-flood-attack";
}
}
}
case app-layer-ddos-attack {
description
"app-layer-ddos-attack";
container app-layer-ddos-attack-types {
description
"app-layer-ddos-attack-types";
leaf http-flood-attack {
type boolean;
description
"http-flood-attack";
}
leaf https-flood-attack {
type boolean;
description
"https-flood-attack";
}
leaf dns-flood-attack {
type boolean;
description
"dns-flood-attack";
}
leaf dns-amp-flood-attack {
type boolean;
description
"dns-amp-flood-attack";
}
leaf ssl-flood-attack {
type boolean;
description
"ssl-flood-attack";
}
}
}
}
}
case single-packet-attack { leaf-list ingress-action-capa {
description type identityref {
"single-packet-attack"; base ingress-action-capa;
choice single-packet-attack-type {
description
"single-packet-attack-type";
case scan-and-sniff-attack {
description
"scan-and-sniff-attack";
leaf ip-sweep-attack {
type boolean;
description
"ip-sweep-attack";
}
leaf port-scanning-attack {
type boolean;
description
"port-scanning-attack";
}
}
case malformed-packet-attack {
description
"malformed-packet-attack";
leaf ping-of-death-attack {
type boolean;
description
"ping-of-death-attack";
}
leaf teardrop-attack {
type boolean;
description
"teardrop-attack";
}
}
case special-packet-attack {
description
"special-packet-attack";
leaf oversized-icmp-attack {
type boolean;
description
"oversized-icmp-attack";
}
leaf tracert-attack {
type boolean;
description
"tracert-attack";
}
}
}
}
} }
}
}
list nsf {
key "nsf-name";
description
"nsf-name";
leaf nsf-name {
type string;
mandatory true;
description description
"nsf-name"; "Capabilities for an action";
} }
uses capabilities-information; leaf-list egress-action-capa {
type identityref {
container generic-nsf-capabilities { base egress-action-capa;
description }
"generic-nsf-capabilities";
uses i2nsf-net-sec-caps;
}
container advanced-nsf-capabilities {
description description
"advanced-nsf-capabilities"; "Capabilities for an egress action";
uses i2nsf-advanced-sec-caps;
} }
container complete-nsf-capabilities { leaf-list log-action-capa {
type identityref {
base log-action-capa;
}
description description
"generic-nsf-capabilities"; "Capabilities for a log action";
uses i2nsf-con-sec-control-caps;
uses i2nsf-attack-mitigation-control-caps;
} }
} }
rpc call-appropriate-nsf { leaf-list resolution-strategy-capabilities {
type identityref {
base resolution-strategy-capa;
}
description description
"We can acquire appropriate NSF that we want "Capabilities for a resolution strategy.
If we give type of NSF that we want to use, The resolution strategies can be used to
we acquire the location information of NSF"; specify how to resolve conflicts that occur between
the actions of the same or different policy rules that
are matched and contained in this particular NSF";
reference
"draft-ietf-i2nsf-capability-04: Information Model
of NSFs Capabilities - Resolution strategy";
}
input { leaf-list default-action-capabilities {
leaf nsf-type { type identityref {
type nsf-type; base default-action-capa;
mandatory true;
description
"This is used to acquire NSF
This is mandatory";
}
uses i2nsf-it-resources;
}
output {
uses i2nsf-nsf-location;
} }
} description
"Capabilities for a default action.
A default action is used to execute I2NSF policy rule
when no rule matches a packet. The default action is
defined as pass, drop, reject, alert, and mirror.";
reference
"draft-ietf-i2nsf-capability-04: Information Model
of NSFs Capabilities - Default action";
}
} }
<CODE ENDS> /*
* Data nodes
*/
Figure 12: YANG Data Module of I2NSF Capability container nsf {
description
"The list of capabilities of
network security function";
uses nsf-capabilities;
}
}
8. IANA Considerations <CODE ENDS>
No IANA considerations exist for this document at this time. URL Figure 3: YANG Data Module of I2NSF Capability
will be added.
9. Security Considerations 7. IANA Considerations
This document introduces no additional security threats and SHOULD This document requests IANA to register the following URI in the
follow the security requirements as stated in [RFC8329]. "IETF XML Registry" [RFC3688]:
10. References URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability
10.1. Normative References Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
This document requests IANA to register the following YANG module in
the "YANG Module Names" registry [RFC7950].
name: ietf-i2nsf-capability
namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability
prefix: iicapa
reference: RFC XXXX
8. Security Considerations
The YANG module specified in this document defines a data schema
designed to be accessed through network management protocols such as
NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is
the secure transport layer, and the required transport secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the required transport secure transport is TLS
[RFC8446].
The NETCONF access control model [RFC8341] provides a means of
restricting access to specific NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.
9. References
9.1. Normative References
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020, Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010. October 2010.
[RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG
Data Model Documents", RFC 6087, DOI 10.17487/RFC6087,
January 2011, <https://www.rfc-editor.org/info/rfc6087>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>.
[RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language",
RFC 7950, August 2016. RFC 7950, August 2016.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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
(I2NSF): Problem Statement and Use Cases", RFC 8192, July (I2NSF): Problem Statement and Use Cases", RFC 8192, July
2017. 2017.
[RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
Kumar, "Framework for Interface to Network Security Kumar, "Framework for Interface to Network Security
Functions", RFC 8329, February 2018. Functions", RFC 8329, February 2018.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8431] Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini, [RFC8431] Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini,
S., and N. Bahadur, "A YANG Data Model for Routing S., and N. Bahadur, "A YANG Data Model for Routing
Information Base (RIB)", RFC RFC8431, September 2018. Information Base (RIB)", RFC RFC8431, September 2018.
10.2. Informative References [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
9.2. Informative References
[i2nsf-advanced-nsf-dm] [i2nsf-advanced-nsf-dm]
Pan, W. and L. Xia, "Configuration of Advanced Security Pan, W. and L. Xia, "Configuration of Advanced Security
Functions with I2NSF Security Controller", draft-dong- Functions with I2NSF Security Controller", draft-dong-
i2nsf-asf-config-01 (work in progress), October 2018. i2nsf-asf-config-01 (work in progress), October 2018.
[i2nsf-nsf-cap-im] [i2nsf-nsf-cap-im]
Xia, L., Strassner, J., Basile, C., and D. Lopez, Xia, L., Strassner, J., Basile, C., and D. Lopez,
"Information Model of NSFs Capabilities", draft-ietf- "Information Model of NSFs Capabilities", draft-ietf-
i2nsf-capability-04 (work in progress), October 2018. i2nsf-capability-04 (work in progress), October 2018.
[i2nsf-nsf-yang] [i2nsf-nsf-yang]
Kim, J., Jeong, J., Park, J., Hares, S., and Q. Lin, Kim, J., Jeong, J., Park, J., Hares, S., and Q. Lin,
"I2NSF Network Security Function-Facing Interface YANG "I2NSF Network Security Function-Facing Interface YANG
Data Model", draft-ietf-i2nsf-nsf-facing-interface-dm-01 Data Model", draft-ietf-i2nsf-nsf-facing-interface-dm-01
(work in progress), July 2018. (work in progress), July 2018.
[i2nsf-sfc]
Hyun, S., Jeong, J., Park, J., and S. Hares, "Service
Function Chaining-Enabled I2NSF Architecture", draft-hyun-
i2nsf-nsf-triggered-steering-06 (work in progress), July
2018.
[i2nsf-terminology] [i2nsf-terminology]
Hares, S., Strassner, J., Lopez, D., Xia, L., and H. Hares, S., Strassner, J., Lopez, D., Xia, L., and H.
Birkholz, "Interface to Network Security Functions (I2NSF) Birkholz, "Interface to Network Security Functions (I2NSF)
Terminology", draft-ietf-i2nsf-terminology-06 (work in Terminology", draft-ietf-i2nsf-terminology-07 (work in
progress), July 2018. progress), January 2019.
[Policy-Reconciliation]
Basile, C., Lioy, A., Pitscheider, C., and S. Zhao, "A
Formal Model of Policy Reconciliation",
Euromicro Euromicro International Conference on Parallel,
Distributed and Network-Based Processing (PDP), March
2015.
[supa-policy-info-model] [supa-policy-info-model]
Strassner, J., Halpern, J., and S. Meer, "Generic Policy Strassner, J., Halpern, J., and S. Meer, "Generic Policy
Information Model for Simplified Use of Policy Information Model for Simplified Use of Policy
Abstractions (SUPA)", draft-ietf-supa-generic-policy-info- Abstractions (SUPA)", draft-ietf-supa-generic-policy-info-
model-03 (work in progress), May 2017. model-03 (work in progress), May 2017.
Appendix A. Example: Extended VoIP-VoLTE Security Function Capabilities Appendix A. Changes from draft-ietf-i2nsf-capability-data-model-02
Module
This section gives a simple example of how VoIP-VoLTE Security
Function Capabilities module could be extended.
module
ex-voip-volte-capa {
namespace "http://example.com/voip-volte-capa";
prefix "voip-volte-capa";
import ietf-i2nsf-capability {
prefix capa;
}
augment "/capa:nsf/capa:generic-nsf-capabilities/"
+ "capa:net-sec-control-capabilities/"
+ "capa:condition/capa:condition-type" {
case voice-condition {
leaf sip-header-method {
type boolean;
description
"SIP header method.";
}
leaf sip-header-uri {
type boolean;
description
"SIP header URI.";
}
leaf sip-header-from {
type boolean;
description
"SIP header From.";
}
leaf sip-header-to {
type boolean;
description
"SIP header To.";
}
leaf sip-header-expire-time {
type boolean;
description
"SIP header expire time.";
}
leaf sip-header-user-agent {
type boolean;
description
"SIP header user agent.";
}
}
}
}
Figure 13: Example: Extended VoIP-VoLTE Security Function
Capabilities Module
Appendix B. Example: Configuration XML of Capability Module
This section gives a xml examples for a configuration of Capability
module according to a requirement.
B.1. Example: Configuration XML of Generic Network Security Function
Capabilities
This section gives a xml example for generic network security
function capability configuration according to a requirement.
Requirement: Register packet filter according to requirements.
1. The location of the NSF is 221.159.112.150.
2. The NSF can obtain the best effect if the packet was generated by
PC or IoT.
3. The NSF can apply policies according to time.
4. The NSF should be able to block the source packets or destination
packets with IPv4 address.
5. The NSF should be able to pass, reject, or alert packets.
6. Here is XML example for the generic network security function
capability configuration:
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running />
</target>
<config>
<nsf xmlns="urn:ietf:params:xml:ns:yang:" +
"ietf-i2nsf-capability">
<nsf-name>Huawei-Firewall</nsf-name>
<nsf-address>
<ipv4-address>221.159.112.150</ipv4-address>
</nsf-address>
<target-device>
<pc>true</pc>
</target-device>
<target-device>
<iot>true</iot>
</target-device>
<generic-nsf-capabilities>
<net-sec-control-capabilities>
<nsc-capabilities-name>ipv4-packet-filter<nsc-capabilities-name>
<time-zone>
<start-time>true</start-time>
<end-time>true</end-time>
</time-zone>
<condition>
<packet-security-ipv4-condition>
<pkt-sec-cond-ipv4-src>true</pkt-sec-cond-ipv4-src>
<pkt-sec-cond-ipv4-dest>true</pkt-sec-cond-ipv4-dest>
</packet-security-ipv4-condition>
</condition>
<action>
<ingress-action-type>
<pass>true</pass>
<reject>true</reject>
<alert>true</alert>
</ingress-action-type>
</action>
</net-sec-control-capabilities>
</generic-nsf-capabilities>
</nsf>
</config>
</edit-config>
</rpc>
Figure 14: Example: Configuration XML for Generic Network Security
Function Capability
B.2. Example: Configuration XML of Extended VoIP/VoLTE Security
Function Capabilities Module
This section gives a xml example for extended VoIP-VoLTE security
function capabilities (See Figure 13) configuration according to a
requirement.
Requirement: Register VoIP/VoLTe security function according to
requirements.
1. The location of the NSF is 221.159.112.151.
2. The NSF can obtain the best effect if the packet was generated by
VoIP-VoLTE phone.
3. The NSF should be able to block the malicious sip packets with
user agent.
4. The NSF should be able to pass, reject, or alert packets. The following changes are made from draft-ietf-i2nsf-capability-data-
model-03:
Here is XML example for the VoIP-VoLTE security function capabilities o We revised this YANG data module according to guidelines for
configuration: authors and reviewers of YANG data model documents [RFC6087].
<?xml version="1.0" encoding="UTF-8"?> o We changed the structure of the overall YANG data module.
<rpc message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running />
</target>
<config>
<nsf xmlns="urn:ietf:params:xml:ns:yang:" +
"ietf-i2nsf-capability">
<nsf-name>Cisco-VoIP-VoLTE</nsf-name>
<nsf-address>
<ipv4-address>221.159.112.151</ipv4-address>
</nsf-address>
<generic-nsf-capabilities>
<net-sec-control-capabilities>
<nsc-capabilities-name>sip-packet-filter<nsc-capabilities-name>
<condition>
<sip-header-user-agent>true</sip-header-user-agent>
</condition>
<action>
<ingress-action-type>
<pass>true</pass>
<reject>true</reject>
<alert>true</alert>
</ingress-action-type>
</action>
</net-sec-control-capabilities>
</generic-nsf-capabilities>
</nsf>
</config>
</edit-config>
</rpc>
Figure 15: Example: Configuration XML for Extended VoIP/VoLTE o We changed enumeration type to identity type for scalable
Security Function Capabilities components.
Appendix C. Changes from draft-ietf-i2nsf-capability-data-model-01 o We added a description for the YANG tree diagram of the YANG data
module.
The following changes are made from draft-ietf-i2nsf-capability-data- o We revised overall sentences of this YANG data model document.
model-01:
o We added capabilities of advanced network security functions such o We added configuration examples to make it easier for reviewers to
as anti-virus, anti-ddos, and IPS. understand.
Appendix D. Acknowledgments Appendix B. Acknowledgments
This work was supported by Institute for Information & communications This work was supported by Institute for Information & communications
Technology Promotion (IITP) grant funded by the Korea government Technology Promotion (IITP) grant funded by the Korea government
(MSIP) (No.R-20160222-002755, Cloud based Security Intelligence (MSIP) (No.R-20160222-002755, Cloud based Security Intelligence
Technology Development for the Customized Security Service Technology Development for the Customized Security Service
Provisioning). Provisioning).
Appendix E. Contributors Appendix C. Contributors
This document is made by the group effort of I2NSF working group. This document is made by the group effort of I2NSF working group.
Many people actively contributed to this document. The following are Many people actively contributed to this document. The following are
considered co-authors: considered co-authors:
o Hyoungshick Kim (Sungkyunkwan University) o Hyoungshick Kim (Sungkyunkwan University)
o Daeyoung Hyun (Sungkyunkwan University) o Daeyoung Hyun (Sungkyunkwan University)
o Dongjin Hong (Sungkyunkwan University) o Dongjin Hong (Sungkyunkwan University)
 End of changes. 240 change blocks. 
2454 lines changed or deleted 1418 lines changed or added

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