draft-ietf-ipv6-deprecate-rh0-01.txt		rfc5095.txt
	Network Working Group J. Abley		Network Working Group J. Abley
	Internet-Draft Afilias		Request for Comments: 5095 Afilias
	Updates: 2460, 4294 P. Savola		Updates: 2460, 4294 P. Savola
	(if approved) CSC/FUNET		Category: Standards Track CSC/FUNET
	Intended status: Standards Track G. Neville-Neil		G. Neville-Neil
	Expires: December 28, 2007 Neville-Neil Consulting		Neville-Neil Consulting
	June 26, 2007		December 2007
	Deprecation of Type 0 Routing Headers in IPv6		Deprecation of Type 0 Routing Headers in IPv6
	draft-ietf-ipv6-deprecate-rh0-01
	Status of this Memo		Status of This Memo
	By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-
	Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on December 28, 2007.
	Copyright Notice
	Copyright (C) The IETF Trust (2007).		This document specifies an Internet standards track protocol for the
			Internet community, and requests discussion and suggestions for
			improvements. Please refer to the current edition of the "Internet
			Official Protocol Standards" (STD 1) for the standardization state
			and status of this protocol. Distribution of this memo is unlimited.
	Abstract		Abstract
	The functionality provided by IPv6's Type 0 Routing Header can be		The functionality provided by IPv6's Type 0 Routing Header can be
	exploited in order to achieve traffic amplification over a remote		exploited in order to achieve traffic amplification over a remote
	path for the purposes of generating denial-of-service traffic. This		path for the purposes of generating denial-of-service traffic. This
	document updates the IPv6 specification to deprecate the use of IPv6		document updates the IPv6 specification to deprecate the use of IPv6
	Type 0 Routing Headers, in light of this security concern.		Type 0 Routing Headers, in light of this security concern.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Deprecation of RH0 . . . . . . . . . . . . . . . . . . . . . . 4		3. Deprecation of RH0 . . . . . . . . . . . . . . . . . . . . . . 3
	4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 4		4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4.1. Ingress Filtering . . . . . . . . . . . . . . . . . . . . . 4		4.1. Ingress Filtering . . . . . . . . . . . . . . . . . . . . . 3
	4.2. Firewall Policy . . . . . . . . . . . . . . . . . . . . . . 4		4.2. Firewall Policy . . . . . . . . . . . . . . . . . . . . . . 3
	5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5		5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
	7. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . . 5		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 5		8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
	8.2. Informative References . . . . . . . . . . . . . . . . . . 6		8.2. Informative References . . . . . . . . . . . . . . . . . . 5
	Appendix A. Change History . . . . . . . . . . . . . . . . . . . . 6
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
	Intellectual Property and Copyright Statements . . . . . . . . . . 9
	1. Introduction		1. Introduction
	[RFC2460] defines an IPv6 extension header called "Routing Header",		[RFC2460] defines an IPv6 extension header called "Routing Header",
	identified by a Next Header value of 43 in the immediately preceding		identified by a Next Header value of 43 in the immediately preceding
	header. A particular Routing Header subtype denoted as "Type 0" is		header. A particular Routing Header subtype denoted as "Type 0" is
	also defined. Type 0 Routing Headers are referred to as "RH0" in		also defined. Type 0 Routing Headers are referred to as "RH0" in
	this document.		this document.
	A single RH0 may contain multiple intermediate node addresses, and		A single RH0 may contain multiple intermediate node addresses, and
	the same address may be included more than once in the same RH0.		the same address may be included more than once in the same RH0.
	This allows a packet to be constructed such that it will oscillate		This allows a packet to be constructed such that it will oscillate
	between two RH0-processing hosts or routers many times. This allows		between two RH0-processing hosts or routers many times. This allows
	a stream of packets from an attacker to be amplified along the path		a stream of packets from an attacker to be amplified along the path
	between two remote routers, which could be used to cause congestion		between two remote routers, which could be used to cause congestion
	along arbitrary remote paths and hence act as a denial-of-service		along arbitrary remote paths and hence act as a denial-of-service
	mechanism. 88-fold amplification has been demonstrated using this		mechanism. An 88-fold amplification has been demonstrated using this
	technique [CanSecWest07].		technique [CanSecWest07].
	This attack is particularly serious in that it affects the entire		This attack is particularly serious in that it affects the entire
	path between the two exploited nodes, not only the nodes themselves		path between the two exploited nodes, not only the nodes themselves
	or their local networks. Analogous functionality may be found in the		or their local networks. Analogous functionality may be found in the
	IPv4 source route option, but the opportunities for abuse are greater		IPv4 source route option, but the opportunities for abuse are greater
	with RH0 due to the ability to specify many more intermediate node		with RH0 due to the ability to specify many more intermediate node
	addresses in each packet.		addresses in each packet.
	The severity of this threat is considered to be sufficient to warrant		The severity of this threat is considered to be sufficient to warrant
	deprecation of RH0 entirely. A side-effect is that this also		deprecation of RH0 entirely. A side effect is that this also
	eliminates benign RH0 use-cases; however, such applications may be		eliminates benign RH0 use-cases; however, such applications may be
	facilitated by future Routing Header specifications.		facilitated by future Routing Header specifications.
	Potential problems with RH0 were identified in 2001		Potential problems with RH0 were identified in 2001 [Security]. In
	[I-D.savola-ipv6-rh-ha-security]. In 2002 a proposal was made to		2002 a proposal was made to restrict Routing Header processing in
	restrict Routing Header processing in hosts		hosts [Hosts]. These efforts resulted in the modification of the
	[I-D.savola-ipv6-rh-hosts]. These efforts resulted in the		Mobile IPv6 specification to use the type 2 Routing Header instead of
	modification of the Mobile IPv6 specification to use the type 2		RH0 [RFC3775]. Vishwas Manral identified various risks associated
	Routing Header instead of RH0 [RFC3775]. Vishwas Manral identified		with RH0 in 2006 including the amplification attack; several of these
	various risks associated with RH0 in 2006 including the amplification		vulnerabilities (together with other issues) were later documented in
	attack; several of these vulnerabilities (together with other issues)		[RFC4942].
	were later documented in [I-D.ietf-v6ops-security-overview].
	A treatment of the operational security implications of RH0 was		A treatment of the operational security implications of RH0 was
	presented by Philippe Biondi and Arnaud Ebalard at the CanSecWest		presented by Philippe Biondi and Arnaud Ebalard at the CanSecWest
	conference in Vancouver, 2007 [CanSecWest07]. This presentation		conference in Vancouver, 2007 [CanSecWest07]. This presentation
	resulted in widespread publicity for the risks associated with RH0.		resulted in widespread publicity for the risks associated with RH0.
	This document updates [RFC2460] and [RFC4294].		This document updates [RFC2460] and [RFC4294].
	2. Definitions		2. Definitions
	RH0 in this document denotes the IPv6 Extension Header type 43		RH0 in this document denotes the IPv6 Extension Header type 43
	("Routing Header") variant 0 ("Type 0 Routing Header"), as defined in		("Routing Header") variant 0 ("Type 0 Routing Header"), as defined in
	[RFC2460].		[RFC2460].
	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 [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. Deprecation of RH0		3. Deprecation of RH0
	IPv6 nodes MUST NOT process RH0 in packets whose destination address		An IPv6 node that receives a packet with a destination address
	in the IPv6 header is an address assigned to them. Such packets MUST		assigned to it and that contains an RH0 extension header MUST NOT
	be processed according to the behaviour specified in Section 4.4 of		execute the algorithm specified in the latter part of Section 4.4 of
	[RFC2460] for a datagram which includes an unrecognised Routing Type		[RFC2460] for RH0. Instead, such packets MUST be processed according
	value, namely:		to the behaviour specified in Section 4.4 of [RFC2460] for a datagram
			that includes an unrecognised Routing Type value, namely:
	If Segments Left is zero, the node must ignore the Routing header		If Segments Left is zero, the node must ignore the Routing header
	and proceed to process the next header in the packet, whose type		and proceed to process the next header in the packet, whose type
	is identified by the Next Header field in the Routing header.		is identified by the Next Header field in the Routing header.
	If Segments Left is non-zero, the node must discard the packet and		If Segments Left is non-zero, the node must discard the packet and
	send an ICMP Parameter Problem, Code 0, message to the packet's		send an ICMP Parameter Problem, Code 0, message to the packet's
	Source Address, pointing to the unrecognised Routing Type.		Source Address, pointing to the unrecognized Routing Type.
	IPv6 implementations are no longer required to implement RH0 in any		IPv6 implementations are no longer required to implement RH0 in any
	way.		way.
	4. Operations		4. Operations
	4.1. Ingress Filtering		4.1. Ingress Filtering
	It is to be expected that it will take some time before all IPv6		It is to be expected that it will take some time before all IPv6
	nodes are updated to remove support for RH0. Some of the uses of RH0		nodes are updated to remove support for RH0. Some of the uses of RH0
	described in [CanSecWest07] can be mitigated using ingress filtering,		described in [CanSecWest07] can be mitigated using ingress filtering,
	as recommended in [RFC2827] and [RFC3704].		as recommended in [RFC2827] and [RFC3704].
	A site security policy intended to protect against attacks using RH0		A site security policy intended to protect against attacks using RH0
	SHOULD include the implementation of ingress filtering at the site		SHOULD include the implementation of ingress filtering at the site
	border.		border.
	4.2. Firewall Policy		4.2. Firewall Policy
	Blocking all IPv6 packets which carry Routing Headers (rather than		Blocking all IPv6 packets that carry Routing Headers (rather than
	specifically blocking type 0, and permitting other types) has very		specifically blocking Type 0 and permitting other types) has very
	serious implications for the future development of IPv6. If even a		serious implications for the future development of IPv6. If even a
	small percentage of deployed firewalls block other types of routing		small percentage of deployed firewalls block other types of Routing
	headers by default, it will become impossible in practice to extend		Headers by default, it will become impossible in practice to extend
	IPv6 routing headers. For example, Mobile IPv6 [RFC3775] relies upon		IPv6 Routing Headers. For example, Mobile IPv6 [RFC3775] relies upon
	a type-2 RH; wide-scale, indescriminate blocking of Routing Headers		a Type 2 Routing Header; wide-scale, indiscriminate blocking of
	will make Mobile IPv6 undeployable.		Routing Headers will make Mobile IPv6 undeployable.
	Firewall policy intended to protect against packets containing RH0		Firewall policy intended to protect against packets containing RH0
	MUST NOT simply filter all traffic with a routing header; it must be		MUST NOT simply filter all traffic with a Routing Header; it must be
	possible to disable forwarding of type 0 traffic without blocking		possible to disable forwarding of Type 0 traffic without blocking
	other types of routing headers. In addition, the default		other types of Routing Headers. In addition, the default
	configuration MUST permit forwarding of traffic using a RH other than		configuration MUST permit forwarding of traffic using a Routing
	0.		Header other than 0.
	5. Security Considerations		5. Security Considerations
	The purpose of this document is to deprecate a feature of IPv6 which		The purpose of this document is to deprecate a feature of IPv6 that
	has been shown to have undesirable security implications. Specific		has been shown to have undesirable security implications. Specific
	examples of vulnerabilities which are facilitated by the availability		examples of vulnerabilities that are facilitated by the availability
	of RH0 can be found in [CanSecWest07]. In particular, RH0 provides a		of RH0 can be found in [CanSecWest07]. In particular, RH0 provides a
	mechanism for traffic amplification, which might be used as a denial-		mechanism for traffic amplification, which might be used as a denial-
	of-service attack. A description of this functionality can be found		of-service attack. A description of this functionality can be found
	in Section 1.		in Section 1.
	6. IANA Considerations		6. IANA Considerations
	The IANA registry "Internet Protocol Version 6 (IPv6) Parameters"		The IANA registry "Internet Protocol Version 6 (IPv6) Parameters"
	should be updated to reflect that variant 0 of IPv6 header-type 43		should be updated to reflect that variant 0 of IPv6 header-type 43
	("Routing Header") is deprecated.		("Routing Header") is deprecated.
	7. Acknowlegements		7. Acknowledgements
	This document benefits from the contributions of many IPV6 and V6OPS		This document benefits from the contributions of many IPV6 and V6OPS
	working group participants, including Jari Arkko, Arnaud Ebalard, Tim		working group participants, including Jari Arkko, Arnaud Ebalard, Tim
	Enos, Brian Haberman, Jun-ichiro itojun HAGINO, Bob Hinden, Thomas		Enos, Brian Haberman, Jun-ichiro itojun Hagino, Bob Hinden, Thomas
	Narten, JINMEI Tatuya, David Malone, Jeroen Massar, Dave Thaler and		Narten, Jinmei Tatuya, David Malone, Jeroen Massar, Dave Thaler, and
	Guillaume Valadon.		Guillaume Valadon.
	8. References		8. References
	8.1. Normative References		8.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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC2460] Deering, S. and R. Hinden, "Internet Protocol,
	(IPv6) Specification", RFC 2460, December 1998.		Version 6 (IPv6) Specification", RFC 2460,
			December 1998.
	[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294,		[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294,
	April 2006.		April 2006.
	8.2. Informative References		8.2. Informative References
	[CanSecWest07]		[CanSecWest07] Biondi, P. and A. Ebalard, "IPv6 Routing Header
	BIONDI, P. and A. EBALARD, "IPv6 Routing Header Security",		Security", CanSecWest Security Conference 2007,
	CanSecWest Security Conference 2007, April 2007.		April 2007.
	http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf		http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf
	[I-D.ietf-v6ops-security-overview]		[Hosts] Savola, P., "Note about Routing Header Processing on
	Davies, E., "IPv6 Transition/Co-existence Security		IPv6 Hosts", Work in Progress, February 2002.
	Considerations", draft-ietf-v6ops-security-overview-06
	(work in progress), October 2006.
	[I-D.savola-ipv6-rh-ha-security]
	Savola, P., "Security of IPv6 Routing Header and Home
	Address Options", draft-savola-ipv6-rh-ha-security-02
	(work in progress), March 2002.
	[I-D.savola-ipv6-rh-hosts]
	Savola, P., "Note about Routing Header Processing on IPv6
	Hosts", draft-savola-ipv6-rh-hosts-00 (work in progress),
	February 2002.
	[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
	Defeating Denial of Service Attacks which employ IP Source
	Address Spoofing", BCP 38, RFC 2827, May 2000.
	[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
	Networks", BCP 84, RFC 3704, March 2004.
	[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
	in IPv6", RFC 3775, June 2004.
	Appendix A. Change History
	This section to be removed prior to publication.
	00 Strawman, draft-jabley-ipv6-rh0-is-evil, circulated to provoke
	discussion.
	01 Clarified Section 3; presented more options in Section 4; added
	Pekka and George as authors. This document version was not widely
	circulated.
	00 Renamed, draft-ietf-ipv6-deprecate-rh0, a candidate working group		[RFC2827] Ferguson, P. and D. Senie, "Network Ingress
	document.		Filtering: Defeating Denial of Service Attacks which
			employ IP Source Address Spoofing", BCP 38, RFC 2827,
			May 2000.
	01-candidate-00 Incorporated text summarising some of the unwelcome		[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for
	uses of RH0; added some clariying text describing deprecation;		Multihomed Networks", BCP 84, RFC 3704, March 2004.
	modified some ambiguous text in Section 4.2; added "Updates:
	4294".
	01-candidate-01 Incorporated contributions from working group:		[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility
	substantially reduced Section 5; clarified wording in Section 3.		Support in IPv6", RFC 3775, June 2004.
	01-candidate-02 Moved description of traffic amplification to		[RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6
	Section 1, and inserted a corresponding cross-reference in		Transition/Co-existence Security Considerations",
	Section 5. Strengthened the language in Section 4.2 along the		RFC 4942, September 2007.
	lines suggested by Thomas Narten. Small typos corrected. Added a
	further sentence in Section 4.1 intended to act as further
	encouragement for operators to implement [RFC3704].
	01 Minor wordsmithing; removed some subjective language; adopted		[Security] Savola, P., "Security of IPv6 Routing Header and Home
	"intermediate node" nomenclature instead of "waypoint"; shifted		Address Options", Work in Progress, March 2002.
	some history from Section 7 to Section 1.
	Authors' Addresses		Authors' Addresses
	Joe Abley		Joe Abley
	Afilias Canada Corp.		Afilias Canada Corp.
	Suite 204, 4141 Yonge Street		Suite 204, 4141 Yonge Street
	Toronto, ON M2P 2A8		Toronto, ON M2P 2A8
	Canada		Canada
	Phone: +1 416 673 4176		Phone: +1 416 673 4176
	Email: jabley@ca.afilias.info		EMail: jabley@ca.afilias.info
	Pekka Savola		Pekka Savola
	CSC/FUNET		CSC/FUNET
	Espoo,		Espoo,
	Finland		Finland
	Email: psavola@funet.fi		EMail: psavola@funet.fi
	George Neville-Neil		George Neville-Neil
	Neville-Neil Consulting		Neville-Neil Consulting
	2261 Market St. #239		2261 Market St. #239
	San Francisco, CA 94114		San Francisco, CA 94114
	USA		USA
	Email: gnn@neville-neil.com		EMail: gnn@neville-neil.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	skipping to change at page 9, line 44		skipping to change at line 281
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 31 change blocks.
	141 lines changed or deleted		80 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/