draft-ietf-6man-oversized-header-chain-08.txt		draft-ietf-6man-oversized-header-chain-09.txt
	IPv6 maintenance Working Group (6man) F. Gont		IPv6 maintenance Working Group (6man) F. Gont
	Internet-Draft SI6 Networks / UTN-FRH		Internet-Draft SI6 Networks / UTN-FRH
	Updates: 2460 (if approved) V. Manral		Updates: 2460 (if approved) V. Manral
	Intended status: Standards Track Hewlett-Packard Corp.		Intended status: Standards Track Hewlett-Packard Corp.
	Expires: April 5, 2014 R. Bonica		Expires: May 30, 2014 R. Bonica
	Juniper Networks		Juniper Networks
	October 2, 2013		November 26, 2013
	Implications of Oversized IPv6 Header Chains		Implications of Oversized IPv6 Header Chains
	draft-ietf-6man-oversized-header-chain-08		draft-ietf-6man-oversized-header-chain-09
	Abstract		Abstract
	The IPv6 specification allows IPv6 header chains of an arbitrary		The IPv6 specification allows IPv6 header chains of an arbitrary
	size. The specification also allows options which can in turn extend		size. The specification also allows options which can in turn extend
	each of the headers. In those scenarios in which the IPv6 header		each of the headers. In those scenarios in which the IPv6 header
	chain or options are unusually long and packets are fragmented, or		chain or options are unusually long and packets are fragmented, or
	scenarios in which the fragment size is very small, the first		scenarios in which the fragment size is very small, the first
	fragment of a packet may fail to include the entire IPv6 header		fragment of a packet may fail to include the entire IPv6 header
	chain. This document discusses the interoperability and security		chain. This document discusses the interoperability and security
	problems of such traffic, and updates RFC 2460 such that the first		problems of such traffic, and updates RFC 2460 such that the first
	fragment of a packet is required to contain the entire IPv6 header		fragment of a packet is required to contain the entire IPv6 header
	chain.		chain.
	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 http://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 April 5, 2014.		This Internet-Draft will expire on May 30, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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
	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 . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4		2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 7		4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
	5. Updates to RFC 2460 . . . . . . . . . . . . . . . . . . . . . 8		5. Updates to RFC 2460 . . . . . . . . . . . . . . . . . . . . . 4
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 10		7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 12		9.1. Normative References . . . . . . . . . . . . . . . . . . 6
	9.2. Informative References . . . . . . . . . . . . . . . . . . 12		9.2. Informative References . . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
	1. Introduction		1. Introduction
	With IPv6, optional internet-layer information is carried in one or		With IPv6, optional internet-layer information is carried in one or
	more IPv6 Extension Headers [RFC2460]. Extension headers are placed		more IPv6 Extension Headers [RFC2460]. Extension headers are placed
	between the IPv6 header and the upper-layer header in a packet. The		between the IPv6 header and the upper-layer header in a packet. The
	term "header chain" refers collectively to the IPv6 header, extension		term "header chain" refers collectively to the IPv6 header, extension
	headers and upper-layer header occurring in a packet. In those		headers and upper-layer header occurring in a packet. In those
	scenarios in which the IPv6 header chain is unusually long and		scenarios in which the IPv6 header chain is unusually long and
	packets are fragmented, or scenarios in which the fragment size is		packets are fragmented, or scenarios in which the fragment size is
	skipping to change at page 3, line 27		skipping to change at page 3, line 7
	present in a single IPv4 packet, IPv6 does not have any equivalent		present in a single IPv4 packet, IPv6 does not have any equivalent
	maximum limit at present. This document updates the set of IPv6		maximum limit at present. This document updates the set of IPv6
	specifications to create an overall limit on the size of the		specifications to create an overall limit on the size of the
	combination of IPv6 options and IPv6 Extension Headers that is		combination of IPv6 options and IPv6 Extension Headers that is
	allowed in a single IPv6 packet. Namely, it updates RFC 2460 such		allowed in a single IPv6 packet. Namely, it updates RFC 2460 such
	that the first fragment of a fragmented datagram is required to		that the first fragment of a fragmented datagram is required to
	contain the entire IPv6 header chain.		contain the entire IPv6 header chain.
	It should be noted that this requirement does not preclude the use of		It should be noted that this requirement does not preclude the use of
	large payloads but instead merely requires that all headers, starting		large payloads but instead merely requires that all headers, starting
	from IPv6 base header and continuing up to the upper layer header		from the IPv6 base header and continuing up to the upper layer header
	(e.g. TCP or the like) be present in the first fragment.		(e.g., TCP or the like) be present in the first fragment.
	2. Requirements Language		2. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	3. Terminology		3. Terminology
	For the purposes of this document, the terms Extension Header, Header		For the purposes of this document, the terms Extension Header, Header
	skipping to change at page 8, line 7		skipping to change at page 4, line 46
	However, when the firewall is presented with a fragmented packet and		However, when the firewall is presented with a fragmented packet and
	the header chain spans multiple fragments, the first fragment does		the header chain spans multiple fragments, the first fragment does
	not contain enough information for the firewall to enforce its		not contain enough information for the firewall to enforce its
	forwarding policy. Lacking sufficient information, the stateless		forwarding policy. Lacking sufficient information, the stateless
	firewall either forwards or discards that fragment. Regardless of		firewall either forwards or discards that fragment. Regardless of
	the action that it takes, it may fail to enforce its forwarding		the action that it takes, it may fail to enforce its forwarding
	policy.		policy.
	5. Updates to RFC 2460		5. Updates to RFC 2460
	When a host fragments a IPv6 datagram, it MUST include the entire		When a host fragments an IPv6 datagram, it MUST include the entire
	header chain in the first fragment.		header chain in the first fragment.
	A host that receives a first-fragment that does not satisfy the		A host that receives a first-fragment that does not satisfy the
	above- stated requirement SHOULD discard the packet (e.g., including		above- stated requirement SHOULD discard the packet and SHOULD send
	a configuration option that allows such fragments to be accepted for		an ICMPv6 error message to the source address of the offending packet
	backwards compatibility) and SHOULD send an ICMPv6 error message to		(subject to the rules for ICMPv6 errors specified in [RFC4443]).
	the source address of the offending packet (subject to the rules for
	ICMPv6 errors specified in [RFC4443]).
	Likewise, an intermediate system (e.g. router, firewall) that		However, for backwards compatibility, implementations MAY include a
			configuration option that allows such fragments to be accepted.
			Likewise, an intermediate system (e.g., router or firewall) that
	receives an IPv6 first-fragment that does not satisfy the above-		receives an IPv6 first-fragment that does not satisfy the above-
	stated requirements MAY discard that packet, and MAY send an ICMPv6		stated requirement MAY discard that packet, and MAY send an ICMPv6
	error message to the source address of the offending packet (subject		error message to the source address of the offending packet (subject
	to the rules for ICMPv6 error messages specified in [RFC4443]).		to the rules for ICMPv6 error messages specified in [RFC4443]).
	Intermediate systems having this capability SHOULD support		Intermediate systems having this capability SHOULD support
	configuration (e.g. enable/disable) of whether such packets are		configuration (e.g., enable/disable) of whether such packets are
	dropped or not by the intermediate system.		dropped or not by the intermediate system.
	If a host or intermediate system discards a first-fragment because it		If a host or intermediate system discards a first-fragment because it
	does not satisfy the above-stated requirements, and sends an ICMPv6		does not satisfy the above-stated requirement, and sends an ICMPv6
	error message due to the discard, then the ICMPv6 error message MUST		error message due to the discard, then the ICMPv6 error message MUST
	be Type 4 ("Parameter Problem") and MUST use Code TBD ("First-		be Type 4 ("Parameter Problem") and MUST use Code TBD ("First-
	fragment has incomplete IPv6 Header Chain"). The Pointer field		fragment has incomplete IPv6 Header Chain"). The Pointer field
	contained by the ICMPv6 Parameter Problem message MUST be set to		contained by the ICMPv6 Parameter Problem message MUST be set to
	zero. Whether a host or intermediate system originates this ICMP		zero. The format for the ICMPv6 error message is the same regardless
	message, its format is identical.		of whether a host or intermediate system originates it.
	As a result of the above mentioned requirements, a packet's header		As a result of the above mentioned requirement, a packet's header
	chain length cannot exceed the Path MTU associated with its		chain length cannot exceed the Path MTU associated with its
	destination. Hosts MAY discover the Path MTU, using procedures such		destination. Hosts discover the Path MTU using procedures such as
	as those defined in [RFC1981] and [RFC4821]. However, if a host does		those defined in [RFC1981] and [RFC4821]. Hosts that do not discover
	not discover the Path MTU, it MUST limit the header chain length to		the Path MTU MUST limit the header chain length to 1280 bytes.
	1280 bytes. Limiting the header chain length to 1280 bytes ensures		Limiting the header chain length to 1280 bytes ensures that the
	that the header chain length does not exceed the IPv6 minimum MTU		header chain length does not exceed the IPv6 minimum MTU [RFC2460].
	[RFC2460].
	6. IANA Considerations		6. IANA Considerations
	IANA is requested to add a the following entry to the "Reason Code"		IANA is requested to add a the following entry to the "Reason Code"
	registry for ICMPv6 "Type 4 - Parameter Problem" messages:		registry for ICMPv6 "Type 4 - Parameter Problem" messages:
	CODE NAME/DESCRIPTION		CODE NAME/DESCRIPTION
	TBD IPv6 first-fragment has incomplete IPv6 header chain		TBD IPv6 first-fragment has incomplete IPv6 header chain
	7. Security Considerations		7. Security Considerations
	This document describes how improperly-fragmented packets can prevent		No new security exposures or issues are raised by this document.
	traditional stateless packet filtering.		This document describes how undesirably-fragmented packets can be
			leveraged to evade stateless packet filtering. Having made that
	This document updates RFC 2460 such that those packets are forbidden,		observation, this document updates RFC 2460 [RFC2460] so that so
	thus enabling stateless packet filtering for IPv6.		undesirably-fragmented packets are forbidden. Therefore, a security
			vulnerability is removed.
	This specification allows nodes that drop the aforementioned packets		This specification allows nodes that drop the aforementioned packets
	to signal such packet drops with ICMPv6 "Parameter Problem, IPv6		to signal such packet drops with ICMPv6 "Parameter Problem, IPv6
	first-fragment has incomplete IPv6 header chain" (Type 4, Code TBD)		first-fragment has incomplete IPv6 header chain" (Type 4, Code TBD)
	error messages.		error messages.
	As with all ICMPv6 error/diagnostic messages, deploying Source		As with all ICMPv6 error/diagnostic messages, deploying Source
	Address Forgery Prevention filters helps reduce the chances of an		Address Forgery Prevention filters helps reduce the chances of an
	attacker successfully performing a reflection attack by sending		attacker successfully performing a reflection attack by sending
	forged illegal packets with the victim/target's IPv6 address as the		forged illegal packets with the victim/target's IPv6 address as the
	skipping to change at page 11, line 12		skipping to change at page 6, line 25
	correctly process fragmented packets, even if the IPv6 header chain		correctly process fragmented packets, even if the IPv6 header chain
	is not fragmented.		is not fragmented.
	8. Acknowledgements		8. Acknowledgements
	The authors of this document would like to thank Ran Atkinson for		The authors of this document would like to thank Ran Atkinson for
	contributing text and ideas that were incorporated into this		contributing text and ideas that were incorporated into this
	document.		document.
	The authors would like to thank (in alphabetical order) Ran Atkinson,		The authors would like to thank (in alphabetical order) Ran Atkinson,
	Fred Baker, Brian Carpenter, Dominik Elsbroek, Wes George, Mike		Fred Baker, Stewart Bryant, Brian Carpenter, Benoit Claise, Dominik
	Heard, Bill Jouris, Suresh Krishnan, Dave Thaler, Ole Troan, and Eric		Elsbroek, Wes George, Mike Heard, Bill Jouris, Suresh Krishnan, Dave
	Vyncke, for providing valuable comments on earlier versions of this		Thaler, Ole Troan, Eric Vyncke, and Peter Yee, for providing valuable
	document.		comments on earlier versions of this document.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery		[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
	for IP version 6", RFC 1981, August 1996.		for IP version 6", RFC 1981, August 1996.
	[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.
	skipping to change at page 12, line 27		skipping to change at page 7, line 5
	[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control		[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
	Message Protocol (ICMPv6) for the Internet Protocol		Message Protocol (ICMPv6) for the Internet Protocol
	Version 6 (IPv6) Specification", RFC 4443, March 2006.		Version 6 (IPv6) Specification", RFC 4443, March 2006.
	[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU		[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
	Discovery", RFC 4821, March 2007.		Discovery", RFC 4821, March 2007.
	[I-D.ietf-6man-ext-transmit]		[I-D.ietf-6man-ext-transmit]
	Carpenter, B. and S. Jiang, "Transmission and Processing		Carpenter, B. and S. Jiang, "Transmission and Processing
	of IPv6 Extension Headers",		of IPv6 Extension Headers", draft-ietf-6man-ext-
	draft-ietf-6man-ext-transmit-04 (work in progress),		transmit-05 (work in progress), October 2013.
	September 2013.
	9.2. Informative References		9.2. Informative References
	[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:		[RFC2827] 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, May 2000.		Address Spoofing", BCP 38, RFC 2827, May 2000.
	[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed		[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
	Networks", BCP 84, RFC 3704, March 2004.		Networks", BCP 84, RFC 3704, March 2004.
	[IANA-PROTO]		[IANA-PROTO]
	Internet Assigned Numbers Authority, "Protocol Numbers",		Internet Assigned Numbers Authority, "Protocol Numbers",
	February 2013, <http://www.iana.org/assignments/		February 2013, <http://www.iana.org/assignments/protocol-
	protocol-numbers/protocol-numbers.txt>.		numbers/protocol-numbers.txt>.
	Authors' Addresses		Authors' Addresses
	Fernando Gont		Fernando Gont
	SI6 Networks / UTN-FRH		SI6 Networks / UTN-FRH
	Evaristo Carriego 2644		Evaristo Carriego 2644
	Haedo, Provincia de Buenos Aires 1706		Haedo, Provincia de Buenos Aires 1706
	Argentina		Argentina
	Phone: +54 11 4650 8472		Phone: +54 11 4650 8472
	skipping to change at page 13, line 25		skipping to change at page 8, line 4
	URI: http://www.si6networks.com		URI: http://www.si6networks.com
	Vishwas Manral		Vishwas Manral
	Hewlett-Packard Corp.		Hewlett-Packard Corp.
	191111 Pruneridge Ave.		191111 Pruneridge Ave.
	Cupertino, CA 95014		Cupertino, CA 95014
	US		US
	Phone: 408-447-1497		Phone: 408-447-1497
	Email: vishwas.manral@hp.com		Email: vishwas.manral@hp.com
	URI:
	Ronald P. Bonica		Ronald P. Bonica
	Juniper Networks		Juniper Networks
	2251 Corporate Park Drive		2251 Corporate Park Drive
	Herndon, VA 20171		Herndon, VA 20171
	US		US
	Phone: 571 250 5819		Phone: 571 250 5819
	Email: rbonica@juniper.net		Email: rbonica@juniper.net
End of changes. 22 change blocks.
	56 lines changed or deleted		54 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/