draft-ietf-i2nsf-consumer-facing-interface-dm-06.txt		draft-ietf-i2nsf-consumer-facing-interface-dm-07.txt
	I2NSF Working Group J. Jeong		I2NSF Working Group J. Jeong
	Internet-Draft E. Kim		Internet-Draft C. Chung
	Intended status: Standards Track Sungkyunkwan University		Intended status: Standards Track Sungkyunkwan University
	Expires: January 25, 2020 T. Ahn		Expires: May 7, 2020 T. Ahn
	Korea Telecom		Korea Telecom
	R. Kumar		R. Kumar
	Juniper Networks		Juniper Networks
	S. Hares		S. Hares
	Huawei		Huawei
	July 24, 2019		November 4, 2019
	I2NSF Consumer-Facing Interface YANG Data Model		I2NSF Consumer-Facing Interface YANG Data Model
	draft-ietf-i2nsf-consumer-facing-interface-dm-06		draft-ietf-i2nsf-consumer-facing-interface-dm-07
	Abstract		Abstract
	This document describes an information model and a YANG data model		This document describes an information model and a YANG data model
	for the Consumer-Facing Interface between an Interface to Network		for the Consumer-Facing Interface between an Interface to Network
	Security Functions (I2NSF) User and Security Controller in an I2NSF		Security Functions (I2NSF) User and Security Controller in an I2NSF
	system in a Network Functions Virtualization (NFV) environment. The		system in a Network Functions Virtualization (NFV) environment. The
	information model defines various types of managed objects and the		information model defines various types of managed objects and the
	relationship among them needed to build the interface. The		relationship among them needed to build the interface. The
	information model is organized based on the "Event-Condition-Action"		information model is organized based on the "Event-Condition-Action"
	skipping to change at page 1, line 47 ¶		skipping to change at page 1, line 47 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 25, 2020.		This Internet-Draft will expire on May 7, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	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 Multi-Tenancy . . . . . . . . . . . . . 10		5. Information Model for Policy Endpoint Groups . . . . . . . . 10
	5.1. Policy Domain . . . . . . . . . . . . . . . . . . . . . . 10		5.1. User Group . . . . . . . . . . . . . . . . . . . . . . . 10
	5.2. Policy Tenant . . . . . . . . . . . . . . . . . . . . . . 11		5.2. Device Group . . . . . . . . . . . . . . . . . . . . . . 11
	5.3. Policy Role . . . . . . . . . . . . . . . . . . . . . . . 11		5.3. Location Group . . . . . . . . . . . . . . . . . . . . . 12
	5.4. Policy User . . . . . . . . . . . . . . . . . . . . . . . 12		6. Information Model for Threat Prevention . . . . . . . . . . . 13
	5.5. Policy Management Authentication Method . . . . . . . . . 13		6.1. Threat Feed . . . . . . . . . . . . . . . . . . . . . . . 13
	6. Information Model for Policy Endpoint Groups . . . . . . . . 14		6.2. Payload Content . . . . . . . . . . . . . . . . . . . . . 14
	6.1. User Group . . . . . . . . . . . . . . . . . . . . . . . 15		7. Network Configuration Access Control Model (NACM) . . . . . . 15
	6.2. Device Group . . . . . . . . . . . . . . . . . . . . . . 16		8. YANG Data Model of Consumer-Facing Interface . . . . . . . . 15
	6.3. Location Group . . . . . . . . . . . . . . . . . . . . . 16		9. XML Configuration Examples of High-Level Security Policy
	7. Information Model for Threat Prevention . . . . . . . . . . . 17		Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
	7.1. Threat Feed . . . . . . . . . . . . . . . . . . . . . . . 18		9.1. Database Registration: Information of Positions and
	7.2. Payload Content . . . . . . . . . . . . . . . . . . . . . 18		Devices (Endpoint Group) . . . . . . . . . . . . . 36
	8. Role-based Acess Control (RBAC) . . . . . . . . . . . . . . . 19		9.2. Scenario 1: Block SNS Access during Business Hours . . . 37
	9. YANG Data Model for Security Policies for Consumer-Facing		9.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to
	Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 20		a Company . . . . . . . . . . . . . . . . . . . . . . . . 39
	10. Example XML Output for Various Scenarios . . . . . . . . . . 49		9.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a
	10.1. DB Registration: Information of Positions and Devices		Company Web Server . . . . . . . . . . . . . . . . . . . 40
	(Endpoint Group) . . . . . . . . . . . . . . . . . . . . 49		10. Security Considerations . . . . . . . . . . . . . . . . . . . 42
	10.2. Scenario 1: Block SNS Access during Business Hours . . . 50		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
	10.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to		12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42
	a Company . . . . . . . . . . . . . . . . . . . . . . . 52		13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 42
	10.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a		14. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
	Company Web Server . . . . . . . . . . . . . . . . . . . 53		14.1. Normative References . . . . . . . . . . . . . . . . . . 44
			14.2. Informative References . . . . . . . . . . . . . . . . . 45
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 55
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 55
	13.1. Normative References . . . . . . . . . . . . . . . . . . 55
	13.2. Informative References . . . . . . . . . . . . . . . . . 56
	Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-		Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-
	interface-dm-05 . . . . . . . . . . . . . . . . . . 58		interface-dm-06 . . . . . . . . . . . . . . . . . . 47
	Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 58		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
	Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 59
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60
	1. Introduction		1. Introduction
	In a framework of Interface to Network Security Functions (I2NSF),		In a framework of Interface to Network Security Functions (I2NSF),
	each vendor can register their NSFs using a Developer's Management		each vendor can register their NSFs using a Developer's Management
	System (DMS). Assuming that vendors also provide the front-end web		System (DMS). Assuming that vendors also provide the front-end web
	applications registered with an I2NSF User, the Consumer-Facing		applications registered with an I2NSF User, the Consumer-Facing
	Interface is required because the web applications developed by each		Interface is required because the web applications developed by each
	vendor need to have a standard interface specifying the data types		vendor need to have a standard interface specifying the data types
	used when the I2NSF User and Security Controller communicate using		used when the I2NSF User and Security Controller communicate using
	skipping to change at page 4, line 15 ¶		skipping to change at page 4, line 12 ¶
	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 | | Consumer-Facing |
	| Interface +--->+ Interface |		| Interface +--->+ Interface |
	|Information Model| | Data Model |		|Information Model| | Data Model |
	+--------+--------+ +-----------------+		+--------+--------+ +-----------------+
	^		^
	|		|
	+-------------+-------------+------------+		+-------------+------------+
	| | | |		| | |
	+----+----+ +-----+----+ +-----+----+ +----+----+		+-----+----+ +-----+----+ +----+----+
	| Multi | | Policy | | Endpoint | | Threat |		| Policy | | Endpoint | | Threat |
	| Tenancy | | | | groups | | feed |		| | | groups | | feed |
	+---------+ +-----+----+ +----------+ +---------+		+-----+----+ +----------+ +---------+
	^		^
	|		|
	+------+------+		+------+------+
	| Rule |		| Rule |
	+------+------+		+------+------+
	^		^
	|		|
	+----------------+----------------+		+----------------+----------------+
	| | |		| | |
	+------+------+ +------+------+ +------+------+		+------+------+ +------+------+ +------+------+
	skipping to change at page 5, line 17 ¶		skipping to change at page 5, line 14 ¶
	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 RFC 2119 [RFC3444]
	RFC8174 [RFC8174].		RFC8174 [RFC8174].
	3. Terminology		3. Terminology
	This document uses the terminology described in		This document uses the terminology described in [i2nsf-terminology]
	[i2nsf-terminology][client-facing-inf-req].		[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 [RFC6991], and adopts the Network Management
	Datastore Architecture (NMDA). The meaning of the symbols in tree		Datastore Architecture (NMDA). The meaning of the symbols in tree
	diagrams is defined in [RFC8340].		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.
	Date: Date when this object was created or last modified.		Date: Date when this object was created or last modified.
	Rules: This field contains a list of rules. These rules are		Rule: This field contains a list of rules. These rules are
	defined for 1) communication between two Endpoint Groups,		defined for 1) communication between two Endpoint Groups,
	2) for preventing communication with externally or		2) for preventing communication with externally or
	internally identified threats, and 3) for implementing		internally identified threats, and 3) for implementing
	business requirement such as controlling access to internal		business requirement such as controlling access to internal
	or external resources for meeting regulatory compliance or		or external resources for meeting regulatory compliance or
	business objectives. An organization may restrict certain		business objectives. An organization may restrict certain
	communication between a set of user and applications for		communication between a set of user and applications for
	example. The threats may be from threat feeds obtained		example. The threats may be from threat feeds obtained
	from external sources or dynamically identified by using		from external sources or dynamically identified by using
	specialty devices in the network. Rule conflict analysis		specialty devices in the network. Rule conflict analysis
	should be triggered by the monitoring service to perform an		should be triggered by the monitoring service to perform an
	exhaustive detection of anomalies among the configuration		exhaustive detection of anomalies among the configuration
	rules installed into the security functions.		rules installed into the security functions.
	+--rw i2nsf-cfi-policy* [policy-name]		+--rw i2nsf-cfi-policy* [policy-name]
	+--rw policy-name string		+--rw policy-name string
	+--rw rule* [rule-name]		| +--rw rule* [rule-name]
	+--rw multi-tenancy
	+--rw endpoint-group		+--rw endpoint-group
	+--rw threat-prevention		+--rw threat-prevention
	Figure 2: Policy YANG Data Tree		Figure 2: Policy YANG Data Tree
	A policy is a container of Rules. In order to express a Rule, a Rule		A policy is a container of Rule. In order to express a Rule, a Rule
	must have complete information such as where and when a policy needs		must have complete information such as where and when a policy needs
	to be applied. This is done by defining a set of managed objects and		to be applied. This is done by defining a set of managed objects and
	relationship among them. A Policy Rule may be related segmentation,		relationship among them. A Policy Rule may be related segmentation,
	threat mitigation or telemetry data collection from an NSF in the		threat mitigation or telemetry data collection from an NSF in the
	network, which will be specified as the sub-model of the policy model		network, which will be specified as the sub-model of the policy model
	in the subsequent sections. Figure 3 shows the YANG tree of the Rule		in the subsequent sections. Figure 3 shows the YANG data tree of the
	object. The rule object SHALL have the following information:		Rule object. The rule object SHALL have the 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 3.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.
	skipping to change at page 7, line 13 ¶		skipping to change at page 7, line 13 ¶
	the person who created it, and eligible for modifying it.		the person who created it, and eligible for modifying it.
	+--rw rule* [rule-name]		+--rw rule* [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
	+--rw owner identityref		+--rw owner identityref
	Figure 3: YANG Data Tree for Rule		Figure 3: Rule YANG Data Tree
	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
	skipping to change at page 7, line 39 ¶		skipping to change at page 7, line 39 ¶
	Admin: This represents the enforcement type based on admin's		Admin: This represents the enforcement type based on admin's
	decision.		decision.
	Time: This represents the security rule is enforced based on		Time: This represents the security rule is enforced based on
	begin-time and end-time information.		begin-time and end-time information.
	Frequency: This represents how frequent the rule should be		Frequency: This represents how frequent the rule should be
	enforced. There are four options: "only-once", "daily",		enforced. There are four options: "only-once", "daily",
	"weekly" and "monthly".		"weekly" and "monthly".
	+--rw event		+--rw event
	+--rw security-event identityref		+--rw security-event identityref
	+--rw (enforce-type)?		+--rw (enforce-type)?
	| +--:(admin)		| +--:(admin)
	| | +--rw admin? identityref		| | +--rw admin? identityref
	| +--:(time)		| +--:(time)
	| +--rw time-information		| +--rw time-information
	| +--rw begin-time? yang:date-and-time		| +--rw begin-time? yang:date-and-time
	| +--rw end-time? yang:date-and-time		| +--rw end-time? yang:date-and-time
	+--rw frequency? enumeration		+--rw frequency? enumeration
	Figure 4: Event Sub-model YANG Data Tree		Figure 4: Event Sub-model YANG Data Tree
	4.2. Condition Sub-model		4.2. Condition Sub-model
	This object represents Conditions that Security Administrator wants		This object represents Conditions that Security Administrator wants
	to apply the checking on the traffic in order to determine whether		to apply the checking on the traffic in order to determine whether
	the set of actions in the Rule can be executed or not. The Condition		the set of actions in the Rule can be executed or not. The Condition
	Sub-model consists of three different types of containers each		Sub-model consists of three different types of containers each
	representing different cases, such as general firewall and DDoS-		representing different cases, such as general firewall and DDoS-
	skipping to change at page 8, line 25 ¶		skipping to change at page 8, line 25 ¶
	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-group.		address-based groups defined in the endpoint-group.
	DDoS-condition: This field represents the condition for DDoS		Case (DDoS-condition): This field represents the condition for
	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-group.		groups defined and registered in the endpoint-group.
	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 custon-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-group.		the endpoint-group.
	Threat-feed-condition: This field contains the information		Case (Threat-feed-condition): This field contains the information
	obtained from threat-feeds (e.g., Palo-Alto, or RSA-		obtained from threat-feeds (e.g., Palo-Alto, or RSA-
	netwitness). This information is useful when security rule		netwitness). This information is useful when security rule
	condition is based on the existing threat reports gathered		condition is based on the existing threat reports gathered
	by other sources. The source and destination is		by other sources. The source and destination is
	represented as threat-feed-source and threat-feed-		represented as threat-feed-source and threat-feed-
	destination. For clarity, threat-feed-source/destination		destination. For clarity, threat-feed-source/destination
	represent the source/destination of a target security		represent the source/destination of a target security
	threat, not the information source/destination of a threat-		threat, not the information source/destination of a threat-
	feed.		feed.
	+--rw (condition)?		+--rw (condition)?
	+--:(firewall-condition)		+--:(firewall-condition)
	| +--rw firewall-source		| +--rw firewall-source
	| | +--rw src-target -> /../../user-group/name		| | +--rw src-target -> /../../nacm:group/nacm:user-name
	| +--rw firewall-destination		| +--rw firewall-destination
	| +--rw dest-target* -> /../../user-group/name		| +--rw dest-target* -> /../../nacm:group/nacm:user-name
	+--:(ddos-condition)		+--:(ddos-condition)
	| +--rw ddos-source		| +--rw ddos-source
	| | +--rw src-target* -> /../../device-group/name		| | +--rw src-target* -> /../../device-group/name
	| +--rw ddos-destination		| +--rw ddos-destination
	| | +--rw dest-target* -> /../../device-group/name		| | +--rw dest-target* -> /../../device-group/name
	| +--rw rate-limit		| +--rw rate-limit
	| +--rw packet-per-second? uint16		| +--rw packet-per-second? uint16
	+--:(custom-condition)		+--:(custom-condition)
	| +--rw custon-source		| +--rw custon-source
	| | +--rw src-target* -> /../../payload-content/name		| | +--rw src-target* -> /../../payload-content/name
	| +--rw custom-destination		| +--rw custom-destination
	| +--rw dest-target -> /../../payload-content/name		| +--rw dest-target -> /../../payload-content/name
	+--:(threat-feed-condition)		+--:(threat-feed-condition)
	+--rw threat-feed-source		+--rw threat-feed-source
	| +--rw src-target* -> /../../threat-feed-list/feed-name		| +--rw src-target* -> /../../threat-feed-list/feed-name
	+--rw threat-feed-destination		+--rw threat-feed-destination
	+--rw dest-target -> /../../threat-feed-list/feed-name		+--rw dest-target -> /../../threat-feed-list/feed-name
	Figure 5: Condition Sub-model YANG Data Tree		Figure 5: Condition Sub-model YANG Data Tree
	4.3. Action Sub-model		4.3. Action Sub-model
	This object represents actions that Security Admin wants to perform		This object represents actions that Security Admin wants to perform
	based on certain traffic class. Figure 6 shows the YANG tree of the		based on certain traffic class. Figure 6 shows the YANG tree of the
	Action object. The Action object SHALL have following information:		Action object. The Action object SHALL have following information:
	Primary-action: This field identifies the action when a rule is		Primary-action: This field identifies the action when a rule is
	matched by an NSF. The action could be one of "PASS",		matched by an NSF. The action could be one of "PASS",
	"DROP", "ALERT", "RATE-LIMIT", and "MIRROR".		"DROP", "ALERT", "RATE-LIMIT", and "MIRROR".
	Secondary-action: This field identifies the action when a rule is		Secondary-action: This field identifies the action when a rule is
	matched by an NSF. The action could be one of "log",		matched by an NSF. The action could be one of "log",
	"syslog", "session-log".		"syslog", "session-log".
	+--rw action		+--rw action
	+--rw primary-action identityref		+--rw primary-action identityref
	+--rw secondary-action? identityref		+--rw secondary-action? identityref
	Figure 6: Action Sub-model YANG Data Tree		Figure 6: Action Sub-model YANG Data Tree
	5. Information Model for Multi-Tenancy		5. Information Model for Policy Endpoint Groups
	Multi-tenancy is an important aspect of any application that enables
	multiple administrative domains in order to manage application
	resources. An Enterprise organization may have multiple tenants or
	departments such as Human Resources (HR), Finance, and Legal, with
	each tenant having a need to manage their own Security Policies. In
	a Service Provider, a tenant could represent a Customer that wants to
	manage its own Security Policies. There are multiple managed objects
	that constitute multi-tenancy aspects as shown in Figure 7. This
	section lists these objects and the relationship among these objects.
	Below diagram shows an example of multi-tenancy in an Enterprise
	domain.
	+-------------------+
	(Multi-Tenancy) | Domain |
	|(e.g., Enterprise) |
	+---------+---------+
	^
	|
	+--------------------+--------------------+
	| | |
	+--------+-------+ +---------+--------+ +--------+--------+
	| Department 1 | | Department 2 | | Department n |
	+--------+-------+ +---------+--------+ +--------+--------+
	^ ^ ^
	| | |
	+--------+--------+ +-----------------+ +--------+--------+
	| Sub-domain 1..n | | Sub-domain 1..n | | Sub-domain 1..n |
	+--------+--------+ +--------+--------+ +--------+--------+
	^ ^ ^
	| | |
	+--------+--------+ +--------+--------+ +--------+--------+
	| Tenant 1..n | | Tenant 1..n | | Tenant 1..n |
	+-----------------+ +-----------------+ +-----------------+
	Figure 7: Multi-tenancy Diagram
	5.1. Policy Domain
	This object defines a boundary for the purpose of policy management
	within a Security Controller. This may vary based on how the
	Security Controller is deployed and hosted. For example, if an
	Enterprise hosts a Security Controller in their network; the domain
	in this case could just be the one that represents that Enterprise.
	But if a Cloud Service Provider hosts managed services, then a domain
	could represent a single customer of that Provider. Figure 8 shows
	the YANG tree of the Policy-Domain object. Multi-tenancy model
	should be able to work in all such environments. The Policy-Domain
	object SHALL have the following information:
	Domain-name: Name of the domain of an organization or enterprise.
	Address: Address information of the organization or enterprise.
	Contact: Contact information of the organization or enterprise.
	+--rw policy-domain* [domain-name]
	+--rw domain-name identityref
	+--rw address? string
	+--rw contact? string
	Figure 8: Policy Domain YANG Data Tree
	5.2. Policy Tenant
	This object defines an entity within an organization. The entity
	could be a department or business unit within an Enterprise
	organization that would like to manage its own Policies due to
	regulatory compliance or business reasons. Figure 9 shows the YANG
	tree of the Policy-Tenant object. The Policy-Tenant object SHALL
	have the following information:
	Tenant-type: This field represents the type of tenant within a
	domain. In an enterprise, the examples of tenants could be
	the departments or divisions, such as HR department and
	Finance department.
	+--rw policy-tenant* [tenant-name]
	+--rw tenant-type identityref
	Figure 9: Policy Tenant YANG Data Tree
	5.3. Policy Role
	This object defines a set of permissions assigned to a user in an
	organization that wants to manage its own Security Policies. It
	provides a convenient way to assign policy users to a job function or
	a set of permissions within the organization. Figure 10 shows the
	YANG tree of the Policy-Role object. The Policy-Role object SHALL
	have the following information:
	Role-type: "This represent the roles within the tenants, in order
	to distinguish who may or may not have access to policies.
	The role types include "user", "group", "other", and "all".
	"user" "represents an individual where as group represents
	a group of users. "All" means both the individual and the
	group members, whereas "other" denotes anyone who is not a
	specific individual or a member of a specific group.
	+--rw policy-role* [role-name]
	+--rw role-type identityref
	Figure 10: Policy Role YANG Data Tree
	5.4. Policy User
	This object represents a unique identity of a user within an
	organization. The identity authenticates with Security Controller
	using credentials such as a password or token in order to perform
	policy management. A user may be an individual, system, or
	application requiring access to Security Controller. Figure 11 shows
	the YANG tree of the Policy-User object. The Policy-User object
	SHALL have the following information:
	Name: Name of a user.
	Password: User password for basic authentication. The crypto-
	hash mechanism for this entry is ianach:crypt-hash.
	Email: E-mail address of the user.
	Access-profile: This represents the access profile for the user.
	The access-profile is based on the permission-type and the
	scope type defined. The permission-types include "no-
	permission", read", "write", "execute", "read-and-write",
	"read-and-execute", and "write-and-execute"
	Scope-Type: This field identifies whether the user has domain-
	wide or tenant-wide privileges.
	+--rw policy-user* [name]
	+--rw name string
	+--rw password? ianach:crypt-hash
	+--rw email? string
	+--rw access-profile* [permission-type scope-type]
	+--rw permission-type identityref
	+--rw scope-type identityref
	Figure 11: Policy User YANG Data Tree
	5.5. Policy Management Authentication Method
	This object represents authentication schemes supported by Security
	Controller. Figure 12 shows the YANG tree of the Policy Management
	Authentication Method onject. This Policy-Management-Authentication-
	Method object SHALL have the following information:
	Policy-mgmt-auth-method-instance: This field represent the
	authentication instances. Each instance is based on either
	client authentication, server authentication or both
	(mutual) authentication.
	Policy-mgmt-auth-method: This represents the choices of
	authentication methods. Each instance of authentication
	consists of authentication methods chosen by an entity,
	such as a security admin. There are "Password-based",
	"token-based". "certificate-based", and "IPsec"
	authentication methods.
	Password-list: This list contains the passwords that are
	encrypted using crypto-has algorithm (ianach:crypt-hash).
	Token-list: This list contains the information such as the access
	tokens and a token server.
	Cert-server-list: This list contains the certification server
	information such as server address (IPv4 and IPv6) and
	certificate types.
	IPsec: This list has IPsec method types based on the identities
	defined. There are two types such as IPsec-IKE and IPsec-
	IKEless.
	+--rw policy-mgmt-auth-method-instance* [auth-instance-type]
	+--rw auth-instance-type identityref
	+--rw (policy-mgmt-auth-method)?
	+--:(password-based)
	| +--rw password-list* [password]
	| +--rw password ianach:crypt-hash
	+--:(token-based)
	| +--rw token-list* [token]
	| +--rw token string
	| +--rw token-server? inet:ipv4-address
	+--:(certificate-based)
	| +--rw cert-server-list* [cert-server-name]
	| +--rw cert-server-name string
	| +--rw cert-server-ipv4? inet:ipv4-address
	| +--rw cert-server-ipv6? inet:ipv6-address
	| +--rw certificate* [cert-type]
	| +--rw cert-type identityref
	+--:(ipsec)
	+--rw ipsec-method* [method]
	+--rw method identityref
	Figure 12: Policy Management Authentication Method YANG Data Tree
	6. Information Model for Policy Endpoint Groups
	The Policy Endpoint Group is a very important part of building User-		The Policy Endpoint Group is a very important part of building User-
	Construct based policies. A Security Administrator would create and		Construct based policies. A Security Administrator would create and
	use these objects to represent a logical entity in their business		use these objects to represent a logical entity in their business
	environment, where a Security Policy is to be applied. There are		environment, where a Security Policy is to be applied. There are
	multiple managed objects that constitute a Policy's Endpoint Group as		multiple managed objects that constitute a Policy's Endpoint Group as
	shown in Figure 13. Figure 14 shows the YANG tree of the Endpoint-		shown in Figure 7. Figure 8 shows the YANG tree of the Endpoint-
	Group object. This section lists these objects and relationship		Group object. This section lists these objects and relationship
	among them.		among them.
	+-------------------+		+-------------------+
	| Endpoint Group |		| Endpoint Group |
	+---------+---------+		+---------+---------+
	^		^
	|		|
	+--------------+----------------+		+--------------+----------------+
	1..n | 1..n | 1..n |		1..n | 1..n | 1..n |
	+-----+----+ +------+-----+ +-------+------+		+-----+----+ +------+-----+ +-------+------+
	|User-group| |Device-group| |Location-group|		|User-group| |Device-group| |Location-group|
	+----------+ +------------+ +--------------+		+----------+ +------------+ +--------------+
	Figure 13: Endpoint Group Diagram		Figure 7: Endpoint Group Diagram
	+--rw endpoint-group		+--rw endpoint-group
	+--rw user-group* [name]		+--rw user-group* [name]
	...		...
	+--rw device-group* [name]		+--rw device-group* [name]
	...		...
	+--rw location-group* [name]		+--rw location-group* [name]
	...		...
	Figure 14: Endpoint Group YANG Data Tree		Figure 8: Endpoint Group YANG Data Tree
	6.1. User Group		5.1. User Group
	This object represents a User-Group. Figure 15 shows the YANG tree		This object represents a User-Group. Figure 9 shows the YANG tree of
	of the User-Group object. The User-Group object SHALL have the		the User-Group object. The User-Group object SHALL have the
	following information:		following information:
	Name: This field identifies the name of this object.		Name: This field identifies the name of this object.
	IP-address: This represents the IPv4 address of a user in the		IP-address: This represents the IPv4 address of a user in the
	user group.		user group.
	range-ipv4-address: This represents the IPv4 address of a user in		range-ipv4-address: This represents the IPv4 address of a user in
	the user gorup.		the user gorup.
	range-ipv6-address: This represents the IPv6 address of a user in		range-ipv6-address: This represents the IPv6 address of a user in
	the user gorup.		the user gorup.
	+--rw user-group* [name]		+--rw user-group* [name]
	+--rw name string		+--rw name -> /../../nacm:group/nacm:user-name
	+--rw (match-type)?		+--rw (match-type)?
	+--:(exact-match-ipv4)		+--:(exact-match-ipv4)
	| +--rw ip-address* inet:ipv4-address		| +--rw ip-address* inet:ipv4-address
	+--:(exact-match-ipv6)		+--:(exact-match-ipv6)
	| +--rw ip-address* inet:ipv4-address		| +--rw ip-address* inet:ipv4-address
	+--:(range-match-ipv4)		+--:(range-match-ipv4)
	| +--rw range-ipv4-address* [start-ipv4-address end-ipv4-address]		| +--rw range-ipv4-address*
	| +--rw start-ipv4-address inet:ipv4-address		[start-ipv4-address end-ipv4-address]
	| +--rw end-ipv4-address inet:ipv4-address		| +--rw start-ipv4-address inet:ipv4-address
	+--:(range-match-ipv6)		| +--rw end-ipv4-address inet:ipv4-address
	+--rw range-ipv6-address* [start-ipv6-vaddress end-ipv6-address]		+--:(range-match-ipv6)
	+--rw start-ipv6-address inet:ipv6-address		+--rw range-ipv6-address*
	+--rw end-ipv6-address inet:ipv6-address		[start-ipv6-vaddress end-ipv6-address]
			+--rw start-ipv6-address inet:ipv6-address
			+--rw end-ipv6-address inet:ipv6-address
	Figure 15: User Group YANG Data Tree		Figure 9: User Group YANG Data Tree
	6.2. Device Group		5.2. Device Group
	This object represents a Device-Group. Figure 16 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		IP-address: This represents the IPv4 address of a device in the
	device group.		device group.
	range-ipv4-address: This represents the IPv4 address of a device		range-ipv4-address: This represents the IPv4 address of a device
	in the device gorup.		in the device gorup.
	range-ipv6-address: This represents the IPv6 address of a device		range-ipv6-address: This represents the IPv6 address of a device
	in the device gorup.		in the device gorup.
	Protorol: This represents the communication protocols used by the		Protocol: This represents the communication protocols used by the
	devices. The protocols are "SSH", "FTP", "SMTP", "HTTP",		devices. The protocols are "SSH", "FTP", "SMTP", "HTTP",
	"HTTPS", and etc.		"HTTPS", and etc.
	+--rw device-group* [name]		+--rw device-group* [name]
	+--rw name string		+--rw name string
	+--rw (match-type)?		+--rw (match-type)?
	+--:(exact-match-ipv4)		| +--:(exact-match-ipv4)
	| +--rw ip-address* inet:ipv4-address		| | +--rw ip-address* inet:ipv4-address
	+--:(exact-match-ipv6)		| +--:(exact-match-ipv6)
	| +--rw ip-address* inet:ipv4-address		| | +--rw ip-address* inet:ipv4-address
	+--:(range-match-ipv4)		| +--:(range-match-ipv4)
	| +--rw range-ipv4-address* [start-ipv4-address end-ipv4-address]		| | +--rw range-ipv4-address*
	| +--rw start-ipv4-address inet:ipv4-address		[start-ipv4-address end-ipv4-address]
	| +--rw end-ipv4-address inet:ipv4-address		| | +--rw start-ipv4-address inet:ipv4-address
	+--:(range-match-ipv6)		| | +--rw end-ipv4-address inet:ipv4-address
	+--rw range-ipv6-address* [start-ipv6-vaddress end-ipv6-address]		| +--:(range-match-ipv6)
	+--rw start-ipv6-address inet:ipv6-address		| +--rw range-ipv6-address*
	+--rw end-ipv6-address inet:ipv6-address		[start-ipv6-vaddress end-ipv6-address]
			| +--rw start-ipv6-address inet:ipv6-address
			| +--rw end-ipv6-address inet:ipv6-address
			+--rw protocol identityref
	Figure 16: Device Group YANG Data Tree		Figure 10: Device Group YANG Data Tree
	6.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 17 shows the YANG tree of the Location-Group		information. Figure 11 shows the YANG tree of the Location-Group
	object. The Location-Group object SHALL have the following		object. The Location-Group object SHALL have the following
	information:		information:
	Name: This field identifies the name of this object.		Name: This field identifies the name of this object.
	geo-ip-ipv4: This field represents the IPv4 Geo-ip of a location.		geo-ip-ipv4: This field represents the IPv4 Geo-ip of a location.
	geo-ip-ipv6: This field represents the IPv6 Geo-ip of a location.		geo-ip-ipv6: This field represents the IPv6 Geo-ip of a location.
	continent: This field represents the continent where the location		continent: This field represents the continent where the location
	group member is at.		group member is at.
	+--rw location-group* [name]		+--rw location-group* [name]
	+--rw name string		+--rw name string
	+--rw geo-ip-ipv4 inet:ipv4-address		+--rw geo-ip-ipv4 inet:ipv4-address
	+--rw geo-ip-ipv6 inet:ipv6-address		+--rw geo-ip-ipv6 inet:ipv6-address
	+--rw continent? identityref		+--rw continent? identityref
	Figure 17: Location Group YANG Data Tree		Figure 11: Location Group YANG Data Tree
	7. Information Model for Threat Prevention		6. Information Model for Threat Prevention
	The threat prevention plays an important part in the overall security		The threat prevention plays an important part in the overall security
	posture by reducing the attack surfaces. This information could come		posture by reducing the attack surfaces. This information could come
	from various threat feeds (i.e., sources for obtaining the threat		from various threat feeds (i.e., sources for obtaining the threat
	information), such as EmergingThreats.com or AlienVault.com. There		information). There are multiple managed objects that constitute
	are multiple managed objects that constitute this category. This		this category. This section lists these objects and relationship
	section lists these objects and relationship among them. Figure 19		among them. Figure 13 shows the YANG tree of a Threat-Prevention
	shows the YANG tree of a Threat-Prevention object.		object.
	+-------------------+		+-------------------+
	| Threat Prevention |		| Threat Prevention |
	+---------+---------+		+---------+---------+
	^		^
	|		|
	+---------+---------+		+---------+---------+
	1..n | 1..n |		1..n | 1..n |
	+------+------+ +--------+--------+		+------+------+ +--------+--------+
	| Threat-feed | | payload-content |		| Threat-feed | | payload-content |
	+-------------+ +-----------------+		+-------------+ +-----------------+
	Figure 18: 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 19: Threat Prevention YANG Data Tree		Figure 13: Threat Prevention YANG Data Tree
	7.1. Threat Feed		6.1. Threat Feed
	This object represents a threat feed which provides signatures of		This object represents a threat feed which provides signatures of
	malicious activities. Figure 20 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:
	Feed-name: This field identifies the name of this object.		Feed-name: This field identifies the name of this object.
	Feed-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.		feed provider, it may be external or local servers.
	Feed-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.		feed provider, it may be external or local servers.
	skipping to change at page 18, line 33 ¶		skipping to change at page 14, line 18 ¶
	types used (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 signatures of malicious
	programs or activities provided by the threat-feed. The		programs or activities provided by the threat-feed. The
	examples of signature types are "YARA", "SURICATA", and		examples of signature types are "YARA", "SURICATA", and
	"SNORT".		"SNORT".
	+--rw threat-prevention		+--rw threat-prevention
	+--rw threat-feed-list* [feed-name]		+--rw threat-feed-list* [feed-name]
	+--rw feed-name identityref		+--rw feed-name identityref
	+--rw feed-server-ipv4? inet:ipv4-address		+--rw feed-server-ipv4? inet:ipv4-address
	+--rw feed-server-ipv6? inet:ipv6-address		+--rw feed-server-ipv6? inet:ipv6-address
	+--rw feed-description? string		+--rw feed-description? string
	+--rw threat-file-types* identityref		+--rw threat-file-types* identityref
	+--rw signatures* identityref		+--rw signatures* identityref
	Figure 20: Threat Feed YANG Data Tree		Figure 14: Threat Feed YANG Data Tree
	7.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 21 shows the YANG tree of		defining exception to threat feeds. Figure 15 shows the YANG tree of
	a Payload-content list. The Payload-Content object SHALL have the		a Payload-content list. The Payload-Content object SHALL have the
	following information:		following information:
	Name: This field identifies the name of this object. For		Name: This field identifies the name of this object. For
	example, the name "backdoor" indicates the payload content		example, the name "backdoor" indicates the payload content
	is related to backdoor attack.		is related to backdoor attack.
	payload-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.		payload content is related to a security attack.
	Content: This contains the payload contents, which are involed in		Content: This contains the payload contents, which are involed in
	a security attack, as strings.		a security attack, as strings.
	+--rw payload-content* [name]		+--rw payload-content* [name]
	+--rw name string		+--rw name string
	+--rw payload-description string		+--rw payload-description string
	+--rw content* string		+--rw content* string
	Figure 21: Payload Content in YANG Data Tree
	8. Role-based Acess Control (RBAC)
	Role-Based Access Control (RBAC) provides a powerful and centralized
	control within a network. It is a policy neutral access control
	mechanism defined around roles and privileges. The components of
	RBAC, such as role-permissions, user-role and role-role
	relationships, make it simple to perform user assignments.
	+--------------+		Figure 15: Payload Content in YANG Data Tree
	| |
	| User 1 + (has many)
	| |\
	+--------------+ \ +---------------+ +-------------+
	. \ | | (has many) | |
	. --->+ List of roles +----------->+ Permissions |
	+--------------+ / | | | |
	| | / +---------------+ +-------------+
	| User n +/
	| | (has many)
	+--------------+
	Figure 22: Role-based Acess Control Diagram		7. Network Configuration Access Control Model (NACM)
	As shown in Figure 22, a role represents a collection of permissions		Network Configuration Access Control Model (NACM) provides a high-
	(e.g., accessing a file server or other particular resources). A		level overview of the access control with the following features
	role may be assigned to one or multiple users. Both roles and		[RFC8341]:
	permissions can be organized in a hirarchy. A role may consists of
	other roles and permissions.
	Following are the steps required to build RBAC:		o Independent control of action, data, and notification access is
			provided.
	1. Defining roles and permissions.		o A simple and familiar set of datastore permissions is used.
	2. Establishing relations among roles and permissions.		o Support for YANG security tagging allows default security modes to
			automatically exclude sensitive data.
	3. Defining users.		o Separate default access modes for read, write, and execute
			permissions are provided.
	4. Associating rules with roles and permissions.		o Access control rules are applied to configurable groups of users.
	5. assigning roles to users.		The data model for the I2NSF Consumer-Facing Interface provides NACM
			mechanisms and concepts to user-group and owners permissions. The
			NACM with the above features can be used to set up all the management
			access controls in the I2NSF high-level authorization view, and it
			may have a high impact on the optimization and performance.
	9. YANG Data Model for Security Policies for 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 was performed so that this YANG data model can
	skipping to change at page 20, line 42 ¶		skipping to change at page 16, line 16 ¶
	be extended according to the security needs. In other words, the		be extended according to the security needs. In other words, the
	model design is independent of the content and meaning of specific		model design is independent of the content and meaning of specific
	policies as well as the implementation approach. This document		policies as well as the implementation approach. This document
	suggests a VoIP/VoLTE security service as a use case for policy rule		suggests a VoIP/VoLTE security service as a use case for policy rule
	generation.		generation.
	This section describes a YANG data model for Consumer-Facing		This section describes a YANG data model for Consumer-Facing
	Interface, based on the information model of Consumer-Facing		Interface, based on the information model of Consumer-Facing
	Interface to Security Controller.		Interface to Security Controller.
	<CODE BEGINS> file "ietf-cfi-policy.yang"		<CODE BEGINS> file "ietf-i2nsf-cfi-policy@2019-11-04.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;		cfi-policy;
	import ietf-yang-types{		import ietf-yang-types{
	prefix yang;		prefix yang;
	reference		reference
	"Section 3 of RFC 6991";		"Section 3 of RFC 6991";
	}		}
	import ietf-inet-types{		import ietf-inet-types{
	prefix inet;		prefix inet;
	reference		reference
	"Section 4 of RFC 6991";		"Section 4 of RFC 6991";
	}		}
	import iana-crypt-hash {		import ietf-netconf-acm {
	prefix ianach;		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: Adrian Farrel
	<mailto:Adrain@olddog.co.uk>
	WG Chair: Linda Dunbar		WG Chair: Linda Dunbar
	<mailto:Linda.duhbar@huawei.com>		<mailto:Linda.duhbar@huawei.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
			<mailto:darkhong@skku.edu>";
	description		description
	"This module is a YANG module for Consumer-Facing Interface.		"This module is a YANG module for Consumer-Facing Interface.
	Copyright (c) 2018 IETF Trust and the persons identified as		Copyright (c) 2018 IETF Trust and the persons identified as
	authors of the code. All rights reserved.		authors of the code. All rights reserved.
	Redistribution and use in source and binary forms, with or		Redistribution and use in source and binary forms, with or
	without modification, is permitted pursuant to, and subject		without modification, is permitted pursuant to, and subject
	to the license terms contained in, the Simplified BSD License		to the license terms contained in, the Simplified BSD License
	set forth in Section 4.c of the IETF Trust's Legal Provisions		set forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents		Relating to IETF Documents
	(http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info).
	This version of this YANG module is part of RFC XXXX; see		This version of this YANG module is part of RFC XXXX; see
	the RFC itself for full legal notices.";		the RFC itself for full legal notices.";
	revision "2019-07-21"{		revision "2019-11-04"{
	description "latest revision";		description "The latest revision";
	reference		reference
	"draft-ietf-consumer-facing-interface-dm-03";		"draft-ietf-consumer-facing-interface-dm-07";
	}
	identity permission-type {
	description
	"Base identity for the permission types.";
	}
	identity no-permission {
	base permission-type;
	description
	"Identity for no-permission.";
	}
	identity read {
	base permission-type;
	description
	"Identity for read permission.";
	}
	identity write {
	base permission-type;
	description
	"Identity for write permission.";
	}
	identity execute {
	base permission-type;
	description
	"Identity for execute permission.";
	}
	identity write-and-execute {
	base permission-type;
	description
	"Identity for write & execute permission.";
	}
	identity read-and-execute {
	base permission-type;
	description
	"Identity for read & execute permission.";
	}
	identity read-and-write {
	base permission-type;
	description
	"Identity for read & write permission.";
	}
	identity scope-type {
	description
	"Base Identity for scope-type.";
	}
	identity tenant-wide {
	base scope-type;
	description
	"Base Identity for tenant-wide scope type.";
	}
	identity domain-wide {
	base scope-type;
	description
	"Base Identity for domain-wide scope type.";
	}		}
	identity malware-file-type {		identity malware-file-type {
	description		description
	"Base identity for malware file types.";		"Base identity for malware file types.";
	}		}
	identity executable-file {		identity executable-file {
	base malware-file-type;		base malware-file-type;
	description		description
	"Identity for executable file types.";		"Identity for executable file types.";
	skipping to change at page 25, line 32 ¶		skipping to change at page 20, line 4 ¶
	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 certificate-type {
	description
	"Base Identity for certificate-type.
	CRT certificate extension, which is used for certificates.
	The certificates may be encoded as binary DER or as ASCII PEM.
	The CER and CRT extensions are nearly synonymous. Most common
	among *nix systems. CER certificate extension, which is an
	alternate form of .crt (Microsoft Convention) You can use MS to
	convert .crt to .cer (.both DER encoded .cer, or base64[PEM]
	encoded .cer). The KEY extension is used both for public and
	private PKCS#8 keys. The keys may be encoded as binary DER or
	as ASCII PEM.";
	}
	identity cer {
	base certificate-type;
	description
	"Identity for '.cer' certificates.";
	}
	identity crt {
	base certificate-type;
	description
	"Identity for '.crt' certificates.";
	}
	identity key {
	base certificate-type;
	description
	"Identity for '.key' certificates.";
	}
	identity enforce-type {		identity enforce-type {
	description		description
	"This identity represents the event of		"This identity represents the event of
	policy enforcement trigger type.";		policy enforcement trigger type.";
	}		}
	identity admin {		identity admin {
	base enforce-type;		base enforce-type;
	description		description
	"The identity for policy enforcement by admin.";		"The identity for policy enforcement by admin.";
	}		}
	skipping to change at page 28, line 37 ¶		skipping to change at page 22, line 26 ¶
	base secondary-action;		base secondary-action;
	description		description
	"The identity for system logging.";		"The identity for system logging.";
	}		}
	identity session-log {		identity session-log {
	base secondary-action;		base secondary-action;
	description		description
	"The identity for session logging.";		"The identity for session logging.";
	}		}
	identity role-type {
	description
	"This is the base identity for the roles.";
	}
	identity user {
	base role-type;
	description
	"This represents the identity of the user role.";
	}
	identity group {
	base role-type;
	description
	"This represents the identity of any member of the
	security policy's defined group.";
	}
	identity other {
	base role-type;
	description
	"This represents the identity of anyone else.";
	}
	identity all {
	base role-type;
	description
	"This represents the identity of everyone
	(i.e., user, group, and other).";
	}
	identity owner {		identity owner {
	description		description
	"This is the base identity for the owner";		"This is the base identity for the owner";
	}		}
	identity dept-head {		identity dept-head {
	base owner;		base owner;
	description		description
	"This represents the identity of the head of department.";		"This represents the identity of the head of department.";
	}		}
	identity manager {		identity manager {
	skipping to change at page 29, line 46 ¶		skipping to change at page 23, line 8 ¶
	base owner;		base owner;
	description		description
	"This represents the identity of the head of security.";		"This represents the identity of the head of security.";
	}		}
	identity sec-admin {		identity sec-admin {
	base owner;		base owner;
	description		description
	"This represents the identity of security admin.";		"This represents the identity of security admin.";
	}		}
	identity tenant-type {
	description
	"This is the base identity for the tenants
	to represent the ownership of the security policies.";
	}
	identity human-resources {
	base tenant-type;
	description
	"This represents the identity of the human resources
	department or division.";
	}
	identity marketing {
	base tenant-type;
	description
	"This represents the identity of the marketing
	department or division.";
	}
	identity customer-service {
	base tenant-type;
	description
	"This represents the identity of customer service
	department or division.";
	}
	identity research {
	base tenant-type;
	description
	"This represents the identity of research
	department or division.";
	}
	identity finance {
	base tenant-type;
	description
	"This represents the identity of finance
	department or division.";
	}
	identity domain {
	description
	"This represents the base identity of different domains.";
	}
	identity enterprise {
	base domain;
	description
	"This represents the identity of an enterprise domain.";
	}
	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.";
	}		}
	identity signature-snort {		identity signature-snort {
	base signature-type;		base signature-type;
	description		description
	"This represents the SNORT signatures.";		"This represents the SNORT signatures.";
	}		}
	identity signature-suricata {		identity signature-suricata {
	base signature-type;		base signature-type;
	description		description
	"This represents the SURICATA signatures.";		"This represents the SURICATA signatures.";
	skipping to change at page 31, line 41 ¶		skipping to change at page 24, line 4 ¶
	identity fireeye {		identity fireeye {
	base threat-feed-type;		base threat-feed-type;
	description		description
	"This represents FireEye threat-feed.";		"This represents FireEye threat-feed.";
	}		}
	identity alienvault {		identity alienvault {
	base threat-feed-type;		base threat-feed-type;
	description		description
	"This represents Alienvault threat-feed.";		"This represents Alienvault threat-feed.";
	}		}
	identity auth-type {
	description
	"The base identity for authentication type.";
	}
	identity auth-type-server {
	base auth-type;
	description
	"This represents the server authentication.";
	}
	identity auth-type-client {
	base auth-type;
	description
	"This represents the client authentication.";
	}
	identity auth-type-mutual {
	base auth-type;
	description
	"This represents the both server and client
	authentication.";
	}
	identity auth-method-type {
	description
	"Base idendity for authentication-methods";
	}
	identity password-based {
	base auth-method-type;
	description
	"This is the identity for the password-based authetication type.";
	}
	identity token-based {
	base auth-method-type;
	description
	"This is the identity for the token-based authetication type.";
	}
	identity certificate-based {
	base auth-method-type;
	description
	"This is the identity for the certificate-based authetication type.";
	}
	/*		/*
	* Groupings		* Groupings
	*/		*/
	grouping ipv4-list {		grouping ipv4-list {
	description		description
	"Grouping for ipv4 based ip-addresses.";		"Grouping for ipv4 based ip-addresses.";
	leaf-list ipv4 {		leaf-list ipv4 {
	type inet:ipv4-address;		type inet:ipv4-address;
	skipping to change at page 33, line 29 ¶		skipping to change at page 24, line 48 ¶
	grouping ipv6 {		grouping ipv6 {
	description		description
	"Grouping for ipv6 based ip-address.";		"Grouping for ipv6 based ip-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 the ipv6 ip-address.";
	}		}
	}		}
	grouping ip-address-info {		grouping ip-address-info {
	description		description
	"There are two types to configure a security policy		"There are two types to configure a security policy
	for IPv4 address, such as exact match and range match.";		for IPv4 address, such as exact match and range match.";
	choice match-type {
	description
	"User can choose between 'exact match' and 'range match'.";
	case exact-match-ipv4 {
	uses ipv4;
	description
	"Exact ip-address match for ipv4 type addresses";
	}
	case exact-match-ipv6 {
	uses ipv6;
	description
	"Exact ip-address match for ipv6 type addresses";
	}
	case range-match-ipv4 {
	list range-ipv4-address {
	key "start-ipv4-address end-ipv4-address";
	leaf start-ipv4-address {
	type inet:ipv4-address;
	description
	"Start IPv4 address for a range match.";
	}
	leaf end-ipv4-address {
	type inet:ipv4-address;
	description
	"End IPv4 address for a range match.";
	}
	description
	"Range match for an IP-address.";
	}
	}
	case range-match-ipv6 {
	list range-ipv6-address {
	key "start-ipv6-address end-ipv6-address";
	leaf start-ipv6-address {
	type inet:ipv6-address;
	description
	"Start IPv6 address for a range match.";
	}
	leaf end-ipv6-address {
	type inet:ipv6-address;
	description
	"End IPv6 address for a range match.";
	}
	description
	"Range match for an IP-address.";
	}
	}
	}
	}
	grouping password-based-method {		choice match-type {
	list password-list {
	key "auth-method";
	leaf auth-method {
	type identityref {
	base auth-method-type;
	}
	description
	"This represents the authentication method is password-based.";
	}
	leaf password {
	type ianach:crypt-hash;
	description
	"The password for this entry.";
	}
	description
	"This represents the list of
	encrypted passwords.";
	}
	}
	grouping certificate-based-method {
	list cert-server-list {
	key "auth-method";
	description		description
	"This describes the certificate-based authentication list.";		"User can choose between 'exact match' and 'range match'.";
			case exact-match-ipv4 {
	leaf auth-mthod {		uses ipv4;
	type identityref {
	base auth-method-type;
	}
	description
	"This represents the authentication method is
	certificate based method.";
	}
	leaf cert-server-name {
	type string;
	description
	"This field represents the name of the certificate-
	server name.";
	}
	leaf cert-server-ipv4 {
	type inet:ipv4-address;
	description		description
	"This represents ipv4 address of a		"Exact ip-address match for ipv4 type addresses";
	certificate server.";
	}		}
	leaf cert-server-ipv6 {		case exact-match-ipv6 {
	type inet:ipv6-address;		uses ipv6;
	description		description
	"This represents the ipv6 address of a		"Exact ip-address match for ipv6 type addresses";
	certificate server.";
	}		}
	list certificate {		case range-match-ipv4 {
	key "cert-type";		list range-ipv4-address {
	description		key "start-ipv4-address end-ipv4-address";
	"This represents the certificate-types.";		leaf start-ipv4-address {
			type inet:ipv4-address;
	leaf cert-type {		description
	type identityref {		"Start IPv4 address for a range match.";
	base certificate-type;		}
			leaf end-ipv4-address {
			type inet:ipv4-address;
			description
			"End IPv4 address for a range match.";
	}		}
	description		description
	"This represents a certificate type.";		"Range match for an IP-address.";
	}		}
	}		}
	}		case range-match-ipv6 {
	}		list range-ipv6-address {
			key "start-ipv6-address end-ipv6-address";
	grouping token-based-method {		leaf start-ipv6-address {
	list token-list {		type inet:ipv6-address;
	key "auth-method";		description
	description		"Start IPv6 address for a range match.";
	"This represents the list of tokens.";		}
			leaf end-ipv6-address {
	leaf auth-method {		type inet:ipv6-address;
	type identityref {		description
	base auth-method-type;		"End IPv6 address for a range match.";
			}
			description
			"Range match for an IP-address.";
	}		}
	description
	"This represents the authentication type is
	token-based method.";
	}
	leaf token {
	type string;
	description
	"This object contains a string of a token.";
	}
	leaf token-server {
	type inet:ipv4-address;
	description
	"This represents the token-server information.";
	}		}
	}		}
	}		}
	grouping ipsec-based-method {		grouping ipsec-based-method {
			description
			"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.";
	}		}
	}		}
	}		}
	grouping user-group {		grouping user-group {
	description		description
	"The grouping for user-group entities, and		"The grouping for user-group entities, and
	contains information such as name & ip-address.";		contains information such as name & ip-address.";
	leaf name {		leaf-list name {
	type string;		type leafref {
			path /nacm:nacm/nacm:groups/nacm:group/nacm:user-name;
			}
	description		description
	"This represents the name of a user.";		"This represents the name of a user.";
	}		}
	uses ip-address-info;		uses ip-address-info;
	}		}
	grouping device-group {		grouping device-group {
	description		description
	"This group represents device group information		"This group represents device group information
	such as ip-address protocol.";		such as ip-address protocol.";
	leaf name {		leaf name {
	type string;		type string;
	description		description
	"This represents the name of a device.";		"This represents the name of a device.";
	}		}
	uses ip-address-info;		uses ip-address-info;
	leaf-list protocol {		leaf-list protocol {
	type identityref {		type identityref {
	base protocol-type;		base protocol-type;
	}		}
	description		description
	"This represents the communication protocols of devices.";		"This represents the communication protocols of devices.";
	}		}
	}		}
	grouping location-group {		grouping location-group {
	description		description
	"This group represents location-group information		"This group represents location-group information
	such as geo-ip and continent.";		such as geo-ip and continent.";
	leaf name {		leaf name {
	type string;		type string;
	description		description
	"This represents the name of a location.";		"This represents the name of a location.";
	}		}
	leaf geo-ip-ipv4 {		leaf geo-ip-ipv4 {
	type inet:ipv4-address;		type inet:ipv4-address;
	description		description
	"This represents the IPv4 geo-ip of a location.";		"This represents the IPv4 geo-ip of a location.";
	}		}
	skipping to change at page 39, line 4 ¶		skipping to change at page 28, line 28 ¶
	}		}
	grouping payload-string {		grouping payload-string {
	description		description
	"The grouping for payload-string content.		"The grouping for payload-string content.
	It contains information such as name and string content.";		It contains information such as name and string content.";
	leaf payload-description {		leaf payload-description {
	type string;		type string;
	description		description
	"This represents the description of a payload.";		"This represents the description of a payload.";
	}		}
	leaf-list content {		leaf-list content {
	type string;		type string;
	description		description
	"This represents the payload string content.";		"This represents the payload string content.";
	}		}
	}		}
			grouping owners-ref {
			description
			"This grouping is for owners reference using Network configuration Access Control Model (NACM).";
			leaf-list owners {
			type leafref {
			path /nacm:nacm/nacm:groups/nacm:group/nacm:name;
			}
			description
			"This leaf-list names the owner groups of the
			list instace it sits on. Only the owners and
			super users are authorized to modify the contents.";
			}
			}
	list i2nsf-cfi-policy {		list i2nsf-cfi-policy {
	key "policy-name";		key "policy-name";
			description
			"This is the security policy list. Each policy in the list
			contains a list of security rules, and is a policy instance
			to have complete information such as where and when a
			policy needs to be applied.";
			leaf policy-name {
			type string;
			mandatory true;
	description		description
	"This is the security policy list. Each policy in the list		"The name which identifies the policy.";
	contains a list of security rules, and is a policy instance		}
	to have complete information such as where and when a		uses owners-ref;
	policy needs to be applied.";
	leaf policy-name {		container rule{
	type string;		description
	mandatory true;		"This container is for rules.";
	description		nacm:default-deny-write;
	"The name which identifies the policy.";
	}
	list rule {		list rule {
	leaf rule-name {		leaf rule-name {
	type string;		type string;
	mandatory true;		mandatory true;
	description		description
	"This represents the name for rules.";		"This represents the name for the rule.";
	}		}
	key "rule-name";		key "rule-name";
	description		description
	"There can be a single or multiple number of rules.";		"There can be a single or multiple number of rules.";
			uses owners-ref;
	container event {		container event {
	description		description
	"This represents the event (e.g., a security event, which a security rule is made for.";		"This represents the event (e.g., a security event,
			which a security rule is made for.)";
	leaf security-event {		leaf security-event {
	type identityref {		type identityref {
	base security-event-type;		base security-event-type;
	}		}
	mandatory true;		mandatory true;
	description		description
	"This contains the description of security events.";		"This contains the description of security events.";
	}		}
	choice enforce-type {		choice enforce-type {
	description		description
	"There are three different enforcement types;		"There are three different enforcement types; admin, and time.";
	admin, and time.";
	case enforce-admin {		case enforce-admin {
	leaf admin {		leaf admin {
	type identityref {		type identityref {
	base enforce-type;		base enforce-type;
	}		}
	description		description
	"This represents the enforcement type based on admin's decision.";		"This represents the enforcement type based on admin's
			decision.";
	}		}
	}		}
	case time {		case time {
	container time-information {		container time-information {
	description		description
	"The begin-time and end-time information		"The begin-time and end-time information
	when the security rule should be applied.";		when the security rule should be applied.";
	leaf enforce-time {		leaf enforce-time {
	type identityref {		type identityref {
	base enforce-type;		base enforce-type;
	}		}
	description		description
	"The enforcement type is time-enforced.";		"The enforcement type is time-enforced.";
	}		}
	leaf begin-time {		leaf begin-time {
	type yang:date-and-time;		type yang:date-and-time;
	description		description
	"This is start time for time zone";		"This is start time for time zone";
	}		}
	leaf end-time {		leaf end-time {
	type yang:date-and-time;		type yang:date-and-time;
	description		description
	"This is end time for time zone";		"This is end time for time zone";
	}		}
	}		}
	}		}
	}		}
	leaf frequency {		leaf frequency {
	type enumeration {		type enumeration {
	enum only-once {		enum only-once {
	description		description
	"This represents the rule is enforced only once.";		"This represents the rule is enforced only once.";
	}		}
	skipping to change at page 41, line 11 ¶		skipping to change at page 31, line 10 ¶
	"This represents the rule is enforced on a weekly basis.";		"This represents the rule is enforced on a weekly basis.";
	}		}
	enum monthly {		enum monthly {
	description		description
	"This represents the rule is enforced on a monthly basis.";		"This represents the rule is enforced on a monthly basis.";
	}		}
	}		}
	default only-once;		default only-once;
	description		description
	"This represents how frequent the rule should be enforced.";		"This represents how frequent the rule should be enforced.";
			}
	}		}
	}		container condition {
	container condition {
	choice condition {
	description		description
	"The conditions for general security policies.";		"The conditions for general security policies.";
	case firewall-condition {		choice condition {
			description
			"This choice condition is for general firewall.";
			case firewall-condition {
			description
			"The general firewall condition.";
			container firewall-source {
	description		description
	"The general firewall condition.";		"This represents the source.";
	container firewall-source {		leaf src-target {
	description		type leafref {
	"This represents the source.";		path /nacm:nacm/nacm:groups/nacm:group/nacm:user-name;
	leaf src-target {
	type leafref {
	path "/i2nsf-cfi-policy/endpoint-group/user-group/name";
	}
	mandatory true;
	description
	"This describes the paths to
	the source reference.";
	}		}
	}		mandatory true;
	container firewall-destination {
	description		description
	"This represents the destination.";		"This describes the paths to
	leaf-list dest-target {		the source reference.";
	type leafref {		}
	path "/i2nsf-cfi-policy/endpoint-group/user-group/name";
	}
	description
	"This describes the paths to the
	destination target reference.";
	}
	}
	}		}
	case ddos-condition {		container firewall-destination {
	description		description
	"The condition for DDoS mitigation.";		"This represents the destination.";
	container ddos-source {		leaf-list dest-target {
	description		type leafref {
	"This represents the source.";		path /nacm:nacm/nacm:groups/nacm:group/nacm:user-name;
	leaf-list src-target {
	type leafref {
	path "/i2nsf-cfi-policy/endpoint-group/device-group/name";
	}
	description
	"This describes the path to the
	source target references.";
	}		}
			description
			"This describes the paths to the
			destination target reference.";
	}		}
	container ddos-destination {		}
	description		}
	"This represents the target.";		case ddos-condition {
	leaf-list dest-target {		description
	type leafref {		"The condition for DDoS mitigation.";
	path "/i2nsf-cfi-policy/endpoint-group/device-group/name";		container ddos-source {
	}		description
	description		"This represents the source.";
	"This describes the path to the		leaf-list src-target {
	destination target references.";		type leafref {
			path "/i2nsf-cfi-policy/endpoint-group/device-group/name";
	}		}
			description
			"This describes the path to the
			source target references.";
	}		}
	container rate-limit {		}
	description "This describes the rate-limit.";		container ddos-destination {
	leaf packet-per-second {		description
	type uint16;		"This represents the target.";
	description		leaf-list dest-target {
	"The rate-limit limits the amount of incoming packets.";		type leafref {
			path "/i2nsf-cfi-policy/endpoint-group/device-group/name";
	}		}
			description
			"This describes the path to the
			destination target references.";
	}		}
	}		}
	case custom-condition {		container rate-limit {
	description		description "This describes the rate-limit.";
	"The condition based on packet contents.";		leaf packet-per-second {
	container custon-source {		type uint16;
	description		description
	"This represents the source.";		"The rate-limit limits the amount of incoming packets.";
	leaf-list src-target {		}
	type leafref {		}
	path "/i2nsf-cfi-policy/threat-prevention/payload-content/name";		}
	}		case custom-condition {
	description		description
	"Describes the payload string		"The condition based on packet contents.";
	content condition source.";		container custon-source {
			description
			"This represents the source.";
			leaf-list src-target {
			type leafref {
			path "/i2nsf-cfi-policy/threat-prevention/payload-content/name";
	}		}
			description
			"Describes the payload string
			content condition source.";
	}		}
	container custom-destination {		}
	description		container custom-destination {
	"This represents the destination.";		description
			"This represents the destination.";
	leaf dest-target {		leaf dest-target {
	type leafref {		type leafref {
	path "/i2nsf-cfi-policy/threat-prevention/payload-content/name";		path "/i2nsf-cfi-policy/threat-prevention/payload-content/name";
	}
	mandatory true;
	description
	"Describes the payload string
	content condition destination.";
	}		}
			mandatory true;
			description
			"Describes the payload string
			content condition destination.";
	}		}
	}		}
	case threat-feed-condition {		}
			case threat-feed-condition {
			description
			"The condition based on the threat-feed information.";
			container threat-feed-source {
	description		description
	"The condition based on the threat-feed information.";		"This represents the source.";
	container threat-feed-source {		leaf-list src-target {
	description		type leafref {
	"This represents the source.";		path "/i2nsf-cfi-policy/threat-prevention/threat-feed-list/feed-name";
	leaf-list src-target {
	type leafref {
	path "/i2nsf-cfi-policy/threat-prevention/threat-feed-list/feed-name";
	}
	description "Describes the threat-feed
	condition source.";
	}		}
			description "Describes the threat-feed
			condition source.";
	}		}
	container threat-feed-destination {		}
	description		container threat-feed-destination {
	"This represents the destination.";		description
	leaf dest-target {		"This represents the destination.";
	type leafref {		leaf dest-target {
	path "/i2nsf-cfi-policy/threat-prevention/threat-feed-list/feed-name";		type leafref {
	}		path "/i2nsf-cfi-policy/threat-prevention/threat-feed-list/feed-name";
	mandatory true;
	description "Describes the threat-feed
	condition destination.";
	}		}
			mandatory true;
			description "Describes the threat-feed
			condition destination.";
	}		}
	}		}
			}
			}
	}		}
	}		container action {
	container action {
	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;
	}		}
	mandatory true;		mandatory true;
	description		description
	"This represent the primary actions (e.g., PASS, DROP,		"This represent the primary actions (e.g., PASS, DROP,
	ALERT, and MIRROR) to be applied a condition.";		ALERT, and MIRROR) to be applied a condition.";
	}		}
	leaf secondary-action {		leaf secondary-action {
	type identityref {		type identityref {
	base secondary-action;		base secondary-action;
	}		}
	description		description
	"This represents the secondary actions (e.g., log		"This represents the secondary actions (e.g., log
	and syslog) to be applied if needed.";		and syslog) to be applied if needed.";
			}
	}		}
	}		container ipsec-method {
	container ipsec-method {
	description		description
	"This container represents the IPsec IKE and IKEless cases.";		"This container represents the IPsec IKE and IKEless cases.";
	leaf method {		leaf method {
	type leafref {		type identityref {
	path "/i2nsf-cfi-policy/multi-tenancy/policy-mgmt-auth-method-instance/ipsec-method/method";		base i2nsf-ipsec;
	}		}
	description		description
	"This references the IPsec method types,		"This references the IPsec method types,
	which includes IPsec IKE and IPsec IKEless cases.";		which includes IPsec IKE and IPsec IKEless cases.";
			}
	}		}
	}		leaf owner {
	leaf owner {		type identityref {
	type identityref {
	base owner;		base owner;
	}		}
	mandatory true;		mandatory true;
	description		description
	"This field defines the owner of this		"This field defines the owner of this
	rule. Only the owner is authorized to		rule. Only the owner is authorized to
	modify the contents of the rule.";		modify the contents of the rule.";
			}
	}		}
	}		}
			container endpoint-group {
	container multi-tenancy {
	description		description
	"The multi-tenant environment information		"A logical entity in their business
	in which the policy is applied. The Rules		environment, where a security policy
	in the Policy can refer to sub-objects		is to be applied.";
	(e.g., domain, tenant, role, and user) of it.";		uses user-group;
			list device-group {
	list policy-domain {		key "name";
	key "domain-name";		uses device-group;
			description
			"This represents the device group.";
			}
			list location-group{
			key "name";
			uses location-group;
	description		description
	"This represents the list of policy domains.";		"This represents the location group.";
	leaf domain-name {
	type identityref {
	base domain;
	}
	description
	"This represents the name of a domain.";
	}
	leaf address {
	type string;
	description
	"The address details of the organization
	or customer.";
	}
	leaf contact {
	type string;
	description
	"contact information of the organization
	or customer.";
	}		}
	list policy-tenant {		}
	key "tenant-type";
	description
	"This field identifies the domain to which this
	tenant belongs. This should be reference to a
	'Policy-Domain' object.";
	leaf tenant-type{
	type identityref {
	base tenant-type;
	}
	description
	"The name of the tenant, such as HR or Finance department.";
	}
	list policy-role {
	key "role-type";
	description
	"This represent the roles within the tenants,
	in order to distinguish who may or may not
	have access to policies.";
	leaf role-type {		container threat-prevention {
	type identityref {		description
	base role-type;		"this describes the list of threat-prevention.";
	}
	description
	"This represents the name of the role";
	}
	list policy-user {
	key "name";
	description
	"This represents the list of policy users.";
	leaf name {		list threat-feed-list {
	type string;		key "feed-name";
	description
	"This represents the name of the user";
	}
	leaf password {
	type ianach:crypt-hash;
	description
	"User password for basic authentication";
	}
	leaf email {
	type string;
	description
	"The email account of a user";
	}
	list access-profile {
	key "permission-type scope-type";
	description
	"This field identifies the access profile for the
	role. The profile grants or denies access to policy
	objects.";
	leaf permission-type {
	type identityref {
	base permission-type;
	}
	description
	"This represents the permission types, such as
	read, write, execute, read-and-write, and etc.";
	}
	leaf scope-type {
	type identityref {
	base scope-type;
	}
	description
	"identifies whether a user has domain-wide
	or tenant-wide privileges";
	}
	}
	}
	}
	}
	}
	list policy-mgmt-auth-method-instance {
	key "auth-instance-type";
	description		description
	"This represents the list of instances for		"This represents the threat feed list.";
	policy management authentication methods.";		uses threat-feed-info;
	leaf auth-instance-type {		leaf-list threat-file-types {
	type identityref {		type identityref {
	base auth-type;		base malware-file-type;
	}		}
			default executable-file;
	description		description
	"This identifies whether the authentication type		"This contains a list of file types needed to
	is server authentication, client authentication,		be scanned for the virus.";
	or both.";
	}		}
	choice policy-mgmt-auth-method {		leaf-list signatures {
			type identityref {
			base signature-type;
			}
			default signature-suricata;
	description		description
	"This represents the choices for which		"This contains a list of signatures or hash
	authentication method is used.";		of the threats.";
	case password-based {
	uses password-based-method;
	}
	case token-based {
	description
	"This represents the token-based method.";
	uses token-based-method;
	}
	case certificate-based {
	description
	"This represents the certificate-based-method.";
	uses certificate-based-method;
	}
	case ipsec {
	description
	"This repreents authentication method based on IPSEC.";
	uses ipsec-based-method;
	}		}
	}		}
	}		list payload-content {
	}		key "name";
	container endpoint-group {		leaf name {
	description		type string;
	"A logical entity in their business
	environment, where a security policy
	is to be applied.";
	list user-group {
	key "name";
	uses user-group;
	description
	"This represents the user group.";
	}
	list device-group {
	key "name";
	uses device-group;
	description
	"This represents the device group.";
	}
	list location-group{
	key "name";
	uses location-group;
	description
	"This represents the location group.";
	}
	}
	container threat-prevention {
	description
	"this describes the list of threat-prevention.";
	list threat-feed-list {
	key "feed-name";
	description		description
	"This represents the threat feed list.";		"This represents the name of payload-content.
	uses threat-feed-info;		It should give an idea of why specific payload
			content is marked as threat. For example, the name
	leaf-list threat-file-types {		'backdoor' indicates the payload content is related
	type identityref {		to backdoor attack.";
	base malware-file-type;
	}
	default executable-file;
	description
	"This contains a list of file types needed to
	be scanned for the virus.";
	}
	leaf-list signatures {
	type identityref {
	base signature-type;
	}
	default signature-suricata;
	description
	"This contains a list of signatures or hash
	of the threats.";
	}		}
	}		description
	list payload-content {		"This represents the payload-string group.";
	key "name";		uses payload-string;
	leaf name {
	type string;
	decription
	"This represents the name of payload-content".
	It should give an idea of why specific payload
	content is marked as threat. For example, the name
	"backdoor" indicates the payload content is related
	to backdoor attack.";
	}
	description
	"This represents the payload-string group.";
	uses payload-string;
	}		}
	}		}
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	Figure 23: YANG for Consumer-Facing Interface		Figure 16: YANG for Consumer-Facing Interface
	10. Example XML Output for Various Scenarios		9. XML Configuration Examples of High-Level Security Policy Rules
	This section describes the XML instances for different policies		This section shows XML configuration examples of high-level security
	examples that are delivered through Consumer-Facing Interface. The		policy rules that are delivered from the I2NSF User to the Security
	considered use cases are: VoIP/VoLTE security service, DDoS-attack		Controller over the Consumer-Facing Interface. The considered use
	mitigation, time-based firewall as a web-filter.		cases are: Database registration, time-based firewall for web
			filtering, VoIP/VoLTE security service, and DDoS-attack mitigation.
	10.1. DB Registration: Information of Positions and Devices (Endpoint		9.1. Database Registration: Information of Positions and Devices
	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 24 shows an example XML		protocols used by devices. Figure 17 shows an example XML
	representation of the registered information for the user-group and		representation of the registered information for the user-group and
	device-group.		device-group.
	<?xml version="1.0" encoding="UTF-8" ?>		<?xml version="1.0" encoding="UTF-8" ?>
	<endpoint-group xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy">		<endpoint-group xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy">
	<user-group>		<user-group>
	<name>employees</name>		<name>employees</name>
	<range-ip-address>		<range-ip-address>
	<start-ip-address>221.159.112.1</start-ip-address>		<start-ip-address>221.159.112.1</start-ip-address>
	<end-ip-address>221.159.112.90</end-ip-address>		<end-ip-address>221.159.112.90</end-ip-address>
	</range-ip-address>		</range-ip-address>
	</user-group>		</user-group>
	<device-group>		<device-group>
	<name>webservers</name>		<name>webservers</name>
	<range-ip-address>		<range-ip-address>
	<start-ip-address>221.159.112.91</start-ip-address>		<start-ip-address>221.159.112.91</start-ip-address>
	<end-ip-address>221.159.112.97</end-ip-address>		<end-ip-address>221.159.112.97</end-ip-address>
	</range-ip-address>		</range-ip-address>
	<protocol>http</protocol>		<protocol>http</protocol>
	<protocol>https</protocol>		<protocol>https</protocol>
	</device-group>		</device-group>
	</endpoint-group xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy">		</endpoint-group xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy">
	Figure 24: Registering User-group and Device-group Information		Figure 17: Registering User-group and Device-group Information
	10.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 business		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 "employee" in the user-group list are unable to		users registered as "employees" in the user-group list are unable to
	access Social Networking Services (SNS) during the office hours. The		access Social Networking Services (SNS) during the office hours. 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" ?>
	<policy xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy">		<policy xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy">
	<policy-name>security_policy_for_blocking_sns</policy-name>		<policy-name>security_policy_for_blocking_sns</policy-name>
	<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>
	skipping to change at page 51, line 37 ¶		skipping to change at page 38, line 37 ¶
	</condition>		</condition>
	<action>		<action>
	<primary-action>drop</primary-action>		<primary-action>drop</primary-action>
	</action>		</action>
	<ipsec-method>		<ipsec-method>
	<method>ipsec-ike</method>		<method>ipsec-ike</method>
	</ipsec-method>		</ipsec-method>
	</rule>		</rule>
	</policy xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy">		</policy xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy">
	Figure 25: An XML Example for Time-based Firewall		Figure 18: 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-target is "employees".		3. The Source-target is "employees".
	4. The destination target is "sns-websites". "sns-websites" is the		4. The destination target is "sns-websites". "sns-websites" is the
	key which represents the list containing the information, such as		key which represents the list containing the information, such as
	URL, about sns-websites.		URL, about sns-websites.
	5. The action required is to "drop" any attempt to connect to		5. The action required is to "drop" any attempt to connect to
	websites related to Social networking.		websites related to Social networking.
	6. The IPsec method type used for nsf traffic steering is set to		6. The IPsec method type used for nsf traffic steering is set to
	"ipsec-ike".		"ipsec-ike".
	10.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to a		9.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to a Company
	Company
	The second example scenario is to "block malicious VoIP/VoLTE packets		The second example scenario is to "block malicious VoIP/VoLTE packets
	coming to a company" using a VoIP policy. In this scenario, the		coming to a company" using a VoIP policy. In this scenario, the
	calls comming from from VOIP and/or VOLTE sources with VOLTE IDs that		calls comming from from VOIP and/or VOLTE sources with VOLTE IDs that
	are classified as malicious are dropped. The IP addresses of the		are classified as malicious are dropped. The IP addresses of the
	employees and malicious VOIP IDs should be blocked are stored in the		employees and malicious VOIP IDs should be blocked are stored in the
	database or datastore of the enterprise. Here and the rest of the		database or datastore of the enterprise. Here and the rest of the
	cases assume that the security administrators or someone responsible		cases assume that the security administrators or someone responsible
	for the existing and newly generated policies, are not aware of which		for the existing and newly generated policies, are not aware of which
	and/or how many NSFs are needed to meet the security requirements.		and/or how many NSFs are needed to meet the security requirements.
	Figure 26 represents the XML document generated from YANG discussed		Figure 19 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" ?>
	<policy xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy">		<policy xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy">
	<policy-name>security_policy_for_blocking_malicious_voip_packets</policy-name>		<policy-name>security_policy_for_blocking_malicious_voip_packets</policy-name>
	<rule>		<rule>
	<rule-name>Block_malicious_voip_and_volte_packets</rule-name>		<rule-name>Block_malicious_voip_and_volte_packets</rule-name>
	skipping to change at page 52, line 52 ¶		skipping to change at page 39, line 51 ¶
	</condition>		</condition>
	<action>		<action>
	<primary-action>drop</primary-action>		<primary-action>drop</primary-action>
	</action>		</action>
	<ipsec-method>		<ipsec-method>
	<method>ipsec-ikeless</method>		<method>ipsec-ikeless</method>
	</ipsec-method>		</ipsec-method>
	</rule>		</rule>
	</policy xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy">		</policy xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy">
	Figure 26: An XML Example for VoIP Security Service		Figure 19: 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-target is "malicious-id". This can be a single ID or		3. The Source-target is "malicious-id". This can be a single ID or
	a list of IDs, depending on how the ID are stored in the		a list of IDs, depending on how the ID are stored in the
	skipping to change at page 53, line 28 ¶		skipping to change at page 40, line 28 ¶
	4. The destination target is "employees". "employees" is the key		4. The destination target is "employees". "employees" is the key
	which represents the list containing information about employees,		which represents the list containing information about employees,
	such as IP addresses.		such as IP addresses.
	5. The action required is "drop" when any incoming packets are from		5. The action required is "drop" when any incoming packets are from
	"malicious-id".		"malicious-id".
	6. The IPsec method used for nsf traffic steering is set to "ipsec-		6. The IPsec method used for nsf traffic steering is set to "ipsec-
	ikeless".		ikeless".
	10.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a Company		9.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a Company Web
	Web Server		Server
	The third example scenario is to "Mitigate HTTP and HTTPS flood		The third example scenario is to "Mitigate HTTP and HTTPS flood
	attacks on a company web server" using a DDoS-attack mitigation		attacks on a company web server" using a DDoS-attack mitigation
	policy. Here, the time information is not set because the service		policy. Here, the time information is not set because the service
	provided by the network should be maintained at all times. If the		provided by the network should be maintained at all times. If the
	packets sent by any sources are more than the set threshold, then the		packets sent by any sources are more than the set threshold, then the
	admin can set the percentage of the packets to be dropped to safely		admin can set the percentage of the packets to be dropped to safely
	maintain the service. In this scenario, the source is set as "any"		maintain the service. In this scenario, the source is set as "any"
	to block any sources which send abnormal amount of packets. The		to block any sources which send abnormal amount of packets. The
	destination is set as "web_server01". Once the rule is set and		destination is set as "web_server01". Once the rule is set and
	skipping to change at page 54, line 29 ¶		skipping to change at page 41, line 29 ¶
	</condition>		</condition>
	<action>		<action>
	<primary-action>drop</primary-action>		<primary-action>drop</primary-action>
	</action>		</action>
	<ipsec-method>		<ipsec-method>
	<method>ipsec-ikeless</method>		<method>ipsec-ikeless</method>
	</ipsec-method>		</ipsec-method>
	</rule>		</rule>
	</policy xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy">		</policy xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy">
	Figure 27: An XML Example for DDoS-attack Mitigation		Figure 20: 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 55, line 8 ¶		skipping to change at page 42, line 8 ¶
	5. The Source-target is all sources which send abnormal amount of		5. The Source-target is all sources which send abnormal amount of
	packets.		packets.
	6. The action required is to "drop" packet reception is more than		6. The action required is to "drop" packet reception is more than
	100 packets per second.		100 packets per second.
	7. The IPsec method used for nsf traffic steering is set to "ipsec-		7. The IPsec method used for nsf traffic steering is set to "ipsec-
	ike".		ike".
	11. Security Considerations		10. Security Considerations
	The data model for the I2NSF Consumer-Facing Interface is based on		The data model for the I2NSF Consumer-Facing Interface is based on
	the I2NSF framework [RFC8329], so the same security considerations		the I2NSF framework [RFC8329], so the same security considerations
	with the I2NSF framework should be included in this document. The		with the I2NSF framework should be included in this document. The
	data model needs a secure communication channel to protect the		data model needs a secure communication channel to protect the
	Consumer-Facing Interface between the I2NSF User and Security		Consumer-Facing Interface between the I2NSF User and Security
	Controller.		Controller.
	12. IANA Considerations		11. IANA Considerations
	This document requests IANA to register the following URI in the		This document requests IANA to register the following URI in the
	"IETF XML Registry" [RFC3688]:		"IETF XML Registry" [RFC3688]:
	URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy		URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy
	Registrant Contact: The I2NSF.		Registrant Contact: The I2NSF.
	XML: N/A; the requested URI is an XML namespace.		XML: N/A; the requested URI is an XML namespace.
	This document requests IANA to register the following YANG module in		This document requests IANA to register the following YANG module in
	the "YANG Module Names" registry [RFC7950].		the "YANG Module Names" registry [RFC7950].
	name: ietf-i2nsf-cfi-policy		name: ietf-i2nsf-cfi-policy
	namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy		namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi-policy
	prefix: cfi-policy		prefix: cfi-policy
	reference: RFC 7950		reference: RFC 7950
	13. References		12. Acknowledgments
	13.1. Normative References		This work was supported by Institute of Information & Communications
			Technology Planning & Evaluation (IITP) grant funded by the Korea
			MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based
			Security Intelligence Technology Development for the Customized
			Security Service Provisioning).
			13. Contributors
			This document is made by the group effort of I2NSF working group.
			Many people actively contributed to this document, such as Mahdi F.
			Dachmehchi and Daeyoung Hyun. The authors sincerely appreciate their
			contributions.
			The following are co-authors of this document:
			Hyoungshick Kim
			Department of Computer Science and Engineering
			Sungkyunkwan University
			2066 Seo-ro Jangan-gu
			Suwon, Gyeonggi-do 16419
			Republic of Korea
			EMail: hyoung@skku.edu
			Eunsoo Kim
			Department of Electronic, Electrical and Computer Engineering
			Sungkyunkwan University
			2066 Seo-ro Jangan-gu
			Suwon, Gyeonggi-do 16419
			Republic of Korea
			EMail: eskim86@skku.edu
			Seungjin Lee
			Department of Electronic, Electrical and Computer Engineering
			Sungkyunkwan University
			2066 Seo-ro Jangan-gu
			Suwon, Gyeonggi-do 16419
			Republic of Korea
			EMail: jine33@skku.edu
			Jinyong Tim Kim
			Department of Electronic, Electrical and Computer Engineering
			Sungkyunkwan University
			2066 Seo-ro Jangan-gu
			Suwon, Gyeonggi-do 16419
			Republic of Korea
			EMail: timkim@skku.edu
			Anil Lohiya
			Juniper Networks
			1133 Innovation Way
			Sunnyvale, CA 94089
			US
			EMail: alohiya@juniper.net
			Dave Qi
			Bloomberg
			731 Lexington Avenue
			New York, NY 10022
			US
			EMail: DQI@bloomberg.net
			Nabil Bitar
			Nokia
			755 Ravendale Drive
			Mountain View, CA 94043
			US
			EMail: nabil.bitar@nokia.com
			Senad Palislamovic
			Nokia
			755 Ravendale Drive
			Mountain View, CA 94043
			US
			EMail: senad.palislamovic@nokia.com
			Liang Xia
			Huawei
			101 Software Avenue
			Nanjing, Jiangsu 210012
			China
			EMail: Frank.Xialiang@huawei.com
			14. References
			14.1. Normative References
	[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between		[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
	Information Models and Data Models", RFC 3444,		Information Models and Data Models", RFC 3444,
	DOI 10.17487/RFC3444, January 2003,		DOI 10.17487/RFC3444, January 2003,
	<https://www.rfc-editor.org/info/rfc3444>.		<https://www.rfc-editor.org/info/rfc3444>.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	DOI 10.17487/RFC3688, January 2004,		DOI 10.17487/RFC3688, January 2004,
	<https://www.rfc-editor.org/info/rfc3688>.		<https://www.rfc-editor.org/info/rfc3688>.
	skipping to change at page 56, line 32 ¶		skipping to change at page 45, line 37 ¶
	[RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.		[RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
	Kumar, "Framework for Interface to Network Security		Kumar, "Framework for Interface to Network Security
	Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018,		Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018,
	<https://www.rfc-editor.org/info/rfc8329>.		<https://www.rfc-editor.org/info/rfc8329>.
	[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",		[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
	BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,		BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
	<https://www.rfc-editor.org/info/rfc8340>.		<https://www.rfc-editor.org/info/rfc8340>.
			[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
			Access Control Model", STD 91, RFC 8341,
			DOI 10.17487/RFC8341, March 2018,
			<https://www.rfc-editor.org/info/rfc8341>.
	[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>.
	13.2. Informative References		14.2. Informative References
	[client-facing-inf-req]		[client-facing-inf-req]
	Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic,		Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic,
	S., and L. Xia, "Requirements for Client-Facing Interface		S., and L. Xia, "Requirements for Client-Facing Interface
	to Security Controller", draft-ietf-i2nsf-client-facing-		to Security Controller", draft-ietf-i2nsf-client-facing-
	interface-req-05 (work in progress), May 2018.		interface-req-05 (work in progress), May 2018.
	[i2nsf-capability-im]		[i2nsf-capability-im]
	Xia, L., Strassner, J., Basile, C., and D. Lopez,		Xia, L., Strassner, J., Basile, C., and D. Lopez,
	"Information Model of NSFs Capabilities", draft-ietf-		"Information Model of NSFs Capabilities", draft-ietf-
	i2nsf-capability-05 (work in progress), April 2019.		i2nsf-capability-05 (work in progress), April 2019.
	[i2nsf-ipsec]		[i2nsf-ipsec]
	Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez-		Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez-
	Garcia, "Software-Defined Networking (SDN)-based IPsec		Garcia, "Software-Defined Networking (SDN)-based IPsec
	Flow Protection", draft-ietf-i2nsf-sdn-ipsec-flow-		Flow Protection", draft-ietf-i2nsf-sdn-ipsec-flow-
	protection-05 (work in progress), July 2019.		protection-07 (work in progress), August 2019.
	[i2nsf-terminology]		[i2nsf-terminology]
	Hares, S., Strassner, J., Lopez, D., Xia, L., and H.		Hares, S., Strassner, J., Lopez, D., Xia, L., and H.
	Birkholz, "Interface to Network Security Functions (I2NSF)		Birkholz, "Interface to Network Security Functions (I2NSF)
	Terminology", draft-ietf-i2nsf-terminology-08 (work in		Terminology", draft-ietf-i2nsf-terminology-08 (work in
	progress), July 2019.		progress), July 2019.
	Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-interface-		Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-interface-
	dm-05		dm-06
	The following are major changes made from draft-ietf-i2nsf-consumer-
	facing-interface-dm-05:
	o The container policy-mgnt-auth-method uses a list, and the policy-
	mgmt-auth-method consists of choice-cases.
	o Policy-role is changed from container to list. The access-profile
	in the policy-role is not removed. Instead, it is placed inside
	policy-user.
	o Container Condition consists of choice-cases to show that it is
	capable of configuring different triggering conditions.
	o The enforce-type in Event container use a choice-case statement.
	This change shows the clarity that the enforce-type is relevant to
	each case (i.e., enforce-type == admin or time).
	o The name for container "recursive" is changed to "frequency".
	This container represents how frequently the rule is enforced, so
	the name "frequency" is more appropriate.
	o The certificate based authentication method is modified so that a
	certificate server can handle more than one (list) of certificate
	types.
	The minor changes are as follows:
	o Typos are corrected.
	o IPv6 as well as IPv4 are included.
	o Some misused types are corrected (e.g., enum -> identity)
	o Some descriptions that are unclear, mistaken, or shortly explained
	are rewritten.
	Appendix B. Acknowledgments
	This work was supported by Institute of Information & Communications
	Technology Planning & Evaluation (IITP) grant funded by the Korea
	MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based
	Security Intelligence Technology Development for the Customized
	Security Service Provisioning).
	Appendix C. Contributors
	This document is made by the group effort of I2NSF working group.
	Many people actively contributed to this document, such as Mahdi F.
	Dachmehchi and Daeyoung Hyun. The authors sincerely appreciate their
	contributions.
	The following are co-authors of this document:
	Hyoungshick Kim
	Department of Computer Science and Engineering
	Sungkyunkwan University
	2066 Seo-ro Jangan-gu
	Suwon, Gyeonggi-do 16419
	Republic of Korea
	EMail: hyoung@skku.edu
	Seungjin Lee
	Department of Electronic, Electrical and Computer Engineering
	Sungkyunkwan University
	2066 Seo-ro Jangan-gu
	Suwon, Gyeonggi-do 16419
	Republic of Korea
	EMail: jine33@skku.edu
	Jinyong Tim Kim
	Department of Electronic, Electrical and Computer Engineering
	Sungkyunkwan University
	2066 Seo-ro Jangan-gu
	Suwon, Gyeonggi-do 16419
	Republic of Korea
	EMail: timkim@skku.edu		The following changes are made from draft-ietf-i2nsf-consumer-facing-
			interface-dm-06:
	Anil Lohiya		o This version has reflected the comments from Jan Lindblad.
	Juniper Networks
	1133 Innovation Way
	Sunnyvale, CA 94089
	US
	EMail: alohiya@juniper.net		o In Section 1, Figure 1 is modified such that "Multi-Tenancy" is
	Dave Qi		deleted because "Multi-Tenancy" can be described by "Endpoint
	Bloomberg		Groups" in a policy rule.
	731 Lexington Avenue
	New York, NY 10022
	US
	EMail: DQI@bloomberg.net		o In Section 4, Figure 2 is modified such that the YANG data model
			of a policy having at least one rule has a hierarchical structure
			rather than a flat structure by deleing the "Multi-Tenancy" field.
	Nabil Bitar		o The section named "Information Model for Multi-Tenancy" is
	Nokia		deleted. The multi-tenancy can be specified by "Endpoint Groups"
	755 Ravendale Drive		along with "Network Configuration Access Control Model (NACM)"
	Mountain View, CA 94043		mechanisms.
	US
	EMail: nabil.bitar@nokia.com		o In Section 5.1, "NACM" is applied in "user-group" and for its
			access control.
	Senad Palislamovic		o In Section 5.2, Figure 10 is modified because the "protocol" field
	Nokia		was missed in the previous version.
	755 Ravendale Drive
	Mountain View, CA 94043
	US
	EMail: senad.palislamovic@nokia.com		o Section 7 is added as "Network Configuration Access Control Model
			(NACM)" in order to provide the Consumer-Facing Interface with the
			existing access control mechanisms. Also, the reference of
			[RFC8341] is added for NACM.
	Liang Xia		o The section named "Role-based Access Control (RBAC)" is deleted
	Huawei		since this access control can be replaced by "NACM".
	101 Software Avenue
	Nanjing, Jiangsu 210012
	China
	EMail: Frank.Xialiang@huawei.com		o In Section 8, the YANG data module is modified according to the
			above changes.
	Authors' Addresses		Authors' Addresses
	Jaehoon Paul Jeong		Jaehoon Paul Jeong
	Department of Computer Science and Engineering		Department of Computer Science and Engineering
	Sungkyunkwan University		Sungkyunkwan University
	2066 Seobu-Ro, Jangan-Gu		2066 Seobu-Ro, Jangan-Gu
	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
	Eunsoo Kim		Chaehong Chung
	Department of Electronic, Electrical and Computer Engineering		Department of Electronic, Electrical and Computer 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 4104		Phone: +82 31 299 4957
	EMail: eskim86@skku.edu		EMail: darkhong@skku.edu
	URI: http://seclab.skku.edu/people/eunsoo-kim/
	Tae-Jin Ahn		Tae-Jin Ahn
	Korea Telecom		Korea Telecom
	70 Yuseong-Ro, Yuseong-Gu		70 Yuseong-Ro, Yuseong-Gu
	Daejeon 305-811		Daejeon 305-811
	Republic of Korea		Republic of Korea
	Phone: +82 42 870 8409		Phone: +82 42 870 8409
	EMail: taejin.ahn@kt.com		EMail: taejin.ahn@kt.com
End of changes. 199 change blocks.
	1251 lines changed or deleted		631 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/