draft-ietf-i2nsf-consumer-facing-interface-dm-08.txt   draft-ietf-i2nsf-consumer-facing-interface-dm-09.txt 
I2NSF Working Group J. Jeong I2NSF Working Group J. Jeong
Internet-Draft C. Chung Internet-Draft C. Chung
Intended status: Standards Track Sungkyunkwan University Intended status: Standards Track Sungkyunkwan University
Expires: September 12, 2020 T. Ahn Expires: January 14, 2021 T. Ahn
Korea Telecom Korea Telecom
R. Kumar R. Kumar
Juniper Networks Juniper Networks
S. Hares S. Hares
Huawei Huawei
March 11, 2020 July 13, 2020
I2NSF Consumer-Facing Interface YANG Data Model I2NSF Consumer-Facing Interface YANG Data Model
draft-ietf-i2nsf-consumer-facing-interface-dm-08 draft-ietf-i2nsf-consumer-facing-interface-dm-09
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 organized based on the "Event-Condition-Action"
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 September 12, 2020. This Internet-Draft will expire on January 14, 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 . . . . . . . . 10 5. Information Model for Policy Endpoint Groups . . . . . . . . 9
5.1. User Group . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. User Group . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Device Group . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Device Group . . . . . . . . . . . . . . . . . . . . . . 11
5.3. Location Group . . . . . . . . . . . . . . . . . . . . . 12 5.3. Location Group . . . . . . . . . . . . . . . . . . . . . 12
6. Information Model for Threat Prevention . . . . . . . . . . . 13 6. Information Model for Threat Prevention . . . . . . . . . . . 13
6.1. Threat Feed . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Threat Feed . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Payload Content . . . . . . . . . . . . . . . . . . . . . 14 6.2. Payload Content . . . . . . . . . . . . . . . . . . . . . 14
7. Network Configuration Access Control Model (NACM) . . . . . . 15 7. Network Configuration Access Control Model (NACM) for I2NSF
8. YANG Data Model of Consumer-Facing Interface . . . . . . . . 15 Consumer-Facing Interface . . . . . . . . . . . . . . . . . . 15
8. YANG Data Model of Consumer-Facing Interface . . . . . . . . 17
9. XML Configuration Examples of High-Level Security Policy 9. XML Configuration Examples of High-Level Security Policy
Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
9.1. Database Registration: Information of Positions and 9.1. Database Registration: Information of Positions and
Devices (Endpoint Group) . . . . . . . . . . . . . 36 Devices (Endpoint Group) . . . . . . . . . . . . . . . . 40
9.2. Scenario 1: Block SNS Access during Business Hours . . . 37 9.2. Scenario 1: Block SNS Access during Business Hours . . . 41
9.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to 9.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to
a Company . . . . . . . . . . . . . . . . . . . . . . . . 39 a Company . . . . . . . . . . . . . . . . . . . . . . . . 43
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 . . . . . . . . . . . . . . . . . . . 40 Company Web Server . . . . . . . . . . . . . . . . . . . 45
10. Security Considerations . . . . . . . . . . . . . . . . . . . 42 10. XML Configuration Example of a User Group's Access Control
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 for I2NSF Consumer-Facing Interface . . . . . . . . . . . . . 46
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 11. Security Considerations . . . . . . . . . . . . . . . . . . . 48
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 42 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48
14.1. Normative References . . . . . . . . . . . . . . . . . . 44 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 48
14.2. Informative References . . . . . . . . . . . . . . . . . 45 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 51
15.1. Normative References . . . . . . . . . . . . . . . . . . 51
15.2. Informative References . . . . . . . . . . . . . . . . . 52
Appendix A. Changes from draft-ietf-i2nsf-consumer-facing- Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-
interface-dm-07 . . . . . . . . . . . . . . . . . . 47 interface-dm-08 . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 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 each vendor can register their NSFs using a Developer's Management
System (DMS). Assuming that vendors also provide the front-end web System (DMS). Assuming that vendors also provide the front-end web
applications registered with an I2NSF User, the Consumer-Facing applications registered with an I2NSF User, the Consumer-Facing
Interface is required because the web applications developed by each Interface is required because the web applications developed by each
vendor need to have a standard interface specifying the data types vendor need to have a standard interface specifying the data types
used when the I2NSF User and Security Controller communicate using used when the I2NSF User and Security Controller communicate using
skipping to change at page 5, line 32 skipping to change at page 5, line 32
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.
Owners: This field contains the owners of the policy. For
example, the owners who created it, and can modify it.
This field represents multiple groups owning as owners,
having full CRUD privileges by default. Note that it is
assumed that a factory-default owner (e.g., root) is
defined and preconfigured in Security Controller in order
to create new policy objects at first.
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
should be triggered by the monitoring service to perform an should be triggered by the monitoring service to perform an
exhaustive detection of anomalies among the configuration exhaustive detection of anomalies among the configuration
rules installed into the security functions. rules installed into the security functions.
+--rw i2nsf-cfi-policy* [policy-name] +--rw i2nsf-cfi-policy* [policy-name]
+--rw policy-name string +--rw policy-name string
| uses owners-ref +--rw rules
| +--rw rules* [rule-name]
+--rw endpoint-groups +--rw endpoint-groups
+--rw threat-prevention +--rw threat-prevention
Figure 2: Policy YANG Data Tree Figure 2: Policy YANG Data Tree
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.
Owners: This field contains the owners of the rule. For example,
the owners who created it, and can modify it. This field
represents multiple groups owning as owners, having full
CRUD privileges by default.
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 [i2nsf-ipsec].
+--rw rules* [rule-name] +--rw rules* [rule-name]
+--rw rule-name string +--rw rule-name string
| uses owners-ref
+--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" [i2nsf-capability-im].
skipping to change at page 7, line 30 skipping to change at page 7, line 20
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".
Enforce-type: This field identifies whether the event of Time-information: This represents the security rule is enforced
triggering policy enforcement is "Admin" or "Time". based on the period information with the end time for the
event.
Admin: This represents the enforcement type based on admin's Period: This represents the period of time the rule event is
decision. active.
Time: This represents the security rule is enforced based on End-time: This represents the end time of the event. If the rule
begin-time and end-time information. 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 (enforce-type)? +--rw time-information
| +--:(admin) | +--rw start-date-time? yang:date-and-time
| | +--rw admin? | +--rw end-date-time? yang:date-and-time
| +--:(time) | +--rw period
| +--rw time-information | | +--rw start-time? time
| +--rw begin-time? date-and-time | | +--rw stop-time? time
| +--rw end-time? date-and-time | | +--rw day* identityref
+--rw frequency? enumeration | | +--rw date* int32
| | +--rw month* string
+--rw frequency? enumeration
Figure 4: Event Sub-model YANG Data Tree Figure 4: Event Sub-model YANG Data Tree
4.2. Condition Sub-model 4.2. Condition Sub-model
This object represents Conditions that Security Administrator wants This object represents Conditions that Security Administrator wants
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-
skipping to change at page 9, line 16 skipping to change at page 9, line 5
obtained from threat-feeds (e.g., Palo-Alto, or RSA- obtained from threat-feeds (e.g., Palo-Alto, or RSA-
netwitness). This information is useful when security rule netwitness). This information is useful when security rule
condition is based on the existing threat reports gathered condition is based on the existing threat reports gathered
by other sources. The source and destination is 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 -> /../../nacm:group/nacm:user-name | +--rw source -> /../../user-group/name
| +--rw dest-target* -> /../../nacm:group/nacm:user-name | +--rw destination* -> /../../user-group/name
+--:(ddos-condition) +--:ddos-condition
| +--rw source* -> /../../device-group/name | +--rw source* -> /../../device-group/name
| +--rw dest-target* -> /../../device-group/name | +--rw destination* -> /../../device-group/name
| +--rw rate-limit | +--rw rate-limit
+--:(custom-condition) | +--rw packet-threshold-per-second? uint32
+--:location-condition
| +--rw source* -> /../../location-group/name
| +--rw destination -> /../../location-group/name
+--:custom-condition
| +--rw source* -> /../../payload-content/name | +--rw source* -> /../../payload-content/name
| +--rw dest-target -> /../../payload-content/name | +--rw destination -> /../../payload-content/name
+--:(threat-feed-condition) +--:threat-feed-condition
+--rw source* -> /../../threat-feed-list/name +--rw source* -> /../../threat-feed-list/name
+--rw dest-target -> /../../threat-feed-list/name +--rw destination -> /../../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 is
matched by an NSF. The action could be one of "log", 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 as
skipping to change at page 10, line 36 skipping to change at page 10, line 24
| |
+--------------+----------------+ +--------------+----------------+
1..n | 1..n | 1..n | 1..n | 1..n | 1..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]
... | ...
+--rw location-group* [name] | +--rw location-group* [name]
... | ...
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 IP-address: This represents the IPv4 address of a user in the
user group. user group.
range-ipv4-address: This represents the IPv4 address of a user in range-ipv4-address: This represents the IPv4 address of a user in
the user gorup. the user gorup.
range-ipv6-address: This represents the IPv6 address of a user in range-ipv6-address: This represents the IPv6 address of a user in
the user gorup. the user gorup.
+--rw user-group* [name] +--rw user-group* [name]
+--rw name -> /../../nacm:group/nacm:user-name +--rw name string
+--rw (match-type)? +--rw (match-type)
+--:(exact-match-ipv4) +--:(exact-match-ipv4)
| +--rw ipv4-address* inet:ipv4-address | +--rw ipv4? inet:ipv4-address
+--:(exact-match-ipv6) +--:(exact-match-ipv6)
| +--rw ipv6-address* inet:ipv6-address | +--rw ipv6? inet:ipv6-address
+--:(range-match-ipv4) +--:(range-match-ipv4)
| +--rw range-ipv4-address* | +--rw range-ipv4-address
[start-ipv4-address end-ipv4-address] | +--rw start-ipv4-address inet:ipv4-address
| +--rw start-ipv4-address inet:ipv4-address | +--rw end-ipv4-address inet:ipv4-address
| +--rw end-ipv4-address inet:ipv4-address +--:(range-match-ipv6)
+--:(range-match-ipv6) +--rw range-ipv6-address*
+--rw range-ipv6-address* +--rw start-ipv6-address inet:ipv6-address
[start-ipv6-vaddress end-ipv6-address] +--rw end-ipv6-address inet:ipv6-address
+--rw start-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.
skipping to change at page 12, line 9 skipping to change at page 12, line 5
range-ipv4-address: This represents the IPv4 address of a device range-ipv4-address: This represents the IPv4 address of a device
in the device gorup. in the device gorup.
range-ipv6-address: This represents the IPv6 address of a device range-ipv6-address: This represents the IPv6 address of a device
in the device gorup. in the device gorup.
Protocol: This represents the communication protocols used by the Protocol: This represents the communication protocols used by the
devices. The protocols are "SSH", "FTP", "SMTP", "HTTP", devices. The protocols are "SSH", "FTP", "SMTP", "HTTP",
"HTTPS", and etc. "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-address* inet:ipv4-address | | +--rw ipv4? inet:ipv4-address
| +--:(exact-match-ipv6) | +--:(exact-match-ipv6)
| | +--rw ipv6-address* inet:ipv6-address | | +--rw ipv6? inet:ipv6-address
| +--:(range-match-ipv4) | +--:(range-match-ipv4)
| | +--rw range-ipv4-address* | | +--rw range-ipv4-address*
[start-ipv4-address end-ipv4-address] | | | +--rw start-ipv4-address inet:ipv4-address
| | +--rw start-ipv4-address inet:ipv4-address | | | +--rw end-ipv4-address inet:ipv4-address
| | +--rw end-ipv4-address inet:ipv4-address | +--:(range-match-ipv6)
| +--:(range-match-ipv6) | | +--rw range-ipv6-address*
| +--rw range-ipv6-address* | | | +--rw start-ipv6-address inet:ipv6-address
[start-ipv6-vaddress end-ipv6-address] | | | +--rw end-ipv6-address inet:ipv6-address
| +--rw start-ipv6-address inet:ipv6-address +--rw protocol identityref
| +--rw end-ipv6-address inet:ipv6-address
+--rw protocol identityref
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 of a location.
geo-ip-ipv6: This field represents the IPv6 Geo-ip of a location. geo-ip-ipv6: This field represents the IPv6 Geo-ip of a location.
continent: This field represents the continent where the location continent: This field represents the continent where the location
group member is at. group member is at.
+--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
The threat prevention plays an important part in the overall security The threat prevention plays an important part in the overall security
posture by reducing the attack surfaces. This information could come posture by reducing the attack surfaces. This information could come
from various threat feeds (i.e., sources for obtaining the threat from various threat feeds (i.e., sources for obtaining the threat
information). There are multiple managed objects that constitute information). There are multiple managed objects that constitute
this category. This section lists these objects and relationship this category. This section lists these objects and relationship
skipping to change at page 13, line 38 skipping to change at page 13, line 30
+---------+---------+ +---------+---------+
1..n | 1..n | 1..n | 1..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 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:
skipping to change at page 14, line 26 skipping to change at page 14, line 18
(e.g., executable malware). (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 signatures of malicious
programs or activities provided by the threat-feed. The programs or activities provided by the threat-feed. The
examples of signature types are "YARA", "SURICATA", and examples of signature types are "YARA", "SURICATA", and
"SNORT". "SNORT".
+--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 exception to threat feeds. Figure 15 shows the YANG tree of
a Payload-content list. The Payload-Content object SHALL have the 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 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 in
a security attack, as strings. a security attack, 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) 7. Network Configuration Access Control Model (NACM) for I2NSF
Consumer-Facing Interface
Network Configuration Access Control Model (NACM) provides a high- Network Configuration Access Control Model (NACM) provides a user
level overview of the access control with the following features group with an access control with the following features [RFC8341]:
[RFC8341]:
o Independent control of action, data, and notification access is o Independent control of action, data, and notification access is
provided. provided.
o A simple and familiar set of datastore permissions is used. o A simple and familiar set of datastore permissions is used.
o Support for YANG security tagging allows default security modes to o Support for YANG security tagging allows default security modes to
automatically exclude sensitive data. automatically exclude sensitive data.
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 for the I2NSF Consumer-Facing Interface provides NACM The data model of the I2NSF Consumer-Facing Interface utilizes the
mechanisms and concepts to user-group and owners permissions. The NACM's mechanisms to manage the access control on the I2NSF Consumer-
NACM with the above features can be used to set up all the management Facing Interface. The NACM with the above features can be used to
access controls in the I2NSF high-level authorization view, and it set up the access control rules of a user group in the I2NSF
may have a high impact on the optimization and performance. Consumer-Facing Interface. Figure 16 shows part of the NACM module
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
NETCONF or RESTCONF server 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.,
ietf-i2nsf-cfi-policy). An XML example to configure the access
control a user group for the I2NSF Consumer-Facing Interface can be
seen in Section 10.
list rule {
key "name";
ordered-by user;
leaf name {
type string {
length "1..max";
}
description
"Arbitrary name assigned to the rule.";
}
leaf module-name {
type union {
type matchall-string-type;
type string;
}
default "*";
description
"Name of the module associated with this rule."
}
leaf access-operations {
type union {
type matchall-string-type;
type access-operations-type;
}
default "*";
description
"Access operations associated with this rule."
}
leaf action {
type action-type;
mandatory true;
description
"The access control action associated with the
rule. If a rule is determined to match a
particular request, then this object is used
to determine whether to permit or deny the
request.";
}
Figure 16: A Part of the NACM YANG Data Model
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
skipping to change at page 16, line 18 skipping to change at page 17, line 30
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. This document
suggests a VoIP/VoLTE security service as a use case for policy rule suggests a VoIP/VoLTE security service as a use case for policy rule
generation. generation.
This section describes a YANG data model for Consumer-Facing This section describes a YANG data model for Consumer-Facing
Interface, based on the information model of Consumer-Facing Interface, based on the information model of Consumer-Facing
Interface to Security Controller. Interface to Security Controller.
<CODE BEGINS> file "ietf-i2nsf-cfi-policy@2020-03-11.yang" <CODE BEGINS> file "ietf-i2nsf-cfi-policy@2020-07-13.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;
reference "Section 4 of RFC 6991"; }
import ietf-yang-types{
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 WG Chair: Linda Dunbar
<mailto:linda.dunbar@futurewei.com> <mailto:linda.dunbar@futurewei.com>
WG Chair: Yoav Nir WG Chair: Yoav Nir
<mailto:ynir.ietf@gmail.com> <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: Chaehong Chung
<mailto:darkhong@skku.edu>"; <mailto:darkhong@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 Copyright (c) 2020 IETF Trust and the persons
identified as authors of the code. All rights reserved. identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision "2020-03-11"{ revision "2020-07-13"{
description "The latest revision"; description "The latest revision";
reference reference
"draft-ietf-consumer-facing-interface-dm-07"; "draft-ietf-consumer-facing-interface-dm-08";
} }
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 18, line 31 skipping to change at page 19, line 44
description description
"Identity for Microsoft installer file types."; "Identity for Microsoft installer file types.";
} }
identity security-event-type { identity security-event-type {
description description
"Base identity for security event types."; "Base identity for security event types.";
} }
identity ddos { identity ddos {
base security-event-type;
description description
"Identity for DDoS event types."; "Identity for DDoS event types.";
} }
identity spyware { identity spyware {
base malware-file-type; base security-event-type;
description description
"Identity for spyware event types."; "Identity for spyware event types.";
} }
identity trojan { identity trojan {
base malware-file-type; base security-event-type;
description description
"Identity for Trojan infection event types."; "Identity for Trojan infection event types.";
} }
identity ransomware { identity ransomware {
base malware-file-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-07";
} }
identity ipsec-ike { identity ipsec-ike {
base i2nsf-ipsec; base i2nsf-ipsec;
description description
skipping to change at page 20, line 20 skipping to change at page 21, line 34
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 enforce-type {
description
"This identity represents the event of
policy enforcement trigger type.";
}
identity admin {
description
"The identity for policy enforcement by admin.";
}
identity time {
description
"The identity for policy enforcement based on time.";
}
identity protocol-type { identity protocol-type {
description description
"This identity represents the protocol types."; "This identity represents the protocol types.";
} }
identity ftp { identity ftp {
base protocol-type; base protocol-type;
description description
"The identity for ftp protocol."; "The identity for ftp protocol.";
reference reference
skipping to change at page 22, line 20 skipping to change at page 23, line 18
base protocol-type; base protocol-type;
description description
"The identity for nat."; "The identity for nat.";
reference reference
"RFC 1631: The IP Network Address Translator (NAT)"; "RFC 1631: The IP Network Address Translator (NAT)";
} }
identity primary-action { identity primary-action {
description description
"This identity represents the primary actions, such as "This identity represents the primary actions, such as
PASS, DROP, ALERT, RATE-LIMIT, and MIRROR."; PASS, DROP, ALERT, RATE-LIMIT, and MIRROR.";
} }
identity pass { identity pass {
base primary-action; base primary-action;
description description
"The identity for pass."; "The identity for pass.";
} }
identity drop { identity drop {
base primary-action; base primary-action;
skipping to change at page 23, line 4 skipping to change at page 23, line 50
base primary-action; base primary-action;
description description
"The identity for rate-limit."; "The identity for rate-limit.";
} }
identity mirror { identity mirror {
base primary-action; base primary-action;
description description
"The identity for mirroring."; "The identity for mirroring.";
} }
identity secondary-action { identity secondary-action {
description description
"This field identifies additional actions if a rule is "This field identifies additional actions if a rule is
matched. This could be one of 'LOG', 'SYSLOG', matched. This could be one of 'LOG', 'SYSLOG',
'SESSION-LOG', etc."; 'SESSION-LOG', etc.";
} }
identity log { identity log {
base secondary-action; base secondary-action;
description description
"The identity for logging."; "The identity for logging.";
} }
identity syslog { identity syslog {
base secondary-action; base secondary-action;
skipping to change at page 24, line 4 skipping to change at page 24, line 50
base signature-type; base signature-type;
description description
"This represents the SNORT signatures."; "This represents the SNORT signatures.";
} }
identity signature-suricata { identity signature-suricata {
base signature-type; base signature-type;
description description
"This represents the SURICATA signatures."; "This represents the SURICATA signatures.";
} }
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 {
* Typedefs description
*/ "This represents the base for days.";
typedef date-and-time { }
identity monday {
base day;
description
"This represents monday.";
}
identity tuesday {
base day;
description
"This represents tuesday.";
}
identity wednesday {
base day;
description
"This represents wednesday.";
}
identity thursday {
base day;
description
"This represents thursday.";
}
identity friday {
base day;
description
"This represents friday.";
}
identity saturday {
base day;
description
"This represents saturday.";
}
identity sunday {
base day;
description
"This represents sunday.";
}
/*
* Typedefs
*/
typedef time{
type string { type string {
pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?' pattern '\d{2}:\d{2}:\d{2}(\.\d+)?'
+ '(Z|[\+\-]\d{2}:\d{2})'; + '(Z|[\+\-]\d{2}:\d{2})';
} }
description description
"This is the format of date-and-time."; "This is the format of time.";
reference
"RFC 3339: Date and Time on the Internet: Timestamps
RFC 2579: Textual Conventions for SMIv2
XSD-TYPES: XML Schema Part 2: Datatypes Second Edition";
} }
/* /*
* Groupings * Groupings
*/ */
grouping ipv4-list { grouping ipv4-list {
description description
"Grouping for ipv4 based ip-addresses."; "Grouping for ipv4 based ip-addresses.";
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 the ipv4 ip-addresses.";
} }
} }
skipping to change at page 25, line 28 skipping to change at page 27, line 23
"This is the entry for the ipv6 ip-address."; "This is the entry for the ipv6 ip-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 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 type 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 type addresses";
} }
case range-match-ipv4 { case range-match-ipv4 {
list range-ipv4-address { container range-ipv4-address {
key "start-ipv4-address end-ipv4-address";
leaf start-ipv4-address { leaf start-ipv4-address {
type inet:ipv4-address; type inet:ipv4-address;
description description
"Start IPv4 address for a range match."; "Start IPv4 address for a range match.";
} }
leaf end-ipv4-address { leaf end-ipv4-address {
type inet:ipv4-address; type inet:ipv4-address;
description description
"End IPv4 address for a range match."; "End IPv4 address for a range match.";
} }
description description
"Range match for an IP-address."; "Range match for an IP-address.";
} }
} }
case range-match-ipv6 { case range-match-ipv6 {
list range-ipv6-address { container range-ipv6-address {
key "start-ipv6-address end-ipv6-address";
leaf start-ipv6-address { leaf start-ipv6-address {
type inet:ipv6-address; type inet:ipv6-address;
description description
"Start IPv6 address for a range match."; "Start IPv6 address for a range match.";
} }
leaf end-ipv6-address { leaf end-ipv6-address {
type inet:ipv6-address; type inet:ipv6-address;
description description
"End IPv6 address for a range match."; "End IPv6 address for a range match.";
} }
skipping to change at page 26, line 50 skipping to change at page 28, line 43
If this is not set, it cannot support IPsec IKE or If this 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-07";
} }
} }
} }
grouping user-group { grouping user-group {
description description
"The grouping for user-group entities, and "The grouping for user-group entities, and contains
contains information such as name & ip-address."; information such as name & ip-address.";
leaf name { leaf name {
type string; type string;
description description
"This represents the name of a user."; "This represents the name of a user-group.
A user-group name is used to map a user-group's
name (e.g., employees) to an ip address.
It is implementation dependent";
}
uses ip-address-info{
refine match-type{
mandatory true;
}
description
"This represent the IP address of a user-group.";
} }
uses ip-address-info;
} }
grouping device-group { grouping device-group {
description description
"This group represents device group information "This group represents device group information
such as ip-address protocol."; such as ip-address protocol.";
leaf name { leaf name {
type string; type string;
description description
"This represents the name of a device."; "This represents the name of a device-group.";
}
uses ip-address-info{
refine match-type{
mandatory true;
}
} }
uses ip-address-info;
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. devices.
If this is not set, it cannot support the If this is not set, it cannot support the
appropriate protocol"; appropriate protocol";
} }
skipping to change at page 27, line 44 skipping to change at page 29, line 50
grouping location-group { grouping location-group {
description description
"This group represents location-group information "This group represents location-group information
such as geo-ip and continent."; such as geo-ip 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.";
} }
leaf geo-ip-ipv4 { list geo-ip-ipv4 {
type inet:ipv4-address; key "ipv4-address";
description description
"This represents the IPv4 geo-ip of a location."; "This represents the list of IPv4 address based on
a location.";
leaf ipv4-address{
type inet:ipv4-address;
description
"This represents an IPv4 geo-ip of a location.";
}
leaf ipv4-prefix{
type inet:ipv4-prefix;
description
"This represents the prefix for the IPv4-address.";
}
} }
leaf geo-ip-ipv6 { list geo-ip-ipv6 {
type inet:ipv6-address; key "ipv6-address";
description description
"This represents the IPv6 geo-ip of a location."; "This represents the list of IPv6 address based on
a location.";
leaf ipv6-address{
type inet:ipv6-address;
description
"This represents an IPv6 geo-ip of a location.";
}
leaf ipv6-prefix{
type inet:ipv6-prefix;
description
"This represents the prefix for the IPv6-address.";
}
} }
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-based on geo-ip of
respective continent."; respective 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 name { leaf threat-type {
type identityref { type identityref {
base threat-feed-type; base threat-feed-type;
} }
description description
"This represents the name of the a 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 ip-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 ip-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 description should include information, such as The description should include information, such as
the type, related threat, method, and file type."; the type, related threat, method, and file type.
Structured Threat Information Expression (STIX) can
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 such as name and string It contains information such as name and string
content."; content.";
leaf description { leaf description {
type string; type string;
skipping to change at page 29, line 26 skipping to change at page 32, line 8
Due to the types of threats, the type of the Due to the types of threats, the type of the
content is defined as string to accommodate content is defined as string to accommodate
any kind of a payload type such as HTTP, HTTPS, any kind of a payload type such as HTTP, HTTPS,
and SIP. and SIP.
If this is not set, it cannot support the If this is not set, it cannot support the
payload contents involved in a security attack payload contents involved in a security attack
as strings"; as strings";
} }
} }
grouping owners-ref {
description
"This grouping is for owners reference using
Network Configuration Access Control Model
(NACM).";
leaf-list owners {
type leafref {
path "/nacm:nacm/nacm:groups/nacm:group/nacm:name";
}
description
"This leaf-list names the owner groups of the
list instance it sits on. Only the owners listed
in a NACM group are authorized to get full CRUD
privileges for the contents.
If this is not set, it cannot support who has
the prvilege of the contents";
}
}
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 the security policy list. Each policy in
the list contains a list of security rules, and is the list contains a list of security rules, and is
a policy instance to have complete information a policy instance to have complete information
such as where and when a policy needs to be such as where and when a policy needs to be
applied."; applied.";
leaf policy-name { leaf policy-name {
type string; type string;
mandatory true;
description description
"The name which identifies the policy."; "The name which identifies the policy."; }
}
uses owners-ref;
container rules{ container rules{
description description
"This container is for rules."; "This container is for 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;
mandatory true;
description description
"This represents the name for the rule."; "This represents the name for the rule.";
} }
description description
"There can be a single or multiple number of "There can be a single or multiple number of
rules."; rules.";
uses owners-ref;
container event { container event {
description description
"This represents the event (e.g., a security "This represents the event (e.g., a security
event, for which a security rule is made.)"; event, for which 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 security
events. If this is not set, it cannot events. If this is not set, it cannot
support which security event is enforced"; support which security event is enforced";
} }
choice enforce-type {
container time-information {
description description
"There are two different enforcement types; "The time information when the security
admin, and time. rule should be applied.";
It cannot be allowed to configure leaf start-date-time {
admin=='time' or enforce-time=='admin'."; type yang:date-and-time;
case enforce-admin { description
leaf admin { "This is the start date and time
type string; for policy.";
}
leaf end-date-time {
type yang:date-and-time;
description
"This is the end date and time
for policy. The policy will stop
working after the specified
end-date-time";
}
container period{
when
"/i2nsf-cfi-policy/rules/rule/event/frequency!='only-once'";
description
"This represents the repetition time.
In case of frequency is weekly, the days
can be set.";
leaf start-time {
type time;
description description
"This represents the enforcement type "This is period start time for event.";
based on admin's decision.";
} }
} leaf end-time {
case time { type time;
container time-information {
description description
"The begin-time and end-time information "This is period end time for event.";
when the security rule should be applied."; }
leaf enforce-time { leaf-list day {
type date-and-time; when
description "/i2nsf-cfi-policy/rules/rule/event/frequency='weekly'";
"The enforcement type is time-enforced."; type identityref{
base day;
} }
leaf begin-time { description
type date-and-time; "This represents the repeated day of
description every week (e.g., monday and tuesday).
"This is start time for time zone"; More than one day can be specified";
}
leaf-list date {
when
"/i2nsf-cfi-policy/rules/rule/event/frequency='monthly'";
type int32{
range "1..31";
} }
leaf end-time { description
type date-and-time; "This represents the repeated date of
description every month. More than one date can be
"This is end time for time zone"; specified.";
}
leaf-list month {
when
"/i2nsf-cfi-policy/rules/rule/event/frequency='yearly'";
type string{
pattern '\d{2}-\d{2}';
} }
description
"This represents the repeated date and month
of every year. More than one can be specified.
Pattern used is Month-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 the rule is enforced
only once immediately and not only once immediately and not repeated.
repeated."; The policy will continuously active from
start time and terminated at end-time.";
} }
enum daily { enum daily {
description description
"This represents the rule is enforced "This represents the rule is enforced
on a daily basis."; on a daily basis. The policy will be
repeated daily until the end-date.";
} }
enum weekly { enum weekly {
description description
"This represents the rule is enforced "This represents the rule is enforced
on a weekly basis."; on a weekly basis. The policy will be
repeated weekly until the end-date. The
repeated days can be specified.";
} }
enum monthly { enum monthly {
description description
"This represents the rule is enforced "This represents the rule is enforced
on a monthly basis."; on a monthly basis. The policy will be
repeated monthly until the end-date.";
}
enum yearly {
description
"This represents the rule is enforced
on a yearly basis. The policy will be
repeated yearly until the end-date.";
} }
} }
default only-once; default only-once;
description description
"This represents how frequent the rule "This represents how frequent the rule
should be enforced."; should be enforced.";
} }
} }
container condition { container condition {
description description
"The conditions for general security policies."; "The conditions for general security policies.";
container firewall-condition { container firewall-condition {
description description
"The general firewall condition."; "The general firewall condition.";
leaf source { leaf source {
type leafref { type leafref {
path "/i2nsf-cfi-policy/endpoint-groups/user-group/name"; path
"/i2nsf-cfi-policy/endpoint-groups/user-group/name";
} }
description description
"This describes the paths to the source reference."; "This describes the paths to the source reference.";
} }
leaf-list dest-target {
leaf-list destination {
type leafref { type leafref {
path "/i2nsf-cfi-policy/endpoint-groups/user-group/name"; path
"/i2nsf-cfi-policy/endpoint-groups/user-group/name";
} }
description description
"This describes the paths to the destination "This describes the paths to the destination
target reference."; target reference.";
} }
} }
container ddos-condition { container ddos-condition {
description description
"The condition for DDoS mitigation."; "The condition for DDoS mitigation.";
leaf-list source { leaf-list source {
type leafref { type leafref {
path "/i2nsf-cfi-policy/endpoint-groups/device-group/name"; path
"/i2nsf-cfi-policy/endpoint-groups/device-group/name";
} }
description description
"This describes the path to the "This describes the path to the
source target references."; source target references.";
} }
leaf-list dest-target { leaf-list destination {
type leafref { type leafref {
path "/i2nsf-cfi-policy/endpoint-groups/device-group/name"; path
"/i2nsf-cfi-policy/endpoint-groups/device-group/name";
} }
description description
"This describes the path to the destination target "This describes the path to the destination target
references."; 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 the condition.";
} }
} }
} }
container location-condition {
description
"The condition for location based connection";
leaf-list source {
type leafref {
path
"/i2nsf-cfi-policy/endpoint-groups/location-group/name";
}
description
"This describes the path to the location
source reference.";
}
leaf-list destination {
type leafref {
path
"/i2nsf-cfi-policy/endpoint-groups/location-group/name";
}
description
"This describes the path to the location
destination reference.";
}
}
container custom-condition { container custom-condition {
description description
"The condition based on packet contents."; "The condition based on packet contents.";
leaf-list source { leaf-list source {
type leafref { type leafref {
path "/i2nsf-cfi-policy/threat-preventions/payload-content/name"; path
"/i2nsf-cfi-policy/threat-preventions/payload-content/name";
} }
description description
"Describes the payload string content condition "Describes the payload string content condition
source."; source.";
} }
leaf dest-target { leaf destination {
type leafref { type leafref {
path "/i2nsf-cfi-policy/threat-preventions/payload-content/name"; path
"/i2nsf-cfi-policy/threat-preventions/payload-content/name";
} }
description description
"Describes the payload string content condition destination."; "Describes the payload string content condition
destination.";
} }
} }
container threat-feed-condition { container threat-feed-condition {
description description
"The condition based on the threat-feed information."; "The condition based on the threat-feed information.";
leaf-list source { leaf-list source {
type leafref { type leafref {
path "/i2nsf-cfi-policy/threat-preventions/threat-feed-list/name"; path
"/i2nsf-cfi-policy/threat-preventions/threat-feed-list/name";
} }
description description
"Describes the threat-feed condition source."; "Describes the threat-feed condition source.";
} }
leaf dest-target { leaf destination {
type leafref { type leafref {
path "/i2nsf-cfi-policy/threat-preventions/threat-feed-list/name"; path
"/i2nsf-cfi-policy/threat-preventions/threat-feed-list/name";
} }
description
description "Describes the threat-feed condition destination.";
"Describes the threat-feed condition 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 the primary actions (e.g.,
PASS, DROP, ALERT, and MIRROR) to be PASS, DROP, ALERT, and MIRROR) to be
applied a condition. applied a condition.
If this is not set, it cannot support If this is not set, it cannot support
the primary actions."; the primary actions.";
skipping to change at page 35, line 9 skipping to change at page 38, line 49
which includes IPsec IKE and IPsec IKEless which includes IPsec IKE and IPsec IKEless
cases. cases.
If this is not set, it cannot support If this is not set, it cannot support
IPsec IKE or IPsec IKEless."; IPsec IKE or IPsec IKEless.";
reference reference
"draft-ietf-i2nsf-sdn-ipsec-flow-protection-07"; "draft-ietf-i2nsf-sdn-ipsec-flow-protection-07";
} }
} }
} }
} }
container endpoint-groups { container endpoint-groups {
description description
"A logical entity in their business "A logical entity in their business
environment, where a security policy environment, where a security 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 the 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 the device group.";
} }
list location-group{ list location-group{
skipping to change at page 35, line 43 skipping to change at page 39, line 33
} }
container threat-preventions { container threat-preventions {
description description
"this describes the list of threat-prevention."; "this describes the list of threat-prevention.";
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 {
type string;
description
"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; 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 the virus."; be scanned for the virus.";
} }
leaf-list signatures { leaf-list signatures {
type identityref { type identityref {
base signature-type; base signature-type;
} }
default signature-suricata; default signature-suricata;
description description
"This contains a list of signatures or hash "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 payload-content.
It should give an idea of why specific payload It should give an idea of why specific payload
skipping to change at page 36, line 36 skipping to change at page 40, line 30
} }
description description
"This represents the payload-string group."; "This represents the payload-string group.";
uses payload-string; uses payload-string;
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
Figure 16: 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
This section shows XML configuration examples of high-level security Note: This section is informative with XML configuration examples.
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 17 shows an example XML protocols used by devices. Figure 18 shows an example XML
representation of the registered information for the user-group and representation of the registered information for the user-group and
device-group. device-group.
<?xml version="1.0" encoding="UTF-8" ?> <?xml version="1.0" encoding="UTF-8" ?>
<endpoint-groups 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">
<user-group> <endpoint-groups>
<name>employees</name> <user-group>
<range-ipv4-address> <name>employees</name>
<start-ipv4-address>221.159.112.1</start-ipv4-address> <range-ipv4-address>
<end-ipv4-address>221.159.112.90</end-ipv4-address> <start-ipv4-address>221.159.112.1</start-ipv4-address>
</range-ipv4-address> <end-ipv4-address>221.159.112.90</end-ipv4-address>
</user-group> </range-ipv4-address>
<device-group> </user-group>
<name>webservers</name> <device-group>
<range-ipv4-address> <name>webservers</name>
<start-ipv4-address>221.159.112.91</start-ipv4-address> <range-ipv4-address>
<end-ipv4-address>221.159.112.97</end-ipv4-address> <start-ipv4-address>221.159.112.91</start-ipv4-address>
</range-ipv4-address> <end-ipv4-address>221.159.112.97</end-ipv4-address>
<protocol>http</protocol> </range-ipv4-address>
<protocol>https</protocol> <protocol>http</protocol>
</device-group> <protocol>https</protocol>
</endpoint-groups> </device-group>
</endpoint-groups>
</i2nsf-cfi-policy>
Figure 17: Registering User-group and Device-group Information Figure 18: Registering User-group and Device-group Information
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. The access Social Networking Services (SNS) during the office hours
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" ?>
<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>security_policy_for_blocking_sns</policy-name> <policy-name>security_policy_for_blocking_sns123</policy-name>
<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>
<begin-time>2020-03-11T09:00:00.00Z</begin-time> <start-date-time>2020-03-11T09:00:00.00Z</start-date-time>
<end-time>2020-03-11T18:00:00.00Z</end-time> <end-date-time>2020-12-31T18:00:00.00Z</end-date-time>
<period>
<start-time>09:00:00Z</start-time>
<end-time>18:00:00Z</end-time>
<day>monday</day>
<day>tuesday</day>
<day>wednesday</day>
<day>thursday</day>
<day>friday</day>
</period>
</time-information> </time-information>
<frequency>only-once</frequency> <frequency>weekly</frequency>
</event> </event>
<conditions> <condition>
<firewall-condition> <firewall-condition>
<source>employees</source> <source>employees</source>
</firewall-condition> </firewall-condition>
<custom-condition> </condition>
<dest-target>sns-websites</dest-target>
</custom-condition>
</conditions>
<actions> <actions>
<primary-action>drop</primary-action> <primary-action>drop</primary-action>
</actions> </actions>
<ipsec-method>
<method>ipsec-ike</method>
</ipsec-method>
</rule> </rule>
</rules> </rules>
</i2nsf-cfi-policy> </i2nsf-cfi-policy>
Figure 18: An XML Example for Time-based Firewall Figure 19: 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 39, line 19 skipping to change at page 43, line 22
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 19 represents the XML document generated from YANG discussed Figure 20 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>security_policy_for_blocking_malicious_voip_packets</policy-name> <policy-name>
security_policy_for_blocking_malicious_voip_packets
</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> <conditions>
<custom-condition> <custom-condition>
<source>malicious-id</source> <source>malicious-id</source>
</custom-condition> </custom-condition>
<firewall-condition> <firewall-condition>
<dest-target>employees</dest-target> <destination>employees</destination>
</firewall-condition> </firewall-condition>
</conditions> </conditions>
<actions> <actions>
<primary-action>drop</primary-action> <primary-action>drop</primary-action>
</actions> </actions>
<ipsec-method> <ipsec-method>
<method>ipsec-ikeless</method> <method>ipsec-ikeless</method>
</ipsec-method> </ipsec-method>
</rule> </rule>
</rules> </rules>
</i2nsf-cfi-policy> </i2nsf-cfi-policy>
Figure 19: An XML Example for VoIP Security Service Figure 20: 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
"malicious-id" is the key so that the security admin can read "malicious-id" is the key so that the security admin can read
every stored malicious VOIP IDs that are named as "malicious-id". every stored malicious VOIP IDs that are named as "malicious-id".
skipping to change at page 41, line 13 skipping to change at page 45, line 32
act according to the rule set. The XML instance is described below: act according to the rule set. The 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>security_policy_for_ddos_attacks</policy-name> <policy-name>security_policy_for_ddos_attacks</policy-name>
<rules> <rules>
<rule> <rule>
<rule-name>100_packets_per_second</rule-name> <rule-name>100_packets_per_second</rule-name>
<conditions> <conditions>
<ddos-condition> <ddos-condition>
<dest-target>webservers</dest-target> <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>drop</primary-action>
</actions> </actions>
<ipsec-method> <ipsec-method>
<method>ipsec-ikeless</method> <method>ipsec-ikeless</method>
</ipsec-method> </ipsec-method>
</rule> </rule>
</rules> </rules>
</i2nsf-cfi-policy> </i2nsf-cfi-policy>
Figure 20: An XML Example for DDoS-attack Mitigation Figure 21: 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.
4. The rate limit exists to limit the incoming amount of packets per 4. The rate limit exists to limit the incoming amount of packets per
second. In this case the rate limit is "100" packets per second. second. In this case the rate limit is "100" packets per second.
skipping to change at page 42, line 5 skipping to change at page 46, line 25
server devices. server devices.
5. The Source is all sources which send abnormal amount of packets. 5. The Source is all sources which send abnormal amount of packets.
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. Security Considerations 10. XML Configuration Example of a User Group's Access Control for
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
(i.e., a user group) to access and use the I2NSF Consumer-Facing
Interface to create security policies via the interface. For the
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
group (named Example-Group) for I2NSF Consumer-Facing Interface A
group called Example-Group can be created and configured with NACM
for the Consumer-Facing Interface. For Example-Group, a rule list
can created with the name of Example-Group-Rules. Example-Group-
Rules has two rules of Example-Group-Rule1 and Example-Group-Rule2 as
follows. For Example-Group-Rule1, the privilege of "Read" is allowed
to Example-Group for the Consumer-Facing Interface. On the other
hand, for Example-Group-Rule2, the privileges of "Create", "Update",
and "Delete" are denied against Example-Group for the Consumer-Facing
Interface.
<?xml version="1.0" encoding="UTF-8" ?>
<nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm">
<enable-nacm>true</enable-nacm>
<groups>
<group>
<name>Example-Group</name>
<user-name>Alice</user-name>
<user-name>Bob</user-name>
<user-name>Eve</user-name>
</group>
</groups>
<rule-list>
<name>Example-Group-Rules</name>
<group>Example-Group</group>
<rule>
<name>Example-Group-Rule1</name>
<access-operations>read</access-operations>
<module-name>ietf-i2nsf-cfi-policy</module-name>
<action>permit</action>
</rule>
<rule>
<name>Example-Group-Rule2</name>
<access-operations>create update delete</access-operations>
<module-name>ietf-i2nsf-cfi-policy</module-name>
<action>deny</action>
</rule>
</rule-list>
</nacm>
Figure 22: An XML Example of a User Group's Access Control for I2NSF
Consumer-Facing Interface
The access control for the I2NSF Consumer-Facing Interface is as
follows.
1. The NACM is enabled.
2. As a group name, Example-Group is specified.
3. As members of the group, Alice, Bob, and Eve are specified.
4. As a rule list name, Example-Group-Rules is specified for
managing privileges of Example-Group's members.
5. As the first rule name, Example-Group-Rule1 is specified. This
rule is used to give read privilege to Example-Group's members
for the module of the I2NSF Consumer-Facing Interface.
6. As the second rule name, Example-Group-Rule2 is specified. This
rule is used to deny create, update, and delete privileges
against Example-Group's members for the module of the I2NSF
Consumer-Facing Interface.
11. Security Considerations
The data model for the I2NSF Consumer-Facing Interface is based on The data model for the I2NSF Consumer-Facing Interface is based on
the I2NSF framework [RFC8329], so the same security considerations the I2NSF framework [RFC8329], so the same security considerations
with the I2NSF framework should be included in this document. The with the I2NSF framework should be included in this document. The
data model needs a secure communication channel to protect the data model needs a secure communication channel to protect the
Consumer-Facing Interface between the I2NSF User and Security Consumer-Facing Interface between the I2NSF User and Security
Controller. Also, the data model's management access control is Controller. Also, the data model's management access control is
based on Network Configuration Access Control Model(NACM) mechanisms based on Network Configuration Access Control Model(NACM) mechanisms
[RFC8341]. [RFC8341].
11. IANA Considerations 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 I2NSF.
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].
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 7950
12. 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).
13. 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
Department of Electronic, Electrical and Computer Engineering
Sungkyunkwan University
2066 Seo-ro Jangan-gu
Suwon, Gyeonggi-do 16419
Republic of Korea
EMail: patricklink@skku.edu
Hyoungshick Kim Hyoungshick Kim
Department of Computer Science and Engineering Department of Computer Science and Engineering
Sungkyunkwan University Sungkyunkwan University
2066 Seo-ro Jangan-gu 2066 Seo-ro Jangan-gu
Suwon, Gyeonggi-do 16419 Suwon, Gyeonggi-do 16419
Republic of Korea Republic of Korea
EMail: hyoung@skku.edu EMail: hyoung@skku.edu
Eunsoo Kim Eunsoo Kim
skipping to change at page 44, line 33 skipping to change at page 51, line 4
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
14. References 15. References
14.1. Normative References 15.1. Normative References
[i2nsf-ipsec]
Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez-
Garcia, "Software-Defined Networking (SDN)-based IPsec
Flow Protection", draft-ietf-i2nsf-sdn-ipsec-flow-
protection-08 (work in progress), June 2020.
[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>.
skipping to change at page 45, line 47 skipping to change at page 52, line 24
[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>.
14.2. Informative References 15.2. Informative References
[client-facing-inf-req] [client-facing-inf-req]
Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic, Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic,
S., and L. Xia, "Requirements for Client-Facing Interface S., and L. Xia, "Requirements for Client-Facing Interface
to Security Controller", draft-ietf-i2nsf-client-facing- to Security Controller", draft-ietf-i2nsf-client-facing-
interface-req-05 (work in progress), May 2018. interface-req-05 (work in progress), May 2018.
[i2nsf-capability-im] [i2nsf-capability-im]
Xia, L., Strassner, J., Basile, C., and D. Lopez, Xia, L., Strassner, J., Basile, C., and D. Lopez,
"Information Model of NSFs Capabilities", draft-ietf- "Information Model of NSFs Capabilities", draft-ietf-
i2nsf-capability-05 (work in progress), April 2019. i2nsf-capability-05 (work in progress), April 2019.
[i2nsf-ipsec]
Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez-
Garcia, "Software-Defined Networking (SDN)-based IPsec
Flow Protection", draft-ietf-i2nsf-sdn-ipsec-flow-
protection-07 (work in progress), August 2019.
[i2nsf-terminology] [i2nsf-terminology]
Hares, S., Strassner, J., Lopez, D., Xia, L., and H. Hares, S., Strassner, J., Lopez, D., Xia, L., and H.
Birkholz, "Interface to Network Security Functions (I2NSF) Birkholz, "Interface to Network Security Functions (I2NSF)
Terminology", draft-ietf-i2nsf-terminology-08 (work in Terminology", draft-ietf-i2nsf-terminology-08 (work in
progress), July 2019. progress), July 2019.
[STIX] Jordan, B., Piazza, R., and T. Darley, "STIX Version 2.1",
Committee Specification 01 https://docs.oasis-
open.org/cti/stix/v2.1/stix-v2.1.pdf, March 2020.
Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-interface- Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-interface-
dm-07 dm-08
The following changes are made from draft-ietf-i2nsf-consumer-facing- The following changes are made from draft-ietf-i2nsf-consumer-facing-
interface-dm-07: interface-dm-08:
o This version is revised according to the comments from Jan o This version is revised according to the comments from Jan
Lindblad who reviewed this document as a YANG doctor. Lindblad who reviewed this document as a YANG doctor.
Authors' Addresses Authors' Addresses
Jaehoon Paul Jeong Jaehoon Paul Jeong
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
 End of changes. 163 change blocks. 
378 lines changed or deleted 645 lines changed or added

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