draft-ietf-i2nsf-consumer-facing-interface-dm-10.txt   draft-ietf-i2nsf-consumer-facing-interface-dm-11.txt 
I2NSF Working Group J. Jeong, Ed. I2NSF Working Group J. Jeong, Ed.
Internet-Draft C. Chung Internet-Draft C. Chung
Intended status: Standards Track Sungkyunkwan University Intended status: Standards Track Sungkyunkwan University
Expires: March 1, 2021 T. Ahn Expires: March 10, 2021 T. Ahn
Korea Telecom Korea Telecom
R. Kumar R. Kumar
Juniper Networks Juniper Networks
S. Hares S. Hares
Huawei Huawei
August 28, 2020 September 6, 2020
I2NSF Consumer-Facing Interface YANG Data Model I2NSF Consumer-Facing Interface YANG Data Model
draft-ietf-i2nsf-consumer-facing-interface-dm-10 draft-ietf-i2nsf-consumer-facing-interface-dm-11
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 based on the "Event-Condition-Action" (ECA) information model is based on the "Event-Condition-Action" (ECA)
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 March 1, 2021. This Internet-Draft will expire on March 10, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Information Model for Policy . . . . . . . . . . . . . . . . 5
4. Information Model for Policy . . . . . . . . . . . . . . . . 5 3.1. Event Sub-model . . . . . . . . . . . . . . . . . . . . . 6
4.1. Event Sub-model . . . . . . . . . . . . . . . . . . . . . 7 3.2. Condition Sub-model . . . . . . . . . . . . . . . . . . . 7
4.2. Condition Sub-model . . . . . . . . . . . . . . . . . . . 8 3.3. Action Sub-model . . . . . . . . . . . . . . . . . . . . 9
4.3. Action Sub-model . . . . . . . . . . . . . . . . . . . . 9 4. Information Model for Policy Endpoint Groups . . . . . . . . 10
5. Information Model for Policy Endpoint Groups . . . . . . . . 10 4.1. User Group . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. User Group . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Device Group . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Device Group . . . . . . . . . . . . . . . . . . . . . . 12 4.3. Location Group . . . . . . . . . . . . . . . . . . . . . 13
5.3. Location Group . . . . . . . . . . . . . . . . . . . . . 13 5. Information Model for Threat Prevention . . . . . . . . . . . 14
6. Information Model for Threat Prevention . . . . . . . . . . . 14 5.1. Threat Feed . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Threat Feed . . . . . . . . . . . . . . . . . . . . . . . 14 5.2. Payload Content . . . . . . . . . . . . . . . . . . . . . 15
6.2. Payload Content . . . . . . . . . . . . . . . . . . . . . 15 6. Network Configuration Access Control Model (NACM) for I2NSF
7. Network Configuration Access Control Model (NACM) for I2NSF
Consumer-Facing Interface . . . . . . . . . . . . . . . . . . 16 Consumer-Facing Interface . . . . . . . . . . . . . . . . . . 16
8. YANG Data Model of Consumer-Facing Interface . . . . . . . . 18 7. YANG Data Model of Consumer-Facing Interface . . . . . . . . 18
8.1. YANG Module of Consumer-Facing Interface . . . . . . . . 18 7.1. YANG Module of Consumer-Facing Interface . . . . . . . . 18
9. XML Configuration Examples of High-Level Security Policy 8. XML Configuration Examples of High-Level Security Policy
Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
9.1. Database Registration: Information of Positions and 8.1. Database Registration: Information of Positions and
Devices (Endpoint Group) . . . . . . . . . . . . . . . . 41 Devices (Endpoint Group) . . . . . . . . . . . . . . . . 42
9.2. Scenario 1: Block SNS Access during Business Hours . . . 43 8.2. Scenario 1: Block SNS Access during Business Hours . . . 44
9.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to 8.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to
a Company . . . . . . . . . . . . . . . . . . . . . . . . 45 a Company . . . . . . . . . . . . . . . . . . . . . . . . 46
9.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a 8.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a
Company Web Server . . . . . . . . . . . . . . . . . . . 47 Company Web Server . . . . . . . . . . . . . . . . . . . 48
10. XML Configuration Example of a User Group's Access Control 9. XML Configuration Example of a User Group's Access Control
for I2NSF Consumer-Facing Interface . . . . . . . . . . . . . 48 for I2NSF Consumer-Facing Interface . . . . . . . . . . . . . 49
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
12. Security Considerations . . . . . . . . . . . . . . . . . . . 50 11. Security Considerations . . . . . . . . . . . . . . . . . . . 51
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 54
15.1. Normative References . . . . . . . . . . . . . . . . . . 53 14.1. Normative References . . . . . . . . . . . . . . . . . . 54
15.2. Informative References . . . . . . . . . . . . . . . . . 56 14.2. Informative References . . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57
1. Introduction 1. Introduction
In a framework of Interface to Network Security Functions (I2NSF) In a framework of Interface to Network Security Functions (I2NSF)
[RFC8329], each vendor can register their NSFs using a Developer's [RFC8329], each vendor can register their NSFs using a Developer's
Management System (DMS). Assuming that vendors also provide the Management System (DMS). Assuming that vendors also provide the
front-end web applications registered with an I2NSF User, the front-end web applications registered with an I2NSF User, the
Consumer-Facing Interface is required because the web applications Consumer-Facing Interface is required because the web applications
developed by each vendor need to have a standard interface specifying developed by each vendor need to have a standard interface specifying
the data types used when the I2NSF User and Security Controller the data types used when the I2NSF User and Security Controller
skipping to change at page 5, line 5 skipping to change at page 5, line 5
Network Functions Virtualization (NFV) system leads to a rapid Network Functions Virtualization (NFV) system leads to a rapid
advance in the network industry. As practical applications, Network advance in the network industry. As practical applications, Network
Security Functions (NSFs), such as firewall, Intrusion Detection Security Functions (NSFs), such as firewall, Intrusion Detection
System (IDS)/Intrusion Prevention System (IPS), and attack System (IDS)/Intrusion Prevention System (IPS), and attack
mitigation, can also be provided as Virtual Network Functions (VNF) mitigation, can also be provided as Virtual Network Functions (VNF)
in the NFV system. By the efficient virtualization technology, these in the NFV system. By the efficient virtualization technology, these
VNFs might be automatically provisioned and dynamically migrated VNFs might be automatically provisioned and dynamically migrated
based on real-time security requirements. This document presents a based on real-time security requirements. This document presents a
YANG data model to implement security functions based on NFV. YANG data model to implement security functions based on NFV.
2. Requirements Language 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119][RFC3444]
[RFC8174].
3. Terminology
This document uses the terminology described in [RFC8329]. This document uses the terminology described in [RFC8329].
This document follows the guidelines of [RFC8407], uses the common This document follows the guidelines of [RFC8407], uses the common
YANG types defined in [I-D.ietf-netmod-rfc6991-bis], and adopts the YANG types defined in [I-D.ietf-netmod-rfc6991-bis], and adopts the
Network Management Datastore Architecture (NMDA). The meaning of the Network Management Datastore Architecture (NMDA). The meaning of the
symbols in tree diagrams is defined in [RFC8340]. symbols in tree diagrams is defined in [RFC8340].
4. Information Model for Policy 3. Information Model for Policy
A Policy object represents a mechanism to express a Security Policy A Policy object represents a mechanism to express a Security Policy
by Security Administrator (i.e., I2NSF User) using Consumer-Facing by Security Administrator (i.e., I2NSF User) using Consumer-Facing
Interface toward Security Controller; the policy would be enforced on Interface toward Security Controller; the policy would be enforced on
an NSF. Figure 2 shows the YANG tree of the Policy object. The an NSF. Figure 2 shows the YANG tree of the Policy object. The
Policy object SHALL have the following information: Policy object SHALL have the following information:
Name: This field identifies the name of this object. Name: This field identifies the name of this object.
Rule: This field contains a list of rules. These rules are Rule: This field contains a list of rules. These rules are
skipping to change at page 7, line 9 skipping to change at page 6, line 42
+--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" [I-D.ietf-i2nsf-capability]. of NSFs Capabilities" [I-D.ietf-i2nsf-capability].
4.1. Event Sub-model 3.1. Event Sub-model
The Event Object contains information related to scheduling a Rule. The Event Object contains information related to scheduling a Rule.
The Rule could be activated based on a set time or security event. The Rule could be activated based on a set time or security event.
Figure 4 shows the YANG tree of the Event object. Event object SHALL Figure 4 shows the YANG tree of the Event object. Event object SHALL
have following information: have following information:
Security-event: This field identifies for which security event Security-event: This field identifies for which security event
the policy is enforced. The examples of security events the policy is enforced. The examples of security events
are: "DDOS", "spyware", "trojan", and "ransomware". are: "DDOS", "spyware", "trojan", and "ransomware".
skipping to change at page 8, line 5 skipping to change at page 7, line 39
| +--rw period | +--rw period
| | +--rw start-time? time | | +--rw start-time? time
| | +--rw stop-time? time | | +--rw stop-time? time
| | +--rw day* identityref | | +--rw day* identityref
| | +--rw date* int32 | | +--rw date* int32
| | +--rw month* string | | +--rw month* string
+--rw frequency? enumeration +--rw frequency? enumeration
Figure 4: Event Sub-model YANG Data Tree Figure 4: Event Sub-model YANG Data Tree
4.2. Condition Sub-model 3.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-
mitigation cases, and a case when the condition is based on the mitigation cases, and a case when the condition is based on the
payload strings of packets. Each containers have source and payload strings of packets. Each containers have source and
destination-target to represent the source and destination for each destination-target to represent the source and destination for each
case. Figure 5 shows the YANG tree of the Condition object. The case. Figure 5 shows the YANG tree of the Condition object. The
skipping to change at page 9, line 36 skipping to change at page 9, line 36
| +--rw destination? | +--rw destination?
| | -> /i2nsf-cfi-policy/threat-preventions/payload-content/name | | -> /i2nsf-cfi-policy/threat-preventions/payload-content/name
+--:threat-feed-condition +--:threat-feed-condition
+--rw source* +--rw source*
| -> /i2nsf-cfi-policy/threat-preventions/threat-feed-list/name | -> /i2nsf-cfi-policy/threat-preventions/threat-feed-list/name
+--rw destination? +--rw destination?
| -> /i2nsf-cfi-policy/threat-preventions/threat-feed-list/name | -> /i2nsf-cfi-policy/threat-preventions/threat-feed-list/name
Figure 5: Condition Sub-model YANG Data Tree Figure 5: Condition Sub-model YANG Data Tree
4.3. Action Sub-model 3.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 Secondary-action: This field identifies the action when a rule
is matched by an NSF. The action could be one of "log", is matched by an NSF. The action could be one of "log",
"syslog", "session-log". "syslog", "session-log".
+--rw action +--rw action
+--rw primary-action identityref +--rw primary-action identityref
+--rw secondary-action? identityref +--rw secondary-action? identityref
Figure 6: Action Sub-model YANG Data Tree Figure 6: Action Sub-model YANG Data Tree
5. Information Model for Policy Endpoint Groups 4. 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, multiple managed objects that constitute a Policy's Endpoint Group,
as shown in Figure 7. Figure 8 shows the YANG tree of the Endpoint- as shown in Figure 7. Figure 8 shows the YANG tree of the Endpoint-
Groups object. This section lists these objects and relationship Groups object. This section lists these objects and relationship
among them. among them.
skipping to change at page 11, line 15 skipping to change at page 11, line 15
+--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 4.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.
IPv4: This represents the IPv4 address of a user in the user IPv4: This represents the IPv4 address of a user in the user
group. group.
skipping to change at page 12, line 23 skipping to change at page 12, line 23
| +--rw range-ipv4-address | +--rw range-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 +--rw start-ipv6-address inet:ipv6-address
+--rw end-ipv6-address inet:ipv6-address +--rw end-ipv6-address inet:ipv6-address
Figure 9: User Group YANG Data Tree Figure 9: User Group YANG Data Tree
5.2. Device Group 4.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.
IPv4: This represents the IPv4 address of a device in the device IPv4: This represents the IPv4 address of a device in the device
group. group.
skipping to change at page 13, line 24 skipping to change at page 13, line 24
| | | +--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 | | | +--rw start-ipv6-address inet:ipv6-address
| | | +--rw end-ipv6-address inet:ipv6-address | | | +--rw end-ipv6-address inet:ipv6-address
+--rw protocol identityref +--rw protocol identityref
Figure 10: Device Group YANG Data Tree Figure 10: Device Group YANG Data Tree
5.3. Location Group 4.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 address of a Geo-ip-ipv4: This field represents the IPv4 Geo-ip address of a
location [RFC8805]. location [RFC8805].
skipping to change at page 14, line 5 skipping to change at page 14, line 5
location group member is located. location group member is located.
+--rw location-group* [name] +--rw location-group* [name]
+--rw name string +--rw name string
+--rw geo-ip-ipv4 inet:ipv4-address +--rw geo-ip-ipv4 inet:ipv4-address
+--rw geo-ip-ipv6 inet:ipv6-address +--rw geo-ip-ipv6 inet:ipv6-address
+--rw continent? identityref +--rw continent? identityref
Figure 11: Location Group YANG Data Tree Figure 11: Location Group YANG Data Tree
6. Information Model for Threat Prevention 5. 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
among them. Figure 13 shows the YANG tree of a Threat-Prevention among them. Figure 13 shows the YANG tree of a Threat-Prevention
object. object.
+-------------------+ +-------------------+
skipping to change at page 14, line 36 skipping to change at page 14, line 36
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 5.1. Threat Feed
This object represents a threat feed which provides the signatures of This object represents a threat feed which provides the signatures of
malicious activities. Figure 14 shows the YANG tree of a Threat- malicious activities. Figure 14 shows the YANG tree of a Threat-
feed-list. The Threat-Feed object SHALL have the following feed-list. The Threat-Feed object SHALL have the following
information: information:
Name: This field identifies the name of this object. Name: This field identifies the name of this object.
Server-ipv4: This represents the IPv4 server address of the feed Server-ipv4: This represents the IPv4 server address of the feed
provider, which may be either an external or local server. provider, which may be either an external or local server.
skipping to change at page 15, line 36 skipping to change at page 15, line 36
+--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 5.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 an exception to threat feeds. Figure 15 shows the YANG tree defining an exception to threat feeds. Figure 15 shows the YANG tree
of a Payload-content list. The Payload-Content object SHALL have the of a Payload-content list. The Payload-Content object SHALL have the
following information: following information:
Name: This field identifies the name of this object. For Name: This field identifies the name of this object. For
example, the name "backdoor" indicates the payload content example, the name "backdoor" indicates the payload content
is related to a backdoor attack. is related to a backdoor attack.
skipping to change at page 16, line 12 skipping to change at page 16, line 12
Content: This contains the payload contents, which are involed Content: This contains the payload contents, which are involed
in a security attack, such as strings. in a security attack, such as strings.
+--rw payload-content* [name] +--rw payload-content* [name]
+--rw name string +--rw name string
+--rw description string +--rw description string
+--rw content* string +--rw content* string
Figure 15: Payload Content in YANG Data Tree Figure 15: Payload Content in YANG Data Tree
7. Network Configuration Access Control Model (NACM) for I2NSF 6. Network Configuration Access Control Model (NACM) for I2NSF
Consumer-Facing Interface Consumer-Facing Interface
Network Configuration Access Control Model (NACM) provides a user Network Configuration Access Control Model (NACM) provides a user
group with an access control with the following features [RFC8341]: group with an access control with the following features [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.
skipping to change at page 16, line 45 skipping to change at page 16, line 45
Consumer-Facing Interface. Consumer-Facing Interface.
Figure 16 shows part of the NACM module to enable the access control 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 of a user group for the I2NSF Consumer-Facing Interface. To use the
NACM, a user needs to configure either a NETCONF server [RFC6241] or NACM, a user needs to configure either a NETCONF server [RFC6241] or
a RESTCONF server [RFC8040] to enable the NACM module. Then, the a RESTCONF server [RFC8040] to enable the NACM module. Then, the
user can simply use an account of root or admin user for the access user can simply use an account of root or admin user for the access
control for the module of the I2NSF Consumer-Facing Interface (i.e., control for the module of the I2NSF Consumer-Facing Interface (i.e.,
ietf-i2nsf-cfi-policy). An XML example to configure the access ietf-i2nsf-cfi-policy). An XML example to configure the access
control a user group for the I2NSF Consumer-Facing Interface can be control a user group for the I2NSF Consumer-Facing Interface can be
seen in Section 10. seen in Section 9.
list rule { list rule {
key "name"; key "name";
ordered-by user; ordered-by user;
leaf name { leaf name {
type string { type string {
length "1..max"; length "1..max";
} }
description description
"Arbitrary name assigned to the rule."; "Arbitrary name assigned to the rule.";
skipping to change at page 18, line 5 skipping to change at page 18, line 5
description description
"The access control action associated with the "The access control action associated with the
rule. If a rule is determined to match a rule. If a rule is determined to match a
particular request, then this object is used particular request, then this object is used
to determine whether to permit or deny the to determine whether to permit or deny the
request."; request.";
} }
Figure 16: A Part of the NACM YANG Data Model Figure 16: A Part of the NACM YANG Data Model
8. YANG Data Model of Consumer-Facing Interface 7. YANG Data Model of Consumer-Facing Interface
The main objective of this data model is to provide both an The main objective of this data model is to provide both an
information model and the corresponding YANG data model of I2NSF information model and the corresponding YANG data model of I2NSF
Consumer-Facing Interface. This interface can be used to deliver Consumer-Facing Interface. This interface can be used to deliver
control and management messages between an I2NSF User and Security control and management messages between an I2NSF User and Security
Controller for the I2NSF User's high-level security policies. Controller for the I2NSF User's high-level security policies.
The semantics of the data model must be aligned with the information The semantics of the data model must be aligned with the information
model of the Consumer-Facing Interface. The transformation of the model of the Consumer-Facing Interface. The transformation of the
information model is performed so that this YANG data model can information model is performed so that this YANG data model can
skipping to change at page 18, line 27 skipping to change at page 18, line 27
messages. messages.
This data model is designed to support the I2NSF framework that can This data model is designed to support the I2NSF framework that can
be extended according to the security needs. In other words, the be extended according to the security needs. In other words, the
model design is independent of the content and meaning of specific model design is independent of the content and meaning of specific
policies as well as the implementation approach. policies as well as the implementation approach.
With the YANG data model of I2NSF Consumer-Facing Interface, this With the YANG data model of I2NSF Consumer-Facing Interface, this
document suggests use cases for security policy rules such as time- document suggests use cases for security policy rules such as time-
based firewall, VoIP/VoLTE security service, and DDoS-attack based firewall, VoIP/VoLTE security service, and DDoS-attack
mitigation in Section 9. mitigation in Section 8.
8.1. YANG Module of Consumer-Facing Interface 7.1. YANG Module of Consumer-Facing Interface
This section describes a YANG module of Consumer-Facing Interface. This section describes a YANG module of Consumer-Facing Interface.
This YANG module imports from [RFC6991] and uses the typedef of time This YANG module imports from [I-D.ietf-netmod-rfc6991-bis]. It
in [I-D.ietf-netmod-rfc6991-bis]. It makes references to [RFC0854][R makes references to [RFC0854][RFC0913][RFC0959][RFC1081][RFC1631][RFC
FC0913][RFC0959][RFC1081][RFC1631][RFC2616][RFC2818][RFC4250][RFC5321 2616][RFC2818][RFC4250][RFC5321].
].
<CODE BEGINS> file "ietf-i2nsf-cfi-policy@2020-08-28.yang" <CODE BEGINS> file "ietf-i2nsf-cfi-policy@2020-09-06.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 cfi-policy; prefix nsfcfi;
import ietf-inet-types{ import ietf-inet-types{
prefix inet; prefix inet;
} }
import ietf-yang-types{ import ietf-yang-types{
prefix yang; prefix yang;
} }
import ietf-netconf-acm { import ietf-netconf-acm {
skipping to change at page 19, line 37 skipping to change at page 19, line 37
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-08-28"{ // RFC Ed.: replace XXXX with an actual RFC number and remove
// this note.
revision "2020-09-06"{
description "Initial revision."; description "Initial revision.";
reference reference
"RFC XXXX: I2NSF Consumer-Facing Interface YANG Data Model"; "RFC XXXX: I2NSF Consumer-Facing Interface YANG Data Model";
// RFC Ed.: replace XXXX with an actual RFC number and remove
// this note.
} }
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
"Identity for executable file types."; "Identity for executable file types.";
} }
identity doc-file { identity doc-file {
base malware-file-type; base malware-file-type;
description description
"Identity for Microsoft document file types."; "Identity for Microsoft document file types.";
} }
identity html-app-file { identity html-app-file {
base malware-file-type; base malware-file-type;
skipping to change at page 27, line 34 skipping to change at page 27, line 40
*/ */
typedef time { typedef time {
type string { type string {
pattern '(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.\d+)?' pattern '(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.\d+)?'
+ '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?'; + '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?';
} }
description description
"The time type represents an instance of time of zero-duration "The time type represents an instance of time of zero-duration
that recurs every day."; that recurs every day.";
reference reference
"draft-ietf-netmod-rfc6991-bis-04: Common YANG Data Types - "RFC 6991-bis: Common YANG Data Types - typedef time is used.";
typedef time is used.";
// RFC Ed.: When RFC 6991-bis becomes an RFC, remove 'typedef time'
// this note.
} }
/* /*
* Groupings * Groupings
*/ */
grouping ipv4-list { grouping ipv4-list {
description description
"Grouping for an IPv4 address list."; "Grouping for an IPv4 address list.";
leaf-list ipv4 { leaf-list ipv4 {
skipping to change at page 34, line 38 skipping to change at page 34, line 46
end-date-time."; end-date-time.";
} }
container period{ container period{
when when
"../../frequency!='only-once'"; "../../frequency!='only-once'";
description description
"This represents the repetition time. In the case where "This represents the repetition time. In the case where
the frequency is weekly, the days can be set."; the frequency is weekly, the days can be set.";
leaf start-time { leaf start-time {
type time; type time;
// RFC Ed.: When RFC 6991-bis becomes an RFC, time must
// be replaced with yang:time.
// this note.
description description
"This is a period's start time for an event."; "This is a period's start time for an event.";
reference reference
"RFC 6991-bis: Common YANG Data Types - The time type "RFC 6991-bis: Common YANG Data Types - The time type
represents an instance of time of zero-duration that represents an instance of time of zero-duration that
recurs every day. When RFC 6991-bis becomes an RFC, recurs every day.";
time must be replaced with yang:time.";
// RFC Ed.: Replace 6991-bis with an actual RFC number
// and remove this note.
} }
leaf end-time { leaf end-time {
type time; type time;
// RFC Ed.: When RFC 6991-bis becomes an RFC, time must
// be replaced with yang:time.
// this note.
description description
"This is a period's end time for an event."; "This is a period's end time for an event.";
reference reference
"RFC 6991-bis: Common YANG Data Types - The time type "RFC 6991-bis: Common YANG Data Types - The time type
represents an instance of time of zero-duration that represents an instance of time of zero-duration that
recurs every day. When RFC 6991-bis becomes an RFC, recurs every day.";
time must be replaced with yang:time.";
// RFC Ed.: Replace 6991-bis with an actual RFC number
// and remove this note.
} }
leaf-list day { leaf-list day {
when when
"../../../frequency='weekly'"; "../../../frequency='weekly'";
type identityref{ type identityref{
base day; base day;
} }
min-elements 1; min-elements 1;
description description
"This represents the repeated day of every week (e.g., "This represents the repeated day of every week (e.g.,
skipping to change at page 41, line 28 skipping to change at page 42, line 4
description description
"This represents the name of a packet's payload-content. It "This represents the name of a packet's payload-content. It
should give an idea of why a specific payload content is should give an idea of why a specific payload content is
marked as a threat. For example, the name 'backdoor' marked as a threat. For example, the name 'backdoor'
indicates the payload content is related to a backdoor indicates the payload content is related to a backdoor
attack."; attack.";
} }
description description
"This represents a payload-string group."; "This represents a payload-string group.";
uses payload-string; uses payload-string;
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
Figure 17: YANG for Consumer-Facing Interface Figure 17: YANG for Consumer-Facing Interface
9. XML Configuration Examples of High-Level Security Policy Rules 8. XML Configuration Examples of High-Level Security Policy Rules
This section shows XML configuration examples of high-level security 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 8.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. protocols used by devices.
Figure 18 shows an example XML representation of the registered Figure 18 shows an example XML representation of the registered
skipping to change at page 42, line 27 skipping to change at page 43, line 21
<start-ipv4-address>192.0.2.11</start-ipv4-address> <start-ipv4-address>192.0.2.11</start-ipv4-address>
<end-ipv4-address>192.0.2.90</end-ipv4-address> <end-ipv4-address>192.0.2.90</end-ipv4-address>
</range-ipv4-address> </range-ipv4-address>
</user-group> </user-group>
<device-group> <device-group>
<name>webservers</name> <name>webservers</name>
<range-ipv4-address> <range-ipv4-address>
<start-ipv4-address>198.51.100.11</start-ipv4-address> <start-ipv4-address>198.51.100.11</start-ipv4-address>
<end-ipv4-address>198.51.100.20</end-ipv4-address> <end-ipv4-address>198.51.100.20</end-ipv4-address>
</range-ipv4-address> </range-ipv4-address>
<protocol>cfi-policy:http</protocol> <protocol>nsfcfi:http</protocol>
<protocol>cfi-policy:https</protocol> <protocol>nsfcfi:https</protocol>
</device-group> </device-group>
</endpoint-groups> </endpoint-groups>
</i2nsf-cfi-policy> </i2nsf-cfi-policy>
Figure 18: Registering User-group and Device-group Information with Figure 18: Registering User-group and Device-group Information with
IPv4 Addresses IPv4 Addresses
Also, Figure 19 shows an example XML representation of the registered Also, Figure 19 shows an example XML representation of the registered
information for the user-group and device-group with IPv6 addresses information for the user-group and device-group with IPv6 addresses
[RFC3849]. [RFC3849].
skipping to change at page 43, line 21 skipping to change at page 44, line 21
<start-ipv6-address>2001:DB8:0:1::11</start-ipv6-address> <start-ipv6-address>2001:DB8:0:1::11</start-ipv6-address>
<end-ipv6-address>2001:DB8:0:1::90</end-ipv6-address> <end-ipv6-address>2001:DB8:0:1::90</end-ipv6-address>
</range-ipv6-address> </range-ipv6-address>
</user-group> </user-group>
<device-group> <device-group>
<name>webservers</name> <name>webservers</name>
<range-ipv6-address> <range-ipv6-address>
<start-ipv6-address>2001:DB8:0:2::11</start-ipv6-address> <start-ipv6-address>2001:DB8:0:2::11</start-ipv6-address>
<end-ipv6-address>2001:DB8:0:2::20</end-ipv6-address> <end-ipv6-address>2001:DB8:0:2::20</end-ipv6-address>
</range-ipv6-address> </range-ipv6-address>
<protocol>cfi-policy:http</protocol> <protocol>nsfcfi:http</protocol>
<protocol>cfi-policy:https</protocol> <protocol>nsfcfi:https</protocol>
</device-group> </device-group>
</endpoint-groups> </endpoint-groups>
</i2nsf-cfi-policy> </i2nsf-cfi-policy>
Figure 19: Registering User-group and Device-group Information with Figure 19: Registering User-group and Device-group Information with
IPv6 Addresses IPv6 Addresses
9.2. Scenario 1: Block SNS Access during Business Hours 8.2. Scenario 1: Block SNS Access during Business Hours
The first example scenario is to "block SNS access during office The first example scenario is to "block SNS access during office
hours" using a time-based firewall policy. In this scenario, all hours" using a time-based firewall policy. In this scenario, all
users registered as "employees" in the user-group list are unable to users registered as "employees" in the user-group list are unable to
access Social Networking Services (SNS) during the office hours access Social Networking Services (SNS) during the office hours
(weekdays). The XML instance is described below: (weekdays). The XML instance is described below:
<?xml version="1.0" encoding="UTF-8" ?> <?xml version="1.0" encoding="UTF-8" ?>
<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_sns123</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>
<start-date-time>2020-03-11T09:00:00.00Z</start-date-time> <start-date-time>2020-03-11T09:00:00.00Z</start-date-time>
<end-date-time>2020-12-31T18:00:00.00Z</end-date-time> <end-date-time>2020-12-31T18:00:00.00Z</end-date-time>
<period> <period>
<start-time>09:00:00Z</start-time> <start-time>09:00:00Z</start-time>
<end-time>18:00:00Z</end-time> <end-time>18:00:00Z</end-time>
<day>cfi-policy:monday</day> <day>nsfcfi:monday</day>
<day>cfi-policy:tuesday</day> <day>nsfcfi:tuesday</day>
<day>cfi-policy:wednesday</day> <day>nsfcfi:wednesday</day>
<day>cfi-policy:thursday</day> <day>nsfcfi:thursday</day>
<day>cfi-policy:friday</day> <day>nsfcfi:friday</day>
</period> </period>
</time-information> </time-information>
<frequency>weekly</frequency> <frequency>weekly</frequency>
</event> </event>
<condition> <condition>
<firewall-condition> <firewall-condition>
<source>employees</source> <source>employees</source>
</firewall-condition> </firewall-condition>
<custom-condition> <custom-condition>
<destination>sns-websites</destination> <destination>sns-websites</destination>
</custom-condition> </custom-condition>
</condition> </condition>
<actions> <actions>
<primary-action>cfi-policy:drop</primary-action> <primary-action>nsfcfi:drop</primary-action>
</actions> </actions>
</rule> </rule>
</rules> </rules>
</i2nsf-cfi-policy> </i2nsf-cfi-policy>
Figure 20: An XML Example for Time-based Firewall Figure 20: An XML Example for Time-based Firewall
Time-based-condition Firewall Time-based-condition Firewall
1. The policy name is "security_policy_for_blocking_sns". 1. The policy name is "security_policy_for_blocking_sns".
skipping to change at page 45, line 15 skipping to change at page 46, line 15
4. The destination target is "sns-websites". "sns-websites" is the 4. The destination target is "sns-websites". "sns-websites" is the
key which represents the list containing the information, such as key which represents the list containing the information, such as
URL, about sns-websites. URL, about sns-websites.
5. The action required is to "drop" any attempt to connect to 5. The action required is to "drop" any attempt to connect to
websites related to Social networking. websites related to Social networking.
6. The IPsec method type used for nsf traffic steering is set to 6. The IPsec method type used for nsf traffic steering is set to
"ipsec-ike". "ipsec-ike".
9.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to a Company 8.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to a Company
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.
skipping to change at page 46, line 22 skipping to change at page 47, line 22
<rule-name>Block_malicious_voip_and_volte_packets</rule-name> <rule-name>Block_malicious_voip_and_volte_packets</rule-name>
<condition> <condition>
<custom-condition> <custom-condition>
<source>malicious-id</source> <source>malicious-id</source>
</custom-condition> </custom-condition>
<firewall-condition> <firewall-condition>
<destination>employees</destination> <destination>employees</destination>
</firewall-condition> </firewall-condition>
</condition> </condition>
<actions> <actions>
<primary-action>cfi-policy:drop</primary-action> <primary-action>nsfcfi:drop</primary-action>
</actions> </actions>
<ipsec-method> <ipsec-method>
<method>cfi-policy:ipsec-ikeless</method> <method>nsfcfi:ipsec-ikeless</method>
</ipsec-method> </ipsec-method>
</rule> </rule>
</rules> </rules>
</i2nsf-cfi-policy> </i2nsf-cfi-policy>
Figure 21: An XML Example for VoIP Security Service Figure 21: An XML Example for VoIP Security Service
Custom-condition Firewall Custom-condition Firewall
1. The policy name is 1. The policy name is
skipping to change at page 47, line 8 skipping to change at page 48, line 8
4. The destination target is "employees". "employees" is the key 4. The destination target is "employees". "employees" is the key
which represents the list containing information about employees, which represents the list containing information about employees,
such as IP addresses. such as IP addresses.
5. The action required is "drop" when any incoming packets are from 5. The action required is "drop" when any incoming packets are from
"malicious-id". "malicious-id".
6. The IPsec method used for nsf traffic steering is set to "ipsec- 6. The IPsec method used for nsf traffic steering is set to "ipsec-
ikeless". ikeless".
9.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a Company Web 8.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a Company Web
Server Server
The third example scenario is to "Mitigate HTTP and HTTPS flood The third example scenario is to "Mitigate HTTP and HTTPS flood
attacks on a company web server" using a DDoS-attack mitigation attacks on a company web server" using a DDoS-attack mitigation
policy. Here, the time information is not set because the service policy. Here, the time information is not set because the service
provided by the network should be maintained at all times. If the provided by the network should be maintained at all times. If the
packets sent by any sources are more than the set threshold, then the packets sent by any sources are more than the set threshold, then the
admin can set the percentage of the packets to be dropped to safely admin can set the percentage of the packets to be dropped to safely
maintain the service. In this scenario, the source is set as "any" maintain the service. In this scenario, the source is set as "any"
to block any sources which send abnormal amount of packets. The to block any sources which send abnormal amount of packets. The
skipping to change at page 47, line 39 skipping to change at page 48, line 39
<rule-name>100_packets_per_second</rule-name> <rule-name>100_packets_per_second</rule-name>
<conditions> <conditions>
<ddos-condition> <ddos-condition>
<destination>webservers</destination> <destination>webservers</destination>
<rate-limit> <rate-limit>
<packet-threshold-per-second>100</packet-threshold-per-second> <packet-threshold-per-second>100</packet-threshold-per-second>
</rate-limit> </rate-limit>
</ddos-condition> </ddos-condition>
</conditions> </conditions>
<actions> <actions>
<primary-action>cfi-policy:drop</primary-action> <primary-action>nsfcfi:drop</primary-action>
</actions> </actions>
<ipsec-method> <ipsec-method>
<method>cfi-policy:ipsec-ikeless</method> <method>nsfcfi:ipsec-ikeless</method>
</ipsec-method> </ipsec-method>
</rule> </rule>
</rules> </rules>
</i2nsf-cfi-policy> </i2nsf-cfi-policy>
Figure 22: An XML Example for DDoS-attack Mitigation Figure 22: An XML Example for DDoS-attack Mitigation
DDoS-condition Firewall DDoS-condition Firewall
1. The policy name is "security_policy_for_ddos_attacks". 1. The policy name is "security_policy_for_ddos_attacks".
skipping to change at page 48, line 25 skipping to change at page 49, 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. XML Configuration Example of a User Group's Access Control for 9. XML Configuration Example of a User Group's Access Control for I2NSF
I2NSF Consumer-Facing Interface Consumer-Facing Interface
This is an example for creating privileges for a group of users This is an example for creating privileges for a group of users
(i.e., a user group) to access and use the I2NSF Consumer-Facing (i.e., a user group) to access and use the I2NSF Consumer-Facing
Interface to create security policies via the interface. For the Interface to create security policies via the interface. For the
access control of the Consumer-Facing Interface, the NACM module can access control of the Consumer-Facing Interface, the NACM module can
be used. Figure 23 shows an XML example the access control of a user be used. Figure 23 shows an XML example the access control of a user
group (named Example-Group) for I2NSF Consumer-Facing Interface A group (named Example-Group) for I2NSF Consumer-Facing Interface A
group called Example-Group can be created and configured with NACM group called Example-Group can be created and configured with NACM
for the Consumer-Facing Interface. For Example-Group, a rule list for the Consumer-Facing Interface. For Example-Group, a rule list
can created with the name of Example-Group-Rules. Example-Group- can created with the name of Example-Group-Rules. Example-Group-
skipping to change at page 50, line 10 skipping to change at page 51, line 10
5. As the first rule name, Example-Group-Rule1 is specified. This 5. As the first rule name, Example-Group-Rule1 is specified. This
rule is used to give read privilege to Example-Group's members rule is used to give read privilege to Example-Group's members
for the module of the I2NSF Consumer-Facing Interface. for the module of the I2NSF Consumer-Facing Interface.
6. As the second rule name, Example-Group-Rule2 is specified. This 6. As the second rule name, Example-Group-Rule2 is specified. This
rule is used to deny create, update, and delete privileges rule is used to deny create, update, and delete privileges
against Example-Group's members for the module of the I2NSF against Example-Group's members for the module of the I2NSF
Consumer-Facing Interface. Consumer-Facing Interface.
11. IANA Considerations 10. 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 IESG. Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
This document requests IANA to register the following YANG module in This document requests IANA to register the following YANG module in
the "YANG Module Names" registry [RFC7950][RFC8525]. the "YANG Module Names" registry [RFC7950][RFC8525]:
name: ietf-i2nsf-cfi-policy name: ietf-i2nsf-cfi-policy
namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy
prefix: cfi-policy prefix: nsfcfi
reference: RFC XXXX reference: RFC XXXX
12. Security Considerations // RFC Ed.: replace XXXX with an actual RFC number and remove
// this note.
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].
13. Acknowledgments 12. 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). This work was supported in part by Security Service Provisioning). This work was supported in part by
the IITP (2020-0-00395, Standard Development of Blockchain based the IITP (2020-0-00395, Standard Development of Blockchain based
Network Management Automation Technology). Network Management Automation Technology).
14. Contributors 13. Contributors
This document is made by the group effort of I2NSF working group. This document is made by the group effort of I2NSF working group.
Many people actively contributed to this document, such as Mahdi F. Many people actively contributed to this document, such as Mahdi F.
Dachmehchi and Daeyoung Hyun. The authors sincerely appreciate their Dachmehchi and Daeyoung Hyun. The authors sincerely appreciate their
contributions. contributions.
The following are co-authors of this document: The following are co-authors of this document:
Patrick Lingga Patrick Lingga
Department of Electronic, Electrical and Computer Engineering Department of Electronic, Electrical and Computer Engineering
skipping to change at page 53, line 10 skipping to change at page 54, line 10
EMail: senad.palislamovic@nokia.com EMail: senad.palislamovic@nokia.com
Liang Xia Liang Xia
Huawei Huawei
101 Software Avenue 101 Software Avenue
Nanjing, Jiangsu 210012 Nanjing, Jiangsu 210012
China China
EMail: Frank.Xialiang@huawei.com EMail: Frank.Xialiang@huawei.com
15. References 14. References
15.1. Normative References 14.1. Normative References
[I-D.ietf-netmod-rfc6991-bis] [I-D.ietf-netmod-rfc6991-bis]
Schoenwaelder, J., "Common YANG Data Types", draft-ietf- Schoenwaelder, J., "Common YANG Data Types", draft-ietf-
netmod-rfc6991-bis-04 (work in progress), July 2020. netmod-rfc6991-bis-04 (work in progress), July 2020.
[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol
Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May
1983, <https://www.rfc-editor.org/info/rfc854>. 1983, <https://www.rfc-editor.org/info/rfc854>.
[RFC0913] Lottor, M., "Simple File Transfer Protocol", RFC 913, [RFC0913] Lottor, M., "Simple File Transfer Protocol", RFC 913,
skipping to change at page 54, line 47 skipping to change at page 55, line 47
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
skipping to change at page 56, line 5 skipping to change at page 56, line 48
[RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K.,
and R. Wilton, "YANG Library", RFC 8525, and R. Wilton, "YANG Library", RFC 8525,
DOI 10.17487/RFC8525, March 2019, DOI 10.17487/RFC8525, March 2019,
<https://www.rfc-editor.org/info/rfc8525>. <https://www.rfc-editor.org/info/rfc8525>.
[RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W. [RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W.
Kumari, "A Format for Self-Published IP Geolocation Kumari, "A Format for Self-Published IP Geolocation
Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020, Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020,
<https://www.rfc-editor.org/info/rfc8805>. <https://www.rfc-editor.org/info/rfc8805>.
15.2. Informative References 14.2. Informative References
[I-D.ietf-i2nsf-capability] [I-D.ietf-i2nsf-capability]
Xia, L., Strassner, J., Basile, C., and D. Lopez, Xia, L., Strassner, J., Basile, C., and D. Lopez,
"Information Model of NSFs Capabilities", draft-ietf- "Information Model of NSFs Capabilities", draft-ietf-
i2nsf-capability-05 (work in progress), April 2019. i2nsf-capability-05 (work in progress), April 2019.
[I-D.ietf-i2nsf-sdn-ipsec-flow-protection] [I-D.ietf-i2nsf-sdn-ipsec-flow-protection]
Lopez, R., Lopez-Millan, G., and F. Pereniguez-Garcia, Lopez, R., Lopez-Millan, G., and F. Pereniguez-Garcia,
"Software-Defined Networking (SDN)-based IPsec Flow "Software-Defined Networking (SDN)-based IPsec Flow
Protection", draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 Protection", draft-ietf-i2nsf-sdn-ipsec-flow-protection-08
 End of changes. 60 change blocks. 
112 lines changed or deleted 124 lines changed or added

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