draft-ietf-i2nsf-consumer-facing-interface-dm-09.txt   draft-ietf-i2nsf-consumer-facing-interface-dm-10.txt 
I2NSF Working Group J. Jeong I2NSF Working Group J. Jeong, Ed.
Internet-Draft C. Chung Internet-Draft C. Chung
Intended status: Standards Track Sungkyunkwan University Intended status: Standards Track Sungkyunkwan University
Expires: January 14, 2021 T. Ahn Expires: March 1, 2021 T. Ahn
Korea Telecom Korea Telecom
R. Kumar R. Kumar
Juniper Networks Juniper Networks
S. Hares S. Hares
Huawei Huawei
July 13, 2020 August 28, 2020
I2NSF Consumer-Facing Interface YANG Data Model I2NSF Consumer-Facing Interface YANG Data Model
draft-ietf-i2nsf-consumer-facing-interface-dm-09 draft-ietf-i2nsf-consumer-facing-interface-dm-10
Abstract Abstract
This document describes an information model and a YANG data model This document describes an information model and a YANG data model
for the Consumer-Facing Interface between an Interface to Network for the Consumer-Facing Interface between an Interface to Network
Security Functions (I2NSF) User and Security Controller in an I2NSF Security Functions (I2NSF) User and Security Controller in an I2NSF
system in a Network Functions Virtualization (NFV) environment. The system in a Network Functions Virtualization (NFV) environment. The
information model defines various types of managed objects and the information model defines various types of managed objects and the
relationship among them needed to build the interface. The relationship among them needed to build the interface. The
information model is organized based on the "Event-Condition-Action" information model is based on the "Event-Condition-Action" (ECA)
(ECA) policy model defined by a capability information model for policy model defined by a capability information model for I2NSF
I2NSF [i2nsf-capability-im], and the data model is defined for [I-D.ietf-i2nsf-capability], and the data model is defined for
enabling different users of a given I2NSF system to define, manage, enabling different users of a given I2NSF system to define, manage,
and monitor security policies for specific flows within an and monitor security policies for specific flows within an
administrative domain. administrative domain.
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 January 14, 2021. This Internet-Draft will expire on March 1, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Information Model for Policy . . . . . . . . . . . . . . . . 5 4. Information Model for Policy . . . . . . . . . . . . . . . . 5
4.1. Event Sub-model . . . . . . . . . . . . . . . . . . . . . 7 4.1. Event Sub-model . . . . . . . . . . . . . . . . . . . . . 7
4.2. Condition Sub-model . . . . . . . . . . . . . . . . . . . 8 4.2. Condition Sub-model . . . . . . . . . . . . . . . . . . . 8
4.3. Action Sub-model . . . . . . . . . . . . . . . . . . . . 9 4.3. Action Sub-model . . . . . . . . . . . . . . . . . . . . 9
5. Information Model for Policy Endpoint Groups . . . . . . . . 9 5. Information Model for Policy Endpoint Groups . . . . . . . . 10
5.1. User Group . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. User Group . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Device Group . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Device Group . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Location Group . . . . . . . . . . . . . . . . . . . . . 12 5.3. Location Group . . . . . . . . . . . . . . . . . . . . . 13
6. Information Model for Threat Prevention . . . . . . . . . . . 13 6. Information Model for Threat Prevention . . . . . . . . . . . 14
6.1. Threat Feed . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Threat Feed . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Payload Content . . . . . . . . . . . . . . . . . . . . . 14 6.2. Payload Content . . . . . . . . . . . . . . . . . . . . . 15
7. Network Configuration Access Control Model (NACM) for I2NSF 7. Network Configuration Access Control Model (NACM) for I2NSF
Consumer-Facing Interface . . . . . . . . . . . . . . . . . . 15 Consumer-Facing Interface . . . . . . . . . . . . . . . . . . 16
8. YANG Data Model of Consumer-Facing Interface . . . . . . . . 17 8. YANG Data Model of Consumer-Facing Interface . . . . . . . . 18
8.1. YANG Module of Consumer-Facing Interface . . . . . . . . 18
9. XML Configuration Examples of High-Level Security Policy 9. XML Configuration Examples of High-Level Security Policy
Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
9.1. Database Registration: Information of Positions and 9.1. Database Registration: Information of Positions and
Devices (Endpoint Group) . . . . . . . . . . . . . . . . 40 Devices (Endpoint Group) . . . . . . . . . . . . . . . . 41
9.2. Scenario 1: Block SNS Access during Business Hours . . . 41 9.2. Scenario 1: Block SNS Access during Business Hours . . . 43
9.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to 9.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to
a Company . . . . . . . . . . . . . . . . . . . . . . . . 43 a Company . . . . . . . . . . . . . . . . . . . . . . . . 45
9.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a 9.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a
Company Web Server . . . . . . . . . . . . . . . . . . . 45 Company Web Server . . . . . . . . . . . . . . . . . . . 47
10. XML Configuration Example of a User Group's Access Control 10. XML Configuration Example of a User Group's Access Control
for I2NSF Consumer-Facing Interface . . . . . . . . . . . . . 46 for I2NSF Consumer-Facing Interface . . . . . . . . . . . . . 48
11. Security Considerations . . . . . . . . . . . . . . . . . . . 48 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 12. Security Considerations . . . . . . . . . . . . . . . . . . . 50
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 48 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
15.1. Normative References . . . . . . . . . . . . . . . . . . 51 15.1. Normative References . . . . . . . . . . . . . . . . . . 53
15.2. Informative References . . . . . . . . . . . . . . . . . 52 15.2. Informative References . . . . . . . . . . . . . . . . . 56
Appendix A. Changes from draft-ietf-i2nsf-consumer-facing- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56
interface-dm-08 . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53
1. Introduction 1. Introduction
In a framework of Interface to Network Security Functions (I2NSF), In a framework of Interface to Network Security Functions (I2NSF)
each vendor can register their NSFs using a Developer's Management [RFC8329], each vendor can register their NSFs using a Developer's
System (DMS). Assuming that vendors also provide the front-end web Management System (DMS). Assuming that vendors also provide the
applications registered with an I2NSF User, the Consumer-Facing front-end web applications registered with an I2NSF User, the
Interface is required because the web applications developed by each Consumer-Facing Interface is required because the web applications
vendor need to have a standard interface specifying the data types developed by each vendor need to have a standard interface specifying
used when the I2NSF User and Security Controller communicate using the data types used when the I2NSF User and Security Controller
this interface. Therefore, this document specifies the required communicate using this interface. Therefore, this document specifies
information, their data types, and encoding schemes so that high- the required information, their data types, and encoding schemes so
level security policies (or configuration information for security that high-level security policies (or configuration information for
policies) can be transferred to the Security Controller through the security policies) can be transferred to the Security Controller
Consumer-Facing Interface. These policies can easily be translated through the Consumer-Facing Interface. These policies can easily be
by the Security Controller into low-level security policies. The translated by the Security Controller into low-level security
Security Controller delivers the translated policies to Network policies. The Security Controller delivers the translated policies
Security Functions (NSFs) according to their respective security to Network Security Functions (NSFs) according to their respective
capabilities for the required securiy enforcement. security capabilities for the required securiy enforcement.
The Consumer-Facing Interface would be built using a set of objects, The Consumer-Facing Interface would be built using a set of objects,
with each object capturing a unique set of information from Security with each object capturing a unique set of information from Security
Administrator (i.e., I2NSF User [RFC8329]) needed to express a Administrator (i.e., I2NSF User [RFC8329]) needed to express a
Security Policy. An object may have relationship with various other Security Policy. An object may have relationship with various other
objects to express a complete set of requirements. An information objects to express a complete set of requirements. An information
model captures the managed objects and relationship among these model captures the managed objects and relationship among these
objects. The information model proposed in this document is objects. The information model proposed in this document is
structured in accordance with the "Event-Condition-Action" (ECA) structured in accordance with the "Event-Condition-Action" (ECA)
policy model. policy model.
An NSF Capability model is proposed in [i2nsf-capability-im] as the An NSF Capability model is proposed in [I-D.ietf-i2nsf-capability] as
basic model for both the NSF-Facing interface and Consumer-Facing the basic model for both the NSF-Facing interface and Consumer-Facing
Interface security policy model of this document. Interface security policy model of this document.
[RFC3444] explains differences between an information and data model. [RFC3444] explains differences between an information and data model.
This document uses the guidelines in [RFC3444] to define both the This document uses the guidelines in [RFC3444] to define both the
information and data model for Consumer-Facing Interface. Figure 1 information and data model for Consumer-Facing Interface. Figure 1
shows a high-level abstraction of Consumer-Facing Interface. A data shows a high-level abstraction of Consumer-Facing Interface. A data
model, which represents an implementation of the information model in model, which represents an implementation of the information model in
a specific data representation language, is also defined in this a specific data representation language, is also defined in this
document. document.
+-----------------+ +-----------------+ +-----------------+
| Consumer-Facing | | Consumer-Facing | | Consumer-Facing |
| Interface +--->+ Interface | | Interface |
|Information Model| | Data Model | +--------+--------+
+--------+--------+ +-----------------+
^ ^
| |
+-------------+------------+ +-------------+------------+
| | | | | |
+-----+----+ +-----+----+ +----+----+ +-----+----+ +-----+----+ +----+----+
| Policy | | Endpoint | | Threat | | Policy | | Endpoint | | Threat |
| | | groups | | feed | | | | groups | | feed |
+-----+----+ +----------+ +---------+ +-----+----+ +----------+ +---------+
^ ^
| |
skipping to change at page 5, line 9 skipping to change at page 5, line 9
mitigation, can also be provided as Virtual Network Functions (VNF) mitigation, can also be provided as Virtual Network Functions (VNF)
in the NFV system. By the efficient virtualization technology, these in the NFV system. By the efficient virtualization technology, these
VNFs might be automatically provisioned and dynamically migrated VNFs might be automatically provisioned and dynamically migrated
based on real-time security requirements. This document presents a based on real-time security requirements. This document presents a
YANG data model to implement security functions based on NFV. YANG data model to implement security functions based on NFV.
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 RFC 2119 [RFC3444] document are to be interpreted as described in [RFC2119][RFC3444]
RFC8174 [RFC8174]. [RFC8174].
3. Terminology 3. Terminology
This document uses the terminology described in [i2nsf-terminology] This document uses the terminology described in [RFC8329].
[client-facing-inf-req].
This document follows the guidelines of [RFC8407], uses the common This document follows the guidelines of [RFC8407], uses the common
YANG types defined in [RFC6991], and adopts the Network Management YANG types defined in [I-D.ietf-netmod-rfc6991-bis], and adopts the
Datastore Architecture (NMDA). The meaning of the symbols in tree Network Management Datastore Architecture (NMDA). The meaning of the
diagrams is defined in [RFC8340]. symbols in tree diagrams is defined in [RFC8340].
4. Information Model for Policy 4. Information Model for Policy
A Policy object represents a mechanism to express a Security Policy A Policy object represents a mechanism to express a Security Policy
by Security Administrator (i.e., I2NSF User) using Consumer-Facing by Security Administrator (i.e., I2NSF User) using Consumer-Facing
Interface toward Security Controller; the policy would be enforced on Interface toward Security Controller; the policy would be enforced on
an NSF. Figure 2 shows the YANG tree of the Policy object. The an NSF. Figure 2 shows the YANG tree of the Policy object. The
Policy object SHALL have the following information: Policy object SHALL have the following information:
Name: This field identifies the name of this object. Name: This field identifies the name of this object.
Rule: This field contains a list of rules. These rules are Rule: This field contains a list of rules. These rules are
defined for 1) communication between two Endpoint Groups, defined for 1) communication between two Endpoint Groups,
2) for preventing communication with externally or 2) for preventing communication with externally or
internally identified threats, and 3) for implementing internally identified threats, and 3) for implementing
business requirement such as controlling access to internal business requirement such as controlling access to internal
or external resources for meeting regulatory compliance or or external resources for meeting regulatory compliance or
business objectives. An organization may restrict certain business objectives. An organization may restrict certain
communication between a set of user and applications for communication between a set of user and applications for
example. The threats may be from threat feeds obtained example. The threats may be from threat feeds obtained
from external sources or dynamically identified by using from external sources or dynamically identified by using
specialty devices in the network. Rule conflict analysis specialty devices in the network. Rule conflict analysis
skipping to change at page 6, line 23 skipping to change at page 6, line 23
A policy is a container of Rule(s). In order to express a Rule, a A policy is a container of Rule(s). In order to express a Rule, a
Rule must have complete information such as where and when a policy Rule must have complete information such as where and when a policy
needs to be applied. This is done by defining a set of managed needs to be applied. This is done by defining a set of managed
objects and relationship among them. A Policy Rule may be related objects and relationship among them. A Policy Rule may be related
segmentation, threat mitigation or telemetry data collection from an segmentation, threat mitigation or telemetry data collection from an
NSF in the network, which will be specified as the sub-model of the NSF in the network, which will be specified as the sub-model of the
policy model in the subsequent sections. Figure 3 shows the YANG policy model in the subsequent sections. Figure 3 shows the YANG
data tree of the Rule object. The rule object SHALL have the data tree of the Rule object. The rule object SHALL have the
following information: following information:
Name: This field identifies the name of this object. Name: This field identifies the name of this object.
Event: This field includes the information to determine whether Event: This field includes the information to determine whether
the Rule Condition can be evaluated or not. See details in the Rule Condition can be evaluated or not. See details in
Section 4.1. Section 4.1.
Condition: This field contains all the checking conditions to Condition: This field contains all the checking conditions to
apply to the objective traffic. See details in apply to the objective traffic. See details in
Section 4.2. Section 4.2.
Action: This field identifies the action taken when a rule is Action: This field identifies the action taken when a rule is
matched. There is always an implicit action to drop matched. There is always an implicit action to drop
traffic if no rule is matched for a traffic type. See traffic if no rule is matched for a traffic type. See
details in Section 4.3. details in Section 4.3.
IPsec-Method: This field contains the information about IPsec IPsec-method: This field contains the information about IPsec
method type. There are two types such as IPsec-IKE and method type. There are two types such as IPsec-IKE and
IPsec-IKEless [i2nsf-ipsec]. IPsec-IKEless [I-D.ietf-i2nsf-sdn-ipsec-flow-protection].
+--rw rules* [rule-name] +--rw rules* [rule-name]
+--rw rule-name string +--rw rule-name string
+--rw event +--rw event
+--rw (condition)? +--rw (condition)?
+--rw action +--rw action
+--rw ipsec-method +--rw ipsec-method
Figure 3: Rule YANG Data Tree Figure 3: Rule YANG Data Tree
Note that in the case of policy conflicts, the resolution of the Note that in the case of policy conflicts, the resolution of the
conflicted policies conforms to the guidelines of "Information Model conflicted policies conforms to the guidelines of "Information Model
of NSFs Capabilities" [i2nsf-capability-im]. of NSFs Capabilities" [I-D.ietf-i2nsf-capability].
4.1. Event Sub-model 4.1. Event Sub-model
The Event Object contains information related to scheduling a Rule. The Event Object contains information related to scheduling a Rule.
The Rule could be activated based on a set time or security event. The Rule could be activated based on a set time or security event.
Figure 4 shows the YANG tree of the Event object. Event object SHALL Figure 4 shows the YANG tree of the Event object. Event object SHALL
have following information: have following information:
Security-event: This field identifies for which security event Security-event: This field identifies for which security event
the policy is enforced. The examples of security events the policy is enforced. The examples of security events
are: "DDOS", "spyware", "trojan", and "ransomware". are: "DDOS", "spyware", "trojan", and "ransomware".
Time-information: This represents the security rule is enforced Time-information: This represents the security rule is enforced
based on the period information with the end time for the based on the period information with the end time for the
event. event.
Period: This represents the period of time the rule event is Period: This represents the period of time the rule event is
active. active.
End-time: This represents the end time of the event. If the rule End-time: This represents the end time of the event. If the
time has pass the end-time, the rule will stop repeating" rule time has pass the end-time, the rule will stop
repeating"
Frequency: This represents how frequent the rule should be Frequency: This represents how frequent the rule should be
enforced. There are four options: "only-once", "daily", enforced. There are four options: "only-once", "daily",
"weekly" and "monthly". "weekly" and "monthly".
+--rw event +--rw event
+--rw security-event identityref +--rw security-event identityref
+--rw time-information +--rw time-information
| +--rw start-date-time? yang:date-and-time | +--rw start-date-time? yang:date-and-time
| +--rw end-date-time? yang:date-and-time | +--rw end-date-time? yang:date-and-time
| +--rw period | +--rw period
| | +--rw start-time? time | | +--rw start-time? time
skipping to change at page 8, line 18 skipping to change at page 8, line 18
to apply the checking on the traffic in order to determine whether to apply the checking on the traffic in order to determine whether
the set of actions in the Rule can be executed or not. The Condition the set of actions in the Rule can be executed or not. The Condition
Sub-model consists of three different types of containers each Sub-model consists of three different types of containers each
representing different cases, such as general firewall and DDoS- representing different cases, such as general firewall and DDoS-
mitigation cases, and a case when the condition is based on the mitigation cases, and a case when the condition is based on the
payload strings of packets. Each containers have source and payload strings of packets. Each containers have source and
destination-target to represent the source and destination for each destination-target to represent the source and destination for each
case. Figure 5 shows the YANG tree of the Condition object. The case. Figure 5 shows the YANG tree of the Condition object. The
Condition Sub-model SHALL have following information: Condition Sub-model SHALL have following information:
Case (Firewall-condition): This field represents the general Case (Firewall-condition): This field represents the general
firewall case, where a security admin can set up firewall firewall case, where a security admin can set up firewall
conditions using the information present in this field. conditions using the information present in this field.
The source and destination is represented as firewall- The source and destination is represented as firewall-
source and firewall-destination, each referring to the IP- source and firewall-destination, each referring to the IP-
address-based groups defined in the endpoint-groups. address-based groups defined in the endpoint-groups.
Case (DDoS-condition): This field represents the condition for Case (DDoS-condition): This field represents the condition for
DDoS mitigation, where a security admin can set up DDoS DDoS mitigation, where a security admin can set up DDoS
mitigation conditions using the information present in this mitigation conditions using the information present in this
field. The source and destination is represented as ddos- field. The source and destination is represented as ddos-
source and ddos-destination, each referring to the device- source and ddos-destination, each referring to the device-
groups defined and registered in the endpoint-groups. groups defined and registered in the endpoint-groups.
Case (Custom-condition): This field contains the payload string Case (Custom-condition): This field contains the payload string
information. This information is useful when security rule information. This information is useful when security rule
condition is based on the string contents of incoming or condition is based on the string contents of incoming or
outgoing packets. The source and destination is outgoing packets. The source and destination is
represented as custom-source and custom-destination, each represented as custom-source and custom-destination, each
referring to the payload-groups defined and registered in referring to the payload-groups defined and registered in
the endpoint-groups. the endpoint-groups.
Case (Threat-feed-condition): This field contains the information Case (Threat-feed-condition): This field contains the
obtained from threat-feeds (e.g., Palo-Alto, or RSA- information obtained from threat-feeds (e.g., Palo-Alto, or
netwitness). This information is useful when security rule RSA-netwitness). This information is useful when security
condition is based on the existing threat reports gathered rule condition is based on the existing threat reports
by other sources. The source and destination is gathered by other sources. The source and destination is
represented as threat-feed-source and threat-feed- represented as threat-feed-source and threat-feed-
destination. For clarity, threat-feed-source/destination destination. For clarity, threat-feed-source/destination
represent the source/destination of a target security represent the source/destination of a target security
threat, not the information source/destination of a threat- threat, not the information source/destination of a threat-
feed. feed.
+--rw condition +--rw condition
+--:firewall-condition +--:firewall-condition
| +--rw source -> /../../user-group/name | +--rw source
| +--rw destination* -> /../../user-group/name | | -> /i2nsf-cfi-policy/endpoint-groups/user-group/name
+--:ddos-condition | +--rw destination*
| +--rw source* -> /../../device-group/name | | -> /i2nsf-cfi-policy/endpoint-groups/user-group/name
| +--rw destination* -> /../../device-group/name +--:ddos-condition
| +--rw rate-limit | +--rw source*
| +--rw packet-threshold-per-second? uint32 | | -> /i2nsf-cfi-policy/endpoint-groups/device-group/name
+--:location-condition | +--rw destination*
| +--rw source* -> /../../location-group/name | | -> /i2nsf-cfi-policy/endpoint-groups/device-group/name
| +--rw destination -> /../../location-group/name | +--rw rate-limit
+--:custom-condition | | +--rw packet-threshold-per-second? uint32
| +--rw source* -> /../../payload-content/name +--:location-condition
| +--rw destination -> /../../payload-content/name | +--rw source*
+--:threat-feed-condition | | -> /i2nsf-cfi-policy/endpoint-groups/location-group/name
+--rw source* -> /../../threat-feed-list/name | +--rw destination
+--rw destination -> /../../threat-feed-list/name | | -> /i2nsf-cfi-policy/endpoint-groups/location-group/name
+--:custom-condition
| +--rw source*
| | -> /i2nsf-cfi-policy/threat-preventions/payload-content/name
| +--rw destination?
| | -> /i2nsf-cfi-policy/threat-preventions/payload-content/name
+--:threat-feed-condition
+--rw source*
| -> /i2nsf-cfi-policy/threat-preventions/threat-feed-list/name
+--rw destination?
| -> /i2nsf-cfi-policy/threat-preventions/threat-feed-list/name
Figure 5: Condition Sub-model YANG Data Tree Figure 5: Condition Sub-model YANG Data Tree
4.3. Action Sub-model 4.3. Action Sub-model
This object represents actions that Security Admin wants to perform This object represents actions that Security Admin wants to perform
based on certain traffic class. Figure 6 shows the YANG tree of the based on certain traffic class. Figure 6 shows the YANG tree of the
Action object. The Action object SHALL have following information: Action object. The Action object SHALL have following information:
Primary-action: This field identifies the action when a rule is Primary-action: This field identifies the action when a rule is
matched by an NSF. The action could be one of "PASS", matched by an NSF. The action could be one of "PASS",
"DROP", "ALERT", "RATE-LIMIT", and "MIRROR". "DROP", "ALERT", "RATE-LIMIT", and "MIRROR".
Secondary-action: This field identifies the action when a rule is Secondary-action: This field identifies the action when a rule
matched by an NSF. The action could be one of "log", is matched by an NSF. The action could be one of "log",
"syslog", "session-log". "syslog", "session-log".
+--rw action +--rw action
+--rw primary-action identityref +--rw primary-action identityref
+--rw secondary-action? identityref +--rw secondary-action? identityref
Figure 6: Action Sub-model YANG Data Tree Figure 6: Action Sub-model YANG Data Tree
5. Information Model for Policy Endpoint Groups 5. Information Model for Policy Endpoint Groups
The Policy Endpoint Group is a very important part of building User- The Policy Endpoint Group is a very important part of building User-
Construct based policies. A Security Administrator would create and Construct based policies. A Security Administrator would create and
use these objects to represent a logical entity in their business use these objects to represent a logical entity in their business
environment, where a Security Policy is to be applied. There are environment, where a Security Policy is to be applied. There are
multiple managed objects that constitute a Policy's Endpoint Group as multiple managed objects that constitute a Policy's Endpoint Group,
shown in Figure 7. Figure 8 shows the YANG tree of the Endpoint- as shown in Figure 7. Figure 8 shows the YANG tree of the Endpoint-
Groups object. This section lists these objects and relationship Groups object. This section lists these objects and relationship
among them. among them.
It is assumed that the information of Endpoint Groups (e.g., User-
group, Device-group, and Location-group) such as the IP address(es)
of each member in a group are stored in the I2NSF database available
to the Security Controller, and that the IP address information of
each group in the I2NSF database is synchronized with other systems
in the networks under the same administration.
+-------------------+ +-------------------+
| Endpoint Groups | | Endpoint Groups |
+---------+---------+ +---------+---------+
^ ^
| |
+--------------+----------------+ +--------------+----------------+
1..n | 1..n | 1..n | 0..n | 0..n | 0..n |
+-----+----+ +------+-----+ +-------+------+ +-----+----+ +------+-----+ +-------+------+
|User-group| |Device-group| |Location-group| |User-group| |Device-group| |Location-group|
+----------+ +------------+ +--------------+ +----------+ +------------+ +--------------+
Figure 7: Endpoint Group Diagram Figure 7: Endpoint Group Diagram
+--rw endpoint-groups +--rw endpoint-groups
| +--rw user-group* [name] | +--rw user-group* [name]
| ... | ...
| +--rw device-group* [name] | +--rw device-group* [name]
skipping to change at page 10, line 39 skipping to change at page 11, line 21
| ... | ...
Figure 8: Endpoint Group YANG Data Tree Figure 8: Endpoint Group YANG Data Tree
5.1. User Group 5.1. User Group
This object represents a User-Group. Figure 9 shows the YANG tree of This object represents a User-Group. Figure 9 shows the YANG tree of
the User-Group object. The User-Group object SHALL have the the User-Group object. The User-Group object SHALL have the
following information: following information:
Name: This field identifies the name of this object. Name: This field identifies the name of this object.
IP-address: This represents the IPv4 address of a user in the IPv4: This represents the IPv4 address of a user in the user
user group. group.
range-ipv4-address: This represents the IPv4 address of a user in IPv6: This represents the IPv6 address of a user in the user
the user gorup. group.
range-ipv6-address: This represents the IPv6 address of a user in Range-ipv4-address: This represents the IPv4 address range of a
the user gorup. user in the user group.
Range-ipv6-address: This represents the IPv6 address range of a
user in the user group.
+--rw user-group* [name] +--rw user-group* [name]
+--rw name string +--rw name string
+--rw (match-type) +--rw (match-type)
+--:(exact-match-ipv4) +--:(exact-match-ipv4)
| +--rw ipv4? inet:ipv4-address | +--rw ipv4? inet:ipv4-address
+--:(exact-match-ipv6) +--:(exact-match-ipv6)
| +--rw ipv6? inet:ipv6-address | +--rw ipv6? inet:ipv6-address
+--:(range-match-ipv4) +--:(range-match-ipv4)
| +--rw range-ipv4-address | +--rw range-ipv4-address
skipping to change at page 11, line 29 skipping to change at page 12, line 29
+--rw end-ipv6-address inet:ipv6-address +--rw end-ipv6-address inet:ipv6-address
Figure 9: User Group YANG Data Tree Figure 9: User Group YANG Data Tree
5.2. Device Group 5.2. Device Group
This object represents a Device-Group. Figure 10 shows the YANG tree This object represents a Device-Group. Figure 10 shows the YANG tree
of the Device-group object. The Device-Group object SHALL have the of the Device-group object. The Device-Group object SHALL have the
following information: following information:
Name: This field identifies the name of this object. Name: This field identifies the name of this object.
IP-address: This represents the IPv4 address of a device in the IPv4: This represents the IPv4 address of a device in the device
device group. group.
range-ipv4-address: This represents the IPv4 address of a device IPv6: This represents the IPv6 address of a device in the device
in the device gorup. group.
range-ipv6-address: This represents the IPv6 address of a device Range-ipv4-address: This represents the IPv4 address range of a
in the device gorup. device in the device group.
Protocol: This represents the communication protocols used by the Range-ipv6-address: This represents the IPv6 address range of a
devices. The protocols are "SSH", "FTP", "SMTP", "HTTP", device in the device group.
"HTTPS", and etc.
Protocol: This represents the communication protocols used by
the devices. The protocols are "SSH", "FTP", "SMTP",
"HTTP", "HTTPS", and etc.
+--rw device-group* [name] +--rw device-group* [name]
+--rw name string +--rw name string
+--rw (match-type) +--rw (match-type)
| +--:(exact-match-ipv4) | +--:(exact-match-ipv4)
| | +--rw ipv4? inet:ipv4-address | | +--rw ipv4? inet:ipv4-address
| +--:(exact-match-ipv6) | +--:(exact-match-ipv6)
| | +--rw ipv6? inet:ipv6-address | | +--rw ipv6? inet:ipv6-address
| +--:(range-match-ipv4) | +--:(range-match-ipv4)
| | +--rw range-ipv4-address* | | +--rw range-ipv4-address*
skipping to change at page 12, line 31 skipping to change at page 13, line 31
Figure 10: Device Group YANG Data Tree Figure 10: Device Group YANG Data Tree
5.3. Location Group 5.3. Location Group
This object represents a location group based on either tag or other This object represents a location group based on either tag or other
information. Figure 11 shows the YANG tree of the Location-Group information. Figure 11 shows the YANG tree of the Location-Group
object. The Location-Group object SHALL have the following object. The Location-Group object SHALL have the following
information: information:
Name: This field identifies the name of this object. Name: This field identifies the name of this object.
geo-ip-ipv4: This field represents the IPv4 Geo-ip of a location. Geo-ip-ipv4: This field represents the IPv4 Geo-ip address of a
location [RFC8805].
geo-ip-ipv6: This field represents the IPv6 Geo-ip of a location. Geo-ip-ipv6: This field represents the IPv6 Geo-ip address of a
location [RFC8805].
continent: This field represents the continent where the location Continent: This field represents the continent where the
group member is at. location group member is located.
+--rw location-group* [name] +--rw location-group* [name]
+--rw name string +--rw name string
+--rw geo-ip-ipv4 inet:ipv4-address +--rw geo-ip-ipv4 inet:ipv4-address
+--rw geo-ip-ipv6 inet:ipv6-address +--rw geo-ip-ipv6 inet:ipv6-address
+--rw continent? identityref +--rw continent? identityref
Figure 11: Location Group YANG Data Tree Figure 11: Location Group YANG Data Tree
6. Information Model for Threat Prevention 6. Information Model for Threat Prevention
skipping to change at page 13, line 21 skipping to change at page 14, line 21
this category. This section lists these objects and relationship this category. This section lists these objects and relationship
among them. Figure 13 shows the YANG tree of a Threat-Prevention among them. Figure 13 shows the YANG tree of a Threat-Prevention
object. object.
+-------------------+ +-------------------+
| Threat Prevention | | Threat Prevention |
+---------+---------+ +---------+---------+
^ ^
| |
+---------+---------+ +---------+---------+
1..n | 1..n | 0..n | 0..n |
+------+------+ +--------+--------+ +------+------+ +--------+--------+
| Threat-feed | | payload-content | | Threat-feed | | payload-content |
+-------------+ +-----------------+ +-------------+ +-----------------+
Figure 12: Threat Prevention Diagram Figure 12: Threat Prevention Diagram
+--rw threat-prevention +--rw threat-prevention
+--rw threat-feed-list* [name] +--rw threat-feed-list* [name]
... ...
+--rw payload-content* [name] +--rw payload-content* [name]
... ...
Figure 13: Threat Prevention YANG Data Tree Figure 13: Threat Prevention YANG Data Tree
6.1. Threat Feed 6.1. Threat Feed
This object represents a threat feed which provides signatures of This object represents a threat feed which provides the signatures of
malicious activities. Figure 14 shows the YANG tree of a Threat- malicious activities. Figure 14 shows the YANG tree of a Threat-
feed-list. The Threat-Feed object SHALL have the following feed-list. The Threat-Feed object SHALL have the following
information: information:
name: This field identifies the name of this object. Name: This field identifies the name of this object.
Server-ipv4: This represents the IPv4 server address of the feed Server-ipv4: This represents the IPv4 server address of the feed
provider, it may be external or local servers. provider, which may be either an external or local server.
Server-ipv6: This represents the IPv6 server address of the feed Server-ipv6: This represents the IPv6 server address of the feed
provider, it may be external or local servers. provider, which may be either an external or local server.
description: This is the description of the threat feed. The Description: This is the description of the threat feed. The
descriptions should have clear indication of the security description should have the clear indication of the
attack such as attack type (e.g., APT) and file types used security attack such as attack type (e.g., APT) and file
(e.g., executable malware). types used (e.g., executable malware).
Threat-file-types: This field identifies the information about Threat-file-types: This field identifies the information about
the file types identified and reported by the threat-feed. the file types identified and reported by the threat-feed.
signatures: This field contains the signatures of malicious Signatures: This field contains the threat signatures of
programs or activities provided by the threat-feed. The malicious programs or activities provided by the threat-
examples of signature types are "YARA", "SURICATA", and feed. The examples of signature types are "YARA",
"SNORT". "SURICATA", and "SNORT" [YARA][SURICATA][SNORT].
It is assumed that the I2NSF User obtains the threat signatures
(i.e., threat content patterns) from a threat-feed server (i.e., feed
provider), which is a server providing threat signatures. With the
obtained threat signatures, the I2NSF User can deliver them to the
Security Controller. The retrieval of the threat signatures by the
I2NSF User is out of scope in this document.
+--rw threat-prevention +--rw threat-prevention
+--rw threat-feed-list* [name] +--rw threat-feed-list* [name]
+--rw name identityref +--rw name identityref
+--rw server-ipv4? inet:ipv4-address +--rw server-ipv4? inet:ipv4-address
+--rw server-ipv6? inet:ipv6-address +--rw server-ipv6? inet:ipv6-address
+--rw description? string +--rw description? string
+--rw threat-file-types* identityref +--rw threat-file-types* identityref
+--rw signatures* identityref +--rw signatures* identityref
Figure 14: Threat Feed YANG Data Tree Figure 14: Threat Feed YANG Data Tree
6.2. Payload Content 6.2. Payload Content
This object represents a custom list created for the purpose of This object represents a custom list created for the purpose of
defining exception to threat feeds. Figure 15 shows the YANG tree of defining an exception to threat feeds. Figure 15 shows the YANG tree
a Payload-content list. The Payload-Content object SHALL have the of a Payload-content list. The Payload-Content object SHALL have the
following information: following information:
Name: This field identifies the name of this object. For Name: This field identifies the name of this object. For
example, the name "backdoor" indicates the payload content example, the name "backdoor" indicates the payload content
is related to backdoor attack. is related to a backdoor attack.
description: This represents the description of how the payload Description: This represents the description of how the payload
content is related to a security attack. content is related to a security attack.
Content: This contains the payload contents, which are involed in Content: This contains the payload contents, which are involed
a security attack, as strings. in a security attack, such as strings.
+--rw payload-content* [name] +--rw payload-content* [name]
+--rw name string +--rw name string
+--rw description string +--rw description string
+--rw content* string +--rw content* string
Figure 15: Payload Content in YANG Data Tree Figure 15: Payload Content in YANG Data Tree
7. Network Configuration Access Control Model (NACM) for I2NSF 7. Network Configuration Access Control Model (NACM) for I2NSF
Consumer-Facing Interface Consumer-Facing Interface
skipping to change at page 15, line 35 skipping to change at page 16, line 35
o Separate default access modes for read, write, and execute o Separate default access modes for read, write, and execute
permissions are provided. permissions are provided.
o Access control rules are applied to configurable groups of users. o Access control rules are applied to configurable groups of users.
The data model of the I2NSF Consumer-Facing Interface utilizes the The data model of the I2NSF Consumer-Facing Interface utilizes the
NACM's mechanisms to manage the access control on the I2NSF Consumer- NACM's mechanisms to manage the access control on the I2NSF Consumer-
Facing Interface. The NACM with the above features can be used to Facing Interface. The NACM with the above features can be used to
set up the access control rules of a user group in the I2NSF set up the access control rules of a user group in the I2NSF
Consumer-Facing Interface. Figure 16 shows part of the NACM module Consumer-Facing Interface.
to enable the access control of a user group for the I2NSF Consumer-
Facing Interface. To use the NACM, a user needs to configure a Figure 16 shows part of the NACM module to enable the access control
NETCONF or RESTCONF server to enable the NACM module. Then, the user of a user group for the I2NSF Consumer-Facing Interface. To use the
can simply use an account of root or admin user for the access NACM, a user needs to configure either a NETCONF server [RFC6241] or
a RESTCONF server [RFC8040] to enable the NACM module. Then, the
user can simply use an account of root or admin user for the access
control for the module of the I2NSF Consumer-Facing Interface (i.e., control for the module of the I2NSF Consumer-Facing Interface (i.e.,
ietf-i2nsf-cfi-policy). An XML example to configure the access ietf-i2nsf-cfi-policy). An XML example to configure the access
control a user group for the I2NSF Consumer-Facing Interface can be control a user group for the I2NSF Consumer-Facing Interface can be
seen in Section 10. seen in Section 10.
list rule { list rule {
key "name"; key "name";
ordered-by user; ordered-by user;
leaf name { leaf name {
type string { type string {
skipping to change at page 17, line 15 skipping to change at page 18, line 15
8. YANG Data Model of Consumer-Facing Interface 8. YANG Data Model of Consumer-Facing Interface
The main objective of this data model is to provide both an The main objective of this data model is to provide both an
information model and the corresponding YANG data model of I2NSF information model and the corresponding YANG data model of I2NSF
Consumer-Facing Interface. This interface can be used to deliver Consumer-Facing Interface. This interface can be used to deliver
control and management messages between an I2NSF User and Security control and management messages between an I2NSF User and Security
Controller for the I2NSF User's high-level security policies. Controller for the I2NSF User's high-level security policies.
The semantics of the data model must be aligned with the information The semantics of the data model must be aligned with the information
model of the Consumer-Facing Interface. The transformation of the model of the Consumer-Facing Interface. The transformation of the
information model was performed so that this YANG data model can information model is performed so that this YANG data model can
facilitate the efficient delivery of the control or management facilitate the efficient delivery of the control or management
messages. messages.
This data model is designed to support the I2NSF framework that can This data model is designed to support the I2NSF framework that can
be extended according to the security needs. In other words, the be extended according to the security needs. In other words, the
model design is independent of the content and meaning of specific model design is independent of the content and meaning of specific
policies as well as the implementation approach. This document policies as well as the implementation approach.
suggests a VoIP/VoLTE security service as a use case for policy rule
generation.
This section describes a YANG data model for Consumer-Facing With the YANG data model of I2NSF Consumer-Facing Interface, this
Interface, based on the information model of Consumer-Facing document suggests use cases for security policy rules such as time-
Interface to Security Controller. based firewall, VoIP/VoLTE security service, and DDoS-attack
mitigation in Section 9.
<CODE BEGINS> file "ietf-i2nsf-cfi-policy@2020-07-13.yang" 8.1. YANG Module of Consumer-Facing Interface
This section describes a YANG module of Consumer-Facing Interface.
This YANG module imports from [RFC6991] and uses the typedef of time
in [I-D.ietf-netmod-rfc6991-bis]. It makes references to [RFC0854][R
FC0913][RFC0959][RFC1081][RFC1631][RFC2616][RFC2818][RFC4250][RFC5321
].
<CODE BEGINS> file "ietf-i2nsf-cfi-policy@2020-08-28.yang"
module ietf-i2nsf-cfi-policy { module ietf-i2nsf-cfi-policy {
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy"; "urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy";
prefix prefix cfi-policy;
i2nsf-cfi;
import ietf-inet-types{ import ietf-inet-types{
prefix inet; prefix inet;
} }
import ietf-yang-types{ import ietf-yang-types{
prefix yang; prefix yang;
} }
import ietf-netconf-acm { import ietf-netconf-acm {
prefix nacm; prefix nacm;
} }
organization organization
"IETF I2NSF (Interface to Network Security Functions) "IETF I2NSF (Interface to Network Security Functions)
Working Group"; Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/i2nsf> "WG Web: <http://tools.ietf.org/wg/i2nsf>
WG List: <mailto:i2nsf@ietf.org> WG List: <mailto:i2nsf@ietf.org>
WG Chair: Linda Dunbar
<mailto:linda.dunbar@futurewei.com>
WG Chair: Yoav Nir
<mailto:ynir.ietf@gmail.com>
Editor: Jaehoon Paul Jeong Editor: Jaehoon Paul Jeong
<mailto:pauljeong@skku.edu> <mailto:pauljeong@skku.edu>
Editor: Chaehong Chung Editor: Patrick Lingga
<mailto:darkhong@skku.edu>"; <mailto:patricklink@skku.edu>";
description description
"This module is a YANG module for Consumer-Facing Interface. "This module is a YANG module for Consumer-Facing Interface.
Copyright (c) 2020 IETF Trust and the persons
identified as authors of the code. All rights reserved. Copyright (c) 2020 IETF Trust and the persons identified as
Redistribution and use in source and binary forms, with or authors of the code. All rights reserved.
without modification, is permitted pursuant to, and subject
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
http://trustee.ietf.org/license-info). http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision "2020-07-13"{ revision "2020-08-28"{
description "The latest revision"; description "Initial revision.";
reference reference
"draft-ietf-consumer-facing-interface-dm-08"; "RFC XXXX: I2NSF Consumer-Facing Interface YANG Data Model";
} }
identity malware-file-type { identity malware-file-type {
description description
"Base identity for malware file types."; "Base identity for malware file types.";
} }
identity executable-file { identity executable-file {
base malware-file-type; base malware-file-type;
description description
skipping to change at page 20, line 23 skipping to change at page 21, line 26
identity ransomware { identity ransomware {
base security-event-type; base security-event-type;
description description
"Identity for ransomware infection event types."; "Identity for ransomware infection event types.";
} }
identity i2nsf-ipsec { identity i2nsf-ipsec {
description description
"Base identity for IPsec method types."; "Base identity for IPsec method types.";
reference reference
"draft-ietf-i2nsf-sdn-ipsec-flow-protection-07"; "draft-ietf-i2nsf-sdn-ipsec-flow-protection-08: Software-Defined
Networking (SDN)-based IPsec Flow Protection - IPsec method
types can be selected.";
} }
identity ipsec-ike { identity ipsec-ike {
base i2nsf-ipsec; base i2nsf-ipsec;
description description
"Identity for ipsec-ike."; "Identity for ipsec-ike.";
reference reference
"draft-ietf-i2nsf-sdn-ipsec-flow-protection-07"; "draft-ietf-i2nsf-sdn-ipsec-flow-protection-08: Software-Defined
Networking (SDN)-based IPsec Flow Protection - IPsec method
type with IKE is selected.";
} }
identity ipsec-ikeless { identity ipsec-ikeless {
base i2nsf-ipsec; base i2nsf-ipsec;
description description
"Identity for ipsec-ikeless."; "Identity for ipsec-ikeless.";
reference reference
"draft-ietf-i2nsf-sdn-ipsec-flow-protection-07"; "draft-ietf-i2nsf-sdn-ipsec-flow-protection-08: Software-Defined
Networking (SDN)-based IPsec Flow Protection - IPsec method
type without IKE is selected.";
} }
identity continent { identity continent {
description description
"Base Identity for continent types."; "Base Identity for continent types.";
} }
identity africa { identity africa {
base continent; base continent;
description description
"Identity for africa."; "Identity for Africa.";
} }
identity asia { identity asia {
base continent; base continent;
description description
"Identity for asia."; "Identity for Asia.";
} }
identity europe { identity europe {
base continent; base continent;
description description
"Identity for europe."; "Identity for Europe.";
} }
identity north-america { identity north-america {
base continent; base continent;
description description
"Identity for north-america."; "Identity for North America.";
} }
identity south-america { identity south-america {
base continent; base continent;
description description
"Identity for south-america."; "Identity for South America.";
} }
identity oceania { identity oceania {
base continent; base continent;
description description
"Identity for Oceania"; "Identity for Oceania";
} }
identity protocol-type { identity protocol-type {
description description
skipping to change at page 24, line 37 skipping to change at page 25, line 47
identity signature-type { identity signature-type {
description description
"This represents the base identity for signature types."; "This represents the base identity for signature types.";
} }
identity signature-yara { identity signature-yara {
base signature-type; base signature-type;
description description
"This represents the YARA signatures."; "This represents the YARA signatures.";
reference
"YARA: YARA signatures are explained.";
} }
identity signature-snort { identity signature-snort {
base signature-type; base signature-type;
description description
"This represents the SNORT signatures."; "This represents the SNORT signatures.";
reference
"SNORT: SNORT signatures are explained.";
} }
identity signature-suricata { identity signature-suricata {
base signature-type; base signature-type;
description description
"This represents the SURICATA signatures."; "This represents the SURICATA signatures.";
reference
"SURICATA: SURICATA signatures are explained.";
} }
identity threat-feed-type { identity threat-feed-type {
description description
"This represents the base identity for threat-feed."; "This represents the base identity for threat-feed.";
} }
identity day { identity day {
description description
"This represents the base for days."; "This represents the base for days.";
} }
identity monday { identity monday {
base day; base day;
description description
"This represents monday."; "This represents Monday.";
} }
identity tuesday { identity tuesday {
base day; base day;
description description
"This represents tuesday."; "This represents Tuesday.";
} }
identity wednesday { identity wednesday {
base day; base day;
description description
"This represents wednesday."; "This represents Wednesday.";
} }
identity thursday { identity thursday {
base day; base day;
description description
"This represents thursday."; "This represents Thursday.";
} }
identity friday { identity friday {
base day; base day;
description description
"This represents friday."; "This represents Friday.";
} }
identity saturday { identity saturday {
base day; base day;
description description
"This represents saturday."; "This represents Saturday.";
} }
identity sunday { identity sunday {
base day; base day;
description description
"This represents sunday."; "This represents Sunday.";
} }
/* /*
* Typedefs * Typedefs
*/ */
typedef time{ typedef time {
type string { type string {
pattern '\d{2}:\d{2}:\d{2}(\.\d+)?' pattern '(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.\d+)?'
+ '(Z|[\+\-]\d{2}:\d{2})'; + '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?';
} }
description description
"This is the format of time."; "The time type represents an instance of time of zero-duration
that recurs every day.";
reference
"draft-ietf-netmod-rfc6991-bis-04: Common YANG Data Types -
typedef time is used.";
} }
/* /*
* Groupings * Groupings
*/ */
grouping ipv4-list { grouping ipv4-list {
description description
"Grouping for ipv4 based ip-addresses."; "Grouping for an IPv4 address list.";
leaf-list ipv4 { leaf-list ipv4 {
type inet:ipv4-address; type inet:ipv4-address;
description description
"This is the entry for the ipv4 ip-addresses."; "This is the entry for an IPv4 address list.";
} }
} }
grouping ipv6-list { grouping ipv6-list {
description description
"Grouping for ipv6 based ip-addresses."; "Grouping for an IPv6 address list.";
leaf-list ipv6 { leaf-list ipv6 {
type inet:ipv6-address; type inet:ipv6-address;
description description
"This is the entry for the ipv6 ip-addresses."; "This is the entry for an IPv6 address list.";
} }
} }
grouping ipv4 { grouping ipv4 {
description description
"Grouping for ipv4 based ip-address."; "Grouping for an IPv4 address.";
leaf ipv4 { leaf ipv4 {
type inet:ipv4-address; type inet:ipv4-address;
description description
"This is the entry for the ipv4 ip-address."; "This is the entry for an IPv4 address.";
} }
} }
grouping ipv6 { grouping ipv6 {
description description
"Grouping for ipv6 based ip-address."; "Grouping for an IPv6 address.";
leaf ipv6 { leaf ipv6 {
type inet:ipv6-address; type inet:ipv6-address;
description description
"This is the entry for the ipv6 ip-address."; "This is the entry for an IPv6 address.";
} }
} }
grouping ip-address-info { grouping ip-address-info {
description description
"There are two types to configure a security policy "There are two types to configure a security policy
for IPv4 address, such as exact match and range match."; for an IPv4 address, such as exact match and range match.";
choice match-type { choice match-type {
description description
"User can choose between 'exact match' and 'range match'."; "User can choose between 'exact match' and 'range match'.";
case exact-match-ipv4 { case exact-match-ipv4 {
uses ipv4; uses ipv4;
description description
"Exact ip-address match for ipv4 type addresses"; "Exact ip-address match for IPv4 addresses";
} }
case exact-match-ipv6 { case exact-match-ipv6 {
uses ipv6; uses ipv6;
description description
"Exact ip-address match for ipv6 type addresses"; "Exact ip-address match for IPv6 addresses";
} }
case range-match-ipv4 { case range-match-ipv4 {
container range-ipv4-address { container range-ipv4-address {
leaf start-ipv4-address { leaf start-ipv4-address {
type inet:ipv4-address; type inet:ipv4-address;
mandatory true;
description description
"Start IPv4 address for a range match."; "A start IPv4 address for a range match.";
} }
leaf end-ipv4-address { leaf end-ipv4-address {
type inet:ipv4-address; type inet:ipv4-address;
mandatory true;
description description
"End IPv4 address for a range match."; "An end IPv4 address for a range match.";
} }
description description
"Range match for an IP-address."; "A range match for IPv4 addresses is provided. Note that the
start IPv4 address must be lower than the end IPv4 address.";
} }
} }
case range-match-ipv6 { case range-match-ipv6 {
container range-ipv6-address { container range-ipv6-address {
leaf start-ipv6-address { leaf start-ipv6-address {
type inet:ipv6-address; type inet:ipv6-address;
mandatory true;
description description
"Start IPv6 address for a range match."; "A start IPv6 address for a range match.";
} }
leaf end-ipv6-address { leaf end-ipv6-address {
type inet:ipv6-address; type inet:ipv6-address;
mandatory true;
description description
"End IPv6 address for a range match."; "An end IPv6 address for a range match.";
} }
description description
"Range match for an IP-address."; "A range match for IPv6 addresses is provided. Note that the
start IPv6 address must be lower than the end IPv4 address.";
} }
} }
} }
} }
grouping ipsec-based-method { grouping ipsec-based-method {
description description
"This represents the ipsec-based method."; "This represents the ipsec-based method.";
list ipsec-method { list ipsec-method {
key "method"; key "method";
description description
"This represents the list of IPsec method types."; "This represents the list of IPsec method types.";
leaf method { leaf method {
type identityref { type identityref {
base i2nsf-ipsec; base i2nsf-ipsec;
} }
description description
"This represents IPsec IKE and IPsec IKEless cases. "This represents IPsec IKE and IPsec IKEless cases. If this
If this is not set, it cannot support IPsec IKE or is not set, it cannot support IPsec IKE or IPsec IKEless.";
IPsec IKEless.";
reference reference
"draft-ietf-i2nsf-sdn-ipsec-flow-protection-07"; "draft-ietf-i2nsf-sdn-ipsec-flow-protection-08:
Software-Defined Networking (SDN)-based IPsec Flow Protection
- IPsec method types can be selected.";
} }
} }
} }
grouping user-group { grouping user-group {
description description
"The grouping for user-group entities, and contains "The grouping for user-group entities, and contains information
information such as name & ip-address."; such as name & ip-address.";
leaf name { leaf name {
type string; type string;
description description
"This represents the name of a user-group. "This represents the name of a user-group. A user-group name
A user-group name is used to map a user-group's is used to map a user-group's name (e.g., employees) to an IP
name (e.g., employees) to an ip address. address. It is dependent on implementation.";
It is implementation dependent";
} }
uses ip-address-info{ uses ip-address-info{
refine match-type{ refine match-type{
mandatory true; mandatory true;
} }
description description
"This represent the IP address of a user-group."; "This represent the IP addresses of a user-group.";
} }
} }
grouping device-group { grouping device-group {
description description
"This group represents device group information "This group represents device group information such as ip-address
such as ip-address protocol."; protocol.";
leaf name { leaf name {
type string; type string;
description description
"This represents the name of a device-group."; "This represents the name of a device-group.";
} }
uses ip-address-info{ uses ip-address-info{
refine match-type{ refine match-type{
mandatory true; mandatory true;
} }
} }
leaf-list protocol { leaf-list protocol {
type identityref { type identityref {
base protocol-type; base protocol-type;
} }
description description
"This represents the communication protocols of "This represents the communication protocols of devices. If this
devices. is not set, it cannot support the appropriate protocol";
If this is not set, it cannot support the
appropriate protocol";
} }
} }
grouping location-group { grouping location-group {
description description
"This group represents location-group information "This group represents location-group information such as geo-ip
such as geo-ip and continent."; and continent.";
leaf name { leaf name {
type string; type string;
description description
"This represents the name of a location."; "This represents the name of a location.";
} }
list geo-ip-ipv4 { list geo-ip-ipv4 {
key "ipv4-address"; key "ipv4-address";
description description
"This represents the list of IPv4 address based on "This represents the list of IPv4 addresses based on a location.";
a location.";
leaf ipv4-address{ leaf ipv4-address{
type inet:ipv4-address; type inet:ipv4-address;
description description
"This represents an IPv4 geo-ip of a location."; "This represents an IPv4 geo-ip address of a location.";
} }
leaf ipv4-prefix{ leaf ipv4-prefix{
type inet:ipv4-prefix; type inet:ipv4-prefix;
description description
"This represents the prefix for the IPv4-address."; "This represents the prefix for the IPv4 addresses.";
} }
} }
list geo-ip-ipv6 { list geo-ip-ipv6 {
key "ipv6-address"; key "ipv6-address";
description description
"This represents the list of IPv6 address based on "This represents the list of IPv6 addresses based on a location.";
a location.";
leaf ipv6-address{ leaf ipv6-address{
type inet:ipv6-address; type inet:ipv6-address;
description description
"This represents an IPv6 geo-ip of a location."; "This represents an IPv6 geo-ip address of a location.";
} }
leaf ipv6-prefix{ leaf ipv6-prefix{
type inet:ipv6-prefix; type inet:ipv6-prefix;
description description
"This represents the prefix for the IPv6-address."; "This represents the prefix for the IPv6 addresses.";
} }
} }
leaf continent { leaf continent {
type identityref { type identityref {
base continent; base continent;
} }
default asia; default asia;
description description
"location-group-based on geo-ip of "location-group has geo-ip addresses of the corresponding
respective continent."; continent.";
} }
} }
grouping threat-feed-info { grouping threat-feed-info {
description description
"This is the grouping for the threat-feed-list"; "This is the grouping for the threat-feed-list";
leaf threat-type { leaf threat-type {
type identityref { type identityref {
base threat-feed-type; base threat-feed-type;
} }
description description
"This represents the type of the threat-feed."; "This represents the type of the threat-feed.";
} }
leaf server-ipv4 { leaf server-ipv4 {
type inet:ipv4-address; type inet:ipv4-address;
description description
"The IPv4 ip-address for the threat-feed server."; "The IPv4 address for the threat-feed server.";
} }
leaf server-ipv6 { leaf server-ipv6 {
type inet:ipv6-address; type inet:ipv6-address;
description description
"The IPv6 ip-address for the threat-feed server."; "The IPv6 address for the threat-feed server.";
} }
leaf description { leaf description {
type string; type string;
description description
"This represents the descriptions of a threat-feed. "This represents the descriptions of a threat-feed. The
The description should include information, such as description should include information, such as type, threat,
the type, related threat, method, and file type. method, and file type. Structured Threat Information Expression
Structured Threat Information Expression (STIX) can (STIX) can be used for description of a threat [STIX].";
be used for description of a threat [STIX].";
} }
} }
grouping payload-string { grouping payload-string {
description description
"The grouping for payload-string content. "The grouping for payload-string content. It contains information
It contains information such as name and string such as name and string content.";
content.";
leaf description { leaf description {
type string; type string;
description description
"This represents the description of a payload. "This represents the description of a payload. If this is not
If this is not set, it cannot support the set, it cannot support the description of how the payload content
description of how the payload content is is related to a security attack.";
related to a security attack.";
} }
leaf-list content { leaf-list content {
type string; type string;
description description
"This represents the string of the payload "This represents the string of the payload contents. This content
contents. This content leaf-list contains the leaf-list contains the payload of a packet to analyze a threat.
payload of a packet to analyze a threat. Due to the types of threats, the type of the content is defined
Due to the types of threats, the type of the as a string to accommodate any kind of a payload type such as
content is defined as string to accommodate HTTP, HTTPS, and SIP. If this is not set, it cannot support the
any kind of a payload type such as HTTP, HTTPS, payload contents involved in a security attack as a string.";
and SIP.
If this is not set, it cannot support the
payload contents involved in a security attack
as strings";
} }
} }
list i2nsf-cfi-policy { list i2nsf-cfi-policy {
key "policy-name"; key "policy-name";
description description
"This is the security policy list. Each policy in "This is a security policy list. Each policy in the list contains
the list contains a list of security rules, and is a list of security policy rules, and is a policy instance to have
a policy instance to have complete information the information of where and when a policy needs to be applied.";
such as where and when a policy needs to be
applied.";
leaf policy-name { leaf policy-name {
type string; type string;
description description
"The name which identifies the policy."; } "The name which identifies the policy.";
}
container rules{ container rules{
description description
"This container is for rules."; "This container has rules.";
nacm:default-deny-write; nacm:default-deny-write;
list rule { list rule {
key "rule-name"; key "rule-name";
ordered-by user; ordered-by user;
leaf rule-name { leaf rule-name {
type string; type string;
description description
"This represents the name for the rule."; "This represents the name for a rule.";
} }
description description
"There can be a single or multiple number of "There can be a single or multiple number of rules.";
rules.";
container event { container event {
description description
"This represents the event (e.g., a security "This represents an event (i.e., a security event), for which
event, for which a security rule is made.)"; a security rule is made.";
leaf security-event { leaf security-event {
type identityref { type identityref {
base security-event-type; base security-event-type;
} }
description description
"This contains the description of security "This contains the description of a security event. If this
events. If this is not set, it cannot is not set, it cannot support what security event will be
support which security event is enforced"; enforced.";
} }
container time-information { container time-information {
description description
"The time information when the security "The time information when a security policy rule should be
rule should be applied."; applied.";
leaf start-date-time { leaf start-date-time {
type yang:date-and-time; type yang:date-and-time;
description description
"This is the start date and time "This is the start date and time for a security policy
for policy."; rule.";
} }
leaf end-date-time { leaf end-date-time {
type yang:date-and-time; type yang:date-and-time;
description description
"This is the end date and time "This is the end date and time for a policy rule. The
for policy. The policy will stop policy rule will stop working after the specified
working after the specified end-date-time.";
end-date-time";
} }
container period{ container period{
when when
"/i2nsf-cfi-policy/rules/rule/event/frequency!='only-once'"; "../../frequency!='only-once'";
description description
"This represents the repetition time. "This represents the repetition time. In the case where
In case of frequency is weekly, the days the frequency is weekly, the days can be set.";
can be set.";
leaf start-time { leaf start-time {
type time; type time;
description description
"This is period start time for event."; "This is a period's start time for an event.";
reference
"RFC 6991-bis: Common YANG Data Types - The time type
represents an instance of time of zero-duration that
recurs every day. When RFC 6991-bis becomes an RFC,
time must be replaced with yang:time.";
} }
leaf end-time { leaf end-time {
type time; type time;
description description
"This is period end time for event."; "This is a period's end time for an event.";
reference
"RFC 6991-bis: Common YANG Data Types - The time type
represents an instance of time of zero-duration that
recurs every day. When RFC 6991-bis becomes an RFC,
time must be replaced with yang:time.";
} }
leaf-list day { leaf-list day {
when when
"/i2nsf-cfi-policy/rules/rule/event/frequency='weekly'"; "../../../frequency='weekly'";
type identityref{ type identityref{
base day; base day;
} }
min-elements 1;
description description
"This represents the repeated day of "This represents the repeated day of every week (e.g.,
every week (e.g., monday and tuesday). Monday and Tuesday). More than one day can be
More than one day can be specified"; specified.";
} }
leaf-list date { leaf-list date {
when when
"/i2nsf-cfi-policy/rules/rule/event/frequency='monthly'"; "../../../frequency='monthly'";
type int32{ type int32{
range "1..31"; range "1..31";
} }
min-elements 1;
description description
"This represents the repeated date of "This represents the repeated date of every month. More
every month. More than one date can be than one date can be specified.";
specified.";
} }
leaf-list month { leaf-list month {
when when
"/i2nsf-cfi-policy/rules/rule/event/frequency='yearly'"; "../../../frequency='yearly'";
type string{ type string{
pattern '\d{2}-\d{2}'; pattern '\d{2}-\d{2}';
} }
min-elements 1;
description description
"This represents the repeated date and month "This represents the repeated date and month of every
of every year. More than one can be specified. year. More than one can be specified. A pattern used
Pattern used is Month-Date (MM-DD)."; here is Month and Date (MM-DD).";
} }
} }
} }
leaf frequency { leaf frequency {
type enumeration { type enumeration {
enum only-once { enum only-once {
description description
"This represents the rule is enforced "This represents that the rule is immediately enforced
only once immediately and not repeated. only once and not repeated. The policy will
The policy will continuously active from continuously be active from the start-time to the
start time and terminated at end-time."; end-time.";
} }
enum daily { enum daily {
description description
"This represents the rule is enforced "This represents that the rule is enforced on a daily
on a daily basis. The policy will be basis. The policy will be repeated daily until the
repeated daily until the end-date."; end-date.";
} }
enum weekly { enum weekly {
description description
"This represents the rule is enforced "This represents that the rule is enforced on a weekly
on a weekly basis. The policy will be basis. The policy will be repeated weekly until the
repeated weekly until the end-date. The end-date. The repeated days can be specified.";
repeated days can be specified.";
} }
enum monthly { enum monthly {
description description
"This represents the rule is enforced "This represents that the rule is enforced on a monthly
on a monthly basis. The policy will be basis. The policy will be repeated monthly until the
repeated monthly until the end-date."; end-date.";
} }
enum yearly { enum yearly {
description description
"This represents the rule is enforced "This represents that the rule is enforced on a yearly
on a yearly basis. The policy will be basis. The policy will be repeated yearly until the
repeated yearly until the end-date."; end-date.";
} }
} }
default only-once; default only-once;
description description
"This represents how frequent the rule "This represents how frequently the rule should be enforced.";
should be enforced.";
} }
} }
container condition { container condition {
description description
"The conditions for general security policies."; "Conditions for general security policies.";
container firewall-condition { container firewall-condition {
description description
"The general firewall condition."; "A general firewall condition.";
leaf source { leaf source {
type leafref { type leafref {
path path
"/i2nsf-cfi-policy/endpoint-groups/user-group/name"; "/i2nsf-cfi-policy/endpoint-groups/user-group/name";
} }
description description
"This describes the paths to the source reference."; "This describes the path to the source.";
} }
leaf-list destination { leaf-list destination {
type leafref { type leafref {
path path
"/i2nsf-cfi-policy/endpoint-groups/user-group/name"; "/i2nsf-cfi-policy/endpoint-groups/user-group/name";
} }
description description
"This describes the paths to the destination "This describes the paths to the destinations.";
target reference.";
} }
} }
container ddos-condition { container ddos-condition {
description description
"The condition for DDoS mitigation."; "A condition for a DDoS attack.";
leaf-list source { leaf-list source {
type leafref { type leafref {
path path
"/i2nsf-cfi-policy/endpoint-groups/device-group/name"; "/i2nsf-cfi-policy/endpoint-groups/device-group/name";
} }
description description
"This describes the path to the "This describes the paths to the sources.";
source target references.";
} }
leaf-list destination { leaf-list destination {
type leafref { type leafref {
path path
"/i2nsf-cfi-policy/endpoint-groups/device-group/name"; "/i2nsf-cfi-policy/endpoint-groups/device-group/name";
} }
description description
"This describes the path to the destination target "This describes the paths to the destinations.";
references.";
} }
container rate-limit { container rate-limit {
description description
"This describes the rate-limit."; "This describes the rate-limit.";
leaf packet-threshold-per-second { leaf packet-threshold-per-second {
type uint32; type uint32;
description description
"This is a trigger value for the condition."; "This is a trigger value for a rate limit for a
DDoS-attack mitigation.";
} }
} }
} }
container location-condition { container location-condition {
description description
"The condition for location based connection"; "A condition for a location-based connection";
leaf-list source { leaf-list source {
type leafref { type leafref {
path path
"/i2nsf-cfi-policy/endpoint-groups/location-group/name"; "/i2nsf-cfi-policy/endpoint-groups/location-group/name";
} }
description description
"This describes the path to the location "This describes the paths to a location's sources.";
source reference.";
} }
leaf-list destination { leaf-list destination {
type leafref { type leafref {
path path
"/i2nsf-cfi-policy/endpoint-groups/location-group/name"; "/i2nsf-cfi-policy/endpoint-groups/location-group/name";
} }
description description
"This describes the path to the location "This describes the paths to a location's destinations.";
destination reference.";
} }
} }
container custom-condition { container custom-condition {
description description
"The condition based on packet contents."; "A condition based on a packet's content.";
leaf-list source { leaf-list source {
type leafref { type leafref {
path path
"/i2nsf-cfi-policy/threat-preventions/payload-content/name"; "/i2nsf-cfi-policy/threat-preventions/payload-content/name";
} }
description description
"Describes the payload string content condition "This describes the paths to a packet content's sources.";
source.";
} }
leaf destination { leaf destination {
type leafref { type leafref {
path path
"/i2nsf-cfi-policy/threat-preventions/payload-content/name"; "/i2nsf-cfi-policy/threat-preventions/payload-content/name";
} }
description description
"Describes the payload string content condition "This describes the path to a packet content's
destination."; destination.";
} }
} }
container threat-feed-condition { container threat-feed-condition {
description description
"The condition based on the threat-feed information."; "A condition based on the threat-feed information.";
leaf-list source { leaf-list source {
type leafref { type leafref {
path path
"/i2nsf-cfi-policy/threat-preventions/threat-feed-list/name"; "/i2nsf-cfi-policy/threat-preventions/threat-feed-list/name";
} }
description description
"Describes the threat-feed condition source."; "This describes the paths to a threat-feed's sources.";
} }
leaf destination { leaf destination {
type leafref { type leafref {
path path
"/i2nsf-cfi-policy/threat-preventions/threat-feed-list/name"; "/i2nsf-cfi-policy/threat-preventions/threat-feed-list/name";
} }
description description
"Describes the threat-feed condition destination."; "This describes the path to a threat-feed's destination.";
} }
} }
} }
container actions { container actions {
description description
"This is the action container."; "This is the action container.";
leaf primary-action { leaf primary-action {
type identityref { type identityref {
base primary-action; base primary-action;
} }
description description
"This represent the primary actions (e.g., "This represent primary actions (e.g., PASS, DROP, ALERT,
PASS, DROP, ALERT, and MIRROR) to be and MIRROR) to be applied to a condition. If this is not
applied a condition. set, it cannot support the primary actions.";
If this is not set, it cannot support
the primary actions.";
} }
leaf secondary-action { leaf secondary-action {
type identityref { type identityref {
base secondary-action; base secondary-action;
} }
description description
"This represents the secondary actions "This represents secondary actions (e.g., log and syslog)
(e.g., log and syslog) to be applied to be applied if they are needed. If this is not set, it
if needed. cannot support the secondary actions.";
If this is not set, it cannot support
the secondary actions.";
} }
} }
container ipsec-method { container ipsec-method {
description description
"This container represents the IPsec IKE "This container represents the IPsec method such as IKE case
and IKEless cases."; and IKEless case.";
leaf method { leaf method {
type identityref { type identityref {
base i2nsf-ipsec; base i2nsf-ipsec;
} }
description description
"This references the IPsec method types, "This represents the IPsec method type such as IKE case and
which includes IPsec IKE and IPsec IKEless IKEless case. If this is not set, it cannot support
cases. either IPsec IKE or IPsec IKEless.";
If this is not set, it cannot support
IPsec IKE or IPsec IKEless.";
reference reference
"draft-ietf-i2nsf-sdn-ipsec-flow-protection-07"; "draft-ietf-i2nsf-sdn-ipsec-flow-protection-08:
Software-Defined Networking (SDN)-based IPsec Flow
Protection - IPsec method types can be selected.";
} }
} }
} }
} }
container endpoint-groups { container endpoint-groups {
description description
"A logical entity in their business "A logical entity in a business environment, where a security
environment, where a security policy policy is to be applied.";
is to be applied.";
list user-group{ list user-group{
uses user-group; uses user-group;
key "name"; key "name";
description description
"This represents the user group."; "This represents a user group.";
} }
list device-group { list device-group {
key "name"; key "name";
uses device-group; uses device-group;
description description
"This represents the device group."; "This represents a device group.";
} }
list location-group{ list location-group{
key "name"; key "name";
uses location-group; uses location-group;
description description
"This represents the location group."; "This represents a location group.";
} }
} }
container threat-preventions { container threat-preventions {
description description
"this describes the list of threat-prevention."; "This describes the list of threat-preventions.";
list threat-feed-list { list threat-feed-list {
key "name"; key "name";
description description
"There can be a single or multiple number of "There can be a single or multiple number of threat-feeds.";
threat-feeds.";
leaf name { leaf name {
type string; type string;
description description
"This represents the name of the threat-feed."; "This represents the name of the threat-feed.";
} }
uses threat-feed-info; uses threat-feed-info;
leaf-list threat-file-types { leaf-list threat-file-types {
type identityref { type identityref {
base malware-file-type; base malware-file-type;
} }
default executable-file;
description description
"This contains a list of file types needed to "This contains a list of file types needed to be scanned for
be scanned for the virus."; a security threat (e.g., virus).";
} }
leaf-list signatures { leaf-list signatures {
type identityref { type identityref {
base signature-type; base signature-type;
} }
default signature-suricata;
description description
"This contains a list of signatures or hashes "This contains a list of signatures or hashes of the threats.";
of the threats.";
} }
} }
list payload-content { list payload-content {
key "name"; key "name";
leaf name { leaf name {
type string; type string;
description description
"This represents the name of payload-content. "This represents the name of a packet's payload-content. It
It should give an idea of why specific payload should give an idea of why a specific payload content is
content is marked as threat. For example, the marked as a threat. For example, the name 'backdoor'
name 'backdoor' indicates the payload content indicates the payload content is related to a backdoor
is related to backdoor attack."; attack.";
} }
description description
"This represents the payload-string group."; "This represents a payload-string group.";
uses payload-string; uses payload-string;
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
Figure 17: YANG for Consumer-Facing Interface Figure 17: YANG for Consumer-Facing Interface
9. XML Configuration Examples of High-Level Security Policy Rules 9. XML Configuration Examples of High-Level Security Policy Rules
Note: This section is informative with XML configuration examples. This section shows XML configuration examples of high-level security
This section is informative with XML configuration examples. This
section shows XML configuration examples of high-level security
policy rules that are delivered from the I2NSF User to the Security policy rules that are delivered from the I2NSF User to the Security
Controller over the Consumer-Facing Interface. The considered use Controller over the Consumer-Facing Interface. The considered use
cases are: Database registration, time-based firewall for web cases are: Database registration, time-based firewall for web
filtering, VoIP/VoLTE security service, and DDoS-attack mitigation. filtering, VoIP/VoLTE security service, and DDoS-attack mitigation.
9.1. Database Registration: Information of Positions and Devices 9.1. Database Registration: Information of Positions and Devices
(Endpoint Group) (Endpoint Group)
If new endpoints are introduced to the network, it is necessary to If new endpoints are introduced to the network, it is necessary to
first register their data to the database. For example, if new first register their data to the database. For example, if new
members are newly introduced in either of three different groups members are newly introduced in either of three different groups
(i.e., user-group, device-group, and payload-group), each of them (i.e., user-group, device-group, and payload-group), each of them
should be registered with information such as ip-addresses or should be registered with information such as ip-addresses or
protocols used by devices. Figure 18 shows an example XML protocols used by devices.
representation of the registered information for the user-group and
device-group. Figure 18 shows an example XML representation of the registered
information for the user-group and device-group with IPv4 addresses
[RFC5737].
<?xml version="1.0" encoding="UTF-8" ?> <?xml version="1.0" encoding="UTF-8" ?>
<i2nsf-cfi-policy xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy"> <i2nsf-cfi-policy xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy">
<endpoint-groups> <endpoint-groups>
<user-group> <user-group>
<name>employees</name> <name>employees</name>
<range-ipv4-address> <range-ipv4-address>
<start-ipv4-address>221.159.112.1</start-ipv4-address> <start-ipv4-address>192.0.2.11</start-ipv4-address>
<end-ipv4-address>221.159.112.90</end-ipv4-address> <end-ipv4-address>192.0.2.90</end-ipv4-address>
</range-ipv4-address> </range-ipv4-address>
</user-group> </user-group>
<device-group> <device-group>
<name>webservers</name> <name>webservers</name>
<range-ipv4-address> <range-ipv4-address>
<start-ipv4-address>221.159.112.91</start-ipv4-address> <start-ipv4-address>198.51.100.11</start-ipv4-address>
<end-ipv4-address>221.159.112.97</end-ipv4-address> <end-ipv4-address>198.51.100.20</end-ipv4-address>
</range-ipv4-address> </range-ipv4-address>
<protocol>http</protocol> <protocol>cfi-policy:http</protocol>
<protocol>https</protocol> <protocol>cfi-policy:https</protocol>
</device-group> </device-group>
</endpoint-groups> </endpoint-groups>
</i2nsf-cfi-policy> </i2nsf-cfi-policy>
Figure 18: Registering User-group and Device-group Information Figure 18: Registering User-group and Device-group Information with
IPv4 Addresses
Also, Figure 19 shows an example XML representation of the registered
information for the user-group and device-group with IPv6 addresses
[RFC3849].
<?xml version="1.0" encoding="UTF-8" ?>
<i2nsf-cfi-policy xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy">
<endpoint-groups>
<user-group>
<name>employees</name>
<range-ipv6-address>
<start-ipv6-address>2001:DB8:0:1::11</start-ipv6-address>
<end-ipv6-address>2001:DB8:0:1::90</end-ipv6-address>
</range-ipv6-address>
</user-group>
<device-group>
<name>webservers</name>
<range-ipv6-address>
<start-ipv6-address>2001:DB8:0:2::11</start-ipv6-address>
<end-ipv6-address>2001:DB8:0:2::20</end-ipv6-address>
</range-ipv6-address>
<protocol>cfi-policy:http</protocol>
<protocol>cfi-policy:https</protocol>
</device-group>
</endpoint-groups>
</i2nsf-cfi-policy>
Figure 19: Registering User-group and Device-group Information with
IPv6 Addresses
9.2. Scenario 1: Block SNS Access during Business Hours 9.2. Scenario 1: Block SNS Access during Business Hours
The first example scenario is to "block SNS access during office The first example scenario is to "block SNS access during office
hours" using a time-based firewall policy. In this scenario, all hours" using a time-based firewall policy. In this scenario, all
users registered as "employees" in the user-group list are unable to users registered as "employees" in the user-group list are unable to
access Social Networking Services (SNS) during the office hours access Social Networking Services (SNS) during the office hours
(weekdays). The XML instance is described below: (weekdays). The XML instance is described below:
<?xml version="1.0" encoding="UTF-8" ?> <?xml version="1.0" encoding="UTF-8" ?>
skipping to change at page 42, line 18 skipping to change at page 44, line 18
<rules> <rules>
<rule> <rule>
<rule-name>block_access_to_sns_during_office_hours</rule-name> <rule-name>block_access_to_sns_during_office_hours</rule-name>
<event> <event>
<time-information> <time-information>
<start-date-time>2020-03-11T09:00:00.00Z</start-date-time> <start-date-time>2020-03-11T09:00:00.00Z</start-date-time>
<end-date-time>2020-12-31T18:00:00.00Z</end-date-time> <end-date-time>2020-12-31T18:00:00.00Z</end-date-time>
<period> <period>
<start-time>09:00:00Z</start-time> <start-time>09:00:00Z</start-time>
<end-time>18:00:00Z</end-time> <end-time>18:00:00Z</end-time>
<day>monday</day> <day>cfi-policy:monday</day>
<day>tuesday</day> <day>cfi-policy:tuesday</day>
<day>wednesday</day> <day>cfi-policy:wednesday</day>
<day>thursday</day> <day>cfi-policy:thursday</day>
<day>friday</day> <day>cfi-policy:friday</day>
</period> </period>
</time-information> </time-information>
<frequency>weekly</frequency> <frequency>weekly</frequency>
</event> </event>
<condition> <condition>
<firewall-condition> <firewall-condition>
<source>employees</source> <source>employees</source>
</firewall-condition> </firewall-condition>
<custom-condition>
<destination>sns-websites</destination>
</custom-condition>
</condition> </condition>
<actions> <actions>
<primary-action>drop</primary-action> <primary-action>cfi-policy:drop</primary-action>
</actions> </actions>
</rule> </rule>
</rules> </rules>
</i2nsf-cfi-policy> </i2nsf-cfi-policy>
Figure 19: An XML Example for Time-based Firewall Figure 20: An XML Example for Time-based Firewall
Time-based-condition Firewall Time-based-condition Firewall
1. The policy name is "security_policy_for_blocking_sns". 1. The policy name is "security_policy_for_blocking_sns".
2. The rule name is "block_access_to_sns_during_office_hours". 2. The rule name is "block_access_to_sns_during_office_hours".
3. The Source is "employees". 3. The Source is "employees".
4. The destination target is "sns-websites". "sns-websites" is the 4. The destination target is "sns-websites". "sns-websites" is the
skipping to change at page 43, line 22 skipping to change at page 45, line 26
The second example scenario is to "block malicious VoIP/VoLTE packets The second example scenario is to "block malicious VoIP/VoLTE packets
coming to a company" using a VoIP policy. In this scenario, the coming to a company" using a VoIP policy. In this scenario, the
calls comming from from VOIP and/or VOLTE sources with VOLTE IDs that calls comming from from VOIP and/or VOLTE sources with VOLTE IDs that
are classified as malicious are dropped. The IP addresses of the are classified as malicious are dropped. The IP addresses of the
employees and malicious VOIP IDs should be blocked are stored in the employees and malicious VOIP IDs should be blocked are stored in the
database or datastore of the enterprise. Here and the rest of the database or datastore of the enterprise. Here and the rest of the
cases assume that the security administrators or someone responsible cases assume that the security administrators or someone responsible
for the existing and newly generated policies, are not aware of which for the existing and newly generated policies, are not aware of which
and/or how many NSFs are needed to meet the security requirements. and/or how many NSFs are needed to meet the security requirements.
Figure 20 represents the XML document generated from YANG discussed Figure 21 represents the XML document generated from YANG discussed
in previous sections. Once a high-level seucurity policy is created in previous sections. Once a high-level seucurity policy is created
by a security admin, it is delivered by the Consumer-Facing by a security admin, it is delivered by the Consumer-Facing
Interface, through RESTCONF server, to the security controller. The Interface, through RESTCONF server, to the security controller. The
XML instance is described below: XML instance is described below:
<?xml version="1.0" encoding="UTF-8" ?> <?xml version="1.0" encoding="UTF-8" ?>
<i2nsf-cfi-policy xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy"> <i2nsf-cfi-policy xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy">
<policy-name> <policy-name>
security_policy_for_blocking_malicious_voip_packets security_policy_for_blocking_malicious_voip_packets
</policy-name> </policy-name>
<rules> <rules>
<rule> <rule>
<rule-name>Block_malicious_voip_and_volte_packets</rule-name> <rule-name>Block_malicious_voip_and_volte_packets</rule-name>
<conditions> <condition>
<custom-condition> <custom-condition>
<source>malicious-id</source> <source>malicious-id</source>
</custom-condition> </custom-condition>
<firewall-condition> <firewall-condition>
<destination>employees</destination> <destination>employees</destination>
</firewall-condition> </firewall-condition>
</conditions> </condition>
<actions> <actions>
<primary-action>drop</primary-action> <primary-action>cfi-policy:drop</primary-action>
</actions> </actions>
<ipsec-method> <ipsec-method>
<method>ipsec-ikeless</method> <method>cfi-policy:ipsec-ikeless</method>
</ipsec-method> </ipsec-method>
</rule> </rule>
</rules> </rules>
</i2nsf-cfi-policy> </i2nsf-cfi-policy>
Figure 20: An XML Example for VoIP Security Service Figure 21: An XML Example for VoIP Security Service
Custom-condition Firewall Custom-condition Firewall
1. The policy name is 1. The policy name is
"security_policy_for_blocking_malicious_voip_packets". "security_policy_for_blocking_malicious_voip_packets".
2. The rule name is "Block_malicious_voip_and_volte_packets". 2. The rule name is "Block_malicious_voip_and_volte_packets".
3. The Source is "malicious-id". This can be a single ID or a list 3. The Source is "malicious-id". This can be a single ID or a list
of IDs, depending on how the ID are stored in the database. The of IDs, depending on how the ID are stored in the database. The
skipping to change at page 45, line 39 skipping to change at page 47, line 39
<rule-name>100_packets_per_second</rule-name> <rule-name>100_packets_per_second</rule-name>
<conditions> <conditions>
<ddos-condition> <ddos-condition>
<destination>webservers</destination> <destination>webservers</destination>
<rate-limit> <rate-limit>
<packet-threshold-per-second>100</packet-threshold-per-second> <packet-threshold-per-second>100</packet-threshold-per-second>
</rate-limit> </rate-limit>
</ddos-condition> </ddos-condition>
</conditions> </conditions>
<actions> <actions>
<primary-action>drop</primary-action> <primary-action>cfi-policy:drop</primary-action>
</actions> </actions>
<ipsec-method> <ipsec-method>
<method>ipsec-ikeless</method> <method>cfi-policy:ipsec-ikeless</method>
</ipsec-method> </ipsec-method>
</rule> </rule>
</rules> </rules>
</i2nsf-cfi-policy> </i2nsf-cfi-policy>
Figure 21: An XML Example for DDoS-attack Mitigation Figure 22: An XML Example for DDoS-attack Mitigation
DDoS-condition Firewall DDoS-condition Firewall
1. The policy name is "security_policy_for_ddos_attacks". 1. The policy name is "security_policy_for_ddos_attacks".
2. The rule name is "100_packets_per_second". 2. The rule name is "100_packets_per_second".
3. The destination target is "webservers". "webservers" is the key 3. The destination target is "webservers". "webservers" is the key
which represents the list containing information, such as IP which represents the list containing information, such as IP
addresses and ports, about web-servers. addresses and ports, about web-servers.
skipping to change at page 46, line 28 skipping to change at page 48, line 28
6. The action required is to "drop" packet reception is more than 6. The action required is to "drop" packet reception is more than
100 packets per second. 100 packets per second.
7. The IPsec method used for nsf traffic steering is set to "ipsec- 7. The IPsec method used for nsf traffic steering is set to "ipsec-
ike". ike".
10. XML Configuration Example of a User Group's Access Control for 10. XML Configuration Example of a User Group's Access Control for
I2NSF Consumer-Facing Interface I2NSF Consumer-Facing Interface
Note: This section is informative with an XML configuration example.
This is an example for creating privileges for a group of users This is an example for creating privileges for a group of users
(i.e., a user group) to access and use the I2NSF Consumer-Facing (i.e., a user group) to access and use the I2NSF Consumer-Facing
Interface to create security policies via the interface. For the Interface to create security policies via the interface. For the
access control of the Consumer-Facing Interface, the NACM module can access control of the Consumer-Facing Interface, the NACM module can
be used. Figure 22 shows an XML example the access control of a user be used. Figure 23 shows an XML example the access control of a user
group (named Example-Group) for I2NSF Consumer-Facing Interface A group (named Example-Group) for I2NSF Consumer-Facing Interface A
group called Example-Group can be created and configured with NACM group called Example-Group can be created and configured with NACM
for the Consumer-Facing Interface. For Example-Group, a rule list for the Consumer-Facing Interface. For Example-Group, a rule list
can created with the name of Example-Group-Rules. Example-Group- can created with the name of Example-Group-Rules. Example-Group-
Rules has two rules of Example-Group-Rule1 and Example-Group-Rule2 as Rules has two rules of Example-Group-Rule1 and Example-Group-Rule2 as
follows. For Example-Group-Rule1, the privilege of "Read" is allowed follows. For Example-Group-Rule1, the privilege of "Read" is allowed
to Example-Group for the Consumer-Facing Interface. On the other to Example-Group for the Consumer-Facing Interface. On the other
hand, for Example-Group-Rule2, the privileges of "Create", "Update", hand, for Example-Group-Rule2, the privileges of "Create", "Update",
and "Delete" are denied against Example-Group for the Consumer-Facing and "Delete" are denied against Example-Group for the Consumer-Facing
Interface. Interface.
skipping to change at page 47, line 34 skipping to change at page 49, line 34
</rule> </rule>
<rule> <rule>
<name>Example-Group-Rule2</name> <name>Example-Group-Rule2</name>
<access-operations>create update delete</access-operations> <access-operations>create update delete</access-operations>
<module-name>ietf-i2nsf-cfi-policy</module-name> <module-name>ietf-i2nsf-cfi-policy</module-name>
<action>deny</action> <action>deny</action>
</rule> </rule>
</rule-list> </rule-list>
</nacm> </nacm>
Figure 22: An XML Example of a User Group's Access Control for I2NSF Figure 23: An XML Example of a User Group's Access Control for I2NSF
Consumer-Facing Interface Consumer-Facing Interface
The access control for the I2NSF Consumer-Facing Interface is as The access control for the I2NSF Consumer-Facing Interface is as
follows. follows.
1. The NACM is enabled. 1. The NACM is enabled.
2. As a group name, Example-Group is specified. 2. As a group name, Example-Group is specified.
3. As members of the group, Alice, Bob, and Eve are specified. 3. As members of the group, Alice, Bob, and Eve are specified.
skipping to change at page 48, line 10 skipping to change at page 50, line 10
5. As the first rule name, Example-Group-Rule1 is specified. This 5. As the first rule name, Example-Group-Rule1 is specified. This
rule is used to give read privilege to Example-Group's members rule is used to give read privilege to Example-Group's members
for the module of the I2NSF Consumer-Facing Interface. for the module of the I2NSF Consumer-Facing Interface.
6. As the second rule name, Example-Group-Rule2 is specified. This 6. As the second rule name, Example-Group-Rule2 is specified. This
rule is used to deny create, update, and delete privileges rule is used to deny create, update, and delete privileges
against Example-Group's members for the module of the I2NSF against Example-Group's members for the module of the I2NSF
Consumer-Facing Interface. Consumer-Facing Interface.
11. Security Considerations 11. IANA Considerations
The data model for the I2NSF Consumer-Facing Interface is based on
the I2NSF framework [RFC8329], so the same security considerations
with the I2NSF framework should be included in this document. The
data model needs a secure communication channel to protect the
Consumer-Facing Interface between the I2NSF User and Security
Controller. Also, the data model's management access control is
based on Network Configuration Access Control Model(NACM) mechanisms
[RFC8341].
12. IANA Considerations
This document requests IANA to register the following URI in the This document requests IANA to register the following URI in the
"IETF XML Registry" [RFC3688]: "IETF XML Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy
Registrant Contact: The I2NSF. Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
This document requests IANA to register the following YANG module in This document requests IANA to register the following YANG module in
the "YANG Module Names" registry [RFC7950]. the "YANG Module Names" registry [RFC7950][RFC8525].
name: ietf-i2nsf-cfi-policy name: ietf-i2nsf-cfi-policy
namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy
prefix: cfi-policy prefix: cfi-policy
reference: RFC 7950 reference: RFC XXXX
12. Security Considerations
The data model for the I2NSF Consumer-Facing Interface is based on
the I2NSF framework [RFC8329], so the same security considerations
with the I2NSF framework should be included in this document. The
data model needs a secure communication channel to protect the
Consumer-Facing Interface between the I2NSF User and Security
Controller. Also, the data model's management access control is
based on Network Configuration Access Control Model(NACM) mechanisms
[RFC8341].
13. Acknowledgments 13. Acknowledgments
This work was supported by Institute of Information & Communications This work was supported by Institute of Information & Communications
Technology Planning & Evaluation (IITP) grant funded by the Korea Technology Planning & Evaluation (IITP) grant funded by the Korea
MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based
Security Intelligence Technology Development for the Customized Security Intelligence Technology Development for the Customized
Security Service Provisioning). Security Service Provisioning). This work was supported in part by
the IITP (2020-0-00395, Standard Development of Blockchain based
Network Management Automation Technology).
14. Contributors 14. 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, such as Mahdi F. Many people actively contributed to this document, such as Mahdi F.
Dachmehchi and Daeyoung Hyun. The authors sincerely appreciate their Dachmehchi and Daeyoung Hyun. The authors sincerely appreciate their
contributions. contributions.
The following are co-authors of this document: The following are co-authors of this document:
Patrick Lingga Patrick Lingga
Department of Electronic, Electrical and Computer Engineering Department of Electronic, Electrical and Computer Engineering
Sungkyunkwan University Sungkyunkwan University
2066 Seo-ro Jangan-gu 2066 Seo-ro Jangan-gu
Suwon, Gyeonggi-do 16419 Suwon, Gyeonggi-do 16419
skipping to change at page 51, line 4 skipping to change at page 53, line 7
Mountain View, CA 94043 Mountain View, CA 94043
US US
EMail: senad.palislamovic@nokia.com EMail: senad.palislamovic@nokia.com
Liang Xia Liang Xia
Huawei Huawei
101 Software Avenue 101 Software Avenue
Nanjing, Jiangsu 210012 Nanjing, Jiangsu 210012
China China
EMail: Frank.Xialiang@huawei.com EMail: Frank.Xialiang@huawei.com
15. References 15. References
15.1. Normative References 15.1. Normative References
[i2nsf-ipsec] [I-D.ietf-netmod-rfc6991-bis]
Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez- Schoenwaelder, J., "Common YANG Data Types", draft-ietf-
Garcia, "Software-Defined Networking (SDN)-based IPsec netmod-rfc6991-bis-04 (work in progress), July 2020.
Flow Protection", draft-ietf-i2nsf-sdn-ipsec-flow-
protection-08 (work in progress), June 2020. [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol
Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May
1983, <https://www.rfc-editor.org/info/rfc854>.
[RFC0913] Lottor, M., "Simple File Transfer Protocol", RFC 913,
DOI 10.17487/RFC0913, September 1984,
<https://www.rfc-editor.org/info/rfc913>.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985,
<https://www.rfc-editor.org/info/rfc959>.
[RFC1081] Rose, M., "Post Office Protocol: Version 3", RFC 1081,
DOI 10.17487/RFC1081, November 1988,
<https://www.rfc-editor.org/info/rfc1081>.
[RFC1631] Egevang, K. and P. Francis, "The IP Network Address
Translator (NAT)", RFC 1631, DOI 10.17487/RFC1631, May
1994, <https://www.rfc-editor.org/info/rfc1631>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616,
DOI 10.17487/RFC2616, June 1999,
<https://www.rfc-editor.org/info/rfc2616>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>.
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444, Information Models and Data Models", RFC 3444,
DOI 10.17487/RFC3444, January 2003, DOI 10.17487/RFC3444, January 2003,
<https://www.rfc-editor.org/info/rfc3444>. <https://www.rfc-editor.org/info/rfc3444>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
Reserved for Documentation", RFC 3849,
DOI 10.17487/RFC3849, July 2004,
<https://www.rfc-editor.org/info/rfc3849>.
[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Assigned Numbers", RFC 4250,
DOI 10.17487/RFC4250, January 2006,
<https://www.rfc-editor.org/info/rfc4250>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008,
<https://www.rfc-editor.org/info/rfc5321>.
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
Reserved for Documentation", RFC 5737,
DOI 10.17487/RFC5737, January 2010,
<https://www.rfc-editor.org/info/rfc5737>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
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 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/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, (I2NSF): Problem Statement and Use Cases", RFC 8192,
DOI 10.17487/RFC8192, July 2017, DOI 10.17487/RFC8192, July 2017,
<https://www.rfc-editor.org/info/rfc8192>. <https://www.rfc-editor.org/info/rfc8192>.
skipping to change at page 52, line 24 skipping to change at page 55, line 42
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341, Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018, DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>. <https://www.rfc-editor.org/info/rfc8341>.
[RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of
Documents Containing YANG Data Models", BCP 216, RFC 8407, Documents Containing YANG Data Models", BCP 216, RFC 8407,
DOI 10.17487/RFC8407, October 2018, DOI 10.17487/RFC8407, October 2018,
<https://www.rfc-editor.org/info/rfc8407>. <https://www.rfc-editor.org/info/rfc8407>.
15.2. Informative References [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K.,
and R. Wilton, "YANG Library", RFC 8525,
DOI 10.17487/RFC8525, March 2019,
<https://www.rfc-editor.org/info/rfc8525>.
[client-facing-inf-req] [RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W.
Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic, Kumari, "A Format for Self-Published IP Geolocation
S., and L. Xia, "Requirements for Client-Facing Interface Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020,
to Security Controller", draft-ietf-i2nsf-client-facing- <https://www.rfc-editor.org/info/rfc8805>.
interface-req-05 (work in progress), May 2018.
[i2nsf-capability-im] 15.2. Informative References
[I-D.ietf-i2nsf-capability]
Xia, L., Strassner, J., Basile, C., and D. Lopez, Xia, L., Strassner, J., Basile, C., and D. Lopez,
"Information Model of NSFs Capabilities", draft-ietf- "Information Model of NSFs Capabilities", draft-ietf-
i2nsf-capability-05 (work in progress), April 2019. i2nsf-capability-05 (work in progress), April 2019.
[i2nsf-terminology] [I-D.ietf-i2nsf-sdn-ipsec-flow-protection]
Hares, S., Strassner, J., Lopez, D., Xia, L., and H. Lopez, R., Lopez-Millan, G., and F. Pereniguez-Garcia,
Birkholz, "Interface to Network Security Functions (I2NSF) "Software-Defined Networking (SDN)-based IPsec Flow
Terminology", draft-ietf-i2nsf-terminology-08 (work in Protection", draft-ietf-i2nsf-sdn-ipsec-flow-protection-08
progress), July 2019. (work in progress), June 2020.
[STIX] Jordan, B., Piazza, R., and T. Darley, "STIX Version 2.1", [SNORT] Roesch, M., Green, C., and B. Caswell, "SNORT", SNORT
Documents https://www.snort.org/#documents, August 2020.
[STIX] Jordan, B., Piazza, R., and T. Darley, "Structured Threat
Information Expression (STIX)", STIX Version 2.1:
Committee Specification 01 https://docs.oasis- Committee Specification 01 https://docs.oasis-
open.org/cti/stix/v2.1/stix-v2.1.pdf, March 2020. open.org/cti/stix/v2.1/stix-v2.1.pdf, March 2020.
Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-interface- [SURICATA]
dm-08 Julien, V. and , "SURICATA", SURICATA Documents
https://suricata-ids.org/docs/, August 2020.
The following changes are made from draft-ietf-i2nsf-consumer-facing-
interface-dm-08:
o This version is revised according to the comments from Jan [YARA] Alvarez, V., Bengen, H., Metz, J., Buehlmann, S., and W.
Lindblad who reviewed this document as a YANG doctor. Shields, "YARA", YARA
Documents https://yara.readthedocs.io/en/v3.5.0/, August
2020.
Authors' Addresses Authors' Addresses
Jaehoon Paul Jeong Jaehoon Paul Jeong (editor)
Department of Computer Science and Engineering Department of Computer Science and Engineering
Sungkyunkwan University Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu 2066 Seobu-Ro, Jangan-Gu
Suwon, Gyeonggi-Do 16419 Suwon, Gyeonggi-Do 16419
Republic of Korea Republic of Korea
Phone: +82 31 299 4957 Phone: +82 31 299 4957
Fax: +82 31 290 7996 Fax: +82 31 290 7996
EMail: pauljeong@skku.edu EMail: pauljeong@skku.edu
URI: http://iotlab.skku.edu/people-jaehoon-jeong.php URI: http://iotlab.skku.edu/people-jaehoon-jeong.php
 End of changes. 258 change blocks. 
483 lines changed or deleted 619 lines changed or added

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