draft-ietf-i2nsf-terminology-01.txt		draft-ietf-i2nsf-terminology-02.txt
	I2NSF S. Hares		I2NSF S. Hares
	Internet-Draft J. Strassner		Internet-Draft J. Strassner
	Intended status: Informational Huawei		Intended status: Informational Huawei
	Expires: January 29, 2017 D. Lopez		Expires: April 25, 2017 D. Lopez
	Telefonica I+D		Telefonica I+D
	L. Xia		L. Xia
	Huawei		Huawei
	July 8, 2016		H. Birkholz
			Fraunhofer SIT
			October 23, 2016
	Interface to Network Security Functions (I2NSF) Terminology		Interface to Network Security Functions (I2NSF) Terminology
	draft-ietf-i2nsf-terminology-01.txt		draft-ietf-i2nsf-terminology-02.txt
	Abstract		Abstract
	This document defines a set of terms that are used for the Interface		This document defines a set of terms that are used for the Interface
	to Network Security Functions (I2NSF) effort.		to Network Security Functions (I2NSF) effort.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 38 ¶
	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		working documents as Internet-Drafts. The list of current
	Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.		Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other		months and may be updated, replaced, or obsoleted by other
	documents at any time. It is inappropriate to use Internet-Drafts		documents at any time. It is inappropriate to use Internet-Drafts
	as reference material or to cite them other than as "work in		as reference material or to cite them other than as "work in
	progress."		progress."
	This Internet-Draft will expire on January 29, 2017.		This Internet-Draft will expire on April 25, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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 3, line 35 ¶		skipping to change at page 3, line 35 ¶
	Access Control: Protection of system resources against unauthorized		Access Control: Protection of system resources against unauthorized
	access; a process by which use of system resources is regulated		access; a process by which use of system resources is regulated
	according to a security policy, and is permitted by only		according to a security policy, and is permitted by only
	authorized entities (users, programs, processes, or other systems)		authorized entities (users, programs, processes, or other systems)
	according to that policy [RFC4949].		according to that policy [RFC4949].
	Accounting: The act of collecting information on resource usage for		Accounting: The act of collecting information on resource usage for
	the purpose of trend analysis, auditing, billing, or cost		the purpose of trend analysis, auditing, billing, or cost
	allocation ([RFC2975] [RFC3539]).		allocation ([RFC2975] [RFC3539]).
	ACL (Acess Control List): This is a mechanism that implements		ACL (Access Control List): This is a mechanism that implements
	access control for a system resource by enumerating the system		access control for a system resource by enumerating the system
	entities that are permitted to access the resource and stating,		entities that are permitted to access the resource and stating,
	either implicitly or explicitly, the access modes granted to each		either implicitly or explicitly, the access modes granted to each
	entity [RFC4949]. A YANG description is defined in		entity [RFC4949]. A YANG description is defined in
	[I-D.ietf-netmod-acl-model].		[I-D.ietf-netmod-acl-model].
	Action: Defines what is to be done when a set of Conditions are		Action: Defines what is to be done when a set of Conditions are
	met (See I2NSF Action). (from		met (See I2NSF Action). (from
	[I-D.ietf-supa-generic-policy-info-model]).		[I-D.ietf-supa-generic-policy-info-model]).
	skipping to change at page 4, line 32 ¶		skipping to change at page 4, line 32 ¶
	or FALSE. Also called Boolean Expression.		or FALSE. Also called Boolean Expression.
	Capability: Defines a set of features that are available from a		Capability: Defines a set of features that are available from a
	managed entity (see also I2NSF Capability). Examples of "managed		managed entity (see also I2NSF Capability). Examples of "managed
	entities" are NSFs and Controllers, where NSF Capabilities and		entities" are NSFs and Controllers, where NSF Capabilities and
	Controller Capabilities define functionality of an NSF and about		Controller Capabilities define functionality of an NSF and about
	Controller, respectively. These functions may, but do not have		Controller, respectively. These functions may, but do not have
	to, be used. All Capabilities are announced through the		to, be used. All Capabilities are announced through the
	Registration Interface.		Registration Interface.
	Capability Interface: An interface dedicated to requesting,
	receiving, editing, and deleting capability information.
	Client: See Consumer. [Editor's note: placeholder for gradually		Client: See Consumer. [Editor's note: placeholder for gradually
	replacing Client with Consumer, since Client is too vague and		replacing Client with Consumer, since Client is too vague and
	has other connotations (e.g., client-server)].		has other connotations (e.g., client-server)].
	Client-Facing Interface: See Consumer-Facing Interface.		Client-Facing Interface: See Consumer-Facing Interface.
	See also: Interface, NSF-Facing Interface.		See also: Interface, NSF-Facing Interface.
	Component: An encapsulation of software that communicates using		Component: An encapsulation of software that communicates using
	Interfaces. A Component may be implemented by hardware and/or		Interfaces. A Component may be implemented by hardware and/or
	software, and be represented using a set of classes. In general,		software, and be represented using a set of classes. In general,
	a Component encapsulates a set of data structures and a set of		a Component encapsulates a set of data structures and a set of
	algorithms that implement the function(s) that it provides.		algorithms that implement the function(s) that it provides.
	Consumer: A Consumer is a Role that is assigned to an I2NSF		Consumer: A Consumer is a Role that is assigned to an I2NSF
	Component that can receive information from another I2NSF		Component that represents the needs of a user of I2NSF services.
	Component. See also: Provider, Role.		A consumer can send/receive information to/from another I2NSF
			Component (e.g., for defining and monitoring security policies
			for the Consumer's specific flows through an I2NSF
			administrative domain). See also: Producer, Role.
	Consumer-Facing Interface: An Interface dedicated to communication		Consumer-Facing Interface: An Interface dedicated to communication
	with Consumers of NSF data and Services. This is typically		with Consumers of NSF Data and Services. This is typically
	defined per I2NSF administrative domain. See also: Interface,		defined per I2NSF administrative domain. See also: Interface,
	NSF-Facing Interface.		NSF-Facing Interface.
	Condition: A set of attributes, features, and/or values that are to		Condition: A set of attributes, features, and/or values that are to
	be compared with a set of known attributes, features, and/or		be compared with a set of known attributes, features, and/or
	values in order to make a decision. A Condition, when used in the		values in order to make a decision. A Condition, when used in the
	context of a Policy Rule, is used to determine whether or not the		context of a Policy Rule, is used to determine whether or not the
	set of Actions in that Policy Rule can be executed or not.		set of Actions in that Policy Rule can be executed or not.
	Examples of an I2NSF Condition include matching attributes of a		Examples of an I2NSF Condition include matching attributes of a
	packet or flow, and comparing the internal state of a NSF to a		packet or flow, and comparing the internal state of a NSF to a
	skipping to change at page 6, line 39 ¶		skipping to change at page 6, line 39 ¶
	ECA: Event - Condition - Action (a type of Policy Rule).		ECA: Event - Condition - Action (a type of Policy Rule).
	Firewall (FW): A function that restricts data communication traffic		Firewall (FW): A function that restricts data communication traffic
	to and from one of the connected networks (the one said to be		to and from one of the connected networks (the one said to be
	'inside' the firewall), and thus protects that network's system		'inside' the firewall), and thus protects that network's system
	resources against threats from the other network (the one that		resources against threats from the other network (the one that
	is said to be 'outside' the firewall) [RFC4949].		is said to be 'outside' the firewall) [RFC4949].
	[I-D.ietf-opsawg-firewalls]		[I-D.ietf-opsawg-firewalls]
	Flow-based NSF: A NSF that inspects network flows according to a		Flow: A set of information (e.g., packets) that are related in a
			fundamental manner (e.g., sent from the same source and sent to
			the same destination). A common example is a sequence of packets.
			It is the opposite of packet-based, which treats each packet
			discretely (e.g., each packet is assessed individually to
			determine the action(s) to be taken).
			Flow-based NSF: A NSF that inspects network flows according to a
	set of policies intended for enforcing security properties. Flow-		set of policies intended for enforcing security properties. Flow-
	based security also means that packets are inspected in the order		based security also means that packets are inspected in the order
	they are received, and without modification to the packet due to		they are received, and without modification to the packet due to
	the inspection process.		the inspection process.
			I2NSF Agent: A software Component in a device that implements an
			NSF. It receives provisioning information and requests for
			operational data (e.g., monitoring data) from an I2NSF Consumer.
			It is also responsible for enforcing the policies that it
			receives from an I2NSF Consumer.
	I2NSF Action: An I2NSF Action is a special type of Action that is		I2NSF Action: An I2NSF Action is a special type of Action that is
	used to control and monitor aspects of flow-based Network Security		used to control and monitor aspects of flow-based Network Security
	Functions. Examples of I2NSF Actions include providing intrusion		Functions. Examples of I2NSF Actions include providing intrusion
	detection and/or protection, web and flow filtering, and deep		detection and/or protection, web and flow filtering, and deep
	packet inspection for packets and flows. An I2NSF Action, when		packet inspection for packets and flows. An I2NSF Action, when
	used in the context of a I2NSF Policy Rule, may be executed when		used in the context of a I2NSF Policy Rule, may be executed when
	both the Event and the Condition clauses of its owning I2NSF		both the Event and the Condition clauses of its owning I2NSF
	Policy Rule evaluate to true. The execution of this Action may be		Policy Rule evaluate to true. The execution of this Action may be
	influenced by applicable metadata. (from		influenced by applicable metadata. (from
	[I-D.ietf-supa-generic-policy-info-model]).		[I-D.ietf-supa-generic-policy-info-model]).
	I2NSF Agent: A software Component in a device that implements an
	NSF. It receives provisioning information and requests for
	operational data (e.g., monitoring data) from an I2NSF Consumer.
	It is also responsible for enforcing the policies that it
	receives from an I2NSF Consumer.
	I2NSF Capability: A set of features that are available from an NSF		I2NSF Capability: A set of features that are available from an NSF
	Server or an NSF Controller. While both are Capabilities, the		Server or an NSF Controller. While both are Capabilities, the
	former defines functions that are available from an NSF, whereas		former defines functions that are available from an NSF, whereas
	the latter defines functions that are available from a security		the latter defines functions that are available from a security
	Controller or other Management Entity. This definition is based		Controller or other Management Entity. This definition is based
	on that in [I-D.ietf-sacm-terminology].		on that in [I-D.ietf-sacm-terminology].
	I2NSF Client: See I2NSF Consumer.		I2NSF Client: See I2NSF Consumer.
	I2NSF Component: A Component that provides one or more I2NSF		I2NSF Component: A Component that provides one or more I2NSF
	skipping to change at page 8, line 40 ¶		skipping to change at page 8, line 52 ¶
	and protocol [I-D.ietf-supa-generic-policy-info-model].		and protocol [I-D.ietf-supa-generic-policy-info-model].
	Interface: A set of operations one object knows it can invoke on,		Interface: A set of operations one object knows it can invoke on,
	and expose to, another object. It is a subset of all operations		and expose to, another object. It is a subset of all operations
	that a given object implements. The same object may have multiple		that a given object implements. The same object may have multiple
	types of interfaces to serve different purposes. An example of		types of interfaces to serve different purposes. An example of
	multiple interfaces can be seen by considering the interfaces		multiple interfaces can be seen by considering the interfaces
	include a firewall uses; these include:		include a firewall uses; these include:
	* multiple interfaces for data packets to traverse through,		* multiple interfaces for data packets to traverse through,
	* an interface for a controller to impose policy,or retrieve		* an interface for a controller to impose policy, or retrieve
	the results of execution of a policy rule.		the results of execution of a policy rule.
	See also: Consumer Interface, I2NSF Interface, Provider Interface		See also: Consumer Interface, I2NSF Interface, Provider Interface
			Interface Group: A set of Interfaces that are related in purpose and
			which share the same communication mechanisms.
	Intrusion Detection System (IDS): A system that detects network		Intrusion Detection System (IDS): A system that detects network
	intrusions via a variety of filters, monitors, and/or probes. An		intrusions via a variety of filters, monitors, and/or probes. An
	IDS may be stateful or stateless.		IDS may be stateful or stateless.
	Intrusion Protection System (IPS): A system that protects against		Intrusion Protection System (IPS): A system that protects against
	network intrusions. An IPS may be stateful or stateless.		network intrusions. An IPS may be stateful or stateless.
	Management Plane: In the context of I2NSF, the Management Plane is		Management Plane: In the context of I2NSF, the Management Plane is
	an architectural Component that provides common functions to		an architectural Component that provides common functions to
	define the behavior of I2NSF Components. The primary use of the		define the behavior of I2NSF Components. The primary use of the
	skipping to change at page 11, line 17 ¶		skipping to change at page 11, line 25 ¶
	The following people contributed to creating this document, and are		The following people contributed to creating this document, and are
	listed in alphabetical order:		listed in alphabetical order:
	Henk Birkholz		Henk Birkholz
	6. References		6. References
	6.1. Informative References		6.1. Informative References
	[I-D.ietf-i2nsf-gap-analysis]		[I-D.ietf-i2nsf-gap-analysis]
	Hares, S., Moskowitz, R., and D. Zhang, "Analysis of		Hares, S., Moskowitz, R., and Zhang, D., "Analysis of
	Existing work for I2NSF", draft-ietf-i2nsf-gap-analysis-01		Existing work for I2NSF", draft-ietf-i2nsf-gap-analysis-02
	(work in progress), April 2016.		(work in progress), July 2016.
	[I-D.ietf-i2nsf-problem-and-use-cases]		[I-D.ietf-i2nsf-problem-and-use-cases]
	Hares, S., Dunbar, L., Lopez, D., Zarny, M., and C.		Hares, S., Dunbar, L., Lopez, D., Zarny, M., and C.
	Jacquenet, "I2NSF Problem Statement and Use cases", draft-		Jacquenet, "I2NSF Problem Statement and Use cases", draft-
	ietf-i2nsf-problem-and-use-cases-01 (work in progress),		ietf-i2nsf-problem-and-use-cases-02 (work in progress),
	July 2016.		October 2016.
	[I-D.ietf-netmod-acl-model]		[I-D.ietf-netmod-acl-model]
	Bogdanovic, D., Sreenivasa, K., Huang, L., Blair, D.,		Bogdanovic, D., Sreenivasa, K., Huang, L., Blair, D.,
	"Network Access Control List (ACL) YANG Data Model",		"Network Access Control List (ACL) YANG Data Model",
	draft-ietf-netmod-acl-model-08 (work in progress),		draft-ietf-netmod-acl-model-09 (work in progress),
	July 2016.		October 2016.
	[I-D.ietf-opsawg-firewalls]		[I-D.ietf-opsawg-firewalls]
	Baker, F. and P. Hoffman, "On Firewalls in Internet		Baker, F. and P. Hoffman, "On Firewalls in Internet
	Security", draft-ietf-opsawg-firewalls-01 (work in		Security", draft-ietf-opsawg-firewalls-01 (work in
	progress), October 2012.		progress), October 2012.
	[I-D.ietf-sacm-terminology]		[I-D.ietf-sacm-terminology]
	Birkholz, H., Lu, J., Cam-Wignet, N., "Secure Automation		Birkholz, H., Lu, J., Strassner, J., Cam-Wignet, N.,
	and Continuous Monitoring (SACM) Terminology",		"Secure Automation and Continuous Monitoring (SACM)
	draft-ietf-sacm-terminology-09, March 2016		Terminology", draft-ietf-sacm-terminology-11,
			September 2016
	[I-D.ietf-supa-generic-policy-info-model]		[I-D.ietf-supa-generic-policy-info-model]
	Strassner, J., Halpern, J., and J. Coleman, "Generic		Strassner, J., Halpern, J., and J. Coleman, "Generic
	Policy Information Model for Simplified Use of Policy		Policy Information Model for Simplified Use of Policy
	Abstractions (SUPA)", draft-ietf-supa-generic-policy-		Abstractions (SUPA)", draft-ietf-supa-generic-policy-
	info-model-00 (work in progress), June 2016.		info-model-01 (work in progress), July 2016.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to		[RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to
	Accounting Management", RFC 2975, DOI 10.17487/RFC2975,		Accounting Management", RFC 2975, DOI 10.17487/RFC2975,
	October 2000, <http://www.rfc-editor.org/info/rfc2975>.		October 2000, <http://www.rfc-editor.org/info/rfc2975>.
	[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and		[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
	Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002,		Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002,
	skipping to change at page 12, line 19 ¶		skipping to change at page 12, line 32 ¶
	[RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and		[RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and
	Accounting (AAA) Transport Profile", RFC 3539,		Accounting (AAA) Transport Profile", RFC 3539,
	DOI 10.17487/RFC3539, June 2003,		DOI 10.17487/RFC3539, June 2003,
	<http://www.rfc-editor.org/info/rfc3539>.		<http://www.rfc-editor.org/info/rfc3539>.
	[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",		[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
	FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,		FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
	<http://www.rfc-editor.org/info/rfc4949>.		<http://www.rfc-editor.org/info/rfc4949>.
	[X.1252] ITU-T, "Baseline identity management terms and		[X.1252] ITU-T, "Baseline identity management terms and
	definitions", Recommendation ITU-T X.1252, April 2010		definitions", Recommendation ITU-T X.1252, April 2510
	Authors' Addresses		Authors' Addresses
	Susan Hares		Susan Hares
	Huawei		Huawei
	7453 Hickory Hill		7453 Hickory Hill
	Saline, MI 48176		Saline, MI USA 48176
	USA
	Phone: +1-734-604-0332		Phone: +1-734-604-0332
	Email: shares@ndzh.com		Email: shares@ndzh.com
	John Strassner		John Strassner
	Huawei Technologies		Huawei Technologies
	Santa Clara, CA		Santa Clara, CA USA 95050
	USA
	Email: john.sc.strassner@huawei.com		Email: john.sc.strassner@huawei.com
	Diego R. Lopez		Diego R. Lopez
	Telefonica I+D		Telefonica I+D
	Don Ramon de la Cruz, 82		Don Ramon de la Cruz, 82
	Madrid 28006		Madrid 28006
	Spain		Spain
	Email: diego.r.lopez@telefonica.com		Email: diego.r.lopez@telefonica.com
	Liang Xia (Frank)		Liang Xia (Frank)
	Huawei		Huawei
	101 Software Avenue, Yuhuatai District		101 Software Avenue, Yuhuatai District
	Nanjing , Jiangsu 210012		Nanjing , Jiangsu 210012
	China		China
	Email: Frank.Xialiang@huawei.com		Email: Frank.Xialiang@huawei.com
			Henk Birkholz
			Fraunhofer SIT
			Rheinstrasse 75
			Darmstadt 64295
			Germany
			Email: henk.birkholz@sit.fraunhofer.de
End of changes. 23 change blocks.
	36 lines changed or deleted		46 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/