draft-ietf-sfc-nsh-20.txt		draft-ietf-sfc-nsh-21.txt
	Service Function Chaining P. Quinn, Ed.		Service Function Chaining P. Quinn, Ed.
	Internet-Draft Cisco		Internet-Draft Cisco
	Intended status: Standards Track U. Elzur, Ed.		Intended status: Standards Track U. Elzur, Ed.
	Expires: March 5, 2018 Intel		Expires: March 17, 2018 Intel
	C. Pignataro, Ed.		C. Pignataro, Ed.
	Cisco		Cisco
	September 1, 2017		September 13, 2017
	Network Service Header (NSH)		Network Service Header (NSH)
	draft-ietf-sfc-nsh-20		draft-ietf-sfc-nsh-21
	Abstract		Abstract
	This document describes a Network Service Header (NSH) imposed on		This document describes a Network Service Header (NSH) imposed on
	packets or frames to realize service function paths. The NSH also		packets or frames to realize service function paths. The NSH also
	provides a mechanism for metadata exchange along the instantiated		provides a mechanism for metadata exchange along the instantiated
	service paths. The NSH is the SFC encapsulation required to support		service paths. The NSH is the SFC encapsulation required to support
	the Service Function Chaining (SFC) architecture (defined in		the Service Function Chaining (SFC) architecture (defined in
	RFC7665).		RFC7665).
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://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 5, 2018.		This Internet-Draft will expire on March 17, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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		(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 . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	skipping to change at page 2, line 39		skipping to change at page 2, line 39
	6.3. Service Plane Visibility . . . . . . . . . . . . . . . . 21		6.3. Service Plane Visibility . . . . . . . . . . . . . . . . 21
	6.4. Service Graphs . . . . . . . . . . . . . . . . . . . . . 21		6.4. Service Graphs . . . . . . . . . . . . . . . . . . . . . 21
	7. Policy Enforcement with NSH . . . . . . . . . . . . . . . . . 21		7. Policy Enforcement with NSH . . . . . . . . . . . . . . . . . 21
	7.1. NSH Metadata and Policy Enforcement . . . . . . . . . . . 21		7.1. NSH Metadata and Policy Enforcement . . . . . . . . . . . 21
	7.2. Updating/Augmenting Metadata . . . . . . . . . . . . . . 23		7.2. Updating/Augmenting Metadata . . . . . . . . . . . . . . 23
	7.3. Service Path Identifier and Metadata . . . . . . . . . . 25		7.3. Service Path Identifier and Metadata . . . . . . . . . . 25
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 25		8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
	9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27		9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
	11.1. NSH EtherType . . . . . . . . . . . . . . . . . . . . . 28		11.1. NSH EtherType . . . . . . . . . . . . . . . . . . . . . 29
	11.2. Network Service Header (NSH) Parameters . . . . . . . . 28		11.2. Network Service Header (NSH) Parameters . . . . . . . . 29
	11.2.1. NSH Base Header Bits . . . . . . . . . . . . . . . . 29		11.2.1. NSH Base Header Bits . . . . . . . . . . . . . . . . 29
	11.2.2. NSH Version . . . . . . . . . . . . . . . . . . . . 29		11.2.2. NSH Version . . . . . . . . . . . . . . . . . . . . 29
	11.2.3. MD Type Registry . . . . . . . . . . . . . . . . . . 29		11.2.3. MD Type Registry . . . . . . . . . . . . . . . . . . 29
	11.2.4. MD Class Registry . . . . . . . . . . . . . . . . . 29		11.2.4. MD Class Registry . . . . . . . . . . . . . . . . . 30
	11.2.5. NSH Base Header Next Protocol . . . . . . . . . . . 30		11.2.5. NSH Base Header Next Protocol . . . . . . . . . . . 31
	11.2.6. New IETF Assigned Optional Variable Length Metadata		11.2.6. New IETF Assigned Optional Variable Length Metadata
	Type Registry . . . . . . . . . . . . . . . . . . . 31		Type Registry . . . . . . . . . . . . . . . . . . . 31
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
	12.1. Normative References . . . . . . . . . . . . . . . . . . 31		12.1. Normative References . . . . . . . . . . . . . . . . . . 32
	12.2. Informative References . . . . . . . . . . . . . . . . . 32		12.2. Informative References . . . . . . . . . . . . . . . . . 32
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
	1. Introduction		1. Introduction
	Service functions are widely deployed and essential in many networks.		Service functions are widely deployed and essential in many networks.
	These service functions provide a range of features such as security,		These service functions provide a range of features such as security,
	WAN acceleration, and server load balancing. Service functions may		WAN acceleration, and server load balancing. Service functions may
	be instantiated at different points in the network infrastructure		be instantiated at different points in the network infrastructure
	such as the wide area network, data center, campus, and so forth.		such as the wide area network, data center, campus, and so forth.
	Prior to development of the SFC architecture [RFC7665] and the		Prior to development of the SFC architecture [RFC7665] and the
	skipping to change at page 4, line 20		skipping to change at page 4, line 20
	The NSH is designed to be easy to implement across a range of		The NSH is designed to be easy to implement across a range of
	devices, both physical and virtual, including hardware platforms.		devices, both physical and virtual, including hardware platforms.
	The intended scope of the NSH is for use within a single provider's		The intended scope of the NSH is for use within a single provider's
	operational domain. This deployment scope is deliberately		operational domain. This deployment scope is deliberately
	constrained, as explained also in [RFC7665], and limited to a single		constrained, as explained also in [RFC7665], and limited to a single
	network administrative domain. In this context, a "domain" is a set		network administrative domain. In this context, a "domain" is a set
	of network entities within a single administration. For example, a		of network entities within a single administration. For example, a
	network administrative domain can include a single data center, a		network administrative domain can include a single data center, a
	campus physical network, or an overlay domain using virtual		controlled campus physical network, or an overlay domain using
	connections and tunnels. A corollary is that a network		virtual connections and tunnels. A corollary is that a network
	administrative domain has a well defined perimeter.		administrative domain has a well defined perimeter.
	An NSH-aware control plane is outside the scope of this document.		An NSH-aware control plane is outside the scope of this document.
	[RFC7665] provides an overview of a service chaining architecture		[RFC7665] provides an overview of a service chaining architecture
	that clearly defines the roles of the various elements and the scope		that clearly defines the roles of the various elements and the scope
	of a service function chaining encapsulation. The NSH is the SFC		of a service function chaining encapsulation. The NSH is the SFC
	encapsulation referenced in [RFC7665].		encapsulation referenced in [RFC7665].
	1.1. Requirements Language		1.1. Requirements Language
	skipping to change at page 26, line 7		skipping to change at page 26, line 7
	8. Security Considerations		8. Security Considerations
	As with many other protocols, the NSH encapsulation could be spoofed		As with many other protocols, the NSH encapsulation could be spoofed
	or otherwise modified in transit. However, the deployment scope (as		or otherwise modified in transit. However, the deployment scope (as
	defined in [RFC7665]) of the NSH encapsulation is limited to a single		defined in [RFC7665]) of the NSH encapsulation is limited to a single
	network administrative domain as a controlled environment, with		network administrative domain as a controlled environment, with
	trusted devices (e.g., a data center) hence mitigating the risk of		trusted devices (e.g., a data center) hence mitigating the risk of
	unauthorized manipulation of the encapsulation headers or metadata.		unauthorized manipulation of the encapsulation headers or metadata.
			Packets originating outside the SFC-enabled domain must be dropped if
			they contain an NSH. Similarly, packets exiting the SFC-enabled
			domain must be dropped if they contain an NSH.
	NSH is always encapsulated in a transport protocol (as detailed in		NSH is always encapsulated in a transport protocol (as detailed in
	Section 4 of this specification); and, therefore, when required,		Section 4 of this specification); and, therefore, when required,
	existing security protocols that provide authenticity (e.g.,		existing security protocols that provide authenticity (e.g.,
	[RFC6071]) can be used. Similarly, if confidentiality is required,		[RFC6071]) can be used. Similarly, if confidentiality is required,
	existing encryption protocols can be used in conjunction with the NSH		existing encryption protocols can be used in conjunction with the NSH
	encapsulation.		encapsulation.
	Further, existing best practices, such as [BCP38] SHOULD be deployed		Further, existing best practices, such as [BCP38] SHOULD be deployed
	at the network layer to ensure that traffic entering the service path		at the network layer to ensure that traffic entering the service path
	is indeed "valid". [I-D.ietf-rtgwg-dt-encap] provides additional		is indeed "valid". [I-D.ietf-rtgwg-dt-encap] provides additional
	skipping to change at page 26, line 40		skipping to change at page 26, line 44
	as described under the "SFC Encapsulation" area of the Security		as described under the "SFC Encapsulation" area of the Security
	Considerations of [RFC7665], operators can and should use indirect		Considerations of [RFC7665], operators can and should use indirect
	identification for metadata deemed to be sensitive (such as		identification for metadata deemed to be sensitive (such as
	personally identifying information) significantly mitigating the risk		personally identifying information) significantly mitigating the risk
	of privacy violation. In particular, subscriber identifying		of privacy violation. In particular, subscriber identifying
	information should be handled carefully, and in general should be		information should be handled carefully, and in general should be
	obfuscated. This is covered in the Security Considerations of		obfuscated. This is covered in the Security Considerations of
	[RFC7665]. For those situations where obfuscation is either		[RFC7665]. For those situations where obfuscation is either
	inapplicable or judged to be insufficient, an operator can also		inapplicable or judged to be insufficient, an operator can also
	encrypt the metadata. An approach to an optional capability to do		encrypt the metadata. An approach to an optional capability to do
	this was explored in [I-D.reddy-sfc-nsh-encrypt]. Means to prevent		this was explored in [I-D.reddy-sfc-nsh-encrypt]. For other
	leaking privacy-related information outside an administrative domain		situations where greater assurance is desired, optional mechanisms
	are natively supported by the NSH given that the last SFF of a		such as [I-D.brockners-proof-of-transit] can be used. Means to
			prevent leaking privacy-related information outside an administrative
			domain are natively supported by the NSH given that the last SFF of a
	service path will systematically remove the NSH encapsulation before		service path will systematically remove the NSH encapsulation before
	forwarding a packet exiting the service path.		forwarding a packet exiting the service path.
	Lastly, SF security, although out of scope of this document, should		Lastly, SF security, although out of scope of this document, should
	be considered, particularly if an SF needs to access, authenticate,		be considered, particularly if an SF needs to access, authenticate,
	or update the NSH encapsulation or metadata. However, again, the		or update the NSH encapsulation or metadata. However, again, the
	placement of SFs is assumed to be bounded within the scope of a		placement of SFs is assumed to be bounded within the scope of a
	single administrative domain and therefore under direct control of		single administrative domain and therefore under direct control of
	the operator.		the operator.
	skipping to change at page 31, line 47		skipping to change at page 32, line 9
	The type values are assigned via Standards Action [RFC8126].		The type values are assigned via Standards Action [RFC8126].
	No initial values are assigned at the creation of the registry.		No initial values are assigned at the creation of the registry.
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997, <https://www.rfc-		DOI 10.17487/RFC2119, March 1997,
	editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function		[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
	Chaining (SFC) Architecture", RFC 7665,		Chaining (SFC) Architecture", RFC 7665,
	DOI 10.17487/RFC7665, October 2015, <https://www.rfc-		DOI 10.17487/RFC7665, October 2015,
	editor.org/info/rfc7665>.		<https://www.rfc-editor.org/info/rfc7665>.
	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	12.2. Informative References		12.2. Informative References
	[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering:		[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering:
	Defeating Denial of Service Attacks which employ IP Source		Defeating Denial of Service Attacks which employ IP Source
	Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,		Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
	May 2000, <http://www.rfc-editor.org/info/rfc2827>.		May 2000, <http://www.rfc-editor.org/info/rfc2827>.
			[I-D.brockners-proof-of-transit]
			Brockners, F., Bhandari, S., Dara, S., Pignataro, C.,
			Leddy, J., Youell, S., Mozes, D., and T. Mizrahi, "Proof
			of Transit", draft-brockners-proof-of-transit-03 (work in
			progress), March 2017.
	[I-D.guichard-sfc-nsh-dc-allocation]		[I-D.guichard-sfc-nsh-dc-allocation]
	Guichard, J., Smith, M., Kumar, S., Majee, S., Agarwal,		Guichard, J., Smith, M., Kumar, S., Majee, S., Agarwal,
	P., Glavin, K., Laribi, Y., and T. Mizrahi, "Network		P., Glavin, K., Laribi, Y., and T. Mizrahi, "Network
	Service Header (NSH) MD Type 1: Context Header Allocation		Service Header (NSH) MD Type 1: Context Header Allocation
	(Data Center)", draft-guichard-sfc-nsh-dc-allocation-07		(Data Center)", draft-guichard-sfc-nsh-dc-allocation-07
	(work in progress), August 2017.		(work in progress), August 2017.
	[I-D.ietf-nvo3-vxlan-gpe]		[I-D.ietf-nvo3-vxlan-gpe]
	Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol		Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
	Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-04 (work		Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-04 (work
	skipping to change at page 33, line 18		skipping to change at page 33, line 29
	draft-napper-sfc-nsh-broadband-allocation-03 (work in		draft-napper-sfc-nsh-broadband-allocation-03 (work in
	progress), July 2017.		progress), July 2017.
	[I-D.reddy-sfc-nsh-encrypt]		[I-D.reddy-sfc-nsh-encrypt]
	Reddy, T., Patil, P., Fluhrer, S., and P. Quinn,		Reddy, T., Patil, P., Fluhrer, S., and P. Quinn,
	"Authenticated and encrypted NSH service chains", draft-		"Authenticated and encrypted NSH service chains", draft-
	reddy-sfc-nsh-encrypt-00 (work in progress), April 2015.		reddy-sfc-nsh-encrypt-00 (work in progress), April 2015.
	[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.		[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
	Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,		Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
	DOI 10.17487/RFC2784, March 2000, <https://www.rfc-		DOI 10.17487/RFC2784, March 2000,
	editor.org/info/rfc2784>.		<https://www.rfc-editor.org/info/rfc2784>.
	[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers		[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
	Considered Useful", BCP 82, RFC 3692,		Considered Useful", BCP 82, RFC 3692,
	DOI 10.17487/RFC3692, January 2004, <https://www.rfc-		DOI 10.17487/RFC3692, January 2004,
	editor.org/info/rfc3692>.		<https://www.rfc-editor.org/info/rfc3692>.
	[RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and		[RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and
	Internet Key Exchange (IKE) Document Roadmap", RFC 6071,		Internet Key Exchange (IKE) Document Roadmap", RFC 6071,
	DOI 10.17487/RFC6071, February 2011, <https://www.rfc-		DOI 10.17487/RFC6071, February 2011,
	editor.org/info/rfc6071>.		<https://www.rfc-editor.org/info/rfc6071>.
	[RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A.,		[RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A.,
	and C. Pignataro, "MPLS Forwarding Compliance and		and C. Pignataro, "MPLS Forwarding Compliance and
	Performance Requirements", RFC 7325, DOI 10.17487/RFC7325,		Performance Requirements", RFC 7325, DOI 10.17487/RFC7325,
	August 2014, <https://www.rfc-editor.org/info/rfc7325>.		August 2014, <https://www.rfc-editor.org/info/rfc7325>.
	[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for		[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
	Service Function Chaining", RFC 7498,		Service Function Chaining", RFC 7498,
	DOI 10.17487/RFC7498, April 2015, <https://www.rfc-		DOI 10.17487/RFC7498, April 2015,
	editor.org/info/rfc7498>.		<https://www.rfc-editor.org/info/rfc7498>.
	[RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support		[RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support
	for Generic Routing Encapsulation (GRE)", RFC 7676,		for Generic Routing Encapsulation (GRE)", RFC 7676,
	DOI 10.17487/RFC7676, October 2015, <https://www.rfc-		DOI 10.17487/RFC7676, October 2015,
	editor.org/info/rfc7676>.		<https://www.rfc-editor.org/info/rfc7676>.
	Authors' Addresses		Authors' Addresses
	Paul Quinn (editor)		Paul Quinn (editor)
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Email: paulq@cisco.com		Email: paulq@cisco.com
	Uri Elzur (editor)		Uri Elzur (editor)
	Intel		Intel
	Email: uri.elzur@intel.com		Email: uri.elzur@intel.com
	Carlos Pignataro (editor)		Carlos Pignataro (editor)
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Email: cpignata@cisco.com		Email: cpignata@cisco.com
End of changes. 22 change blocks.
	31 lines changed or deleted		44 lines changed or added
This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/