draft-ietf-i2nsf-applicability-05.txt		draft-ietf-i2nsf-applicability-06.txt
	I2NSF Working Group J. Jeong		I2NSF Working Group J. Jeong
	Internet-Draft Sungkyunkwan University		Internet-Draft Sungkyunkwan University
	Intended status: Informational S. Hyun		Intended status: Informational S. Hyun
	Expires: March 15, 2019 Chosun University		Expires: April 25, 2019 Chosun University
	T. Ahn		T. Ahn
	Korea Telecom		Korea Telecom
	S. Hares		S. Hares
	Huawei		Huawei
	D. Lopez		D. Lopez
	Telefonica I+D		Telefonica I+D
	September 11, 2018		October 22, 2018
	Applicability of Interfaces to Network Security Functions to Network-		Applicability of Interfaces to Network Security Functions to Network-
	Based Security Services		Based Security Services
	draft-ietf-i2nsf-applicability-05		draft-ietf-i2nsf-applicability-06
	Abstract		Abstract
	This document describes the applicability of Interface to Network		This document describes the applicability of Interface to Network
	Security Functions (I2NSF) to network-based security services in		Security Functions (I2NSF) to network-based security services in
	Network Functions Virtualization (NFV) environments, such as		Network Functions Virtualization (NFV) environments, such as
	firewall, deep packet inspection, or attack mitigation engines.		firewall, deep packet inspection, or attack mitigation engines.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 15, 2019.		This Internet-Draft will expire on April 25, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. I2NSF Framework . . . . . . . . . . . . . . . . . . . . . . . 3		3. I2NSF Framework . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Time-dependent Web Access Control Service . . . . . . . . . . 5		4. Time-dependent Web Access Control Service . . . . . . . . . . 5
	5. I2NSF Framework with SFC . . . . . . . . . . . . . . . . . . 6		5. I2NSF Framework with SFC . . . . . . . . . . . . . . . . . . 7
	6. I2NSF Framework with SDN . . . . . . . . . . . . . . . . . . 9		6. I2NSF Framework with SDN . . . . . . . . . . . . . . . . . . 8
	6.1. Firewall: Centralized Firewall System . . . . . . . . . . 11		6.1. Firewall: Centralized Firewall System . . . . . . . . . . 11
	6.2. Deep Packet Inspection: Centralized VoIP/VoLTE Security		6.2. Deep Packet Inspection: Centralized VoIP/VoLTE Security
	System . . . . . . . . . . . . . . . . . . . . . . . . . 12		System . . . . . . . . . . . . . . . . . . . . . . . . . 12
	6.3. Attack Mitigation: Centralized DDoS-attack Mitigation		6.3. Attack Mitigation: Centralized DDoS-attack Mitigation
	System . . . . . . . . . . . . . . . . . . . . . . . . . 14		System . . . . . . . . . . . . . . . . . . . . . . . . . 14
	7. I2NSF Framework with NFV . . . . . . . . . . . . . . . . . . 16		7. I2NSF Framework with NFV . . . . . . . . . . . . . . . . . . 16
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 18		8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
	10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18		10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18
	11. Informative References . . . . . . . . . . . . . . . . . . . 19		11. Informative References . . . . . . . . . . . . . . . . . . . 19
	Appendix A. Changes from draft-ietf-i2nsf-applicability-04 . . . 22		Appendix A. Changes from draft-ietf-i2nsf-applicability-05 . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
	1. Introduction		1. Introduction
	Interface to Network Security Functions (I2NSF) defines a framework		Interface to Network Security Functions (I2NSF) defines a framework
	and interfaces for interacting with Network Security Functions		and interfaces for interacting with Network Security Functions
	(NSFs). The I2NSF framework allows heterogeneous NSFs developed by		(NSFs). The I2NSF framework allows heterogeneous NSFs developed by
	different security solution vendors to be used in the Network		different security solution vendors to be used in the Network
	Functions Virtualization (NFV) environment [ETSI-NFV] by utilizing		Functions Virtualization (NFV) environment [ETSI-NFV] by utilizing
	the capabilities of such products and the virtualization of security		the capabilities of such products and the virtualization of security
	skipping to change at page 3, line 46 ¶		skipping to change at page 4, line 5 ¶
	efficient firewall management.		efficient firewall management.
	o Centralized VoIP Security System: A centralized security system		o Centralized VoIP Security System: A centralized security system
	that handles the security functions required for VoIP and VoLTE		that handles the security functions required for VoIP and VoLTE
	services.		services.
	o Centralized DDoS-attack Mitigation System: A centralized mitigator		o Centralized DDoS-attack Mitigation System: A centralized mitigator
	that can establish and distribute access control policy rules into		that can establish and distribute access control policy rules into
	network resources for efficient DDoS-attack mitigation.		network resources for efficient DDoS-attack mitigation.
			+------------+
			| I2NSF User |
			+------------+
			^
			| Consumer-Facing Interface
			v
			+-------------------+ Registration +-----------------------+
			|Security Controller|<-------------------->|Developer's Mgmt System|
			+-------------------+ Interface +-----------------------+
			^
			| NSF-Facing Interface
			v
			+----------------+ +---------------+ +-----------------------+
			| NSF-1 |-| NSF-2 |...| NSF-n |
			| (Firewall) | | (Web Filter) | |(DDoS-Attack Mitigator)|
			+----------------+ +---------------+ +-----------------------+
			Figure 1: I2NSF Framework
	3. I2NSF Framework		3. I2NSF Framework
	This section summarizes the I2NSF framework as defined in [RFC8329].		This section summarizes the I2NSF framework as defined in [RFC8329].
	As shown in Figure 1, an I2NSF User can use security functions by		As shown in Figure 1, an I2NSF User can use security functions by
	delivering high-level security policies, which specify security		delivering high-level security policies, which specify security
	requirements that the I2NSF user wants to enforce, to the Security		requirements that the I2NSF user wants to enforce, to the Security
	Controller via the Consumer-Facing Interface		Controller via the Consumer-Facing Interface
	[consumer-facing-inf-im][consumer-facing-inf-dm].		[consumer-facing-inf-im][consumer-facing-inf-dm].
	The Security Controller receives and analyzes the high-level security		The Security Controller receives and analyzes the high-level security
	skipping to change at page 4, line 27 ¶		skipping to change at page 5, line 4 ¶
	The Security Controller requests NSFs to perform low-level security		The Security Controller requests NSFs to perform low-level security
	services via the NSF-Facing Interface. The developers (or vendors)		services via the NSF-Facing Interface. The developers (or vendors)
	inform the Security Controller of the capabilities of the NSFs		inform the Security Controller of the capabilities of the NSFs
	through the I2NSF Registration Interface [registration-inf-dm] for		through the I2NSF Registration Interface [registration-inf-dm] for
	registering (or deregistering) the corresponding NSFs.		registering (or deregistering) the corresponding NSFs.
	The Consumer-Facing Interface between an I2NSF User and the Security		The Consumer-Facing Interface between an I2NSF User and the Security
	Controller can be implemented using, for example, RESTCONF [RFC8040].		Controller can be implemented using, for example, RESTCONF [RFC8040].
	Data models specified by YANG [RFC6020] describe high-level security		Data models specified by YANG [RFC6020] describe high-level security
	policies to be specified by an I2NSF User. The data model defined in		policies to be specified by an I2NSF User. The data model defined in
	[consumer-facing-inf-dm] can be used for the I2NSF Consumer-Facing		[consumer-facing-inf-dm] can be used for the I2NSF Consumer-Facing
	Interface.		Interface.
	+------------+
	| I2NSF User |
	+------------+
	^
	| Consumer-Facing Interface
	v
	+-------------------+ Registration +-----------------------+
	|Security Controller|<-------------------->|Developer's Mgmt System|
	+-------------------+ Interface +-----------------------+
	^
	| NSF-Facing Interface
	v
	+----------------+ +---------------+ +-----------------------+
	| NSF-1 |-| NSF-2 |...| NSF-n |
	| (Firewall) | | (Web Filter) | |(DDoS-Attack Mitigator)|
	+----------------+ +---------------+ +-----------------------+
	Figure 1: I2NSF Framework
	The NSF-Facing Interface between the Security Controller and NSFs can		The NSF-Facing Interface between the Security Controller and NSFs can
	be implemented using NETCONF [RFC6241]. YANG data models describe		be implemented using NETCONF [RFC6241]. YANG data models describe
	low-level security policies for the sake of NSFs, which are		low-level security policies for the sake of NSFs, which are
	translated from the high-level security policies by the Security		translated from the high-level security policies by the Security
	Controller. The data model defined in [nsf-facing-inf-dm] can be		Controller. The data model defined in [nsf-facing-inf-dm] can be
	used for the I2NSF NSF-Facing Interface.		used for the I2NSF NSF-Facing Interface.
	The Registration Interface between the Security Controller and the		The Registration Interface between the Security Controller and the
	Developer's Management System can be implemented by RESTCONF		Developer's Management System can be implemented by RESTCONF
	[RFC8040]. The data model defined in [registration-inf-dm] can be		[RFC8040]. The data model defined in [registration-inf-dm] can be
	skipping to change at page 6, line 38 ¶		skipping to change at page 7, line 5 ¶
	filter. SFC technology can be utilized to support such packet		filter. SFC technology can be utilized to support such packet
	forwarding in the I2NSF framework [nsf-triggered-steering].		forwarding in the I2NSF framework [nsf-triggered-steering].
	4. The web filter checks the target URL field of the received		4. The web filter checks the target URL field of the received
	packet, and realizes the packet is toward Example.com. The web		packet, and realizes the packet is toward Example.com. The web
	filter then checks that the current time is in business hours.		filter then checks that the current time is in business hours.
	If so, the web filter drops the packet, and consequently the		If so, the web filter drops the packet, and consequently the
	staff member's access to Example.com during business hours is		staff member's access to Example.com during business hours is
	blocked.		blocked.
	5. I2NSF Framework with SFC
	In the I2NSF architecture, an NSF can trigger an advanced security
	action (e.g., DPI or DDoS attack mitigation) on a packet based on the
	result of its own security inspection of the packet. For example, a
	firewall triggers further inspection of a suspicious packet with DPI.
	For this advanced security action to be fulfilled, the suspicious
	packet should be forwarded from the current NSF to the successor NSF.
	SFC [RFC7665] is a technology that enables this advanced security
	action by steering a packet with multiple service functions (e.g.,
	NSFs), and this technology can be utilized by the I2NSF architecture
	to support the advanced security action.
	SFC generally requires classifiers and service function forwarders
	(SFFs); classifiers are responsible for determining which service
	function path (SFP) (i.e., an ordered sequence of service functions)
	a given packet should pass through, according to pre-configured
	classification rules, and SFFs perform forwarding the given packet to
	the next service function (e.g., NSF) on the SFP of the packet by
	referring to their forwarding tables. In the I2NSF architecture with
	SFC, the Security Controller can take responsibilities of generating
	classification rules for classifiers and forwarding tables for SFFs.
	By analyzing high-level security policies from I2NSF users, the
	Security Controller can construct SFPs that are required to meet the
	high-level security policies, generates classification rules of the
	SFPs, and then configures classifiers with the classification rules
	over NSF-Facing Interface so that relevant traffic packets can follow
	the SFPs. Also, based on the global view of NSF instances available
	in the system, the Security Controller constructs forwarding tables,
	which are required for SFFs to forward a given packet to the next NSF
	over the SFP, and configures SFFs with those forwarding tables over
	NSF-Facing Interface.
	+------------+		+------------+
	| I2NSF User |		| I2NSF User |
	+------------+		+------------+
	^		^
	| Consumer-Facing Interface		| Consumer-Facing Interface
	v		v
	+-------------------+ Registration +-----------------------+		+-------------------+ Registration +-----------------------+
	|Security Controller|<-------------------->|Developer's Mgmt System|		|Security Controller|<-------------------->|Developer's Mgmt System|
	+-------------------+ Interface +-----------------------+		+-------------------+ Interface +-----------------------+
	^ ^		^ ^
	| | NSF-Facing Interface		| | NSF-Facing Interface
	| |-------------------------		| |-------------------------
	| |		| |
	| NSF-Facing Interface |		| NSF-Facing Interface |
	+-+-+-v-+-+-+-+-+-+ +------v-------+		+-----v-----------+ +------v-------+
	| +-----------+ | ------>| NSF-1 |		| +-----------+ | ------>| NSF-1 |
	| |Classifier | | | | (Firewall) |		| |Classifier | | | | (Firewall) |
	| +-----------+ | | +--------------+		| +-----------+ | | +--------------+
	| +-----+ |<-----| +--------------+		| +-----+ |<-----| +--------------+
	| | SFF | | |----->| NSF-2 |		| | SFF | | |----->| NSF-2 |
	| +-----+ | | | (DPI) |		| +-----+ | | | (DPI) |
	+-+-+-+-+-+-+-+-+-+ | +--------------+		+-----------------+ | +--------------+
	| .		| .
	| .		| .
	| .		| .
	| +-----------------------+		| +-----------------------+
	------>| NSF-n |		------>| NSF-n |
	|(DDoS-Attack Mitigator)|		|(DDoS-Attack Mitigator)|
	+-----------------------+		+-----------------------+
	Figure 2: An I2NSF Framework with SFC		Figure 2: An I2NSF Framework with SFC
			5. I2NSF Framework with SFC
			In the I2NSF architecture, an NSF can trigger an advanced security
			action (e.g., DPI or DDoS attack mitigation) on a packet based on the
			result of its own security inspection of the packet. For example, a
			firewall triggers further inspection of a suspicious packet with DPI.
			For this advanced security action to be fulfilled, the suspicious
			packet should be forwarded from the current NSF to the successor NSF.
			SFC [RFC7665] is a technology that enables this advanced security
			action by steering a packet with multiple service functions (e.g.,
			NSFs), and this technology can be utilized by the I2NSF architecture
			to support the advanced security action.
			Figure 2 shows an I2NSF framework with the support of SFC. As shown
			in the figure, SFC generally requires classifiers and service
			function forwarders (SFFs); classifiers are responsible for
			determining which service function path (SFP) (i.e., an ordered
			sequence of service functions) a given packet should pass through,
			according to pre-configured classification rules, and SFFs perform
			forwarding the given packet to the next service function (e.g., NSF)
			on the SFP of the packet by referring to their forwarding tables. In
			the I2NSF architecture with SFC, the Security Controller can take
			responsibilities of generating classification rules for classifiers
			and forwarding tables for SFFs. By analyzing high-level security
			policies from I2NSF users, the Security Controller can construct SFPs
			that are required to meet the high-level security policies, generates
			classification rules of the SFPs, and then configures classifiers
			with the classification rules over NSF-Facing Interface so that
			relevant traffic packets can follow the SFPs. Also, based on the
			global view of NSF instances available in the system, the Security
			Controller constructs forwarding tables, which are required for SFFs
			to forward a given packet to the next NSF over the SFP, and
			configures SFFs with those forwarding tables over NSF-Facing
			Interface.
	To trigger an advanced security action in the I2NSF architecture, the		To trigger an advanced security action in the I2NSF architecture, the
	current NSF appends a metadata describing the security capability		current NSF appends a metadata describing the security capability
	required for the advanced action to the suspicious packet and sends		required for the advanced action to the suspicious packet and sends
	the packet to the classifier. Based on the metadata information, the		the packet to the classifier. Based on the metadata information, the
	classifier searches an SFP which includes an NSF with the required		classifier searches an SFP which includes an NSF with the required
	security capability, changes the SFP-related information (e.g.,		security capability, changes the SFP-related information (e.g.,
	service path identifier and service index [RFC8300]) of the packet		service path identifier and service index [RFC8300]) of the packet
	with the new SFP that has been found, and then forwards the packet to		with the new SFP that has been found, and then forwards the packet to
	the SFF. When receiving the packet, the SFF checks the SFP-related		the SFF. When receiving the packet, the SFF checks the SFP-related
	information such as the service path identifier and service index		information such as the service path identifier and service index
	skipping to change at page 9, line 16 ¶		skipping to change at page 9, line 5 ¶
	This section describes an I2NSF framework with SDN for I2NSF		This section describes an I2NSF framework with SDN for I2NSF
	applicability and use cases, such as firewall, deep packet		applicability and use cases, such as firewall, deep packet
	inspection, and DDoS-attack mitigation functions. SDN enables some		inspection, and DDoS-attack mitigation functions. SDN enables some
	packet filtering rules to be enforced in network forwarding elements		packet filtering rules to be enforced in network forwarding elements
	(e.g., switch) by controlling their packet forwarding rules. By		(e.g., switch) by controlling their packet forwarding rules. By
	taking advantage of this capability of SDN, it is possible to		taking advantage of this capability of SDN, it is possible to
	optimize the process of security service enforcement in the I2NSF		optimize the process of security service enforcement in the I2NSF
	system.		system.
			+------------+
			| I2NSF User |
			+------------+
			^
			| Consumer-Facing Interface
			v
			+-------------------+ Registration +-----------------------+
			|Security Controller|<-------------------->|Developer's Mgmt System|
			+-------------------+ Interface +-----------------------+
			^ ^
			| | NSF-Facing Interface
			| v
			| +----------------+ +---------------+ +-----------------------+
			| | NSF-1 |-| NSF-2 |...| NSF-n |
			| | (Firewall) | | (DPI) | |(DDoS-Attack Mitigator)|
			| +----------------+ +---------------+ +-----------------------+
			|
			|
			| SDN Network
			+--|----------------------------------------------------------------+
			| V NSF-Facing Interface |
			| +----------------+ |
			| | SDN Controller | |
			| +----------------+ |
			| ^ |
			| | SDN Southbound Interface |
			| v |
			| +--------+ +------------+ +--------+ +--------+ |
			| |Switch-1|-| Switch-2 |-|Switch-3|.......|Switch-m| |
			| | | |(Classifier)| | (SFF) | | | |
			| +--------+ +------------+ +--------+ +--------+ |
			+-------------------------------------------------------------------+
			Figure 3: An I2NSF Framework with SDN Network
	Figure 3 shows an I2NSF framework [RFC8329] with SDN networks to		Figure 3 shows an I2NSF framework [RFC8329] with SDN networks to
	support network-based security services. In this system, the		support network-based security services. In this system, the
	enforcement of security policy rules is divided into the SDN		enforcement of security policy rules is divided into the SDN
	forwarding elements (e.g., switch) and NSFs. Especially, SDN		forwarding elements (e.g., switch) and NSFs. Especially, SDN
	forwarding elements enforce simple packet filtering rules that can be		forwarding elements enforce simple packet filtering rules that can be
	translated into their packet forwarding rules, whereas NSFs enforce		translated into their packet forwarding rules, whereas NSFs enforce
	NSF-related security rules requiring the security capabilities of the		NSF-related security rules requiring the security capabilities of the
	NSFs. For this purpose, the Security Controller instructs the SDN		NSFs. For this purpose, the Security Controller instructs the SDN
	Controller via NSF-Facing Interface so that SDN forwarding elements		Controller via NSF-Facing Interface so that SDN forwarding elements
	can perform the required security services with flow tables under the		can perform the required security services with flow tables under the
	skipping to change at page 10, line 7 ¶		skipping to change at page 10, line 32 ¶
	elements and which should be enforced by NSFs. If some of the given		elements and which should be enforced by NSFs. If some of the given
	rules requires security capabilities that can be provided by SDN		rules requires security capabilities that can be provided by SDN
	forwarding elements, then the Security Controller instructs the SDN		forwarding elements, then the Security Controller instructs the SDN
	Controller via NSF-Facing Interface so that SDN forwarding elements		Controller via NSF-Facing Interface so that SDN forwarding elements
	can enforce those security policy rules with flow tables under the		can enforce those security policy rules with flow tables under the
	supervision of the SDN Controller. Or if some rules require security		supervision of the SDN Controller. Or if some rules require security
	capabilities that cannot be provided by SDN forwarding elements but		capabilities that cannot be provided by SDN forwarding elements but
	by NSFs, then the Security Controller instructs relevant NSFs to		by NSFs, then the Security Controller instructs relevant NSFs to
	enforce those rules.		enforce those rules.
	+------------+		For the support of SFC in the I2NSF framework with SDN, as shown in
	| I2NSF User |		Figure 3, network forwarding elements (e.g., switch) can play the
	+------------+		role of either SFC Classifier or SFF, which are explained in
	^		Section 5. Classifier and SFF have an NSF-Facing Interface with
	| Consumer-Facing Interface		Security Controller. This interface is used to update security
	v		service function chaining information for traffic flows. For
	+-------------------+ Registration +-----------------------+		example, when it needs to update an SFP for a traffic flow in an SDN
	|Security Controller|<-------------------->|Developer's Mgmt System|		network, as shown in Figure 3, SFF (denoted as Switch-3) asks
	+-------------------+ Interface +-----------------------+		Security Controller to update the SFP for the traffic flow (needing
	^ ^		another security service as an NSF) via NSF-Facing Interface. This
	| | NSF-Facing Interface		update lets Security Controller ask Classifier (denoted as Switch-2)
	| v		to update the mapping between the traffic flow and SFP in Classifier
	| +----------------+ +---------------+ +-----------------------+		via NSF-Facing Interface.
	| | NSF-1 |-| NSF-2 |...| NSF-n |
	| | (Firewall) | | (DPI) | |(DDoS-Attack Mitigator)|
	| +----------------+ +---------------+ +-----------------------+
	| ^
	| |
	| v
	| +--------+
	| | SFF |
	| +--------+
	| ^
	| |
	| V SDN Network
	+--|----------------------------------------------------------------+
	| V NSF-Facing Interface |
	| +----------------+ |
	| | SDN Controller | |
	| +----------------+ |
	| ^ |
	| | SDN Southbound Interface |
	| v |
	| +--------+ +--------+ +--------+ +--------+ |
	| |Switch 1|-|Switch 2|-|Switch 3|......|Switch m| |
	| +--------+ +--------+ +--------+ +--------+ |
	+-------------------------------------------------------------------+
	Figure 3: An I2NSF Framework with SDN Network
	The following subsections introduce three use cases for cloud-based		The following subsections introduce three use cases for cloud-based
	security services: (i) firewall system, (ii) deep packet inspection		security services: (i) firewall system, (ii) deep packet inspection
	system, and (iii) attack mitigation system. [RFC8192]		system, and (iii) attack mitigation system. [RFC8192]
	6.1. Firewall: Centralized Firewall System		6.1. Firewall: Centralized Firewall System
	A centralized network firewall can manage each network resource and		A centralized network firewall can manage each network resource and
	apply common rules to individual network elements (e.g., switch).		apply common rules to individual network elements (e.g., switch).
	The centralized network firewall controls each forwarding element,		The centralized network firewall controls each forwarding element,
	skipping to change at page 13, line 7 ¶		skipping to change at page 13, line 7 ¶
	1. A switch forwards an unknown flow's packet to the SDN Controller,		1. A switch forwards an unknown flow's packet to the SDN Controller,
	and the SDN Controller further forwards the unknown flow's packet		and the SDN Controller further forwards the unknown flow's packet
	to the Firewall for basic security inspection.		to the Firewall for basic security inspection.
	2. The Firewall analyzes the header fields of the packet, and		2. The Firewall analyzes the header fields of the packet, and
	figures out that this is an unknown VoIP call flow's signal		figures out that this is an unknown VoIP call flow's signal
	packet (e.g., SIP packet) of a suspicious pattern.		packet (e.g., SIP packet) of a suspicious pattern.
	3. The Firewall triggers an appropriate security service function,		3. The Firewall triggers an appropriate security service function,
	such as VoIP IPS, for detailed security analysis of the		such as VoIP IPS, for detailed security analysis of the
	suspicious signal packet. That is, the firewall sends the packet		suspicious signal packet. In order for this triggering of VoIP
	to the Service Function Forwarder (SFF) in the I2NSF framework		IPS to be served, the suspicious packet is sent to the Service
	[nsf-triggered-steering], as shown in Figure 3. The SFF forwards		Function Forwarder (SFF) that is usually a switch in an SDN
	the suspicious signal packet to the VoIP IPS.		network, as shown in Figure 3. The SFF forwards the suspicious
			signal packet to the VoIP IPS.
	4. The VoIP IPS analyzes the headers and contents of the signal		4. The VoIP IPS analyzes the headers and contents of the signal
	packet, such as calling number and session description headers		packet, such as calling number and session description headers
	[RFC4566].		[RFC4566].
	5. If, for example, the VoIP IPS regards the packet as a spoofed		5. If, for example, the VoIP IPS regards the packet as a spoofed
	packet by hackers or a scanning packet searching for VoIP/VoLTE		packet by hackers or a scanning packet searching for VoIP/VoLTE
	devices, it drops the packet. In addition, the VoIP IPS requests		devices, it drops the packet. In addition, the VoIP IPS requests
	the SDN Controller to block that packet and the subsequent		the SDN Controller to block that packet and the subsequent
	packets that have the same call-id.		packets that have the same call-id.
	skipping to change at page 16, line 18 ¶		skipping to change at page 16, line 18 ¶
	This section discusses the implementation of the I2NSF framework		This section discusses the implementation of the I2NSF framework
	using Network Functions Virtualization (NFV).		using Network Functions Virtualization (NFV).
	+--------------------+		+--------------------+
	+-------------------------------------------+ | ---------------- |		+-------------------------------------------+ | ---------------- |
	| I2NSF User (OSS/BSS) | | | NFV | |		| I2NSF User (OSS/BSS) | | | NFV | |
	+------+------------------------------------+ | | Orchestrator +-+ |		+------+------------------------------------+ | | Orchestrator +-+ |
	| Consumer-Facing Interface | -----+---------- | |		| Consumer-Facing Interface | -----+---------- | |
	+------|------------------------------------+ | | | |		+------|------------------------------------+ | | | |
	| -----+---------- (a) ----------------- | | | | |		| -----+---------- (a) ----------------- | | ----+----- | |
	| | Security |-------| Developer's | | | | | |		| | Security +-------+ Developer's | | | | | | |
	| |Controller(EM)| |Mgmt System(EM)| | | | | |		| |Controller(EM)| |Mgmt System(EM)| +-(b)-+ VNFM(s)| | |
	| -----+---------- ----------------- | | ----+----- | |		| -----+---------- ----------------- | | | | | |
	| | NSF-Facing Interface | | | | | |		| | NSF-Facing Interface | | ----+----- | |
	| ----+----- ----+----- ----+----- | | | VNFM(s)| | |		| ----+----- ----+----- ----+----- | | | | |
	| |NSF(VNF)| |NSF(VNF)| |NSF(VNF)| +-(b)-+ | | |		| |NSF(VNF)| |NSF(VNF)| |NSF(VNF)| | | | | |
	| ----+----- ----+----- ----+----- | | ----+----- | |		| ----+----- ----+----- ----+----- | | | | |
	| | | | | | | | |		| | | | | | | | |
	+------|-------------|-------------|--------+ | | | |		+------|-------------|-------------|--------+ | | | |
	| | | | | | |		| | | | | | |
	+------+-------------+-------------+--------+ | | | |		+------+-------------+-------------+--------+ | | | |
	| NFV Infrastructure (NFVI) | | | | |		| NFV Infrastructure (NFVI) | | | | |
	| ----------- ----------- ----------- | | | | |		| ----------- ----------- ----------- | | | | |
	| | Virtual | | Virtual | | Virtual | | | | | |		| | Virtual | | Virtual | | Virtual | | | | | |
	| | Compute | | Storage | | Network | | | | | |		| | Compute | | Storage | | Network | | | | | |
	| ----------- ----------- ----------- | | ----+----- | |		| ----------- ----------- ----------- | | ----+----- | |
	| +---------------------------------------+ | | | | | |		| +---------------------------------------+ | | | | | |
	| | Virtualization Layer | +-----+ VIM(s) +------+ |		| | Virtualization Layer | +-----+ VIM(s) +------+ |
	| +---------------------------------------+ | | | | |		| +---------------------------------------+ | | | | |
	| +---------------------------------------+ | | ---------- |		| +---------------------------------------+ | | ---------- |
	| | ----------- ----------- ----------- | | | |		| | ----------- ----------- ----------- | | | |
	| | | Compute | | Storage | | Network | | | | |		| | | Compute | | Storage | | Network | | | | |
	| | | Hardware| | Hardware| | Hardware| | | | |		| | | Hardware| | Hardware| | Hardware| | | | |
	| | ----------- ----------- ----------- | | | |		| | ----------- ----------- ----------- | | | |
	| | Hardware Resources | | | NFV Management |		| | Hardware Resources | | | NFV Management |
	| +---------------------------------------+ | | and Orchestration |		| +---------------------------------------+ | | and Orchestration |
			| | | (MANO) |
	+-------------------------------------------+ +--------------------+		+-------------------------------------------+ +--------------------+
	(a) = Registration Interface		(a) = Registration Interface
	(b) = Ve-Vnfm Interface		(b) = Ve-Vnfm Interface
	Figure 4: I2NSF Framework Implementation with respect to the NFV		Figure 4: I2NSF Framework Implementation with respect to the NFV
	Reference Architectural Framework		Reference Architectural Framework
	NFV is a promising technology for improving the elasticity and		NFV is a promising technology for improving the elasticity and
	efficiency of network resource utilization. In NFV environments,		efficiency of network resource utilization. In NFV environments,
	NSFs can be deployed in the forms of software-based virtual instances		NSFs can be deployed in the forms of software-based virtual instances
	skipping to change at page 22, line 5 ¶		skipping to change at page 22, line 5 ¶
	(I2NSF): Problem Statement and Use Cases", RFC 8192, July		(I2NSF): Problem Statement and Use Cases", RFC 8192, July
	2017.		2017.
	[RFC8300] Quinn, P., Elzur, U., and C. Pignataro, "Network Service		[RFC8300] Quinn, P., Elzur, U., and C. Pignataro, "Network Service
	Header (NSH)", RFC 8300, January 2018.		Header (NSH)", RFC 8300, January 2018.
	[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, February 2018.		Functions", RFC 8329, February 2018.
	Appendix A. Changes from draft-ietf-i2nsf-applicability-04		Appendix A. Changes from draft-ietf-i2nsf-applicability-05
	The following changes have been made from draft-ietf-i2nsf-
	applicability-04:
	o A more precise description of the basic I2NSF flows is provided.
	o The structure of the document makes each discussed use case be an		The following change has been made from draft-ietf-i2nsf-
	applicability statement according to the applied technology, such		applicability-05:
	as SFC, SDN, and NFV.
	o In Section 6, Switch Controller is replaced by SDN Controller for		o In Figure 3, a separate box of SFF and the relevant interfaces
	the terminology consistency in SDN standards. Switch is replaced		have been omitted to avoid misleading. Instead, SDN switches may
	by forwarding element as a general term.		play the role of SFF and Classifier in an SDN network.
	Authors' Addresses		Authors' Addresses
	Jaehoon Paul Jeong		Jaehoon Paul Jeong
	Department of Software		Department of Software
	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
End of changes. 23 change blocks.
	126 lines changed or deleted		134 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/