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