draft-ietf-i2nsf-consumer-facing-interface-dm-11.txt		draft-ietf-i2nsf-consumer-facing-interface-dm-12.txt
	I2NSF Working Group J. Jeong, Ed.		I2NSF Working Group J. Jeong, Ed.
	Internet-Draft C. Chung		Internet-Draft C. Chung
	Intended status: Standards Track Sungkyunkwan University		Intended status: Standards Track Sungkyunkwan University
	Expires: March 10, 2021 T. Ahn		Expires: March 12, 2021 T. Ahn
	Korea Telecom		Korea Telecom
	R. Kumar		R. Kumar
	Juniper Networks		Juniper Networks
	S. Hares		S. Hares
	Huawei		Huawei
	September 6, 2020		September 8, 2020
	I2NSF Consumer-Facing Interface YANG Data Model		I2NSF Consumer-Facing Interface YANG Data Model
	draft-ietf-i2nsf-consumer-facing-interface-dm-11		draft-ietf-i2nsf-consumer-facing-interface-dm-12
	Abstract		Abstract
	This document describes an information model and a YANG data model		This document describes an information model and a YANG data model
	for the Consumer-Facing Interface between an Interface to Network		for the Consumer-Facing Interface between an Interface to Network
	Security Functions (I2NSF) User and Security Controller in an I2NSF		Security Functions (I2NSF) User and Security Controller in an I2NSF
	system in a Network Functions Virtualization (NFV) environment. The		system in a Network Functions Virtualization (NFV) environment. The
	information model defines various types of managed objects and the		information model defines various types of managed objects and the
	relationship among them needed to build the interface. The		relationship among them needed to build the interface. The
	information model is based on the "Event-Condition-Action" (ECA)		information model is based on the "Event-Condition-Action" (ECA)
	skipping to change at page 1, line 47 ¶		skipping to change at page 1, line 47 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on March 10, 2021.		This Internet-Draft will expire on March 12, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 40 ¶		skipping to change at page 2, line 40 ¶
	4.2. Device Group . . . . . . . . . . . . . . . . . . . . . . 12		4.2. Device Group . . . . . . . . . . . . . . . . . . . . . . 12
	4.3. Location Group . . . . . . . . . . . . . . . . . . . . . 13		4.3. Location Group . . . . . . . . . . . . . . . . . . . . . 13
	5. Information Model for Threat Prevention . . . . . . . . . . . 14		5. Information Model for Threat Prevention . . . . . . . . . . . 14
	5.1. Threat Feed . . . . . . . . . . . . . . . . . . . . . . . 14		5.1. Threat Feed . . . . . . . . . . . . . . . . . . . . . . . 14
	5.2. Payload Content . . . . . . . . . . . . . . . . . . . . . 15		5.2. Payload Content . . . . . . . . . . . . . . . . . . . . . 15
	6. Network Configuration Access Control Model (NACM) for I2NSF		6. Network Configuration Access Control Model (NACM) for I2NSF
	Consumer-Facing Interface . . . . . . . . . . . . . . . . . . 16		Consumer-Facing Interface . . . . . . . . . . . . . . . . . . 16
	7. YANG Data Model of Consumer-Facing Interface . . . . . . . . 18		7. YANG Data Model of Consumer-Facing Interface . . . . . . . . 18
	7.1. YANG Module of Consumer-Facing Interface . . . . . . . . 18		7.1. YANG Module of Consumer-Facing Interface . . . . . . . . 18
	8. XML Configuration Examples of High-Level Security Policy		8. XML Configuration Examples of High-Level Security Policy
	Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42		Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
	8.1. Database Registration: Information of Positions and		8.1. Database Registration: Information of Positions and
	Devices (Endpoint Group) . . . . . . . . . . . . . . . . 42		Devices (Endpoint Group) . . . . . . . . . . . . . . . . 41
	8.2. Scenario 1: Block SNS Access during Business Hours . . . 44		8.2. Scenario 1: Block SNS Access during Business Hours . . . 43
	8.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to		8.3. Scenario 2: Block Malicious VoIP/VoLTE Packets Coming to
	a Company . . . . . . . . . . . . . . . . . . . . . . . . 46		a Company . . . . . . . . . . . . . . . . . . . . . . . . 45
	8.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a		8.4. Scenario 3: Mitigate HTTP and HTTPS Flood Attacks on a
	Company Web Server . . . . . . . . . . . . . . . . . . . 48		Company Web Server . . . . . . . . . . . . . . . . . . . 47
	9. XML Configuration Example of a User Group's Access Control		9. XML Configuration Example of a User Group's Access Control
	for I2NSF Consumer-Facing Interface . . . . . . . . . . . . . 49		for I2NSF Consumer-Facing Interface . . . . . . . . . . . . . 48
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 51		11. Security Considerations . . . . . . . . . . . . . . . . . . . 50
	12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51		12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50
	13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52		13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 54		14. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
	14.1. Normative References . . . . . . . . . . . . . . . . . . 54		14.1. Normative References . . . . . . . . . . . . . . . . . . 53
	14.2. Informative References . . . . . . . . . . . . . . . . . 56		14.2. Informative References . . . . . . . . . . . . . . . . . 55
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56
	1. Introduction		1. Introduction
	In a framework of Interface to Network Security Functions (I2NSF)		In a framework of Interface to Network Security Functions (I2NSF)
	[RFC8329], each vendor can register their NSFs using a Developer's		[RFC8329], each vendor can register their NSFs using a Developer's
	Management System (DMS). Assuming that vendors also provide the		Management System (DMS). Assuming that vendors also provide the
	front-end web applications registered with an I2NSF User, the		front-end web applications registered with an I2NSF User, the
	Consumer-Facing Interface is required because the web applications		Consumer-Facing Interface is required because the web applications
	developed by each vendor need to have a standard interface specifying		developed by each vendor need to have a standard interface specifying
	the data types used when the I2NSF User and Security Controller		the data types used when the I2NSF User and Security Controller
	skipping to change at page 5, line 10 ¶		skipping to change at page 5, line 10 ¶
	in the NFV system. By the efficient virtualization technology, these		in the NFV system. By the efficient virtualization technology, these
	VNFs might be automatically provisioned and dynamically migrated		VNFs might be automatically provisioned and dynamically migrated
	based on real-time security requirements. This document presents a		based on real-time security requirements. This document presents a
	YANG data model to implement security functions based on NFV.		YANG data model to implement security functions based on NFV.
	2. Terminology		2. Terminology
	This document uses the terminology described in [RFC8329].		This document uses the terminology described in [RFC8329].
	This document follows the guidelines of [RFC8407], uses the common		This document follows the guidelines of [RFC8407], uses the common
	YANG types defined in [I-D.ietf-netmod-rfc6991-bis], and adopts the		YANG types defined in [RFC6991], and adopts the Network Management
	Network Management Datastore Architecture (NMDA). The meaning of the		Datastore Architecture (NMDA). The meaning of the symbols in tree
	symbols in tree diagrams is defined in [RFC8340].		diagrams is defined in [RFC8340].
	3. Information Model for Policy		3. Information Model for Policy
	A Policy object represents a mechanism to express a Security Policy		A Policy object represents a mechanism to express a Security Policy
	by Security Administrator (i.e., I2NSF User) using Consumer-Facing		by Security Administrator (i.e., I2NSF User) using Consumer-Facing
	Interface toward Security Controller; the policy would be enforced on		Interface toward Security Controller; the policy would be enforced on
	an NSF. Figure 2 shows the YANG tree of the Policy object. The		an NSF. Figure 2 shows the YANG tree of the Policy object. The
	Policy object SHALL have the following information:		Policy object SHALL have the following information:
	Name: This field identifies the name of this object.		Name: This field identifies the name of this object.
	skipping to change at page 18, line 32 ¶		skipping to change at page 18, line 32 ¶
	policies as well as the implementation approach.		policies as well as the implementation approach.
	With the YANG data model of I2NSF Consumer-Facing Interface, this		With the YANG data model of I2NSF Consumer-Facing Interface, this
	document suggests use cases for security policy rules such as time-		document suggests use cases for security policy rules such as time-
	based firewall, VoIP/VoLTE security service, and DDoS-attack		based firewall, VoIP/VoLTE security service, and DDoS-attack
	mitigation in Section 8.		mitigation in Section 8.
	7.1. YANG Module of Consumer-Facing Interface		7.1. YANG Module of Consumer-Facing Interface
	This section describes a YANG module of Consumer-Facing Interface.		This section describes a YANG module of Consumer-Facing Interface.
	This YANG module imports from [I-D.ietf-netmod-rfc6991-bis]. It		This YANG module imports from [RFC6991]. It makes references to [RFC
	makes references to [RFC0854][RFC0913][RFC0959][RFC1081][RFC1631][RFC		0854][RFC0913][RFC0959][RFC1081][RFC1631][RFC2616][RFC2818][RFC4250][
	2616][RFC2818][RFC4250][RFC5321].		RFC5321].
	<CODE BEGINS> file "ietf-i2nsf-cfi-policy@2020-09-06.yang"		<CODE BEGINS> file "ietf-i2nsf-cfi-policy@2020-09-08.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 nsfcfi;		prefix nsfcfi;
	import ietf-inet-types{		import ietf-inet-types{
	prefix inet;		prefix inet;
	}		}
	skipping to change at page 19, line 40 ¶		skipping to change at page 19, line 40 ¶
	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.";
	// RFC Ed.: replace XXXX with an actual RFC number and remove		// RFC Ed.: replace XXXX with an actual RFC number and remove
	// this note.		// this note.
	revision "2020-09-06"{		revision "2020-09-08"{
	description "Initial revision.";		description "Initial revision.";
	reference		reference
	"RFC XXXX: I2NSF Consumer-Facing Interface YANG Data Model";		"RFC XXXX: I2NSF Consumer-Facing Interface YANG Data Model";
	// RFC Ed.: replace XXXX with an actual RFC number and remove		// RFC Ed.: replace XXXX with an actual RFC number and remove
	// this note.		// this note.
	}		}
	identity malware-file-type {		identity malware-file-type {
	description		description
	skipping to change at page 27, line 39 ¶		skipping to change at page 27, line 39 ¶
	* Typedefs		* Typedefs
	*/		*/
	typedef time {		typedef time {
	type string {		type string {
	pattern '(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.\d+)?'		pattern '(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.\d+)?'
	+ '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?';		+ '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?';
	}		}
	description		description
	"The time type represents an instance of time of zero-duration		"The time type represents an instance of time of zero-duration
	that recurs every day.";		that recurs every day.";
	reference
	"RFC 6991-bis: Common YANG Data Types - typedef time is used.";
	// RFC Ed.: When RFC 6991-bis becomes an RFC, remove 'typedef time'
	// this note.
	}		}
	/*		/*
	* Groupings		* Groupings
	*/		*/
	grouping ipv4-list {		grouping ipv4-list {
	description		description
	"Grouping for an IPv4 address list.";		"Grouping for an IPv4 address list.";
	leaf-list ipv4 {		leaf-list ipv4 {
	skipping to change at page 34, line 47 ¶		skipping to change at page 34, line 42 ¶
	}		}
	container period{		container period{
	when		when
	"../../frequency!='only-once'";		"../../frequency!='only-once'";
	description		description
	"This represents the repetition time. In the case where		"This represents the repetition time. In the case where
	the frequency is weekly, the days can be set.";		the frequency is weekly, the days can be set.";
	leaf start-time {		leaf start-time {
	type time;		type time;
	// RFC Ed.: When RFC 6991-bis becomes an RFC, time must
	// be replaced with yang:time.
	// this note.
	description		description
	"This is a period's start time for an event.";		"This is a period's start time for an event.";
	reference
	"RFC 6991-bis: Common YANG Data Types - The time type
	represents an instance of time of zero-duration that
	recurs every day.";
	// RFC Ed.: Replace 6991-bis with an actual RFC number
	// and remove this note.
	}		}
	leaf end-time {		leaf end-time {
	type time;		type time;
	// RFC Ed.: When RFC 6991-bis becomes an RFC, time must
	// be replaced with yang:time.
	// this note.
	description		description
	"This is a period's end time for an event.";		"This is a period's end time for an event.";
	reference
	"RFC 6991-bis: Common YANG Data Types - The time type
	represents an instance of time of zero-duration that
	recurs every day.";
	// RFC Ed.: Replace 6991-bis with an actual RFC number
	// and remove this note.
	}		}
	leaf-list day {		leaf-list day {
	when		when
	"../../../frequency='weekly'";		"../../../frequency='weekly'";
	type identityref{		type identityref{
	base day;		base day;
	}		}
	min-elements 1;		min-elements 1;
	description		description
	"This represents the repeated day of every week (e.g.,		"This represents the repeated day of every week (e.g.,
	skipping to change at page 54, line 14 ¶		skipping to change at page 53, line 14 ¶
	101 Software Avenue		101 Software Avenue
	Nanjing, Jiangsu 210012		Nanjing, Jiangsu 210012
	China		China
	EMail: Frank.Xialiang@huawei.com		EMail: Frank.Xialiang@huawei.com
	14. References		14. References
	14.1. Normative References		14.1. Normative References
	[I-D.ietf-netmod-rfc6991-bis]
	Schoenwaelder, J., "Common YANG Data Types", draft-ietf-
	netmod-rfc6991-bis-04 (work in progress), July 2020.
	[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol		[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol
	Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May		Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May
	1983, <https://www.rfc-editor.org/info/rfc854>.		1983, <https://www.rfc-editor.org/info/rfc854>.
	[RFC0913] Lottor, M., "Simple File Transfer Protocol", RFC 913,		[RFC0913] Lottor, M., "Simple File Transfer Protocol", RFC 913,
	DOI 10.17487/RFC0913, September 1984,		DOI 10.17487/RFC0913, September 1984,
	<https://www.rfc-editor.org/info/rfc913>.		<https://www.rfc-editor.org/info/rfc913>.
	[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",		[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
	STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985,		STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985,
	skipping to change at page 55, line 47 ¶		skipping to change at page 54, line 43 ¶
	[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for		[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
	the Network Configuration Protocol (NETCONF)", RFC 6020,		the Network Configuration Protocol (NETCONF)", RFC 6020,
	DOI 10.17487/RFC6020, October 2010,		DOI 10.17487/RFC6020, October 2010,
	<https://www.rfc-editor.org/info/rfc6020>.		<https://www.rfc-editor.org/info/rfc6020>.
	[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,		[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
	and A. Bierman, Ed., "Network Configuration Protocol		and A. Bierman, Ed., "Network Configuration Protocol
	(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,		(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
	<https://www.rfc-editor.org/info/rfc6241>.		<https://www.rfc-editor.org/info/rfc6241>.
			[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
			RFC 6991, DOI 10.17487/RFC6991, July 2013,
			<https://www.rfc-editor.org/info/rfc6991>.
	[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",		[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
	RFC 7950, DOI 10.17487/RFC7950, August 2016,		RFC 7950, DOI 10.17487/RFC7950, August 2016,
	<https://www.rfc-editor.org/info/rfc7950>.		<https://www.rfc-editor.org/info/rfc7950>.
	[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF		[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
	Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,		Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
	<https://www.rfc-editor.org/info/rfc8040>.		<https://www.rfc-editor.org/info/rfc8040>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
End of changes. 20 change blocks.
	58 lines changed or deleted		30 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/