< draft-gont-6man-ipv6-smurf-amplifier-02.txt		draft-gont-6man-ipv6-smurf-amplifier-03.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, 4443 (if approved) W. Liu		Updates: 2460, 4443 (if approved) W. Liu
	Intended status: Standards Track Huawei Technologies		Intended status: Standards Track Huawei Technologies
	Expires: July 28, 2013 January 24, 2013		Expires: September 22, 2013 March 21, 2013
	Security Implications of IPv6 Options of Type 10xxxxxx		Security Implications of IPv6 Options of Type 10xxxxxx
	draft-gont-6man-ipv6-smurf-amplifier-02		draft-gont-6man-ipv6-smurf-amplifier-03
	Abstract		Abstract
	When an IPv6 node processing an IPv6 packet does not support an IPv6		When an IPv6 node processing an IPv6 packet does not support an IPv6
	option whose two-highest-order bits of the Option Type are '10', it		option whose two-highest-order bits of the Option Type are '10', it
	is required to respond with an ICMPv6 Parameter Problem error		is required to respond with an ICMPv6 Parameter Problem error
	message, even if the Destination Address of the packet was a		message, even if the Destination Address of the packet was a
	multicast address. This feature provides an amplification vector,		multicast address. This feature provides an amplification vector,
	opening the door to an IPv6 version of the 'Smurf' Denial-of-Service		opening the door to an IPv6 version of the 'Smurf' Denial-of-Service
	(DoS) attack found in IPv4 networks. This document discusses the		(DoS) attack found in IPv4 networks. This document discusses the
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	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 July 28, 2013.		This Internet-Draft will expire on September 22, 2013.
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Updating RFC 2460 and RFC 4443 . . . . . . . . . . . . . . . . 5		2. Updating RFC 2460 and RFC 4443 . . . . . . . . . . . . . . . . 5
	3. Operational mitigations . . . . . . . . . . . . . . . . . . . 6		3. Operational mitigations . . . . . . . . . . . . . . . . . . . 7
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 8		5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 10		7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
	7.2. Informative References . . . . . . . . . . . . . . . . . . 10		7.2. Informative References . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	IPv6 has eliminated most of the amplification vectors that were		IPv6 has eliminated most of the amplification vectors that were
	available in IPv4 to perform 'Smurf'-like Denial of Service (DoS)		available in IPv4 to perform 'Smurf'-like Denial of Service (DoS)
	attacks [CERT1998]. However, an amplification vector has been left		attacks [CERT1998]. However, an amplification vector has been left
	in the core IPv6 and ICMPv6 specifications ([RFC2460] and [RFC4443])		in the core IPv6 and ICMPv6 specifications ([RFC2460] and [RFC4443])
	that would allow for an IPv6 version of the 'Smurf' Denial-of-Service		that would allow for an IPv6 version of the 'Smurf' Denial-of-Service
	(DoS) attacks [CERT1998] [RFC6274] found in IPv4 networks. The		(DoS) attacks [CERT1998] [RFC6274] found in IPv4 networks. The
	aforementioned vector is based on the use of unsupported IPv6		aforementioned vector is based on the use of unsupported IPv6
	skipping to change at page 5, line 21 ¶		skipping to change at page 5, line 21 ¶
	The following text in Section 4.2 (page 9) of [RFC2460]:		The following text in Section 4.2 (page 9) of [RFC2460]:
	10 - discard the packet and, regardless of whether or not the		10 - discard the packet and, regardless of whether or not the
	packet's Destination Address was a multicast address, send an		packet's Destination Address was a multicast address, send an
	ICMP Parameter Problem, Code 2, message to the packet's		ICMP Parameter Problem, Code 2, message to the packet's
	Source Address, pointing to the unrecognized Option Type.		Source Address, pointing to the unrecognized Option Type.
	is replaced with:		is replaced with:
	10 - discard the packet and, only if the packet's Destination		10 - discard the packet and send an ICMP Parameter Problem, Code 2,
	Address was not a multicast address, send an ICMP Parameter		message to the packet's Source Address (pointing to the
	Problem, Code 2, message to the packet's Source Address,		unrecognized Option Type), only if (1) the packet's Destination
	pointing to the unrecognized Option Type.		Address was not a multicast address, or (2) the packet's
			Destination Address was a multicast address, but the node
			sending the Parameter Problem error message can assert that
			the Source Address of the packet eliciting the error message
			has not been forged.
	Additionally, the following text in Section 2.4 (page 6) of		Additionally, the following text in Section 2.4 (page 6) of
	[RFC4443]:		[RFC4443]:
	(e.3) A packet destined to an IPv6 multicast address. (There are		(e.3) A packet destined to an IPv6 multicast address. (There are
	two exceptions to this rule: (1) the Packet Too Big Message		two exceptions to this rule: (1) the Packet Too Big Message
	(Section 3.2) to allow Path MTU discovery to work for IPv6		(Section 3.2) to allow Path MTU discovery to work for IPv6
	multicast, and (2) the Parameter Problem Message, Code 2		multicast, and (2) the Parameter Problem Message, Code 2
	(Section 3.4) reporting an unrecognized IPv6 option (see		(Section 3.4) reporting an unrecognized IPv6 option (see
	Section 4.2 of [IPv6]) that has the Option Type highest-		Section 4.2 of [IPv6]) that has the Option Type highest-
	order two bits set to 10).		order two bits set to 10).
	is replaced with:		is replaced with:
	(e.3) A packet destined to an IPv6 multicast address. (There is		(e.3) A packet destined to an IPv6 multicast address. (There is
	one exception to this rule: the Packet Too Big Message		one exception to this rule: the Packet Too Big Message
	(Section 3.2) to allow Path MTU discovery to work for IPv6		(Section 3.2) to allow Path MTU discovery to work for IPv6
	multicast).		multicast).
			(e.3) A packet destined to an IPv6 multicast address. (There are
			two exceptions to this rule: (1) the Packet Too Big Message
			(Section 3.2) to allow Path MTU discovery to work for IPv6
			multicast, and (2) the Parameter Problem Message, Code 2
			(Section 3.4) reporting an unrecognized IPv6 option that has
			the Option Type highest-order two bits set to 10, *provided*
			the node sending the Parameter Problem message can assert
			that the Source Address of the packet eliciting the error
			message has not been forged.).
	3. Operational mitigations		3. Operational mitigations
	This section describes a number of operational mitigations that could		This section describes a number of operational mitigations that could
	be implemented for the aforementioned attack vector:		be implemented for the aforementioned attack vector:
	o Firstly, IPv6 nodes should limit their ICMPv6 traffic. This is a		o Firstly, IPv6 nodes should limit their ICMPv6 traffic. This is a
	general mitigation technique for any bandwidth-exhaustion attack		general mitigation technique for any bandwidth-exhaustion attack
	that relies on ICMPv6 traffic. This could be enforced at the		that relies on ICMPv6 traffic. This could be enforced at the
	hosts themselves, or at any router connecting such hosts to the		hosts themselves, or at any router connecting such hosts to the
	skipping to change at page 9, line 7 ¶		skipping to change at page 10, line 7 ¶
	This document describes how IPv6 options whose two-highest-order bits		This document describes how IPv6 options whose two-highest-order bits
	of the Option Type are '10' could be exploited to perform an IPv6		of the Option Type are '10' could be exploited to perform an IPv6
	version of the 'Smurf' Denial-of-Service (DoS) attack [CERT1998]		version of the 'Smurf' Denial-of-Service (DoS) attack [CERT1998]
	[RFC6274] found in IPv4 networks. It formally updates RFC 2460		[RFC6274] found in IPv4 networks. It formally updates RFC 2460
	[RFC2460] such that this attack vector is eliminated, and also		[RFC2460] such that this attack vector is eliminated, and also
	describes a number of operational mitigations that could be deployed		describes a number of operational mitigations that could be deployed
	against this attack vector.		against this attack vector.
	6. Acknowledgements		6. Acknowledgements
	The authors would like to thank (in alphabetical order) Joel Halpern,		The authors would like to thank (in alphabetical order) Francis
	Simon Perreault, and Ole Troan, for providing valuable comments on		Dupont, Joel Halpern, Suresh Krishnan, Simon Perreault, Dave Thaler,
	earlier versions of this document.		and Ole Troan, for providing valuable comments on earlier versions of
			this document.
	This document is based on the technical report "Security Assessment		This document is based on the technical report "Security Assessment
	of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6] authored by		of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6] authored by
	Fernando Gont on behalf of the UK Centre for the Protection of		Fernando Gont on behalf of the UK Centre for the Protection of
	National Infrastructure (CPNI).		National Infrastructure (CPNI).
	Fernando Gont would like to thank CPNI (http://www.cpni.gov.uk) for		Fernando Gont would like to thank CPNI (http://www.cpni.gov.uk) for
	their continued support.		their continued support.
	7. References		7. References
	skipping to change at page 11, line 17 ¶		skipping to change at page 12, line 17 ¶
	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
	Email: fgont@si6networks.com		Email: fgont@si6networks.com
	URI: http://www.si6networks.com		URI: http://www.si6networks.com
	Will Liu		Will (Shucheng) Liu
	Huawei Technologies		Huawei Technologies
	Bantian, Longgang District		Bantian, Longgang District
	Shenzhen 518129		Shenzhen 518129
	P.R. China		P.R. China
	Email: liushucheng@huawei.com		Email: liushucheng@huawei.com
End of changes. 8 change blocks.
	23 lines changed or deleted		38 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/